Re: Seeking critique of "pattern" in clojure.spec (LONG)

Here it is adapted to use a deftype: https://gist.github.com/didibus/2ccd608ed9d226039f944b02a10f9ad5 I gather from your solution that "orchestra" is not needed to spec :ret > types? > It is not. The return spec will be used during st/check. If you want the return spec to be validated outside

Re: Seeking critique of "pattern" in clojure.spec (LONG)

Wow... that's a comprehensive solution, Didier :) Bravo! It's a good lesson for s/fdef, which I haven't yet studied. I gather from your solution that "orchestra" is not needed to spec :ret types? As to semantics, on the one hand, I can spec ::virtual-time as a light overlay over Double and

[QUIL] select-input and select-output?

hello, i'm looking for the Quil equivalents of Processing selectInput() and selectOutput() but i can't find them if they're not there, what would be the best way to directly access the corresponding Processing methods instead? or is there a different more convenient way to get the same

Re: Seeking critique of "pattern" in clojure.spec (LONG)

Using the preset infinity constants is probably the best solution in this case. :) - James On 11 April 2017 at 01:50, Brian Beckman wrote: > James -- just the kind of simplification I was looking for! In fact, I > think the following will do everything I need --- generate

Re: Seeking critique of "pattern" in clojure.spec (LONG)

I agree with James, here's what I'd do: https://gist.github.com/didibus/d0228ffad9b920c201410806b157ff10 The only downside, and why you might still want to use types (probably with deftype), is to prevent people from using standard functions like <,>,= etc. If you deftyped virtual-time, it

Re: Seeking critique of "pattern" in clojure.spec (LONG)

