Re: Idiom question

2016-09-30 Thread Alan Thompson
The idea of the `it->` operator in the Tupelo library is basically just a combination of the explicitness of swiss arrows and the pronoun `it` from Groovy. Alan On Fri, Sep 30, 2016 at 2:00 PM, Stephen Spalding wrote: > The semantic o

Re: Idiom question

2016-09-30 Thread Stephen Spalding
The semantic of the swiss-arrows -<> macro are nice. It's like as-> except that the operator is automatically specified as <>, and it has a default position. Your original example would become: (-<> blah (do-this) (do-that arg) (do-the-oth

Re: Idiom question

2016-09-28 Thread paul
All very interesting, and Sean that first/or threading pattern is very helpful. @puzzler - totally get that the language is extensible yup and appreciate the mainstream warning. When I read your cond-better version I got it; and I also thought "a return statement like thing could be useful in a

Re: Idiom question

2016-09-28 Thread Sean Corfield
Ooops, should be: (defn has-transmitters [^MidiDevice device] (<= 0 (.getMaxTransmitters device))) And if we made a helper for open-device, we could make it return the now-open device and then you wouldn’t need the doto – just call (open-device). Sean Corfield -- (970) FOR-SEAN

Re: Idiom question

2016-09-28 Thread Sean Corfield
And for comparison, here’s a threaded version that uses -> (with ->> embedded, and doto): (-> (MidiSystem/getMidiDeviceInfo) (->> (filter #(= (.getName ^MidiDevice$Info %) name)) (map #(MidiSystem/getMidiDevice ^MidDevice$Info %)) (filter #(>= (.getMaxTransmitters ^M

Re: Idiom question

2016-09-28 Thread Mark Engelberg
Right, and just to take this one step farther, imagine that instead of throwing an error, you wanted to actually return a value. And imagine that your call to MidiSystem/getMidiDeviceInfo might return nil as well, and this is something that needs to be protected against and a value returned accord

Re: Idiom question

2016-09-28 Thread Josh Tilles
By the way, the order of arguments of as-> makes more sense when it’s used *within* one of the other threading macros. For example: (-> x foo (bar y) (baz w z) (as-> mid-x (log/debug "The intermediate value:" mid-x) (if (color-requested? mid-x) (assoc mid-x :color "periwinkle

Re: Idiom question

2016-09-28 Thread paul
This is a super interesting thread. Thank you all for your input I think you are right, @puzzler, that for my case a let may be better. The original code is above. Using as-> it looks like this (using 'it' as the name) (as-> (MidiSystem/getMidiDeviceInfo) it (filter #(= (.getName ^MidiDe

Re: Idiom question

2016-09-28 Thread Mark Engelberg
A common convention with as-> is to use the symbol $ because it is recognized as a Clojure identifier but looks distinctive, so it stands out as the placeholder of where to thread. Personally, when reading code, I don't really like to see long uses of the threading operator, and I'd argue that if

Re: Idiom question

2016-09-28 Thread paul
Wow yes that's exactly the -%> macro I imagined just with "%" replaced with "it". And it exists! Plus I just converted my fragment to use as-> and thought "aren't the first two arguments backwards (vs, say, "let"); and what name should I use (I chose 's')". Thank you. Reading the tupelo docs n

Re: Idiom question

2016-09-28 Thread Alan Thompson
Hi Paul, Since you are interested in the threading macros, you might like to take a look at one of my favorite variants from the Tupelo library : Literate Threading Macro We all love to use the threading macros -> and ->> for certain t

Re: Idiom question

2016-09-28 Thread Colin Yates
Welcome to one of the best things about Clojure - the community. However, if anyone starts using the phrase 'Clojurian' then it is time to leave :-). On Wed, 28 Sep 2016, at 07:17 PM, p...@pwjw.com wrote: > Wow thank you all for the really useful responses. How great. I > appreciate the time. >

Re: Idiom question

2016-09-28 Thread paul
Wow thank you all for the really useful responses. How great. I appreciate the time. as-> cleans up a couple of ugly bits of my code already, yes. And I'm sort of irritated with myself for not thinking of _ (if (throw)) in my let but yes that's a perfect idiom. I totally get the minimalist ap

Re: Idiom question

2016-09-28 Thread Sean Corfield
Welcome to Clojure! As others have noted, there are quite a few threading macros so your example could become: (-> blah (do-this) (->> (do-that arg)) (as-> s (do-the-other a1 s a2))) Or: (-> (->> blah (do-this)

Re: Idiom question

2016-09-28 Thread Stuart Sierra
I will answer the clojure.test question, since I wrote it. You can call clojure.test/is with *any* Clojure expression: if the expression returns logical true, the assertion passes. Having just the one expression keeps the scope of the testing library small. The `clojure.test/is` macro was desig

Re: Idiom question

2016-09-28 Thread Colin Yates
You might want to checkout 'cond->', 'condp' and 'as->'. Checkout the excellent clojuredocs.org website for examples of their usage (https://clojuredocs.org/clojure.core/condp for example). Sorry to be so succinct - deadlines etc. On Wed, 28 Sep 2016, at 03:26 PM, p...@pwjw.com wrote: > Hi. > > I

Re: Idiom question

2016-09-28 Thread Alex Miller
Hi Paul, there is a rich history of people extending the thread macros. For things in core, check out some of the other threading operators: as->, cond->, some-> etc as they handle more of your cases below. This is a good overview of what they do: http://clojure.org/guides/threading_macros Add

Re: idiom question: infinite sequence as data source for many threads?

2010-02-01 Thread free_variation
Urp yes thanks! Remainder of a previous version of the function. jds On Feb 1, 3:57 pm, Daniel Werner wrote: > On Jan 30, 7:07 am, free_variation wrote: > > > (defn init-features [stream] > >         (let [feature-stream (ref stream)] > >                 (dosync (ref-set feature-stream stream)

Re: idiom question: infinite sequence as data source for many threads?

2010-02-01 Thread Daniel Werner
On Jan 30, 7:07 am, free_variation wrote: > (defn init-features [stream] > (let [feature-stream (ref stream)] > (dosync (ref-set feature-stream stream)) The call to ref-set seems redundant here since you already initialize the ref with stream as its value. -- You receive

Re: idiom question: infinite sequence as data source for many threads?

2010-02-01 Thread Daniel Werner
On Jan 30, 8:09 am, Timothy Pratley wrote: > Below I present 'submit-future' which is similar to the existing > 'future' call in that it spawns a thread to execute a task, but > differs in that it will block if n submitted futures are already > running, where n is the number of available processor

Re: idiom question: infinite sequence as data source for many threads?

2010-01-31 Thread Timothy Pratley
On 1 February 2010 15:21, free_variation wrote: > Mind if I use it? Of course I don't mind. It is intended for your use. :) Regards, Tim. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.co

Re: idiom question: infinite sequence as data source for many threads?

2010-01-31 Thread free_variation
Excellent, very nice. Mind if I use it? jds On Jan 30, 2:09 am, Timothy Pratley wrote: > Below I present 'submit-future' which is similar to the existing > 'future' call in that it spawns a thread to execute a task, but > differs in that it will block if n submitted futures are already > runnin

Re: idiom question: infinite sequence as data source for many threads?

2010-01-29 Thread Timothy Pratley
Below I present 'submit-future' which is similar to the existing 'future' call in that it spawns a thread to execute a task, but differs in that it will block if n submitted futures are already running, where n is the number of available processors. I think this could be quite handy for the produce

Re: idiom question: infinite sequence as data source for many threads?

2010-01-29 Thread free_variation
Thank you Meikel, I was aware of the nil issue but it's good that you made that explicit. I got rid of the 'symbol per your suggestion, and factored the closure to take the stream as an input: (defn init-features [stream] (let [feature-stream (ref stream)] (dosync (ref-set

Re: idiom question: infinite sequence as data source for many threads?

2010-01-29 Thread cburroughs
java.util.concurrent.LinkedBlockingQueue Check out the put() method. That what I used for a program similar to the original poster when I needed control over the number of threads. On Jan 28, 7:15 pm, Paul Mooser wrote: > This is something I run into with executors in Java periodically - I > h

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Michael Wood
On 28 January 2010 23:30, Timothy Pratley wrote: > 2010/1/29 Michael Wood : >>> (doseq [d data-seq] >>>  (.submit clojure.lang.Agent/pooledExecutor (cast Callable #(foo d >> >> What's the purpose of the cast here? >> >> #(...) is an fn, which is Callable by definition, isn't it?  So >> wouldn'

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Meikel Brandmeyer
Hi, On Jan 29, 5:05 am, free_variation wrote: > You people are terrific, thanks so much. > > I basically went with what Michal and Konrad worked out: > > (let [feature-stream (ref nil)] >         (defn init-features [stream] >                 (dosync (ref-set feature-stream stream)) >          

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread free_variation
You people are terrific, thanks so much. I basically went with what Michal and Konrad worked out: (let [feature-stream (ref nil)] (defn init-features [stream] (dosync (ref-set feature-stream stream)) 'ready) (defn get-feature [] (dos

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Paul Mooser
This is something I run into with executors in Java periodically - I have never understood why there isn't a default implementation provided which has a blocking queue for tasks which will block on submission to the queue if it is full. If I'm not mistaken, the default ones which use bounded blocki

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Timothy Pratley
2010/1/29 Michael Wood : >> (doseq [d data-seq] >>  (.submit clojure.lang.Agent/pooledExecutor (cast Callable #(foo d > > What's the purpose of the cast here? > > #(...) is an fn, which is Callable by definition, isn't it?  So > wouldn't that line be equivalent to: > (.submit clojure.lang.Agent

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Michael Wood
Hi On 28 January 2010 16:53, Timothy Pratley wrote: [...] > eg: if you had a file which you read as a lazy sequence you could > create worker tasks like this: > (doseq [d data-seq] >  (.submit clojure.lang.Agent/pooledExecutor (cast Callable #(foo d What's the purpose of the cast here? #(..

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Timothy Pratley
2010/1/28 free_variation : > I have an infinite sequence.  I'd like to have the sequence be a > source for N parallel worker threads that now and then will show up to > grab a few elements from the sequence, then go off and crunch on the > data.  The sequence should be traversed only once per execu

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Meikel Brandmeyer
Hi, On Jan 28, 5:21 am, free_variation wrote: > Is the solution to have my-seq somehow > refer to the next element to be retrieved, i.e. to the head of the > infinite sequence that has yet to be fed to the workers? You probably want a Ref here to coordinate the changes on the sequence. (defn g

Re: idiom question: infinite sequence as data source for many threads?

2010-01-28 Thread Christophe Grand
Hi! On Thu, Jan 28, 2010 at 8:39 AM, Michał Marczyk wrote: > 2010/1/28 Konrad Hinsen : >> The Clojure solution for your problem is an agent, which makes the access >> thread-safe: >> >> user> (def data-source (agent (cycle [1 2 3]))) >> #'user/data-source >> user> (defn get-some-data [] (let [v (

Re: idiom question: infinite sequence as data source for many threads?

2010-01-27 Thread Konrad Hinsen
On 28 Jan 2010, at 08:39, Michał Marczyk wrote: Wouldn't this make it possible for two threads to obtain the same value of (first @data-source), then send two rest messages to the agent? A ref would not have this problem, though: You are right. Refs provide synchronous access to the data sour

Re: idiom question: infinite sequence as data source for many threads?

2010-01-27 Thread Michał Marczyk
2010/1/28 Konrad Hinsen : > The Clojure solution for your problem is an agent, which makes the access > thread-safe: > > user> (def data-source (agent (cycle [1 2 3]))) > #'user/data-source > user> (defn get-some-data [] (let [v (first @data-source)] (send data-source > rest) v)) Wouldn't this mak

Re: idiom question: infinite sequence as data source for many threads?

2010-01-27 Thread Konrad Hinsen
On 28 Jan 2010, at 05:21, free_variation wrote: I'm not clear on how to implement this without keeping a reference to the sequence, say in a closure. In scheme I might solve the problem using a continuation. But in clojure if I do, say: (let [my-seq (lazy-seq ...)] (defn get-some-data