Re: any?
So I was thinking of: user=> (def any? (comp boolean some)) #'user/any? user=> (any? true? [false true false]) true user=> (any? even? [1 2 3]) true ; touch "3" user=> (any? #(.exists %) [(file "1") (file "2") (file "3")]) true Some motivations - my main one is Java interop where use of non booleans would be weird - similarly it is nicer for APIs to return booleans than a value that is kinda arbitrary and potentially non deterministic. I might recall Rich saying something like that..? - the symmetry of `any` joining `not-any`, `every` and `not-every`. On Sunday, April 26, 2015 at 2:21:26 PM UTC+12, Alex Miller wrote: > > I think 'some' fills this role. Given truthy values, why do you need to > use boolean with it? > > On Saturday, April 25, 2015 at 8:32:09 PM UTC-5, Colin Taylor wrote: >> >> Any reason why we don't have `any?`. Googled without much luck. >> Trivially done as `comp boolean some` not doubt, but I know I use it more >> than not-any at least. >> It's particularly useful as a composable `or`. >> >> >> -- 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: Performance of defmulti in both ClojureScript and Clojure
I should say all of that is for Clojure and likely bears no similarity to the nuances in ClojureScript. On Saturday, April 25, 2015 at 9:39:06 PM UTC-5, Alex Miller wrote: > > On Saturday, April 25, 2015 at 9:33:18 AM UTC-5, Timur wrote: >> >> Hi everyone, >> >> There are situations where I want to dispatch functions using based on >> their certain properties. I can also use case statements instead but it >> looks more coupled and more change is required if I want to add new types. >> > > case is useful for the particular situation where you have a finite set of > compile-time constants that you are looking for (integers, characters, > etc). Then case will leverage a special JVM bytecode that performs a > *constant-time* look-up (not linear-time like checking a series of cond > conditions, etc). This is one of the two bytecode options (tableswitch, > rather than lookupswitch) underlying the Java switch/case feature. > > What I want to ask is if I need to avoid using multi-methods for >> performance reasons? I read somewhere that they are not really fast but the >> posts were old and the performance might have been improved in between. >> Should I favor case and cond branches instead of defmulti when I need >> performance? >> > > multimethods are slower than protocols - they must effectively invoke the > dispatch function, perform a linear search for a match across the cases, > and then invoke the actual implementation function. Protocols leverage JVM > internals to select the right implementation, then invoke it. However, the > search part of multimethods is cached, making that step fast after the > initial call. The last time I benchmarked multimethods with class dispatch > vs protocols on Java 1.8 + Clojure 1.7 alphas (can't remember which one), I > found multimethods were about 5x slower. > > If you want fastest type-based dispatch with open extension, then > protocols are the best. > If you want any other type of dispatch with open extension, then > multimethods are the best. > If you want a closed system of constant choices, then case is best > (constant-time lookup!) > If you want a closed system of arbitrary conditions, then cond is best. > > I have never compared the performance of cond vs multimethods for > something like this. My guess is that multimethods are faster as they > evaluate a single condition, then do a table lookup once cached vs > evaluating a series of conditions every time. > > Alex > > -- 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: Performance of defmulti in both ClojureScript and Clojure
On Saturday, April 25, 2015 at 9:33:18 AM UTC-5, Timur wrote: > > Hi everyone, > > There are situations where I want to dispatch functions using based on > their certain properties. I can also use case statements instead but it > looks more coupled and more change is required if I want to add new types. > case is useful for the particular situation where you have a finite set of compile-time constants that you are looking for (integers, characters, etc). Then case will leverage a special JVM bytecode that performs a *constant-time* look-up (not linear-time like checking a series of cond conditions, etc). This is one of the two bytecode options (tableswitch, rather than lookupswitch) underlying the Java switch/case feature. What I want to ask is if I need to avoid using multi-methods for > performance reasons? I read somewhere that they are not really fast but the > posts were old and the performance might have been improved in between. > Should I favor case and cond branches instead of defmulti when I need > performance? > multimethods are slower than protocols - they must effectively invoke the dispatch function, perform a linear search for a match across the cases, and then invoke the actual implementation function. Protocols leverage JVM internals to select the right implementation, then invoke it. However, the search part of multimethods is cached, making that step fast after the initial call. The last time I benchmarked multimethods with class dispatch vs protocols on Java 1.8 + Clojure 1.7 alphas (can't remember which one), I found multimethods were about 5x slower. If you want fastest type-based dispatch with open extension, then protocols are the best. If you want any other type of dispatch with open extension, then multimethods are the best. If you want a closed system of constant choices, then case is best (constant-time lookup!) If you want a closed system of arbitrary conditions, then cond is best. I have never compared the performance of cond vs multimethods for something like this. My guess is that multimethods are faster as they evaluate a single condition, then do a table lookup once cached vs evaluating a series of conditions every time. Alex -- 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: any?
I think 'some' fills this role. Given truthy values, why do you need to use boolean with it? On Saturday, April 25, 2015 at 8:32:09 PM UTC-5, Colin Taylor wrote: > > Any reason why we don't have `any?`. Googled without much luck. > Trivially done as `comp boolean some` not doubt, but I know I use it more > than not-any at least. > It's particularly useful as a composable `or`. > > > -- 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: any?
I think Ambrose is getting at what the original poster is after. I've written this a number of times, but seem to recall doing something like `(def any? (complement not-any?))`, though I'd need to go back and look. `not-any?` is just `(comp not some)` under the covers, so I guess I'm not sure why `any?` would be out of bounds in core. Cheers, Devin On Sat, Apr 25, 2015 at 8:56 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Do you mean any? as in > > (defn any? [p c] > (boolean (seq (filter? p c > > Thanks, > Ambrose > > On Sat, Apr 25, 2015 at 9:43 PM, Timothy Baldridge > wrote: > >> bleh, hit reply too fast. Or also returns the first true value, so (or >> false nil 42) returns 42. >> >> I guess I don't see when I'd use 'any?' >> >> On Sat, Apr 25, 2015 at 7:42 PM, Timothy Baldridge >> wrote: >> >>> But it's not really like `or >>> >>> On Sat, Apr 25, 2015 at 7:32 PM, coltnz wrote: >>> Any reason why we don't have `any?`. Googled without much luck. Trivially done as `comp boolean some` not doubt, but I know I use it more than not-any at least. It's particularly useful as a composable `or`. -- 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. >>> >>> >>> >>> -- >>> "One of the main causes of the fall of the Roman Empire was that-lacking >>> zero-they had no way to indicate successful termination of their C >>> programs." >>> (Robert Firth) >>> >> >> >> >> -- >> "One of the main causes of the fall of the Roman Empire was that-lacking >> zero-they had no way to indicate successful termination of their C >> programs." >> (Robert Firth) >> >> -- >> 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. > -- 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: any?
Do you mean any? as in (defn any? [p c] (boolean (seq (filter? p c Thanks, Ambrose On Sat, Apr 25, 2015 at 9:43 PM, Timothy Baldridge wrote: > bleh, hit reply too fast. Or also returns the first true value, so (or > false nil 42) returns 42. > > I guess I don't see when I'd use 'any?' > > On Sat, Apr 25, 2015 at 7:42 PM, Timothy Baldridge > wrote: > >> But it's not really like `or >> >> On Sat, Apr 25, 2015 at 7:32 PM, coltnz wrote: >> >>> Any reason why we don't have `any?`. Googled without much luck. >>> Trivially done as `comp boolean some` not doubt, but I know I use it >>> more than not-any at least. >>> It's particularly useful as a composable `or`. >>> >>> >>> -- >>> 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. >>> >> >> >> >> -- >> “One of the main causes of the fall of the Roman Empire was that–lacking >> zero–they had no way to indicate successful termination of their C >> programs.” >> (Robert Firth) >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > > -- > 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: any?
bleh, hit reply too fast. Or also returns the first true value, so (or false nil 42) returns 42. I guess I don't see when I'd use 'any?' On Sat, Apr 25, 2015 at 7:42 PM, Timothy Baldridge wrote: > But it's not really like `or > > On Sat, Apr 25, 2015 at 7:32 PM, coltnz wrote: > >> Any reason why we don't have `any?`. Googled without much luck. >> Trivially done as `comp boolean some` not doubt, but I know I use it more >> than not-any at least. >> It's particularly useful as a composable `or`. >> >> >> -- >> 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. >> > > > > -- > “One of the main causes of the fall of the Roman Empire was that–lacking > zero–they had no way to indicate successful termination of their C > programs.” > (Robert Firth) > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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: any?
But it's not really like `or On Sat, Apr 25, 2015 at 7:32 PM, coltnz wrote: > Any reason why we don't have `any?`. Googled without much luck. > Trivially done as `comp boolean some` not doubt, but I know I use it more > than not-any at least. > It's particularly useful as a composable `or`. > > > -- > 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. > -- “One of the main causes of the fall of the Roman Empire was that–lacking zero–they had no way to indicate successful termination of their C programs.” (Robert Firth) -- 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.
any?
Any reason why we don't have `any?`. Googled without much luck. Trivially done as `comp boolean some` not doubt, but I know I use it more than not-any at least. It's particularly useful as a composable `or`. -- 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: ClojureScript 0.0-3211
You need to make sure some other dependency isn't pulling in a different version of tools.reader. David On Sat, Apr 25, 2015 at 11:11 PM, Allen Rohner wrote: > > > On Saturday, April 25, 2015 at 12:02:08 PM UTC-5, Mike Fikes wrote: >> >> Hey Tony, try updating the version of Clojure in your project.clj to >> 1.7.0-beta1, which is used by 0.0-3211. >> >> (In short, reader/read was given a second arity to allow options to be >> passed, thus supporting #? conditional reading.) > > > I'm seeing the same behavior on 1.7.0-beta2. Yes, I've cleaned. > > -- > 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: ClojureScript 0.0-3211
On Saturday, April 25, 2015 at 4:11:40 PM UTC-5, Allen Rohner wrote: > > > > On Saturday, April 25, 2015 at 12:02:08 PM UTC-5, Mike Fikes wrote: >> >> Hey Tony, try updating the version of Clojure in your project.clj to >> 1.7.0-beta1, which is used by 0.0-3211. >> >> (In short, reader/read was given a second arity to allow options to be >> passed, thus supporting #? conditional reading.) > > > I'm seeing the same behavior on 1.7.0-beta2. Yes, I've cleaned. > Upgrading tools.reader fixed the problem for me. My project doesn't specify tools.reader, but a dependency does, and that was presumably pulling in an older version that the cljs compiler wanted. -- 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: ClojureScript 0.0-3211
On Saturday, April 25, 2015 at 12:02:08 PM UTC-5, Mike Fikes wrote: > > Hey Tony, try updating the version of Clojure in your project.clj to > 1.7.0-beta1, which is used by 0.0-3211. > > (In short, reader/read was given a second arity to allow options to be > passed, thus supporting #? conditional reading.) I'm seeing the same behavior on 1.7.0-beta2. Yes, I've cleaned. -- 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-beta1 released
Thank you Mr. Alex Miller! Fancy printing of exceptions is working :) Geraldo On Friday, April 10, 2015 at 4:26:30 PM UTC-3, Alex Miller wrote: > > Clojure 1.7.0-beta1 is now available. > > Try it via > - Download: > https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta1/ > - Leiningen: [org.clojure/clojure "1.7.0-beta1"] > > Regression fixes since 1.7.0-alpha6: > > 1) CLJ-1692 - make iterate match prior laziness > 2) CLJ-1694 - make cycle match prior laziness > 3) CLJ-1685 - correctly handle :eof option in read and read-string > > One faster sequence and reduce path that didn't quite make it into alpha6 > is now available - range is now faster for both the traditional sequence > use case (both chunked and unchunked traversal) and the fast reduce path. > > Also, since alpha6 was released, reader conditionals were ported to > tools.reader and the latest ClojureScript release now supports them, so now > is a great time to try them out! > > For all changes new in beta1, see the issues marked "(beta1)" in the > full changes below. > > > Clojure 1.7.0-beta1 has the following updates since 1.6.0: > > # Changes to Clojure in Version 1.7 > > ## 1 New and Improved Features > > ### 1.1 Transducers > > Transducers is a new way to decouple algorithmic transformations from their > application in different contexts. Transducers are functions that transform > reducing functions to build up a "recipe" for transformation. > > Also see: http://clojure.org/transducers > > Many existing sequence functions now have a new arity (one fewer argument > than before). This arity will return a transducer that represents the same > logic but is independent of lazy sequence processing. Functions included > are: > > * conj (conjs to []) > * map > * mapcat > * filter > * remove > * take > * take-while > * drop > * drop-while > * take-nth > * replace > * partition-by > * partition-all > * keep > * keep-indexed > * map-indexed > * distinct > * interpose > > Additionally some new transducer functions have been added: > > * cat - concatenates the contents of each input > * de-dupe - removes consecutive duplicated values > * random-sample - returns items from coll with random probability > > And this function can be used to make completing transforms: > > * completing > > There are also several new or modified functions that can be used to apply > transducers in different ways: > > * sequence - takes a transformation and a coll and produces a lazy seq > * transduce - reduce with a transformation (eager) > * eduction - returns a reducible/iterable of applications of the > transducer to items in coll. Applications are re-performed with every > reduce/iterator. > * run! - run the transformation for side effects on the collection > > There have been a number of internal changes to support transducers: > > * volatiles - there are a new set of functions (volatile!, vswap!, > vreset!, volatile?) to create and use volatile "boxes" to hold state in > stateful transducers. Volatiles are faster than atoms but give up atomicity > guarantees so should only be used with thread isolation. > * array iterators - added support for iterators over arrays > > Some related issues addressed during development: > * [CLJ-1511](http://dev.clojure.org/jira/browse/CLJ-1511) > * [CLJ-1497](http://dev.clojure.org/jira/browse/CLJ-1497) > * [CLJ-1549](http://dev.clojure.org/jira/browse/CLJ-1549) > * [CLJ-1537](http://dev.clojure.org/jira/browse/CLJ-1537) > * [CLJ-1554](http://dev.clojure.org/jira/browse/CLJ-1554) > * [CLJ-1601](http://dev.clojure.org/jira/browse/CLJ-1601) > * [CLJ-1606](http://dev.clojure.org/jira/browse/CLJ-1606) > * [CLJ-1621](http://dev.clojure.org/jira/browse/CLJ-1621) > * [CLJ-1600](http://dev.clojure.org/jira/browse/CLJ-1600) > * [CLJ-1635](http://dev.clojure.org/jira/browse/CLJ-1635) > * [CLJ-1683](http://dev.clojure.org/jira/browse/CLJ-1683) > * [CLJ-1669](http://dev.clojure.org/jira/browse/CLJ-1669) > > ### 1.2 Reader Conditionals > > Reader Conditionals are 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 ar
Re: ANN: ClojureScript 0.0-3211
Hey Tony, try updating the version of Clojure in your project.clj to 1.7.0-beta1, which is used by 0.0-3211. (In short, reader/read was given a second arity to allow options to be passed, thus supporting #? conditional reading.) -- 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: ClojureScript 0.0-3211
Hi, I'm getting the following error when running cljsbuild with the latest clojurescript build (3211). Changing back to 3126 makes the build work. Haven't been able to pinpoint the source. clojure.lang.ArityException: Wrong number of args (2) passed to: reader/read at clojure.lang.AFn.throwArity(AFn.java:429) at clojure.lang.AFn.invoke(AFn.java:36) at cljs.analyzer$forms_seq_STAR_$forms_seq___1930$fn__1931$fn__1932.invoke(analyzer.clj:2001) at cljs.analyzer$forms_seq_STAR_$forms_seq___1930$fn__1931.invoke(analyzer.clj:1995) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at cljs.analyzer$parse_ns$fn__1946.invoke(analyzer.clj:2072) at cljs.analyzer$parse_ns.invoke(analyzer.clj:2055) at cljs.analyzer$parse_ns.invoke(analyzer.clj:2046) at cljs.compiler$compile_root$fn__3062.invoke(compiler.clj:1170) at clojure.core$map$fn__4245.invoke(core.clj:2559) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at clojure.core$map$fn__4245.invoke(core.clj:2551) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at clojure.core.protocols$seq_reduce.invoke(protocols.clj:30) at clojure.core.protocols$fn__6078.invoke(protocols.clj:54) at clojure.core.protocols$fn__6031$G__6026__6044.invoke(protocols.clj:13) at clojure.core$reduce.invoke(core.clj:6289) at cljs.js_deps$build_index.invoke(js_deps.clj:126) at cljs.js_deps$dependency_order.invoke(js_deps.clj:166) at cljs.compiler$compile_root.invoke(compiler.clj:1171) at cljs.closure$compile_dir.invoke(closure.clj:378) at cljs.closure$eval3418$fn__3419.invoke(closure.clj:418) at cljs.closure$eval3354$fn__3355$G__3345__3362.invoke(closure.clj:325) at cljs.closure$eval3405$fn__3406.invoke(closure.clj:432) at cljs.closure$eval3354$fn__3355$G__3345__3362.invoke(closure.clj:325) at cljsbuild.compiler.SourcePaths$fn__3798.invoke(compiler.clj:67) at clojure.core$map$fn__4245.invoke(core.clj:2557) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at clojure.core$apply.invoke(core.clj:624) at clojure.core$mapcat.doInvoke(core.clj:2586) at clojure.lang.RestFn.invoke(RestFn.java:423) at cljsbuild.compiler.SourcePaths._compile(compiler.clj:67) at cljs.closure$build.invoke(closure.clj:1446) at cljs.closure$build.invoke(closure.clj:1404) at cljsbuild.compiler$compile_cljs$fn__3809.invoke(compiler.clj:81) at cljsbuild.compiler$compile_cljs.invoke(compiler.clj:80) at cljsbuild.compiler$run_compiler.invoke(compiler.clj:179) at user$eval3941$iter__3959__3963$fn__3964$fn__3976.invoke(form-init4257815834781263139.clj:1) at user$eval3941$iter__3959__3963$fn__3964.invoke(form-init4257815834781263139.clj:1) at clojure.lang.LazySeq.sval(LazySeq.java:40) at clojure.lang.LazySeq.seq(LazySeq.java:49) at clojure.lang.RT.seq(RT.java:484) at clojure.core$seq.invoke(core.clj:133) at clojure.core$dorun.invoke(core.clj:2855) at clojure.core$doall.invoke(core.clj:2871) at user$eval3941.invoke(form-init4257815834781263139.clj:1) at clojure.lang.Compiler.eval(Compiler.java:6703) at clojure.lang.Compiler.eval(Compiler.java:6693) at clojure.lang.Compiler.load(Compiler.java:7130) at clojure.lang.Compiler.loadFile(Compiler.java:7086) at clojure.main$load_script.invoke(main.clj:274) at clojure.main$init_opt.invoke(main.clj:279) at clojure.main$initialize.invoke(main.clj:307) at clojure.main$null_opt.invoke(main.clj:342) at clojure.main$main.doInvoke(main.clj:420) at clojure.lang.RestFn.invoke(RestFn.java:421) at clojure.lang.Var.invoke(Var.java:383) at clojure.lang.AFn.applyToHelper(AFn.java:156) at clojure.lang.Var.applyTo(Var.java:700) at clojure.main.main(main.java:37) Subprocess failed -- 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: Meaning of part of the doc string for `ns-resolve`
I have found long docs like that to be useful in some major top-level function if it has a large sort of input and configuration parameters to pass in. Markdown I believe means with back ticks around the symbol to make it stand out as an actual art name vs some other word in the sentence. I have seen this be a popular doc style in lisps that I've looked at. When case insensitive I've seen all caps used, which would not work in Clojures case. I've like the back tick markdown style since it doesn't get as easily confused with something like quote. I've also tended to use markdown ticks around code expressions of they were used in the doc string. I'm not sure I've seen a lot of that in the wild though. Doing that on every(most) function I'd be worried would be a maintenance issue. I've wrote doc string style where the arguments are enumerated in an obvious argument name -> description way. It definitely makes it unambiguous. I still tend to reserve that for "larger", more complex functions. While in simpler functions just ensuring all args referenced directly and markdown ticked and are described in a natural type of sentence/paragraph. The idea of consistently naming arguments/types of arguments a certain way is obviously nice too -- 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.
Performance of defmulti in both ClojureScript and Clojure
Hi everyone, There are situations where I want to dispatch functions using based on their certain properties. I can also use case statements instead but it looks more coupled and more change is required if I want to add new types. What I want to ask is if I need to avoid using multi-methods for performance reasons? I read somewhere that they are not really fast but the posts were old and the performance might have been improved in between. Should I favor case and cond branches instead of defmulti when I need performance? Thanks for your help!!! Regards. Timur -- 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: Could type function (type X) print nothing?
My god, you save me. Thanks! 2015년 4월 25일 토요일 오후 12시 48분 25초 UTC+9, James Reeves 님의 말: > > (str nil) > => "" > (type nil) > => nil > (str (type nil)) > => "" > > Rather than use `str`, try using `pr-str` to get a more accurate > representation of the data: > > (pr-str nil) > => "nil" > > - James > > On 25 April 2015 at 03:23, 임정택 > wrote: > >> Hello, Clojure users. >> >> I'm a beginner of Clojure, so it could be a dumb question. >> >> >> I'm playing with Apache Storm, and I leave below line to see tuple value >> when something is wrong. >> >> >> (log-warn "Can't transfer tuple - task value is null. tuple type: " (type >> tuple) " and information: " tuple) >> >> >> log-warn is defined... >> >> >> (ns backtype.storm.log >> >> (:require [clojure.tools [logging :as log]])) >> >> >> (defmacro log-warn >> [& args] >> `(log/warn (str ~@args))) >> >> >> But it prints like... >> >> >> 2015-04-23T14:46:59.517+0200 b.s.d.worker [WARN] Can't transfer tuple - task >> value is null. tuple type: and information: >> >> >> Evaluated value of (type tuple) and tuple value (maybe toString()?) doesn't >> printed. >> >> Is this possible? If possible, please let me know what type the tuple can be. >> >> >> Thanks! >> >> >> Regards. >> >> Jungtaek Lim (HeartSaVioR) >> >> -- >> 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: Meaning of part of the doc string for `ns-resolve`
On Saturday, April 25, 2015 at 1:47:27 AM UTC-4, Mike Rodriguez wrote: > > I agree about wanting to use the explicit argument name surrounded by > markdown quotes in docs. I've definitely started adopting this practice and > wish there were conventions around this sort of thing. Without it, doc > strings can easily get ambiguous and confusing in how they relate the the > actual arguments of the function (in function docs that is). > > I also try to make it a point to mention each argument of he function in > the doc string... I don't know what exactly is meant by "markdown quotes", but here's a style I saw in the docstrings for a game dungeon generator written in Clojure: "Erodes one or more chasms, rivers of water or lava, canyons, or etc. or builds one or more walls across a dungeon, depending on the passed in template. Affected squares are subjected to erode-square. If num-chasms is higher than 1, num-chasms wrap-around chasms will be created that each randomly runs in one of 8 directions: north-south, east-west, NE-SW, NW-SE, and the four directions that have a 1:2 or 2:1 gradient. If num-chasms is 1, up to three chasms will actually be created. There will be a master chasm that is a wrap-around chasm as per the above, with equal probabilities of these five outcomes: 1. There is only the master chasm created, and it lacks an island. 2. The master chasm has an island of unaffected dungeon in a wide spot at a random place; equivalently, it forks and rejoins in one area. 3. There is a secondary chasm that runs from a random point along the master chasm, wraps at a random dungeon border, and ends at the master chasm at a usually-different random point. This chasm is narrower than the master chasm. 4. As in 3, but the master chasm also has an island as in 2, generally away from either of the endpoints of the secondary chasm. 5. As in 3, plus there's a tertiary chasm, narrower still, that joins a random point of the secondary chasm to a random point of the primary chasm, without wrapping. The latter point is generally not near either of the secondary chasm's endpoints. A triangular island is generally the result, bounded by sections of all three chasms, one on each side. If only the master chasm is created, or if num-chasms > 1, then if any master chasm runs north-south, ENE-WSW, or ESE-WNW, the dungeon gains an :ewblocked true mapping, and if any master chasm runs in any other direction the dungeon gains an :nsblocked true mapping. If a secondary chasm is created both mappings are created. Exception: neither mapping is created if the template is a wall or a floor square. These keys interact with build/create-rpm when one wants chasms to inhibit wrapping as much as possible and then only artificially inhibit rooms/passages from wrapping to the extent that chasms inhibited it. Arguments: d - dungeon to modify num-chasms - see above. Optional. Defaults to 1. template - chasm squares are changed into this width - master chasm is this wide; secondary is 1/4 to 3/4 this wide and tertiary is 1/4 to 3/4 as wide as secondary, all with a minimum of 2. variance - width of master chasm can vary by +/- this much. Variances of secondary and tertiary chasms are scaled down with their widths. v2 - effectively randomly perturbs width. If num-chasms > 1, each has its own randomly adjusted width. If num-chasms == 1, the master chasm does, and its width in turn influences any secondary and tertiary chasms' widths as per the above. no-secondary-features? - if true, and num-chasms is 1, only the master chasm is created -- no islands, secondary chasms, etc.; ignored if num-chasms > 1 (treated as true). Optional. Defaults to false." That project had hundreds of functions like these spread across a moderate number of namespaces, and seemed to embody a fair degree of simulation detail -- inspired by Dwarf Fortress, perhaps? And super-documented. I wouldn't be surprised if there were more LOC in docstrings than in actual executable clojure, based on browsing the repository. The author clearly made sure that if he erred, it was on the side of over-documenting rather than under-documenting everything. The relevant thing here is that there's a separate section of the function docs just listing arguments, by name, with their effects. No room for ambiguity there. Nearly all of them start with "d - dungeon to modify", as well, so clearly that API was designed with the thread-first macro in mind for performing sequences of transformations. -- 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 ne
