Transducers: sequence versus eduction
Hi all, I've switched many nested filter/map/mapcat applications in my code to using transducers. That brought a moderate speedup in certain cases and the deeper the nesting has been before, the clearer the transducers code is in comparison, so yay! :-) However, I'm still quite unsure about the difference between `sequence` and `eduction`. From the docs and experimentation, I came to the assumptions below and I'd be grateful if someone with more knowledge could verify/falsify/add: - Return types differ: Sequence returns a standard lazy seq, eductions an instance of Eduction. - Eductions are reducible/sequable/iterable, i.e., basically I can use them wherever a (lazy) seq would also do, so sequence and eduction are quite interchangeable except when poking at internals, e.g., (.contains (sequence ...) x) works whereas (.contains (eduction ...) x) doesn't. - Both compute their contents lazily. - Lazy seqs cache their already realized contents, eductions compute them over and over again on each iteration. Because of that, I came to the conclusion that whenever I ask myself if one of my functions should return a lazy seq or an eduction, I should use these rules: 1. If the function is likely to be used like (let [xs (seq-producing-fn args)] (or (do-stuff-with xs) (do-other-stuff-with xs) ...)) that is, the resulting seq is likely to be bound to a variable which is then used multiple times (and thus lazy seq caching is benefitical), then use sequence. 2. If it is a private function only used internally and never with the usage pattern of point 1, then definitively use eduction. 3. If its a public function which usually isn't used with a pattern as in point 1, then I'm unsure. eduction is probably more efficient but sequence fits better in the original almost everything returns a lazy seq design. Also, the latter has the benefit that users of the library don't need to know anything about transducers. Is that sensible? Or am I completely wrong with my assumptions about sequence and eduction? On a related note, could someone please clarify the statement from the transducers docs for `sequence`? ,[ Docs of sequence at http://clojure.org/transducers ] | The resulting sequence elements are incrementally computed. These | sequences will consume input incrementally as needed and fully realize | intermediate operations. This behavior differs from the equivalent | operations on lazy sequences. ` I'm curious about the "fully realize intermediate operations" part. Does it mean that in a "traditional" (mapcat #(range %) (range 1)) the inner range is also evaluated lazy but with (sequence (mapcat #(range %)) (range 1)) it is not? It seems so. At least dorun-ning these two expressions shows that the "traditional" version is more than twice as fast than the transducer version. Also, the same seems to hold for (eduction (mapcat #(range %)) (range 1)) which is exactly as fast (or rather slow) as the sequence version. But wouldn't that mean that transducers with mapcat where the mapcatted function isn't super-cheap is a bad idea in general at least from a performance POV? Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Transducers: sequence versus eduction
Eduction retains the ability to be recomposed with other transducers higher in the function chain. The following two are nearly equivalent: (transduce (take 1e2) + (eduction (filter odd?) (range))) (transduce (comp (filter odd?) (take 1e2)) + (range)) This will be slower: (transduce (take 1e2) + (sequence (filter odd?) (range))) Execution time mean : 19.054407 µs Execution time mean : 19.530890 µs Execution time mean : 39.955692 µs I also wonder to what extent eduction can be used as a drop in replacement for sequence. On Wednesday, April 1, 2015 at 9:13:07 AM UTC+2, Tassilo Horn wrote: > > Hi all, > > I've switched many nested filter/map/mapcat applications in my code to > using transducers. That brought a moderate speedup in certain cases > and the deeper the nesting has been before, the clearer the transducers > code is in comparison, so yay! :-) > > However, I'm still quite unsure about the difference between `sequence` > and `eduction`. From the docs and experimentation, I came to the > assumptions below and I'd be grateful if someone with more knowledge > could verify/falsify/add: > > - Return types differ: Sequence returns a standard lazy seq, eductions > an instance of Eduction. > > - Eductions are reducible/sequable/iterable, i.e., basically I can use > them wherever a (lazy) seq would also do, so sequence and eduction > are quite interchangeable except when poking at internals, e.g., > (.contains (sequence ...) x) works whereas (.contains (eduction ...) > x) doesn't. > > - Both compute their contents lazily. > > - Lazy seqs cache their already realized contents, eductions compute > them over and over again on each iteration. > > Because of that, I came to the conclusion that whenever I ask myself if > one of my functions should return a lazy seq or an eduction, I should > use these rules: > > 1. If the function is likely to be used like > > (let [xs (seq-producing-fn args)] >(or (do-stuff-with xs) >(do-other-stuff-with xs) >...)) > > that is, the resulting seq is likely to be bound to a variable > which is then used multiple times (and thus lazy seq caching is > benefitical), then use sequence. > > 2. If it is a private function only used internally and never with the > usage pattern of point 1, then definitively use eduction. > > 3. If its a public function which usually isn't used with a pattern as > in point 1, then I'm unsure. eduction is probably more efficient > but sequence fits better in the original almost everything returns > a lazy seq design. Also, the latter has the benefit that users of > the library don't need to know anything about transducers. > > Is that sensible? Or am I completely wrong with my assumptions about > sequence and eduction? > > On a related note, could someone please clarify the statement from the > transducers docs for `sequence`? > > ,[ Docs of sequence at http://clojure.org/transducers ] > | The resulting sequence elements are incrementally computed. These > | sequences will consume input incrementally as needed and fully realize > | intermediate operations. This behavior differs from the equivalent > | operations on lazy sequences. > ` > > I'm curious about the "fully realize intermediate operations" part. > Does it mean that in a "traditional" > > (mapcat #(range %) (range 1)) > > the inner range is also evaluated lazy but with > > (sequence (mapcat #(range %)) (range 1)) > > it is not? It seems so. At least dorun-ning these two expressions > shows that the "traditional" version is more than twice as fast than the > transducer version. Also, the same seems to hold for > > (eduction (mapcat #(range %)) (range 1)) > > which is exactly as fast (or rather slow) as the sequence version. > > But wouldn't that mean that transducers with mapcat where the mapcatted > function isn't super-cheap is a bad idea in general at least from a > performance POV? > > Bye, > Tassilo > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Transducers: sequence versus eduction
vve...@gmail.com writes: > Eduction retains the ability to be recomposed with other transducers > higher in the function chain. The following two are nearly equivalent: > > (transduce (take 1e2) + (eduction (filter odd?) (range))) > (transduce (comp (filter odd?) (take 1e2)) + (range)) > > This will be slower: > (transduce (take 1e2) + (sequence (filter odd?) (range))) > > Execution time mean : 19.054407 µs > Execution time mean : 19.530890 µs > Execution time mean : 39.955692 µs Interesting. But in my code experimentation has shown that sequence is almost always faster in my use-cases which usually look like (sequence (comp (mapcat foo1) (filter p1) (map f1) (mapcat foo2) (filter p2) (mapcat foo3) (filter p3)) coll) Here, I've switched between making the foo* functions return eductions or lazy sequences, and the latter seems to alway be faster although that looks like a use-case of eduction based on my assumptions... So maybe eduction can unfold its full potential only during transduce? Bye, Tassilo -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
Sorry no offense intended, I have prelude, cider and Nrepl going right now. Actually I haven't usually gotten along with emacs but it is just working at the moment and um i like it. I am just changing flx-ido to vertical as it looks a little nicer but that's it really, the only change. On Monday, 30 March 2015 01:27:08 UTC+11, solussd wrote: > > Batsov, > > CIDER is the best Clojure IDE. ;) > > -- > @solussd > > > On Mar 29, 2015, at 9:14 AM, Bozhidar Batsov > wrote: > > And CIDER isn't, right? I find this pretty insulting... > > On 29 March 2015 at 13:47, Colin Yates > > wrote: > >> Cursive Clojure, LightTable and CounterClockwise are all good Clojure >> IDEs. >> >> On 29 March 2015 at 09:54, Sayth Renshaw > > wrote: >> > Hi >> > >> > I last learned clojure in 1.2. Just curious why Clojure hasn't >> developed as a go to for data science? >> > >> > It never seems to get a mention R,Python and now Julia get the >> attention. By design it would appear that Clojure would be a good fit. Is >> it a lack of libraries, ease of install, no good default environment (R >> Rstudio, IPython ) where as you would need to use emacs with clojure, or is >> there just a better default use of Clojure? >> > >> > Sayth >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Clojure" group. >> > To post to this group, send email to clo...@googlegroups.com >> >> > Note that posts from new members are moderated - please be patient with >> your first post. >> > To unsubscribe from this group, send email to >> > clojure+u...@googlegroups.com >> > For more options, visit this group at >> > http://groups.google.com/group/clojure?hl=en >> > --- >> > You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an email to clojure+u...@googlegroups.com . >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
I saw all the changes to incanter. lot of breaking changes going into version 2 but they seem to reduce dependencies and going to core.matrix as you pointed out. There are a lot of things in clojure that I have found that I just haven't heard about need to clean some web data there are several great options hickory seems to stand out as an html parser and css selector based of jsoup https://github.com/davidsantiago/hickory . Gorilla is amazing why is this not heard? http://gorilla-repl.org/ Not data related but for graphics quil seems awesome https://github.com/quil/quil On Tuesday, 31 March 2015 23:36:11 UTC+11, Erebus Mons wrote: > > Joseph Guhlin wrote: > > > Incanter gets your pretty far, especially when combined with Gorilla > > REPL, but all the tools and features aren't quite there yet, but > progress > > is being made. > > Incanter is undergoing major change with the migration to core.matrix, and > a > break in the API. > > Has anybody of you tested incanter 1.9? > Are there plans for the release date of the stable 2.0? > > And how different is incanter 2.x from incanter 1.5x? > > In other words, if you were tempted to start data analysis in clojure now, > what would you do: > > a) take incanter 1.9 > b) take incanter 1.5.6 > c) wait a few more weeks/months for the release of incanter 2.0? > > Best, > > EM > > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
I haven't tested 1.9 or 2.0 yet, but I'm working with an existing project that depends in incanter and I don't think there is a return on investment for updating it at this time (only using a few features). If I was starting now, I would go with 1.9 for my data analysis. --Joseph On Tuesday, March 31, 2015 at 7:36:11 AM UTC-5, Erebus Mons wrote: > > Joseph Guhlin wrote: > > > Incanter gets your pretty far, especially when combined with Gorilla > > REPL, but all the tools and features aren't quite there yet, but > progress > > is being made. > > Incanter is undergoing major change with the migration to core.matrix, and > a > break in the API. > > Has anybody of you tested incanter 1.9? > Are there plans for the release date of the stable 2.0? > > And how different is incanter 2.x from incanter 1.5x? > > In other words, if you were tempted to start data analysis in clojure now, > what would you do: > > a) take incanter 1.9 > b) take incanter 1.5.6 > c) wait a few more weeks/months for the release of incanter 2.0? > > Best, > > EM > > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
I haven't been able to get quil working with gorilla repl yet, but I hope the support is there one day. --Joseph On Wednesday, April 1, 2015 at 5:37:05 AM UTC-5, Sayth Renshaw wrote: > > I saw all the changes to incanter. lot of breaking changes going into > version 2 but they seem to reduce dependencies and going to core.matrix as > you pointed out. > > There are a lot of things in clojure that I have found that I just > haven't heard about need to clean some web data there are several great > options hickory seems to stand out as an html parser and css selector based > of jsoup https://github.com/davidsantiago/hickory . > > Gorilla is amazing why is this not heard? http://gorilla-repl.org/ > > Not data related but for graphics quil seems awesome > https://github.com/quil/quil > > > > On Tuesday, 31 March 2015 23:36:11 UTC+11, Erebus Mons wrote: >> >> Joseph Guhlin wrote: >> >> > Incanter gets your pretty far, especially when combined with Gorilla >> > REPL, but all the tools and features aren't quite there yet, but >> progress >> > is being made. >> >> Incanter is undergoing major change with the migration to core.matrix, >> and a >> break in the API. >> >> Has anybody of you tested incanter 1.9? >> Are there plans for the release date of the stable 2.0? >> >> And how different is incanter 2.x from incanter 1.5x? >> >> In other words, if you were tempted to start data analysis in clojure >> now, >> what would you do: >> >> a) take incanter 1.9 >> b) take incanter 1.5.6 >> c) wait a few more weeks/months for the release of incanter 2.0? >> >> Best, >> >> EM >> >> >> >> -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Transducers: sequence versus eduction
First, I love this discussion! Great questions, great thinking. Up top, I wanted to mention a couple things that have changed in alpha6: - Eduction is no longer Seqable and thus the return from eduction is not seqable (but it is reducible and iterable). You can use iterator-seq to get a chunked seq over the top if you need one. - Prior to alpha6, sequence with transformations returned a LazyTransformer. That's gone and now transformations are done using TransformerIterator, which is subsequently wrapped with a (now chunked) iterator-seq. - There are lots of performance implications due to those changes and I would recommend re-testing any perf test related to sequence or eduction on alpha6 to get a fresh picture as anything pre-alpha6 is not comparable. - eduction now takes multiple transformations, not just one, and composes them. This is designed for mechanical rewriting (hello tool developers!!) of ->> chains like this: (->> s (interpose 5) (partition-all 2)) to this: (->> s (eduction (interpose 5) (partition-all 2))) That particular example has timings in CLJ-1669 and shows a reduction from 501 microseconds to 108 microseconds on a source vector, comparable savings on a source sequence. You do need to be careful to not include non-transducer functions in that chain, or stop the rewrite when you fall into a materialization function at the end (for example, sort). On Wednesday, April 1, 2015 at 2:13:07 AM UTC-5, Tassilo Horn wrote: > > Hi all, > > I've switched many nested filter/map/mapcat applications in my code to > using transducers. That brought a moderate speedup in certain cases > and the deeper the nesting has been before, the clearer the transducers > code is in comparison, so yay! :-) > Depending what you're transducing over, you may see some additional gains in alpha6. > However, I'm still quite unsure about the difference between `sequence` > and `eduction`. From the docs and experimentation, I came to the > assumptions below and I'd be grateful if someone with more knowledge > could verify/falsify/add: > > - Return types differ: Sequence returns a standard lazy seq, eductions > an instance of Eduction. > Yes, although I think the actual return type of eduction is not important, rather the implemented interfaces of Iterable and IReduceInit are the key thing. > - Eductions are reducible/sequable/iterable, i.e., basically I can use > no longer explicitly seqable, although seq will automatically wrap a chunked iterator-seq around it if passed to a sequence function. > them wherever a (lazy) seq would also do, so sequence and eduction > are quite interchangeable except when poking at internals, e.g., > (.contains (sequence ...) x) works whereas (.contains (eduction ...) > x) doesn't. > No guarantees made on those internals, only on what is promised in the docstrings (reducible/iterable for eduction and sequence for sequence). :) > - Both compute their contents lazily. > eduction is not lazy by itself. if used in a non-seq context, it is eagerly recomputed on each use. If you use it in a seq context, then it will be computed and cached as needed. > - Lazy seqs cache their already realized contents, eductions compute > them over and over again on each iteration. > Yes. > > Because of that, I came to the conclusion that whenever I ask myself if > one of my functions should return a lazy seq or an eduction, I should > use these rules: > > 1. If the function is likely to be used like > > (let [xs (seq-producing-fn args)] >(or (do-stuff-with xs) >(do-other-stuff-with xs) >...)) > > that is, the resulting seq is likely to be bound to a variable > which is then used multiple times (and thus lazy seq caching is > benefitical), then use sequence. > Yes, it makes sense to take advantage of seq caching this way. > 2. If it is a private function only used internally and never with the > usage pattern of point 1, then definitively use eduction. > 3. If its a public function which usually isn't used with a pattern as > in point 1, then I'm unsure. eduction is probably more efficient > but sequence fits better in the original almost everything returns > a lazy seq design. Also, the latter has the benefit that users of > the library don't need to know anything about transducers. > > Is that sensible? Or am I completely wrong with my assumptions about > sequence and eduction? > You're definitely on the right track. How the result is going to be used is pretty important - eduction is designed to be consumed entirely for a result and thus gives up the caching of sequences. If you are going to consume the entire thing once, particularly in the context of a reduction, then eduction is far more efficient. Eduction does not need to allocate or cache intermediate sequence objects, so is much more m
Re: Transducers: sequence versus eduction
The general idea is that eduction is best when the result will be completely consumed in a reducible context. Any case of reusing the result will likely be better served by sequence which can cache and reuse the answer. On Wednesday, April 1, 2015 at 3:51:53 AM UTC-5, Tassilo Horn wrote: > > vve...@gmail.com writes: > > > Eduction retains the ability to be recomposed with other transducers > > higher in the function chain. The following two are nearly equivalent: > > > > (transduce (take 1e2) + (eduction (filter odd?) (range))) > > (transduce (comp (filter odd?) (take 1e2)) + (range)) > > > > This will be slower: > > (transduce (take 1e2) + (sequence (filter odd?) (range))) > > > > Execution time mean : 19.054407 µs > > Execution time mean : 19.530890 µs > > Execution time mean : 39.955692 µs > > Interesting. But in my code experimentation has shown that sequence is > almost always faster in my use-cases which usually look like > > (sequence (comp (mapcat foo1) > (filter p1) > (map f1) > (mapcat foo2) > (filter p2) > (mapcat foo3) > (filter p3)) > coll) > > Here, I've switched between making the foo* functions return eductions > or lazy sequences, and the latter seems to alway be faster although that > looks like a use-case of eduction based on my assumptions... > > So maybe eduction can unfold its full potential only during transduce? > > Bye, > Tassilo > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
If this is a use case that could be lifted out into an API level function, that would be an ok enhancement jira request to consider (would need to think about it more, but that seems like one option). On Tuesday, March 31, 2015 at 6:12:09 PM UTC-5, puzzler wrote: > > The reason instaparse uses Clojure's string reader is to make sure that > strings inside the context-free grammar DSL are handled consistently with > Clojure's logic for interpreting strings. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
This patch is incredibly useful! Great job to everyone that contributed. One question: how do I enable conditional reading by default in the REPL as opposed to passing a properties map to /read-string/, etc.? Do I set certain system properties in the command line like "cond_read=true"? On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] > > Regression fixes from previous alphas (and one from 1.6): > > 1) CLJ-1544 was rolled back and will be investigated for a future release. > 2) CLJ-1637 fixed regression with vec on MapEntry > 3) CLJ-1663 fixed regression in classloader (affected Cursive) > 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) > method > 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for > literal nil arg > 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that > prevented update > > Some highlights new in alpha6: > > ## Transducer-related changes: > > The LazyTransformer introduced to create lazy transforming sequences has > been > replaced with a TransformingIterator. This was done to simplify the code > around transformations and to make certain use cases around eduction more > efficient. > > ## Faster reduce, iterator, and sequence paths > > A lot of work has been done across a set of tickets to improve the ability > of > collections to provide more efficient reduce or iterator performance, and > also to > make common sequence generators create faster sequence and reduce paths. > You > should see significant performance in many reduce-related paths (this > includes > reduce, transduce, into, and anything else built on reduce). > > Many of those changes also have beneficial sequence performance, so you > may see > some benefits even in code that does not use transducers. > > * Most uses of SeqIterator have now been replaced with iterators that > directly walk > the underlying source for improved efficiency. This includes maps, sets, > records, etc. > * repeat - now returns a faster sequence with a fast reduce path > * cycle - now returns a faster sequence with a fast reduce path > * iterate - now returns a faster sequence with a fast reduce path > * range - (did not quite make it in, but coming soon...) > * keys - iterates directly over the keys of a map, without seq or MapEntry > allocation > * vals - iterates directly over the vals of a map, without seq or MapEntry > allocation > * iterator-seq - now creates a chunked sequence when previously it was > unchunked > * vec and set - were not changed in this release but were set up in a > previous alpha > to take advantage of the reduce and iterator changes above > > ## Reader conditionals > > Reader Conditionals is a new capability to support portable code that > can run on multiple Clojure platforms with only small changes. In > particular, this feature aims to support the increasingly common case > of libraries targeting both Clojure and ClojureScript. > > Code intended to be common across multiple platforms should use a new > supported file extension: ".cljc". When requested to load a namespace, > the platform-specific file extension (.clj, .cljs) will be checked > prior to .cljc. > > A new reader form can be used to specify "reader conditional" code in > cljc files (and *only* cljc files). Each platform defines a feature > identifying the platform (:clj, :cljs, :cljr). The reader conditional > specifies code that is read conditionally based on the feature/ > > Form #? takes a list of alternating feature and expression. These are > checked like cond and the selected expression is read and returned. Other > branches are unread. If no branch is selected, the reader reads nothing > (not nil, but literally as if reading ""). An optional ":default" branch > can be used as a fallthrough. > > Reader conditional with 2 features and a default: > > #?(:clj Double/NaN >:cljsjs/NaN >:default nil) > > There is also a reader conditional splicing form. The evaluated expression > should be sequential and will be spliced into the surrounded code, similar > to unqoute-splicing. > > For example: > >[1 2 #?@(:clj [3 4] :cljs [5 6])] > > This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, > and [1 2] on any other platform. > > Additionally, the reader can now be invoked with options for the features > to use and how to interpret reader conditionals. By default, reader > conditionals > are not allowed, but that can be turned on, or a "preserve" mode can be > used to > preserve all branches (most likely useful for tooling or source > transforms). > > In the preserve mode, the reader conditional itself and any tagged literals > within the unselected branches are returned as tagged literal data. > > For more information, see: >
Re: [ANN] Clojure 1.7.0-alpha6 released
If you want to invoke the reader programmatically with reader conditionals
allowed, you can do that through the (new) options map available with both
read and read-string:
user=> (read-string {:read-cond :allow} "#?(:clj foo :cljs bar)")
foo
There is no way to "turn on" read conditionals by default at the REPL - it
is only on by default when loading a .cljc file.
On Wednesday, April 1, 2015 at 11:56:12 AM UTC-5, Alexander Gunnarson wrote:
>
> This patch is incredibly useful! Great job to everyone that contributed.
> One question: how do I enable conditional reading by default in the REPL as
> opposed to passing a properties map to /read-string/, etc.? Do I set
> certain system properties in the command line like "cond_read=true"?
>
> On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote:
>
> Clojure 1.7.0-alpha6 is now available.
>
> Try it via
> - Download:
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/
> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"]
>
> Regression fixes from previous alphas (and one from 1.6):
>
> 1) CLJ-1544 was rolled back and will be investigated for a future release.
> 2) CLJ-1637 fixed regression with vec on MapEntry
> 3) CLJ-1663 fixed regression in classloader (affected Cursive)
> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List)
> method
> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for
> literal nil arg
> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that
> prevented update
>
> Some highlights new in alpha6:
>
> ## Transducer-related changes:
>
> The LazyTransformer introduced to create lazy transforming sequences has
> been
> replaced with a TransformingIterator. This was done to simplify the code
> around transformations and to make certain use cases around eduction more
> efficient.
>
> ## Faster reduce, iterator, and sequence paths
>
> A lot of work has been done across a set of tickets to improve the ability
> of
> collections to provide more efficient reduce or iterator performance, and
> also to
> make common sequence generators create faster sequence and reduce paths.
> You
> should see significant performance in many reduce-related paths (this
> includes
> reduce, transduce, into, and anything else built on reduce).
>
> Many of those changes also have beneficial sequence performance, so you
> may see
> some benefits even in code that does not use transducers.
>
> * Most uses of SeqIterator have now been replaced with iterators that
> directly walk
> the underlying source for improved efficiency. This includes maps, sets,
> records, etc.
> * repeat - now returns a faster sequence with a fast reduce path
> * cycle - now returns a faster sequence with a fast reduce path
> * iterate - now returns a faster sequence with a fast reduce path
> * range - (did not quite make it in, but coming soon...)
> * keys - iterates directly over the keys of a map, without seq or MapEntry
> allocation
> * vals - iterates directly over the vals of a map, without seq or MapEntry
> allocation
> * iterator-seq - now creates a chunked sequence when previously it was
> unchunked
> * vec and set - were not changed in this release but were set up in a
> previous alpha
> to take advantage of the reduce and iterator changes above
>
> ## Reader conditionals
>
> Reader Conditionals is a new capability to support portable code that
> can run on multiple Clojure platforms with only small changes. In
> particular, this feature aims to support the increasingly common case
> of libraries targeting both Clojure and ClojureScript.
>
> Code intended to be common across multiple platforms should use a new
> supported file extension: ".cljc". When requested to load a namespace,
> the platform-specific file extension (.clj, .cljs) will be checked
> prior to .cljc.
>
> A new reader form can be used to specify "reader conditional" code in
> cljc files (and *only* cljc files). Each platform defines a feature
> identifying the platform (:clj, :cljs, :cljr). The reader conditional
> specifies code that is read conditionally based on the feature/
>
> Form #? takes a list of alternating feature and expression. These are
> checked like cond and the selected expression is read and returned. Other
> branches are unread. If no branch is selected, the reader reads nothing
> (not nil, but literally as if reading ""). An optional ":default" branch
> can be used as a fallthrough.
>
> Reader conditional with 2 features and a default:
>
> #?(:clj Double/NaN
>:cljsjs/NaN
>:default nil)
>
> There is also a reader conditional splicing form. The evaluated expression
> should be sequential and will be spliced into the surrounded code, similar
> to unqoute-splicing.
>
> For example:
>
>[1 2 #?@(:clj [3 4] :cljs [5 6])]
>
> This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript,
> and [1 2] on any other platform.
>
> Additionally, the reader can now be invoked wi
Re: Debugging in CIDER
Nice work !!! On Sunday, March 29, 2015 at 1:46:33 AM UTC+8, Bozhidar Batsov wrote: > > Hey everyone, > > Just wanted to let you know that the most requested feature for CIDER (a > debugger, in case you're wondering) has just landed in the master branch ( > https://github.com/clojure-emacs/cider/pull/1019#issuecomment-87240470). > > The new CIDER debugger is inspired by edebug (Emacs's own debugger) and > based on https://github.com/razum2um/clj-debugger > > It's not super fancy and there's clearly room for improvement in both > clj-debugger and CIDER itself, but it's a pretty good first step. Please, > take the new debugger out for a spin and let us know what do you think > about it. You might also report any problems you've encountered. :-) > > If all is well, CIDER 0.9 will probably be released in a week or so. > > P.S. Thanks, Artur (https://github.com/Malabarba), for all the hard work > on the debugger! You've once again showed the power of the OSS! There's > nothing we can't build together! > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
On Apr 1, 2015, at 10:09 AM, Alex Miller wrote: > There is no way to "turn on" read conditionals by default at the REPL - it is > only on by default when loading a .cljc file. This sounds like a useful feature to add to the REPL tho’ so that you can copy’n’paste code as-is and have it behave "appropriately" (i.e., you can verify that a given section of code does the right thing for a given environment)? I guess we’ll have to see how various IDEs deal with this to know what’s really needed… Sean > On Wednesday, April 1, 2015 at 11:56:12 AM UTC-5, Alexander Gunnarson wrote: > This patch is incredibly useful! Great job to everyone that contributed. One > question: how do I enable conditional reading by default in the REPL as > opposed to passing a properties map to /read-string/, etc.? Do I set certain > system properties in the command line like "cond_read=true"? -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Transducers: sequence versus eduction
Alex Miller writes:
Hi Alex,
> - Eduction is no longer Seqable and thus the return from eduction is not
> seqable (but it is reducible and iterable). You can use iterator-seq to get a
> chunked seq over the top if you need one.
Really?
user> *clojure-version*
{:major 1, :minor 7, :incremental 0, :qualifier "alpha6"}
user> (seq (eduction (map inc) (range 10)))
(1 2 3 4 5 6 7 8 9 10)
> - There are lots of performance implications due to those changes and
> I would recommend re-testing any perf test related to sequence or
> eduction on alpha6 to get a fresh picture as anything pre-alpha6 is
> not comparable.
My observations are all based on today's experience with alpha6. :-)
> - eduction now takes multiple transformations, not just one, and
> composes them. This is designed for mechanical rewriting (hello tool
> developers!!) of ->> chains like this:
>
> (->> s (interpose 5) (partition-all 2))
>
> to this:
>
> (->> s (eduction (interpose 5) (partition-all 2)))
Ah, that's sensible.
> The general idea is that eduction is best when the result will be
> completely consumed in a reducible context. Any case of reusing the
> result will likely be better served by sequence which can cache and
> reuse the answer.
Yes, that's what I guessed. But at least when I tested replacing
sequence with eduction at exactly these places () the result has been a
slight slowdown instead of a speedup. But that might have been
accidental as it is hard to do measurements with real-world code where a
5% slowdown/speedup might be the reason of something completely
unrelated.
Bye,
Tassilo
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
REPLs are of course free to choose how they read and some of the other changes coming out of the socket repl work may make those choices easier to select. The clojure.main/repl function is already (perhaps excessively) parameterized and can be given a custom read function for example. The read and read-string option maps are intentionally the first arg for easy use with partial. On Wed, Apr 1, 2015 at 1:51 PM, Sean Corfield wrote: > On Apr 1, 2015, at 10:09 AM, Alex Miller wrote: > > There is no way to "turn on" read conditionals by default at the REPL - it > is only on by default when loading a .cljc file. > > > This sounds like a useful feature to add to the REPL tho’ so that you can > copy’n’paste code as-is and have it behave "appropriately" (i.e., you can > verify that a given section of code does the right thing for a given > environment)? > > I guess we’ll have to see how various IDEs deal with this to know what’s > really needed… > > Sean > > On Wednesday, April 1, 2015 at 11:56:12 AM UTC-5, Alexander Gunnarson > wrote: >> >> This patch is incredibly useful! Great job to everyone that contributed. >> One question: how do I enable conditional reading by default in the REPL as >> opposed to passing a properties map to /read-string/, etc.? Do I set >> certain system properties in the command line like "cond_read=true"? >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
@Alex Miller: Thanks for letting me know. I'll unfortunately have to change my workflow accordingly. On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] > > Regression fixes from previous alphas (and one from 1.6): > > 1) CLJ-1544 was rolled back and will be investigated for a future release. > 2) CLJ-1637 fixed regression with vec on MapEntry > 3) CLJ-1663 fixed regression in classloader (affected Cursive) > 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) > method > 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for > literal nil arg > 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that > prevented update > > Some highlights new in alpha6: > > ## Transducer-related changes: > > The LazyTransformer introduced to create lazy transforming sequences has > been > replaced with a TransformingIterator. This was done to simplify the code > around transformations and to make certain use cases around eduction more > efficient. > > ## Faster reduce, iterator, and sequence paths > > A lot of work has been done across a set of tickets to improve the ability > of > collections to provide more efficient reduce or iterator performance, and > also to > make common sequence generators create faster sequence and reduce paths. > You > should see significant performance in many reduce-related paths (this > includes > reduce, transduce, into, and anything else built on reduce). > > Many of those changes also have beneficial sequence performance, so you > may see > some benefits even in code that does not use transducers. > > * Most uses of SeqIterator have now been replaced with iterators that > directly walk > the underlying source for improved efficiency. This includes maps, sets, > records, etc. > * repeat - now returns a faster sequence with a fast reduce path > * cycle - now returns a faster sequence with a fast reduce path > * iterate - now returns a faster sequence with a fast reduce path > * range - (did not quite make it in, but coming soon...) > * keys - iterates directly over the keys of a map, without seq or MapEntry > allocation > * vals - iterates directly over the vals of a map, without seq or MapEntry > allocation > * iterator-seq - now creates a chunked sequence when previously it was > unchunked > * vec and set - were not changed in this release but were set up in a > previous alpha > to take advantage of the reduce and iterator changes above > > ## Reader conditionals > > Reader Conditionals is a new capability to support portable code that > can run on multiple Clojure platforms with only small changes. In > particular, this feature aims to support the increasingly common case > of libraries targeting both Clojure and ClojureScript. > > Code intended to be common across multiple platforms should use a new > supported file extension: ".cljc". When requested to load a namespace, > the platform-specific file extension (.clj, .cljs) will be checked > prior to .cljc. > > A new reader form can be used to specify "reader conditional" code in > cljc files (and *only* cljc files). Each platform defines a feature > identifying the platform (:clj, :cljs, :cljr). The reader conditional > specifies code that is read conditionally based on the feature/ > > Form #? takes a list of alternating feature and expression. These are > checked like cond and the selected expression is read and returned. Other > branches are unread. If no branch is selected, the reader reads nothing > (not nil, but literally as if reading ""). An optional ":default" branch > can be used as a fallthrough. > > Reader conditional with 2 features and a default: > > #?(:clj Double/NaN >:cljsjs/NaN >:default nil) > > There is also a reader conditional splicing form. The evaluated expression > should be sequential and will be spliced into the surrounded code, similar > to unqoute-splicing. > > For example: > >[1 2 #?@(:clj [3 4] :cljs [5 6])] > > This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, > and [1 2] on any other platform. > > Additionally, the reader can now be invoked with options for the features > to use and how to interpret reader conditionals. By default, reader > conditionals > are not allowed, but that can be turned on, or a "preserve" mode can be > used to > preserve all branches (most likely useful for tooling or source > transforms). > > In the preserve mode, the reader conditional itself and any tagged literals > within the unselected branches are returned as tagged literal data. > > For more information, see: > http://dev.clojure.org/display/design/Reader+Conditionals > > Two important side notes: > - Clojure dependencies have been updated and you must re-run antsetup.sh > if you > build Clojur
Re: [ANN] Clojure 1.7.0-alpha6 released
@Sean Corfield — That's exactly my point. I use Sublime Text and I usually just copy-paste code from various buffers / open files into a REPL buffer on my workspace. Maybe that's not the most efficient way, and I want to move to some sort of auto-reload plugin for leiningen a la figwheel for Clojure, but I'm not sure if the new reader conditionals would with such a plugin anyway. I'd have to experiment. Either way, it would be very convenient to be able to enable/disable reader conditionals via something like (set! *cond-eval* true) or some such thing. On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] > > Regression fixes from previous alphas (and one from 1.6): > > 1) CLJ-1544 was rolled back and will be investigated for a future release. > 2) CLJ-1637 fixed regression with vec on MapEntry > 3) CLJ-1663 fixed regression in classloader (affected Cursive) > 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) > method > 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for > literal nil arg > 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that > prevented update > > Some highlights new in alpha6: > > ## Transducer-related changes: > > The LazyTransformer introduced to create lazy transforming sequences has > been > replaced with a TransformingIterator. This was done to simplify the code > around transformations and to make certain use cases around eduction more > efficient. > > ## Faster reduce, iterator, and sequence paths > > A lot of work has been done across a set of tickets to improve the ability > of > collections to provide more efficient reduce or iterator performance, and > also to > make common sequence generators create faster sequence and reduce paths. > You > should see significant performance in many reduce-related paths (this > includes > reduce, transduce, into, and anything else built on reduce). > > Many of those changes also have beneficial sequence performance, so you > may see > some benefits even in code that does not use transducers. > > * Most uses of SeqIterator have now been replaced with iterators that > directly walk > the underlying source for improved efficiency. This includes maps, sets, > records, etc. > * repeat - now returns a faster sequence with a fast reduce path > * cycle - now returns a faster sequence with a fast reduce path > * iterate - now returns a faster sequence with a fast reduce path > * range - (did not quite make it in, but coming soon...) > * keys - iterates directly over the keys of a map, without seq or MapEntry > allocation > * vals - iterates directly over the vals of a map, without seq or MapEntry > allocation > * iterator-seq - now creates a chunked sequence when previously it was > unchunked > * vec and set - were not changed in this release but were set up in a > previous alpha > to take advantage of the reduce and iterator changes above > > ## Reader conditionals > > Reader Conditionals is a new capability to support portable code that > can run on multiple Clojure platforms with only small changes. In > particular, this feature aims to support the increasingly common case > of libraries targeting both Clojure and ClojureScript. > > Code intended to be common across multiple platforms should use a new > supported file extension: ".cljc". When requested to load a namespace, > the platform-specific file extension (.clj, .cljs) will be checked > prior to .cljc. > > A new reader form can be used to specify "reader conditional" code in > cljc files (and *only* cljc files). Each platform defines a feature > identifying the platform (:clj, :cljs, :cljr). The reader conditional > specifies code that is read conditionally based on the feature/ > > Form #? takes a list of alternating feature and expression. These are > checked like cond and the selected expression is read and returned. Other > branches are unread. If no branch is selected, the reader reads nothing > (not nil, but literally as if reading ""). An optional ":default" branch > can be used as a fallthrough. > > Reader conditional with 2 features and a default: > > #?(:clj Double/NaN >:cljsjs/NaN >:default nil) > > There is also a reader conditional splicing form. The evaluated expression > should be sequential and will be spliced into the surrounded code, similar > to unqoute-splicing. > > For example: > >[1 2 #?@(:clj [3 4] :cljs [5 6])] > > This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, > and [1 2] on any other platform. > > Additionally, the reader can now be invoked with options for the features > to use and how to interpret reader conditionals. By default, reader > conditionals > are not allowed, but that can be turned on, or a "preserve" mode can be
Re: Transducers: sequence versus eduction
On Wed, Apr 1, 2015 at 2:17 PM, Tassilo Horn wrote:
> Alex Miller writes:
>
> Hi Alex,
>
> > - Eduction is no longer Seqable and thus the return from eduction is not
> > seqable (but it is reducible and iterable). You can use iterator-seq to
> get a
> > chunked seq over the top if you need one.
>
> Really?
>
> user> *clojure-version*
> {:major 1, :minor 7, :incremental 0, :qualifier "alpha6"}
> user> (seq (eduction (map inc) (range 10)))
> (1 2 3 4 5 6 7 8 9 10)
>
Yep. :)
user=> (supers (class (eduction (map inc) (range 10
#{clojure.lang.Sequential java.lang.Object java.lang.Iterable
clojure.lang.IReduceInit clojure.lang.IType}
However, seq checks for Iterable and will automatically use iterator-seq to
produce a seq from an Iterable, which is what's happening here.
See:
https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/RT.java#L517
> - There are lots of performance implications due to those changes and
> > I would recommend re-testing any perf test related to sequence or
> > eduction on alpha6 to get a fresh picture as anything pre-alpha6 is
> > not comparable.
>
> My observations are all based on today's experience with alpha6. :-)
>
> > - eduction now takes multiple transformations, not just one, and
> > composes them. This is designed for mechanical rewriting (hello tool
> > developers!!) of ->> chains like this:
> >
> > (->> s (interpose 5) (partition-all 2))
> >
> > to this:
> >
> > (->> s (eduction (interpose 5) (partition-all 2)))
>
> Ah, that's sensible.
>
> > The general idea is that eduction is best when the result will be
> > completely consumed in a reducible context. Any case of reusing the
> > result will likely be better served by sequence which can cache and
> > reuse the answer.
>
> Yes, that's what I guessed. But at least when I tested replacing
> sequence with eduction at exactly these places () the result has been a
> slight slowdown instead of a speedup. But that might have been
> accidental as it is hard to do measurements with real-world code where a
> 5% slowdown/speedup might be the reason of something completely
> unrelated.
>
Are you including the cost of realizing the elements? Comparing this stuff
well is hard, or at least I had a hard time thinking through all the
nuances. From what I've looked at, I think the alpha6 changes have made
things slightly worse for sequence with transformations and somewhat better
for eductions used in a reducible or sequence context.
>
> Bye,
> Tassilo
>
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
We'll consider it, thanks for the questions. On Wednesday, April 1, 2015 at 2:32:58 PM UTC-5, Alexander Gunnarson wrote: > > @Sean Corfield — That's exactly my point. I use Sublime Text and I usually > just copy-paste code from various buffers / open files into a REPL buffer > on my workspace. Maybe that's not the most efficient way, and I want to > move to some sort of auto-reload plugin for leiningen a la figwheel for > Clojure, but I'm not sure if the new reader conditionals would with such a > plugin anyway. I'd have to experiment. Either way, it would be very > convenient to be able to enable/disable reader conditionals via something > like (set! *cond-eval* true) or some such thing. > > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
@Alex Miller — Thanks! I appreciate it. On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > > Clojure 1.7.0-alpha6 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha6/ > - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] > > Regression fixes from previous alphas (and one from 1.6): > > 1) CLJ-1544 was rolled back and will be investigated for a future release. > 2) CLJ-1637 fixed regression with vec on MapEntry > 3) CLJ-1663 fixed regression in classloader (affected Cursive) > 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) > method > 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for > literal nil arg > 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols that > prevented update > > Some highlights new in alpha6: > > ## Transducer-related changes: > > The LazyTransformer introduced to create lazy transforming sequences has > been > replaced with a TransformingIterator. This was done to simplify the code > around transformations and to make certain use cases around eduction more > efficient. > > ## Faster reduce, iterator, and sequence paths > > A lot of work has been done across a set of tickets to improve the ability > of > collections to provide more efficient reduce or iterator performance, and > also to > make common sequence generators create faster sequence and reduce paths. > You > should see significant performance in many reduce-related paths (this > includes > reduce, transduce, into, and anything else built on reduce). > > Many of those changes also have beneficial sequence performance, so you > may see > some benefits even in code that does not use transducers. > > * Most uses of SeqIterator have now been replaced with iterators that > directly walk > the underlying source for improved efficiency. This includes maps, sets, > records, etc. > * repeat - now returns a faster sequence with a fast reduce path > * cycle - now returns a faster sequence with a fast reduce path > * iterate - now returns a faster sequence with a fast reduce path > * range - (did not quite make it in, but coming soon...) > * keys - iterates directly over the keys of a map, without seq or MapEntry > allocation > * vals - iterates directly over the vals of a map, without seq or MapEntry > allocation > * iterator-seq - now creates a chunked sequence when previously it was > unchunked > * vec and set - were not changed in this release but were set up in a > previous alpha > to take advantage of the reduce and iterator changes above > > ## Reader conditionals > > Reader Conditionals is a new capability to support portable code that > can run on multiple Clojure platforms with only small changes. In > particular, this feature aims to support the increasingly common case > of libraries targeting both Clojure and ClojureScript. > > Code intended to be common across multiple platforms should use a new > supported file extension: ".cljc". When requested to load a namespace, > the platform-specific file extension (.clj, .cljs) will be checked > prior to .cljc. > > A new reader form can be used to specify "reader conditional" code in > cljc files (and *only* cljc files). Each platform defines a feature > identifying the platform (:clj, :cljs, :cljr). The reader conditional > specifies code that is read conditionally based on the feature/ > > Form #? takes a list of alternating feature and expression. These are > checked like cond and the selected expression is read and returned. Other > branches are unread. If no branch is selected, the reader reads nothing > (not nil, but literally as if reading ""). An optional ":default" branch > can be used as a fallthrough. > > Reader conditional with 2 features and a default: > > #?(:clj Double/NaN >:cljsjs/NaN >:default nil) > > There is also a reader conditional splicing form. The evaluated expression > should be sequential and will be spliced into the surrounded code, similar > to unqoute-splicing. > > For example: > >[1 2 #?@(:clj [3 4] :cljs [5 6])] > > This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, > and [1 2] on any other platform. > > Additionally, the reader can now be invoked with options for the features > to use and how to interpret reader conditionals. By default, reader > conditionals > are not allowed, but that can be turned on, or a "preserve" mode can be > used to > preserve all branches (most likely useful for tooling or source > transforms). > > In the preserve mode, the reader conditional itself and any tagged literals > within the unselected branches are returned as tagged literal data. > > For more information, see: > http://dev.clojure.org/display/design/Reader+Conditionals > > Two important side notes: > - Clojure dependencies have been updated and you must re-run antsetup.sh > if you > build Clojure locally with ant. > - The equivalent ClojureScript support fo
Re: Transducers: sequence versus eduction
Alex Miller writes:
> > seqable (but it is reducible and iterable). You can use
> > iterator-seq to get a chunked seq over the top if you need one.
>
> Really?
>
> user> *clojure-version*
> {:major 1, :minor 7, :incremental 0, :qualifier "alpha6"}
> user> (seq (eduction (map inc) (range 10)))
> (1 2 3 4 5 6 7 8 9 10)
>
> Yep. :)
>
> user=> (supers (class (eduction (map inc) (range 10
> #{clojure.lang.Sequential java.lang.Object java.lang.Iterable
> clojure.lang.IReduceInit clojure.lang.IType}
>
> However, seq checks for Iterable and will automatically use
> iterator-seq to produce a seq from an Iterable, which is what's
> happening here.
Ok. But to me, if I can call `seq` on a thing and iterate it using
`first` and `rest`, that's a sequable thing to me. :-)
> > The general idea is that eduction is best when the result will
> > be completely consumed in a reducible context. Any case of
> > reusing the result will likely be better served by sequence
> > which can cache and reuse the answer.
>
> Yes, that's what I guessed. But at least when I tested replacing
> sequence with eduction at exactly these places () the result has
> been a slight slowdown instead of a speedup. But that might have
> been accidental as it is hard to do measurements with real-world
> code where a 5% slowdown/speedup might be the reason of something
> completely unrelated.
>
> Are you including the cost of realizing the elements?
Oh, yes, and not only that. The tests I did maybe spend 20% of their
time in the transducer part, 80% in other stuff. So I definitively have
to do some more elaborate benchmarking where the transducer part is
somehow isolated.
That's why I've asked if there are clear usage-recipes when to use what.
I think my prime use-case is deeply nested mapcatting where the
mapcatted function gets an object and returns a java collection, and
filtering with usually a quite cheap predicate. E.g.
(sequence-or-eduction (comp (mapcat ...)
(filter ...)
(mapcat ...)
...
(filter ...))
coll)
That's part of a larger search algorithm which either stops after
finding the first match (in which case the resulting sequence is likely
not to be realized completely) or runs till all matches are found (in
which case all these transducer-produced sequences would be fully
realized).
If that would make sense, I could use eduction when I know everything
will be realized and sequence in the other case (or vice versa).
Bye,
Tassilo
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups
"Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to clojure+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: Transducers: sequence versus eduction
On Wed, Apr 1, 2015 at 3:17 PM, Tassilo Horn wrote: > Alex Miller writes: > > Ok. But to me, if I can call `seq` on a thing and iterate it using > `first` and `rest`, that's a sequable thing to me. :-) > Fair enough. I just meant it no longer implements Seqable. :) > > > The general idea is that eduction is best when the result will > > > be completely consumed in a reducible context. Any case of > > > reusing the result will likely be better served by sequence > > > which can cache and reuse the answer. > > > > Yes, that's what I guessed. But at least when I tested replacing > > sequence with eduction at exactly these places () the result has > > been a slight slowdown instead of a speedup. But that might have > > been accidental as it is hard to do measurements with real-world > > code where a 5% slowdown/speedup might be the reason of something > > completely unrelated. > > > > Are you including the cost of realizing the elements? > > Oh, yes, and not only that. The tests I did maybe spend 20% of their > time in the transducer part, 80% in other stuff. So I definitively have > to do some more elaborate benchmarking where the transducer part is > somehow isolated. > > That's why I've asked if there are clear usage-recipes when to use what. > I think my prime use-case is deeply nested mapcatting where the > mapcatted function gets an object and returns a java collection, and > filtering with usually a quite cheap predicate. E.g. > > (sequence-or-eduction (comp (mapcat ...) > (filter ...) > (mapcat ...) > ... > (filter ...)) > coll) > > That's part of a larger search algorithm which either stops after > finding the first match (in which case the resulting sequence is likely > not to be realized completely) or runs till all matches are found (in > which case all these transducer-produced sequences would be fully > realized). > > If that would make sense, I could use eduction when I know everything > will be realized and sequence in the other case (or vice versa). > In this case, I don't know that I'd expect much difference. sequence is going to create a TransformerIterator, and wrap it in an chunkedIteratorSeq. Using (seq (eduction ...) should give you exactly the same thing, except calling through an Eduction type. So, I doubt it matters. > Bye, > Tassilo > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Hi, Iterate calls its function after it is finished iterating. ;; clojure 1.6 user=> (take 2 (iterate zero? 0)) (0 true) ;; clojure 1.7-alpha6 user=> (take 2 (iterate zero? 0)) ClassCastException java.lang.Boolean cannot be cast to java.lang.Number clojure.lang.Numbers.isZero (Numbers.java:92) Thanks, Ambrose On Wed, Apr 1, 2015 at 3:45 PM, Alexander Gunnarson < alexandergunnar...@gmail.com> wrote: > @Alex Miller — Thanks! I appreciate it. > > On Tuesday, March 31, 2015 at 10:51:13 AM UTC-6, Alex Miller wrote: > >> Clojure 1.7.0-alpha6 is now available. >> >> Try it via >> - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1. >> 7.0-alpha6/ >> - Leiningen: [org.clojure/clojure "1.7.0-alpha6"] >> >> Regression fixes from previous alphas (and one from 1.6): >> >> 1) CLJ-1544 was rolled back and will be investigated for a future release. >> 2) CLJ-1637 fixed regression with vec on MapEntry >> 3) CLJ-1663 fixed regression in classloader (affected Cursive) >> 4) CLJ-1638 fixed regression with removed PersistentVector.create(List) >> method >> 5) CLJ-1681 fixed regression in 1.6 with NPE on reflection warning for >> literal nil arg >> 6) CLJ-1604 fixed problem with AOT and shadowing clojure.core symbols >> that prevented update >> >> Some highlights new in alpha6: >> >> ## Transducer-related changes: >> >> The LazyTransformer introduced to create lazy transforming sequences has >> been >> replaced with a TransformingIterator. This was done to simplify the code >> around transformations and to make certain use cases around eduction more >> efficient. >> >> ## Faster reduce, iterator, and sequence paths >> >> A lot of work has been done across a set of tickets to improve the >> ability of >> collections to provide more efficient reduce or iterator performance, and >> also to >> make common sequence generators create faster sequence and reduce paths. >> You >> should see significant performance in many reduce-related paths (this >> includes >> reduce, transduce, into, and anything else built on reduce). >> >> Many of those changes also have beneficial sequence performance, so you >> may see >> some benefits even in code that does not use transducers. >> >> * Most uses of SeqIterator have now been replaced with iterators that >> directly walk >> the underlying source for improved efficiency. This includes maps, sets, >> records, etc. >> * repeat - now returns a faster sequence with a fast reduce path >> * cycle - now returns a faster sequence with a fast reduce path >> * iterate - now returns a faster sequence with a fast reduce path >> * range - (did not quite make it in, but coming soon...) >> * keys - iterates directly over the keys of a map, without seq or >> MapEntry allocation >> * vals - iterates directly over the vals of a map, without seq or >> MapEntry allocation >> * iterator-seq - now creates a chunked sequence when previously it was >> unchunked >> * vec and set - were not changed in this release but were set up in a >> previous alpha >> to take advantage of the reduce and iterator changes above >> >> ## Reader conditionals >> >> Reader Conditionals is a new capability to support portable code that >> can run on multiple Clojure platforms with only small changes. In >> particular, this feature aims to support the increasingly common case >> of libraries targeting both Clojure and ClojureScript. >> >> Code intended to be common across multiple platforms should use a new >> supported file extension: ".cljc". When requested to load a namespace, >> the platform-specific file extension (.clj, .cljs) will be checked >> prior to .cljc. >> >> A new reader form can be used to specify "reader conditional" code in >> cljc files (and *only* cljc files). Each platform defines a feature >> identifying the platform (:clj, :cljs, :cljr). The reader conditional >> specifies code that is read conditionally based on the feature/ >> >> Form #? takes a list of alternating feature and expression. These are >> checked like cond and the selected expression is read and returned. Other >> branches are unread. If no branch is selected, the reader reads nothing >> (not nil, but literally as if reading ""). An optional ":default" branch >> can be used as a fallthrough. >> >> Reader conditional with 2 features and a default: >> >> #?(:clj Double/NaN >>:cljsjs/NaN >>:default nil) >> >> There is also a reader conditional splicing form. The evaluated expression >> should be sequential and will be spliced into the surrounded code, similar >> to unqoute-splicing. >> >> For example: >> >>[1 2 #?@(:clj [3 4] :cljs [5 6])] >> >> This form would read as [1 2 3 4] on Clojure, [1 2 5 6] on ClojureScript, >> and [1 2] on any other platform. >> >> Additionally, the reader can now be invoked with options for the features >> to use and how to interpret reader conditionals. By default, reader >> conditionals >> are not allowed, but that can be turned on, or a "preserve" mode can be >> used to >> preserve all
Re: [ANN] Phoenix 0.1.0 - help with structuring & configuring Component-based systems
On Tuesday, March 31, 2015 at 7:49:52 AM UTC-4, Jeroen van Dijk wrote: > > Thanks for sharing James! I'll have a look. > > As a side note, I see in the example code that you are dissoc-ing on the > component. This can lead to unexpected behaviour as I have > experienced (mostly in repl cases), as this will return a map instead of a > record when the field is not part of the record. This is also mentioned in > the readme of https://github.com/stuartsierra/component where `(assoc > component ::field nil)` is recommended > Perhaps there should be an enablable warning for that, the way there already is for reflection. When enabled, it would go off if a) Code was compiled for (dissoc x :foo) where x could be determined by static analysis to be an instance of a record type for which :foo is a base field, and also if b) A dissoc on a record returned a plain map, or at least b). Enabling the warning could work partly by actually redefining clojure.core/dissoc, as with disabling it, so that the overhead of the warning code was completely avoided with it disabled. With it enabled, the code path in dissoc that produces a non-record from a record would also emit a message to stderr with general wording such as "warning: dissocing base field :foo from MyRecord, producing hash map, at line 666 of evil.clj". (The line and file being obtained by constructing a Throwable and then dismantling and examining its StackTraceElements.) Turning this on and exercising a project (especially, running all the tests if it has good test coverage) would then find most potential-bugs of this sort. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
On Tuesday, March 31, 2015 at 8:45:31 AM UTC-4, Phillip Lord wrote: > > The benefit is that Emacs is that its not constantly changing, and it > gives you some stability over the years. I like latex, for instance, for > the same reason. I can still access a 10 year old document and use it. > First of all, there are other posts in this thread complaining about constantly changing stuff breaking things! One such post is by Colin Yates. Second, to the extent that it isn't changing, it is legacy. Which helps to explain the Wordperfect for DOS style of UI, which is dependent on vast numbers of complex key-combinations being memorized by the user, instead of a just-sit-down-and-start-using-it UI like everything originating after, say, 1995 or so has tended to have. Of course, the result is that Wordperfect (and emacs) seemed to require a great deal of specialized training just to accomplish even the most basic tasks, whereas with modern interfaces the way to do such basic tasks (save, open, copy and paste, move around, select, etc.) tends to be obvious and special training can focus exclusively on doing advanced things (scripting, complicated Photoshop filters and tricks, things like those). Legacy also, obviously, tends to present problems in other areas besides UI-boneheadedness: * I18n and l10n * Compatibility, with modern hardware and with modern operating systems, though that can be alleviated by people porting the code * Boneheaded internal limits, along the same general lines as "640K ought to be enough for anybody". It may be unable to use more than a small fraction of what modern hardware can offer it in the way of memory, storage, cores, ... * Accessibility. Interposing a terminal emulator between the app and screen reading software might cause problems, though on the other hand a text mode app may ultimately have advantages in that area too. On the other hand, it may not play well with accessibility tools that rely on standard UI conventions. Anything that responds to some voice command by generating control-V keystrokes to paste, or that relies on the presence of normal menus and/or mouse support is going to blow up spectacularly when used with 1980s-vintage Unix (or MS-DOS) software, or at best will end up controlling the xterm/Command Prompt window instead of the underlying app. * Interoperation with other (non-operating-system) software. On Windows it won't speak OLE, DDE, OCX, or etc., and copying text in it and attempting to paste into something else (web browser, calculator, etc.) is doomed to failure. This is a general problem with pre-window-system software, much like the stuff listed under Accessibility, with no easy solution. Terminal emulators tend to provide some way to copy from their display into the host-native clipboard, but it tends to be clunky (the Windows command prompt appears to require mouse use, with no keyboard shortcuts) and runs into the obvious difficulties as soon as you want to copy more than will fit on one screen. Ironically, really primitive stuff like ls and dir that just dump possibly-paginated noninteractive listings to the term are easier to make big copies from than text-mode, interactive applications like screen-oriented editors, because you can copy from the backscroll buffer of the terminal emulator in the first case. Pre-window-system *graphical* apps are the absolute worst, e.g. later, WYSIWYG word processor versions on MS-DOS, or pre-window-system X applications. No internal support for the host clipboard and, at the same time, nothing the emulator will recognize as text, meaning if you try to native copy and paste you'll end up with a PNG or something. OCR might work on that, if you can find cheap or free OCR software that's any good. Your better bet would be to save the document as some format that can be read by a native windowed app and then open the file in that, then copy, and at that point you might as well edit in the native windowed app and throw out the legacy cruft entirely, since you'll have to deal with the native app anyway, and the cost of switching between them constantly, reloading in the native app so it sees changes, and re-locating the places you want to copy from in the native app will quickly grow to outweigh any advantage the legacy app might somehow have due to some feature it has that you haven't found in any native app. Put more simply, there are giant costs to not playing well with others, and these are inevitably incurred by all applications developed prior to the advent of a) window systems with window managers, systemwide copy/paste, and etc. and b) widespread user-interface standards for common cross-domain tasks like save and paste. Ultimately, the costs incurred every time you or some data need to cross the boundary between the legacy application and the modern world are likely to vastly outweigh whatever few missing features you can find only in le
Re: [ANN] Clojure 1.7.0-alpha6 released
Ambrose, does that "iterate" result arise from chunking? "iterate" is advertised as producing an infinite lazy sequence. While a suddenly chunking "iterate" will no doubt smoke out some cases like this, doesn't it seem that they are abuses? It's not quite spot-on to employ "take" or "take-while" outside the "iterate" as a loop-ending nanny for sequences that could not genuinely be infinite. The "take" should be concerned with what the consumer wants to consume, not preoccupied with what the producer will be able to produce. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
AFAICT there is consistently one extra call, which seems to suggest an off-by-one error in the IReduce implementation of Iterate. ;; 1.6 user=> (take 11 (iterate (fn [a] (prn (str "PR" a)) (inc a)) 1)) "PR1" "PR2" "PR3" "PR4" "PR5" "PR6" "PR7" "PR8" "PR9" "PR10" (1 2 3 4 5 6 7 8 9 10 ...) ;; 1.7.0-alpha6 user=> (take 11 (iterate (fn [a] (prn (str "PR" a)) (inc a)) 1)) "PR1" "PR2" "PR3" "PR4" "PR5" "PR6" "PR7" "PR8" "PR9" "PR10" "PR11" (1 2 3 4 5 6 7 8 9 10 ...) Thanks, Ambrose On Wed, Apr 1, 2015 at 8:50 PM, Matching Socks wrote: > Ambrose, does that "iterate" result arise from chunking? "iterate" is > advertised as producing an infinite lazy sequence. While a suddenly > chunking "iterate" will no doubt smoke out some cases like this, doesn't it > seem that they are abuses? It's not quite spot-on to employ "take" or > "take-while" outside the "iterate" as a loop-ending nanny for sequences > that could not genuinely be infinite. The "take" should be concerned with > what the consumer wants to consume, not preoccupied with what the producer > will be able to produce. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Actually it seems the oddity is that "next" now does the computation instead of "first" in Iterate.java. On Wed, Apr 1, 2015 at 8:56 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > AFAICT there is consistently one extra call, which seems to suggest an > off-by-one error in the IReduce implementation of Iterate. > > ;; 1.6 > user=> (take 11 (iterate (fn [a] (prn (str "PR" a)) (inc a)) 1)) > "PR1" > "PR2" > "PR3" > "PR4" > "PR5" > "PR6" > "PR7" > "PR8" > "PR9" > "PR10" > (1 2 3 4 5 6 7 8 9 10 ...) > > ;; 1.7.0-alpha6 > user=> (take 11 (iterate (fn [a] (prn (str "PR" a)) (inc a)) 1)) > "PR1" > "PR2" > "PR3" > "PR4" > "PR5" > "PR6" > "PR7" > "PR8" > "PR9" > "PR10" > "PR11" > (1 2 3 4 5 6 7 8 9 10 ...) > > Thanks, > Ambrose > > On Wed, Apr 1, 2015 at 8:50 PM, Matching Socks > wrote: > >> Ambrose, does that "iterate" result arise from chunking? "iterate" is >> advertised as producing an infinite lazy sequence. While a suddenly >> chunking "iterate" will no doubt smoke out some cases like this, doesn't it >> seem that they are abuses? It's not quite spot-on to employ "take" or >> "take-while" outside the "iterate" as a loop-ending nanny for sequences >> that could not genuinely be infinite. The "take" should be concerned with >> what the consumer wants to consume, not preoccupied with what the producer >> will be able to produce. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
I would love a jira for the iterate thIng. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Ok. On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller wrote: > I would love a jira for the iterate thIng. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
http://dev.clojure.org/jira/browse/CLJ-1692 On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Ok. > > On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller wrote: > >> I would love a jira for the iterate thIng. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Thanks! If anyone wants to throw a patch, would love to have one. Must include test ... On Wednesday, April 1, 2015 at 8:14:52 PM UTC-5, Ambrose Bonnaire-Sergeant wrote: > > http://dev.clojure.org/jira/browse/CLJ-1692 > > On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant < > abonnair...@gmail.com > wrote: > >> Ok. >> >> On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller > > wrote: >> >>> I would love a jira for the iterate thIng. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: clojure, not the go to for data science
Hi, I'm working on a machine learning library for Clojure - Clatern( https://github.com/rinuboney/clatern). I've written a couple of blog posts in my blog rinuboney.github.io. I've just begun and there is lot more work to do. I've actually submitted a Google summer of code proposal and I hope I get selected :-). I believe core.matrix and Incanter are awesome tools for data analysis. Clojure is a good fit for data analysis. I too propose that instead of the discussion, everyone channel their energy into open source data science libraries or on articles promoting Clojure for data science. Cheers, Rinu. On Monday, March 30, 2015 at 5:05:50 PM UTC+5:30, Jony Hudson wrote: > > I propose, instead of this discussion, everyone channels their energy into > writing an open-source data-science library, or blog post/article promoting > Clojure for data science. In their favourite editor, of course! > > > Jony > > > On Sunday, 29 March 2015 10:55:34 UTC+1, Sayth Renshaw wrote: >> >> Hi >> >> I last learned clojure in 1.2. Just curious why Clojure hasn't developed >> as a go to for data science? >> >> It never seems to get a mention R,Python and now Julia get the attention. >> By design it would appear that Clojure would be a good fit. Is it a lack of >> libraries, ease of install, no good default environment (R Rstudio, >> IPython ) where as you would need to use emacs with clojure, or is there >> just a better default use of Clojure? >> >> Sayth > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [ANN] Clojure 1.7.0-alpha6 released
Here's some weird behaviour I found from 1.6. user=> (take 1 (iterate zero? true)) (true) user=> (reduce (fn [l _] (reduced l)) (iterate zero? true)) ClassCastException java.lang.Boolean cannot be cast to java.lang.Number clojure.lang.Numbers.isZero (Numbers.java:90) Is this a bug, and should this be fixed? Thanks, Ambrose On Wed, Apr 1, 2015 at 10:28 PM, Alex Miller wrote: > Thanks! If anyone wants to throw a patch, would love to have one. Must > include test ... > > On Wednesday, April 1, 2015 at 8:14:52 PM UTC-5, Ambrose Bonnaire-Sergeant > wrote: >> >> http://dev.clojure.org/jira/browse/CLJ-1692 >> >> On Wed, Apr 1, 2015 at 9:12 PM, Ambrose Bonnaire-Sergeant < >> abonnair...@gmail.com> wrote: >> >>> Ok. >>> >>> On Wed, Apr 1, 2015 at 9:10 PM, Alex Miller >>> wrote: >>> I would love a jira for the iterate thIng. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