James -- just the kind of simplification I was looking for! In fact, I think the following will do everything I need --- generate numbers avoiding only NaN (which isn't equal to itself, nor less than anything) (s/def ::virtual-time (s/with-gen (s/and number? #(not (Double/isNaN %)))

Re: Seeking critique of "pattern" in clojure.spec (LONG)

I think what you have is overly complex for what you want to do. Consider this alternative spec: (s/def ::virtual-time (s/or :number number?, :limit #{::infinity- ::infinity+})) Then we write a comparator: (defn compare-times [a b] (cond (= a b) 0 (= a ::infinity+) +1

Re: Derefs broken after clojure.tools.namespace.repl/refresh

You're reloading your namespaces from a non-repl thread, concurrently while editing code in the repl. I don't think this is use case is supported by tools.namespace. On Mon, Apr 10, 2017 at 2:56 PM, Didier wrote: > Hum, not sure why you would do this, but I'm guessing refresh

Re: Seeking critique of "pattern" in clojure.spec (LONG)

These are good comments that give me things to think about. I'm grateful. * The pattern concerned me because (1) it was just the first thing I came up with, so not sure there wasn't a better way staring me in the face (2) I didn't see any clearly better alternatives, so not sure whether I just

Derefs broken after clojure.tools.namespace.repl/refresh

Hum, not sure why you would do this, but I'm guessing refresh goes in an infinite async loop. You keep reloading a namespace which creates a thread to reload itself. I can't really explain why the symbol exists, but is not bound. I would have thought either the symbol would not exist, or the

Seeking critique of "pattern" in clojure.spec (LONG)

I think this pattern is fine. What specifically about it annoys you? You could do it without records, but then you wouldn't be creating a type. Do you really need a type? The advantage of types in Clojure are that they let you do polymorphic dispatch of them. So they are useful if you have

Re: Using transducers in a new transducing context

Thanks for clearing all of that up Alex! Very helpful. On Monday, April 10, 2017 at 3:46:45 PM UTC-4, Alex Miller wrote: > > > > On Monday, April 10, 2017 at 2:25:48 PM UTC-5, Alexander Gunnarson wrote: >> >> I think you present a key question: what assumptions can a transducer >> make? We know

Re: Using transducers in a new transducing context

On Monday, April 10, 2017 at 2:25:48 PM UTC-5, Alexander Gunnarson wrote: > > I think you present a key question: what assumptions can a transducer > make? We know the standard ones, but what of memory barriers? > Transducers should ensure stateful changes guarantee visibility. That is: you

Re: Using transducers in a new transducing context

On Monday, April 10, 2017 at 1:57:10 PM UTC-5, Léo Noel wrote: > > What you said holds for reduction but not necessarily a parallel fold (see >> clojure.core.reducers/fold). >> > > Exactly, and that's why stateful transducers are explicitly forbidden in > fold and in core.async pipeline

Re: Using transducers in a new transducing context

I think you present a key question: what assumptions can a transducer make? We know the standard ones, but what of memory barriers? Based on the current implementation, in terms of concurrency, it seems to make (inconsistent — see also `partition-by`) guarantees that sequential writes and

Re: Using transducers in a new transducing context

> > What you said holds for reduction but not necessarily a parallel fold (see > clojure.core.reducers/fold). > Exactly, and that's why stateful transducers are explicitly forbidden in fold and in core.async pipeline functions. This is not related to memory visibility, this is due to the fact

Re: Using transducers in a new transducing context

Yes, that makes sense that you can't make that assumption. You'd have to create something like what I was discussing above: (defn map-indexed-transducer-base [f box-mutable inc-mutable] (fn [rf] (let [i (box-mutable -1)] (fn ([] (rf)) ([result] (rf result))

Re: Using transducers in a new transducing context

On Monday, April 10, 2017 at 11:48:41 AM UTC-5, Alexander Gunnarson wrote: > > Léo, I definitely agree that you can use unsynchronized mutable stateful > transducers *as long as you can guarantee they'll be used only in > single-threaded contexts. * > Transducers included in core cannot make

Re: Using transducers in a new transducing context

The problem is at a lower level. The memory model of the JVM doesn't guarantee that changes to an unsynchronized non-volatile reference are visible to other threads. Transducers don't have to worry about concurrency but they do have to worry about visibility of changes across different threads.

Re: Using transducers in a new transducing context

Léo, I definitely agree that you can use unsynchronized mutable stateful transducers *as long as you can guarantee they'll be used only in single-threaded contexts. *We were talking up above on which version of synchronization is appropriate for which context. With core.async, if you're using

Re: Using transducers in a new transducing context

> > On Monday, April 10, 2017 at 12:39:37 PM UTC-4, Alex Miller wrote: Oh, you still need r/folder, sorry! Something like: > > (r/fold + (r/folder v (map inc))) > Ah, okay, glad to know I wasn't going crazy :) Thanks! On Monday, April 10, 2017 at 12:39:37 PM UTC-4, Alex Miller wrote: > > > >

Re: Using transducers in a new transducing context

On Sunday, April 9, 2017 at 9:44:00 PM UTC-5, Alexander Gunnarson wrote: > > > As an aside about the stateful `take` transducer, Tesser uses the > equivalent of one but skirts the issue by not guaranteeing that the first n > items of the collection will be returned, but rather, n items of the

Seeking critique of "pattern" in clojure.spec (LONG)

"I apologize for the length of this post ..." Blaise Pascal? I am seeking critique of a certain "programming pattern" that's arisen several times in a project. I want testable types satisfying a protocol, but the pattern I developed "feels" heavyweight, as the example will show, but I don't

Re: Using transducers in a new transducing context

I don't agree with your conclusions. :) A transducing process could apply each step of the transduce using a thread from a pool and also not use a memory barrier - in that scenario visibility across threads would not be ensured. These kinds of failures are inherently difficult to reproduce

Derefs broken after clojure.tools.namespace.repl/refresh

What happens here? > (send-off (agent {}) (fn [_] (clojure.tools.namespace.repl/refresh))) > @(atom {}) => {} > (def s (atom {})) => #'user/s > s => #object[clojure.lang.Atom 0x5f6a0fab {:status :ready, :val {}}] > @s => ClassCastException clojure.lang.Var$Unbound cannot be cast

Re: Using transducers in a new transducing context

What you said holds for reduction but not necessarily a parallel fold (see clojure.core.reducers/fold). On Monday, April 10, 2017 at 9:37:29 AM UTC-4, Léo Noel wrote: > > This topic is of high interest to me as it is at the core of my current > works. I had a similar questioning a while ago >

Re: Using transducers in a new transducing context

This topic is of high interest to me as it is at the core of my current works. I had a similar questioning a while ago and I have to say I'm even more confused with this : While transducing processes may provide locking to cover the