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 are unread. If no branch is selected, the reader reads nothing (not nil, but literally as if reading ). An optional :default branch can
Re: [ANN] Clojure 1.7.0-beta1 released
I logged it with a patch here - thanks very much for that report. It's tricky because you have to start realizing a chunk before you can see this, so the existing serialization tests for range (which didn't do this) were working! http://dev.clojure.org/jira/browse/CLJ-1713 On Monday, April 20, 2015 at 9:04:59 PM UTC-7, Alex Miller wrote: The serializable thing is not intentional - would definitely like to fix it! -- 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
The serializable thing is not intentional - would definitely like to fix it! -- 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
Just tried the beta on our test suite. Aside from warnings from new Clojure functions now shadowed by existing functions and obvious cases of hash sensitivity, there are a couple less clear-cut cases (which likely fall into the above hash case but will require further investigation), and we also notice that (range 100) cannot be serialized because clojure.lang.LongRange$LongChunk is not Serializable -- not sure if that's intentional. Will follow up when we resolve the remaining test failures. Looking forward to the release -- thanks! On Friday, April 10, 2015 at 12:26:16 PM UTC-7, 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*
Re: [ANN] Clojure 1.7.0-beta1 released
Possible issue with doseq in 1.7.0-beta1? Was working in 1.7.0-alpha5. (Found with clj-jgit) Leiningen 2.5.1 on Java 1.8.0_31 Java HotSpot(TM) 64-Bit Server VM Error: #error{:cause Unable to resolve symbol: private-key in this context, :via [{:type clojure.lang.Compiler$CompilerException, :message java.lang.RuntimeException: Unable to resolve symbol: private-key in this context, compiling:(clj_jgit/porcelain.clj:481:40), :at [clojure.lang.Compiler analyze Compiler.java 6543]} {:type java.lang.RuntimeException, :message Unable to resolve symbol: private-key in this context, :at [clojure.lang.Util runtimeException Util.java 221]}], :trace [[clojure.lang.Util runtimeException Util.java 221] … Files: ;; project.clj (defproject abc 0.1.0-SNAPSHOT :main abc.core :dependencies [;[org.clojure/clojure 1.7.0-alpha5] ;;- no error [org.clojure/clojure 1.7.0-beta1] [clj-jgit 0.8.4]]) ;; src/abc/core.clj (ns abc.core (:require clj-jgit.porcelain)) Link to clj-jgit: https://github.com/clj-jgit/clj-jgit/blob/7817456d55793095fd7dac5de92a0796ded25572/src/clj_jgit/porcelain.clj#L481 -- 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
This looks like the minimal case: ;; beta1 user= (let [x 1] (let [{:keys [a b] :or {a b}} {}] a)) CompilerException java.lang.RuntimeException: Unable to resolve symbol: b in this context, compiling:(/tmp/form-init3618156055290903409.clj:1:12) This returns nil in at least alpha1, could someone else please figure out exactly where this fails? Thanks, Ambrose On Sun, Apr 19, 2015 at 3:08 PM, vrak...@gmail.com wrote: Possible issue with doseq in 1.7.0-beta1? Was working in 1.7.0-alpha5. (Found with clj-jgit) Leiningen 2.5.1 on Java 1.8.0_31 Java HotSpot(TM) 64-Bit Server VM Error: #error{:cause Unable to resolve symbol: private-key in this context, :via [{:type clojure.lang.Compiler$CompilerException, :message java.lang.RuntimeException: Unable to resolve symbol: private-key in this context, compiling:(clj_jgit/porcelain.clj:481:40), :at [clojure.lang.Compiler analyze Compiler.java 6543]} {:type java.lang.RuntimeException, :message Unable to resolve symbol: private-key in this context, :at [clojure.lang.Util runtimeException Util.java 221]}], :trace [[clojure.lang.Util runtimeException Util.java 221] … Files: ;; project.clj (defproject abc 0.1.0-SNAPSHOT :main abc.core :dependencies [;[org.clojure/clojure 1.7.0-alpha5] ;;- no error [org.clojure/clojure 1.7.0-beta1] [clj-jgit 0.8.4]]) ;; src/abc/core.clj (ns abc.core (:require clj-jgit.porcelain)) Link to clj-jgit: https://github.com/clj-jgit/clj-jgit/blob/7817456d55793095fd7dac5de92a0796ded25572/src/clj_jgit/porcelain.clj#L481 -- 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-beta1 released
We deployed beta1 to production this morning. I’ll report back if we encounter any problems (generally we’ve found Clojure pre-release builds to be very stable). We were previously running alpha5 in production. Sean On Apr 10, 2015, at 12:25 PM, Alex Miller a...@puredanger.com 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/ 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. … -- 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
I've been running beta1 in production since about 1 day after it was announced. Everything's been smooth so far :D On Friday, 17 April 2015 06:51:53 UTC+12, Sean Corfield wrote: We deployed beta1 to production this morning. I’ll report back if we encounter any problems (generally we’ve found Clojure pre-release builds to be very stable). We were previously running alpha5 in production. Sean On Apr 10, 2015, at 12:25 PM, Alex Miller al...@puredanger.com javascript: 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. … -- 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
Hi, Fancy printing is not working. Geraldo -- 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 ! We live inside our heads but we expend much time inside repl. This is very much appreciated! Geraldo On Tuesday, April 14, 2015 at 2:56:44 PM UTC-3, Alex Miller wrote: Well, we never added fancy printing, just data printing of Throwables. :) But we were working on this in the context of another thing that got moved out and I have pulled that back as a separate ticket: http://dev.clojure.org/jira/browse/CLJ-1703 Haven't talked to Rich about it yet, but we'll discuss for 1.7. On Tuesday, April 14, 2015 at 6:06:49 AM UTC-5, Geraldo Lopes de Souza wrote: Hi, Fancy printing is not working. Geraldo -- 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
Well, we never added fancy printing, just data printing of Throwables. :) But we were working on this in the context of another thing that got moved out and I have pulled that back as a separate ticket: http://dev.clojure.org/jira/browse/CLJ-1703 Haven't talked to Rich about it yet, but we'll discuss for 1.7. On Tuesday, April 14, 2015 at 6:06:49 AM UTC-5, Geraldo Lopes de Souza wrote: Hi, Fancy printing is not working. Geraldo -- 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
On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- 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: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Your particular example is equivalent to #?(:clj) which is illegal, for the reason given in the error message you saw. Normal Clojure comments are far less surprising in their behavior than #_ is I understand there can be convenience in using #_ when it works. Andy Sent from my iPhone On Apr 13, 2015, at 12:38 PM, whodidthis ton...@gmail.com wrote: On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Just noticed that I sent my previous email to clojure-dev only – reposting to all groups involved: On 13 April 2015 at 16:25, Michał Marczyk michal.marc...@gmail.com wrote: On 13 April 2015 at 15:48, Alex Miller a...@puredanger.com wrote: To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Actually this doesn't work because of the cond-like structure of #? conditionals: user= (read-string {:read-cond :allow} #?(:clj #_foo) bar) RuntimeException read-cond requires an even number of forms. clojure.lang.Util.runtimeException (Util.java:221) To this I would add that it is possible to say Clojure 1.7.0-beta1 user= (read-string {:read-cond :allow} #?(#_#_:clj foo) bar) bar taking advantage of the nice stacking property of #_ (which follows from the recursive nature of the reader in the same way that the original surprising case does). Cheers, Michał On 13 April 2015 at 21:38, whodidthis ton...@gmail.com wrote: On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) Sorry, back to this stuff again. I tried using discard inside but #?(:clj #_'whatever) just throws CompilerException java.lang.RuntimeException: read-cond starting on line 32 requires an even number of forms when compiling on clojure. Would be nice to have a way to ignore reader conditional forms or the thingie things inside but there does not seem to be an easy way. -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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
Why would that be fine? On Sunday, April 12, 2015 at 10:39:17 PM UTC+2, whodidthis wrote: Are there any thoughts on code like this: #_#?(:cljs (def unrelated-1 nil)) #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) #?(:clj (def n 10)) #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh -- 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
Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinney...@gmail.com wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Ahh ok, makes sense. mandag 13. april 2015 12.45.35 UTC+2 skrev David Nolen følgende: The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinn...@gmail.com javascript: wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescrip...@googlegroups.com javascript:. To post to this group, send email to clojur...@googlegroups.com javascript:. Visit this group at http://groups.google.com/group/clojurescript. -- 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: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
There is a ticket to consider a portable solution to this issue: http://dev.clojure.org/jira/browse/CLJ-1293 On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote: The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinn...@gmail.com javascript: wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- 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
I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) -- 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: [ClojureScript] Re: [ANN] Clojure 1.7.0-beta1 released
Ouch! But that actually makes a lot of sense. On Mon, 13 Apr 2015 14:58 Alex Miller a...@puredanger.com wrote: There is a ticket to consider a portable solution to this issue: http://dev.clojure.org/jira/browse/CLJ-1293 On Monday, April 13, 2015 at 5:45:35 AM UTC-5, David Nolen wrote: The only reason :default exists is because *anything* in JavaScript can be thrown and there needs to be some way to catch non-Error derived values. This is not the case for Java of course. :default could probably be aliased to Throwable, but in the meantime differences like this are now handleable via conditional reading. David On Mon, Apr 13, 2015 at 6:37 AM, Robin Heggelund Hansen skinn...@gmail.com wrote: Hmm... In Clojurescript you can do the following (try ;; throw something (catch :default e e)) When I try the same thing in Clojure, it seems to not be supported. Is there any plans to support this syntax in Clojure 1.7? -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups ClojureScript group. To unsubscribe from this group and stop receiving emails from it, send an email to clojurescript+unsubscr...@googlegroups.com. To post to this group, send email to clojurescr...@googlegroups.com. Visit this group at http://groups.google.com/group/clojurescript. -- 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
Sounds like you guys have it figured out; conditional reading forms cannot be ignored, only their results. Just wanted to make sure, had some bad times with it heh On Monday, April 13, 2015 at 4:48:28 PM UTC+3, Alex Miller wrote: I think what you're seeing here makes sense. On Sunday, April 12, 2015 at 3:39:15 PM UTC-5, whodidthis wrote: Are there any thoughts on code like this: #_ This says to ignore the next read form #?(:cljs (def unrelated-1 nil)) This evaluates to *nothing*, ie nothing is read, so it is not ignored by the #_. #?(:cljs (def unrelated-2 nil)) #?(:cljs (def unrelated-3 nil)) These also read as *nothing*. #?(:clj (def n 10)) This *is* read, but ignored per the prior #_ #?(:clj (defn num [] n)) ; compile on clj =RuntimeException: Unable to resolve symbol: n And then this makes sense. I guess it's fine if it continues to work that way but I can imagine it being a little surprising from time to time heh Conditional reading is definitely something to be careful about - I think in this case you are combining two types of conditional reading so be doubly careful. :) To get the effect you want in this, using #_ *inside* the reader conditional would work: #?(:cljs #_(def unrelated-1 nil)) -- 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.