Re: When to use metadata
Solussd is absolutely correct, but maybe even more simplistic (or easier to
grasp) explanation would be to use metadata if you don't want the
additional (meta)data to change the equality semantics of the map, for
example:
(def test-desc1 {:number-of-threads 10})
(def test-desc2 ^{:integration true} {:number-of-threads 10})
(def test-desc3 {:number-of-threads 10 :integration true})
(= test-desc1 test-desc2) ;; returns true
(= test-desc1 test-desc2 test-desc3) ;; returns false, because while the
first two vars reference equal values, the third one doesn't
Dňa štvrtok, 29. januára 2015 16:10:34 UTC+1 Jonathon McKitrick napísal(-a):
Is there a rule of thumb or set of use cases when metadata is a more
elegant solution than simply adding more entries to a map or record?
--
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.
When to use metadata
Is there a rule of thumb or set of use cases when metadata is a more elegant solution than simply adding more entries to a map or record? -- 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: When to use metadata
Yes- when the data you want to add shouldn't affect the value of the map. --- Joe R. Smith @solussd On Jan 29, 2015, at 9:10 AM, Jonathon McKitrick jmckitr...@gmail.com wrote: Is there a rule of thumb or set of use cases when metadata is a more elegant solution than simply adding more entries to a map or record? -- 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: gofmt like tool for Clojure?
Thanks, Lucas, this is exactly what I was looking for! On Wed, Jan 28, 2015 at 9:50 PM, Lucas Bradstreet lucasbradstr...@gmail.com wrote: This was released recently: https://github.com/weavejester/cljfmt On 29 January 2015 at 10:20, Papa Balyo papaba...@gmail.com wrote: Greetings, Is there a tool that reads .clj(s) source file and prints it in canonical fashion? (things like equal number of blank lines between forms, consistent placement of arguments vector in defn, etc.) I use Cursive IDE and it does nice indentation, but it is not enough. Ideally I would like to see code style enforcement before committing to VCS. Thanks! -- 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: core.match: order of patterns
On Thu, Jan 29, 2015 at 10:46:45AM +, László Török wrote: One thing that isn't obvious to me, how it should work when matching more than one pattern. I can't seem to find it anywhere in the core.match wiki, but I'm fairly sure it tries them in order, returning the first one that matches. In the following example, the expression returns 3 or 4 depending on which pattern comes first: (require '[clojure.core.match :as cm]) (cm/match [:a true false] [_ _ true] 1 [:a _ true] 2 [:a true false] 4 [:a true _] 3) This would return 4 because the 4 matches before the 3. If you were to swap their orders then it would return 3. (cm/match [:a true false] [_ _ true] 1 [:a _ true] 2 [:a true _] 3 [:a true false] 4) ;; = 3 Is it correct to assume, that the algorithm constructs an decision tree that will hit a minimum amount of patterns, however, if there are more than one matching clauses, its result is an arbitrary choice of the possible decisions? It will try to create a decision tree to efficiently check the patterns, but they will be checked (at least conceptually) in order. So this: (cm/match [:a true false] [_ _ _] 1 [:a _ true] 2 [:a true _] 3 [:a true false] 4) ;; = 1 doesn't get past the first pattern, despite the fact that the later ones are more specific. I hope that helps! Carlo -- 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.
core.match: order of patterns
Hi, I started experimenting with core.match. One thing that isn't obvious to me, how it should work when matching more than one pattern. In the following example, the expression returns 3 or 4 depending on which pattern comes first: (require '[clojure.core.match :as cm]) (cm/match [:a true false] [_ _ true] 1 [:a _ true] 2 [:a true false] 4 [:a true _] 3 ) where as I'd expect it would go for the most-specific match at least where the choice is between a wildcard and non-wildcard option. Is it correct to assume, that the algorithm constructs an decision tree that will hit a minimum amount of patterns, however, if there are more than one matching clauses, its result is an arbitrary choice of the possible decisions? Thanks! Laszlo -- 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] Hoplon: web applications in Clojure and ClojureScript
2013-12-20 21:42 GMT+01:00 Alan Dipert a...@dipert.org: The result, in my opinion, is mindblowingly beautiful and extremely powerful. By making the DOM a Lisp - and not just any Lisp, ClojureScript - we have a means to *real* DOM component modularity. The exact same modularity that you get with things like namespaces and closures. Where various other HTML component systems drag in their own reference types and scoping rules and evaluation semantics, we have just ClojureScript's usual rules. That's because, via the IFn protocol, it's possible for us to make DOM elements invokable. As implementers of IFn, hlisp-generated DOM nodes can participate fully in the ClojureScript world without introducing new scoping constructs or DOM-specific composition rules. As a result of all this, we have no need to represent HTML anywhere as data. Everything is a program, and expressions in this program may evaluate to DOM. There are no templates, just expressions. I encourage you to check out our Getting Started page to see just how powerful functional composition can be when applied over Lispified DOM nodes. Maybe I'm off track here, but this resounds to me as similar to the arguments that I listened to in lecture 2a of the SICP course. In that lecture, they introduce the representation and manipulation of pictures. They introduce a single primitive and then build on top of that. They create a dsl specific to pictures processing that is embedded into lisp. So it inherits from lisp the common means of expression (abstraction, combination, recursion and whatnot) I see a sort of kinship, here, between DOM elements and SICP pictures. In fact, they stress that data representing pictures are the same kind of lisp citizens we already knew. Data are blurred with the language, in lisp. In the DOM case macros are necessary because there's the html to deal with. So I guess that the solution is to use the macros to end up with lisp stuff and then work with that, rather than the other way around. I hope I didn't make myself a fool, here -- 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-alpha5 now available
Jozef, I looked into this and opened a ticket with a proposed patch to fix this issue: http://dev.clojure.org/jira/browse/CLJ-1650 Jozef Wagner writes: With CLJ-979 applied, lein may crash when doing :aot :all. This is caused when lein forces recompilation of already compiled classes. Not sure whether this should be considered a lein of clojure bug though. See https://github.com/wagjo/aotbug for contrived example. Jozef On Saturday, January 10, 2015 at 4:37:04 PM UTC+1, Alex Miller wrote: Clojure 1.7.0-alpha5 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha5/ - Leiningen: [org.clojure/clojure 1.7.0-alpha5] A few of the highlights in alpha5: 1) New transducer arities for map-indexed, distinct, and interpose. The transducer versions are generally faster than the sequence versions. See CLJ-1601 for more details. 2) The set and vec functions should now be faster in many cases. Some of the vec improvements will not kick in until CLJ-1499 is committed in the future. See CLJ-1546 and CLJ-1618 for more details. 3) Two particularly troublesome AOT classloading bugs have been addressed - CLJ-979 and CLJ-1544. Many other tickets were found to be duplicates of one of these as well. Big thanks to Nicola Mometto for doing the hard work on debugging and providing fixes for these. For all changes new in alpha5, see the issues marked (alpha5) in the full changes below. Clojure 1.7.0-alpha5 has the changes below from 1.6.0: ## 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 * cycle * take-nth * replace * partition-by * partition-all * keep * keep-indexed * map-indexed (alpha5) * distinct (alpha5) * interpose (alpha5) 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/seqable/iterable seq of applications of the transducer to items in coll. Applications are re-performed with every reduce/seq/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) (alpha5) * [CLJ-1606](http://dev.clojure.org/jira/browse/CLJ-1606) (alpha5) * [CLJ-1621](http://dev.clojure.org/jira/browse/CLJ-1621) (alpha5) * [CLJ-1600](http://dev.clojure.org/jira/browse/CLJ-1600) (alpha5) ### 1.2 Keyword and Symbol Construction In response to issues raised in [CLJ-1439]( http://dev.clojure.org/jira/browse/CLJ-1439), several changes have been made in symbol and keyword construction: 1) The main bottleneck in construction of symbols (which also occurs inside keywords) was interning of the name and namespace strings. This interning has been removed, resulting in a performance increase. 2) Keywords are cached and keyword construction includes a cache check. A change was made to only clear the cache reference queue when there is a cache miss. ### 1.3 Warn on Boxed Math One source of performance issues is the (unintended) use of arithmetic operations on boxed numbers. To make detecting the presence of boxed math easier, a warning will now be emitted
Re: [ANN] Clojure 1.7.0-alpha5 now available
Thank you very much Nicola! On Thu, Jan 29, 2015 at 7:24 PM, Nicola Mometto brobro...@gmail.com wrote: Jozef, I looked into this and opened a ticket with a proposed patch to fix this issue: http://dev.clojure.org/jira/browse/CLJ-1650 Jozef Wagner writes: With CLJ-979 applied, lein may crash when doing :aot :all. This is caused when lein forces recompilation of already compiled classes. Not sure whether this should be considered a lein of clojure bug though. See https://github.com/wagjo/aotbug for contrived example. Jozef On Saturday, January 10, 2015 at 4:37:04 PM UTC+1, Alex Miller wrote: Clojure 1.7.0-alpha5 is now available. Try it via - Download: https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-alpha5/ - Leiningen: [org.clojure/clojure 1.7.0-alpha5] A few of the highlights in alpha5: 1) New transducer arities for map-indexed, distinct, and interpose. The transducer versions are generally faster than the sequence versions. See CLJ-1601 for more details. 2) The set and vec functions should now be faster in many cases. Some of the vec improvements will not kick in until CLJ-1499 is committed in the future. See CLJ-1546 and CLJ-1618 for more details. 3) Two particularly troublesome AOT classloading bugs have been addressed - CLJ-979 and CLJ-1544. Many other tickets were found to be duplicates of one of these as well. Big thanks to Nicola Mometto for doing the hard work on debugging and providing fixes for these. For all changes new in alpha5, see the issues marked (alpha5) in the full changes below. Clojure 1.7.0-alpha5 has the changes below from 1.6.0: ## 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 * cycle * take-nth * replace * partition-by * partition-all * keep * keep-indexed * map-indexed (alpha5) * distinct (alpha5) * interpose (alpha5) 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/seqable/iterable seq of applications of the transducer to items in coll. Applications are re-performed with every reduce/seq/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) (alpha5) * [CLJ-1606](http://dev.clojure.org/jira/browse/CLJ-1606) (alpha5) * [CLJ-1621](http://dev.clojure.org/jira/browse/CLJ-1621) (alpha5) * [CLJ-1600](http://dev.clojure.org/jira/browse/CLJ-1600) (alpha5) ### 1.2 Keyword and Symbol Construction In response to issues raised in [CLJ-1439]( http://dev.clojure.org/jira/browse/CLJ-1439), several changes have been made in symbol and keyword construction: 1) The main bottleneck in construction of symbols (which also occurs inside keywords) was interning of the name and namespace strings. This interning has been removed, resulting in a performance increase. 2) Keywords are cached and keyword construction includes a cache check. A change was made to only clear the cache reference queue
Re: Help sought on issue with AOT, hadoop, classloaders, and consistency of Clojure fn classes
Which version of Clojure are you using? Does clojure-hadoop or Schema include AOT-compiled versions of other libraries and/or core namespaces? If the answers are 1.7.0 Alpha 5 and yes then you've run into the same problem I and a few others did: the previously undefined behavior of loading both AOT and JIT versions of the same code now has a defined behavior (preferring AOT) - and you get this exception. Sean On Jan 28, 2015, at 11:39 PM, Jason Wolfe ja...@w01fe.com wrote: First off, I apologize in advance for not having a reduced test case, and express my sincere gratitude in advance for any assistance. I've been tearing my hair out for a day or so and not making headway, and figured someone here might recognize some keywords and have a pointer in the right direction. (I'm admittedly pretty green when it comes to class loading, and have largely exhausted my google fu). Problem: I'm submitting a hadoop job using clojure-hadoop. All is well with a simple job, but once I require something that transitively depends on Schema, I end up with: clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No implementation of method: :walker of protocol: #'schema.core/Schema found for class: clojure.core$long, compiling:(crane/config.clj:33:4) It works fine when run in-process with hadoop-mapreduce-client-jobclient, but not with bin/hadoop -jar. This stunk of a classloader issue, and after digging in it seems that there are multiple versions of clojure.core$long floating around. The version on which the protocol is extended is not the same class for the fn that the symbol 'long resolves to in client code. Context: clojure-hadoop is AOT-compiled, and after being loaded by hadoop it dynamically loads the target namespace (not AOT-compiled, nor any other of the code in question) using https://github.com/alexott/clojure-hadoop/blob/master/src/clojure_hadoop/load.clj#L3 From here, schema is transitively required, and then client namespaces attempt to use the Schema protocol to generate validators, and when the schema 'long is used (which resolves to the fn with class clojure.core$long), it fails to find the appropriate method. After repeated head-bashing, I've determined that there are (at least two) versions of the clojure.core$long class floating around -- the one used to extend the protocol, which stems from a DynamicClassLoader, and the one that 'long resolves to in client code, which stems from a URLClassLoader. The URLClassLoader is the loader of the current thread and Compiler, but not @(clojure.lang.Compiler/LOADER). Attempts: I've tried wrapping the clojure-hadoop loading code with .setContextClassLoader on some obvious candidates and binding *use-context-classloader* around the code doing the loading, with no avail. I've tried changing the schema code to reference the class in different ways (class (resolve 'long)), (class 'long), etc and that hasn't made a difference. I've checked and the clojure-hadoop jar doesn't contain any .class files for clojure, schema, or other offending code. Plea: I suspect there's something obvious I'm missing. (In retrospect it seems like the design of Schema may be suboptimal in light of this, but if possible I'd like to figure out a workaround without changing that substantially). Thanks in advance for your help -- any and all pointers are welcome. -Jason -- 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.
is this a bug in clojure.core/into ?
Hello,
I have clojure 1.6.0 I get these errors:
-- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8
user= ;; expecting {:a 1, :b 2}
user= (into {} '((:a 1) (:b 2)))
java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to
java.util.Map$Entry (NO_SOURCE_FILE:0)
user= ;; expecting {'([a 1] [b 2]) '([c 3] [d 4])}
user= (into {} '(([a 1] [b 2]) ([c 3] [d 4])))
java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast
to java.util.Map$Entry (NO_SOURCE_FILE:0)
-- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8
Is that a bug or expected behaviour?
The second error message is not even true (vectors can be cast into
map$entry).
Cheers,
Giovanni
--
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: Help sought on issue with AOT, hadoop, classloaders, and consistency of Clojure fn classes
On Thursday, January 29, 2015 at 9:45:25 AM UTC-8, Sean Corfield wrote: Which version of Clojure are you using? 1.6.0, both for AOT and at runtime. Does clojure-hadoop or Schema include AOT-compiled versions of other libraries and/or core namespaces? No, as far as I know the only AOT compiled code present is clojure-hadoop and possibly the Clojure jar itself. We may depend on other libs that are AOT as well, but none that live above schema. If the answers are 1.7.0 Alpha 5 and yes then you've run into the same problem I and a few others did: the previously undefined behavior of loading both AOT and JIT versions of the same code now has a defined behavior (preferring AOT) - and you get this exception. I guess this is probably a different issue then, but maybe there's a common workaround? Thanks for the quick reply! Sean On Jan 28, 2015, at 11:39 PM, Jason Wolfe ja...@w01fe.com javascript: wrote: First off, I apologize in advance for not having a reduced test case, and express my sincere gratitude in advance for any assistance. I've been tearing my hair out for a day or so and not making headway, and figured someone here might recognize some keywords and have a pointer in the right direction. (I'm admittedly pretty green when it comes to class loading, and have largely exhausted my google fu). *Problem: * I'm submitting a hadoop job using clojure-hadoop. All is well with a simple job, but once I require something that transitively depends on Schema, I end up with: clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No implementation of method: :walker of protocol: #'schema.core/Schema found for class: clojure.core$long, compiling:(crane/config.clj:33:4) It works fine when run in-process with hadoop-mapreduce-client-jobclient, but not with bin/hadoop -jar. This stunk of a classloader issue, and after digging in it seems that there are multiple versions of clojure.core$long floating around. The version on which the protocol is extended is not the same class for the fn that the symbol 'long resolves to in client code. *Context: * clojure-hadoop is AOT-compiled, and after being loaded by hadoop it dynamically loads the target namespace (not AOT-compiled, nor any other of the code in question) using https://github.com/alexott/clojure-hadoop/blob/master/src/clojure_hadoop/load.clj#L3 From here, schema is transitively required, and then client namespaces attempt to use the Schema protocol to generate validators, and when the schema 'long is used (which resolves to the fn with class clojure.core$long), it fails to find the appropriate method. After repeated head-bashing, I've determined that there are (at least two) versions of the clojure.core$long class floating around -- the one used to extend the protocol, which stems from a DynamicClassLoader, and the one that 'long resolves to in client code, which stems from a URLClassLoader. The URLClassLoader is the loader of the current thread and Compiler, but not @(clojure.lang.Compiler/LOADER). *Attempts:* I've tried wrapping the clojure-hadoop loading code with .setContextClassLoader on some obvious candidates and binding *use-context-classloader* around the code doing the loading, with no avail. I've tried changing the schema code to reference the class in different ways (class (resolve 'long)), (class 'long), etc and that hasn't made a difference. I've checked and the clojure-hadoop jar doesn't contain any .class files for clojure, schema, or other offending code. *Plea:* I suspect there's something obvious I'm missing. (In retrospect it seems like the design of Schema may be suboptimal in light of this, but if possible I'd like to figure out a workaround without changing that substantially). Thanks in advance for your help -- any and all pointers are welcome. -Jason -- 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: Switched map for record and got slower
Hey guys, The major problem was the (.name unit). Changed to (:name unit) and got the speed back. Still not very much faster than maps, but at least not so slow. Thank you for the info :) On Wednesday, January 28, 2015 at 9:00:37 PM UTC, Mike Rodriguez wrote: Sorry. That was a typo. I meant 1.8. I'm just referring to the version tagged on the Jira. -- 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.
datomic - datascript transfers
I am knocking out a webapp, backed by datomic on the server side and planning to use datascript in the client. the plan is to: 1) export a bunch of related data to the client (datomic query/pull/entity apis to create edn data suitable for transact into datascript) -- could be a one-time thing or seed data with more getting pulled later. 2) let the user change it about (transactions into datascript) 3) save all user changes back to datomic (could send complete list of transactions made on client back to server, but ideally one tx representing sum of all changes) One issue to deal with is identity. For example upserts and retractions (on both client and server) need to happen to the right entities. I have some plans for how it will all work, but before going into details I am just curious if anyone else has considered this general approach? Thanks, Henry -- 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: is this a bug in clojure.core/into ?
ah, just seen that Justin Smith reported the bug on JIRA
http://dev.clojure.org/jira/browse/CLJ-1651
On Thu, Jan 29, 2015 at 7:08 PM, Giovanni Gherdovich g.gherdov...@gmail.com
wrote:
Hello,
I have clojure 1.6.0 I get these errors:
-- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8
user= ;; expecting {:a 1, :b 2}
user= (into {} '((:a 1) (:b 2)))
java.lang.ClassCastException: clojure.lang.Keyword cannot be cast to
java.util.Map$Entry (NO_SOURCE_FILE:0)
user= ;; expecting {'([a 1] [b 2]) '([c 3] [d 4])}
user= (into {} '(([a 1] [b 2]) ([c 3] [d 4])))
java.lang.ClassCastException: clojure.lang.PersistentVector cannot be cast
to java.util.Map$Entry (NO_SOURCE_FILE:0)
-- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8 -- -- 8
Is that a bug or expected behaviour?
The second error message is not even true (vectors can be cast into
map$entry).
Cheers,
Giovanni
--
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: datomic - datascript transfers
I have considered the approach once and dropped it quickly. The key problem is the loss of atomicity. It introduces a second transactor (the Datascript transactor) and thus synchronization requirements that can rarely be fulfilled. One example where they would be fulfilled automatically is where the browser is the only instance with write access to the selected information. But in reality, this is almost never the case. Then, if you don't fulfill the synchronization requirements, your local DataScript database is an unreliable information source. Instead, you can change step 2 with Transactions into Datomic (via HTTP request to your app) and stream the relevant Datoms from d/tx-listen via SSD back into the Datascript DB. So you only do transactions into the Datascript DB indirectly. Best regards, Leon. On Thursday, January 29, 2015 at 3:24:57 PM UTC+1, henry w wrote: I am knocking out a webapp, backed by datomic on the server side and planning to use datascript in the client. the plan is to: 1) export a bunch of related data to the client (datomic query/pull/entity apis to create edn data suitable for transact into datascript) -- could be a one-time thing or seed data with more getting pulled later. 2) let the user change it about (transactions into datascript) 3) save all user changes back to datomic (could send complete list of transactions made on client back to server, but ideally one tx representing sum of all changes) One issue to deal with is identity. For example upserts and retractions (on both client and server) need to happen to the right entities. I have some plans for how it will all work, but before going into details I am just curious if anyone else has considered this general approach? Thanks, Henry -- 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 :advanced compilation extern only partly working.
I got to the bottom of it. It's almost embarrassing to say. But the path to
the w3c_audio.js extern file was wrong. Unfortunately, lein doesn't give
any sort of warning or error if any of the externs files don't exist. I'm
not sure if it's a cljsbuild issue, or a clojurescript issue, or a google
closure compiler issue.
So I am thinking I'll give adding this warning (or error?) to clojurescript
a go. I notice in clojurescript source that closure.clj deals with running
the closure compiler. I can see exactly where I want to add the warning (or
tweak the calling of google closure compiler). I could do this, but I'm
having trouble now running a locally built clojurescript.
I've checked it out. Added some debug. Then I build a jar with 'lein jar'.
I upload it to a local maven repository. I add that repository to my
project-with-the-missing-extern's project.clj. I lein deps. It grabs the
new jar. I lein cljsbuild, and the build begins, but then the build
explodes with:
Exception in thread main java.io.FileNotFoundException: Could not locate
clojure/data/json__init.class or clojure/data/json.clj on classpath: ,
compiling:(cljs/source_map.clj:1:1)
...
Caused by: java.io.FileNotFoundException: Could not locate
clojure/data/json__init.class or clojure/data/json.clj on classpath:
So this is now off the original topic, but how do you work on clojurescript
itself? What step am I missing thats leading to the missing
clojre/data/json.clj class on the classpath? What's the best workflow for
hacking clojurescript itself?
Regards
Crispin
On Wednesday, January 28, 2015 at 11:29:25 PM UTC+8, David Nolen wrote:
Run a `lein deps :tree` to compare the version of the Google Closure
Compiler you are getting.
David
On Wed, Jan 28, 2015 at 9:58 AM, Crispin Wellington retrogr...@gmail.com
javascript: wrote:
OK something very strange is going on. I tried the let block, and it was
the same in my project.
So I created a new minimal project, lein new mies test-sound, and made a
minimal test: https://github.com/retrogradeorbit/test-sound
And here it works!
Go back to my old project, and it doesn't.
So now I have to go and gradually work through the project differences to
see what's causing this. If I find anything, I'll post it.
Thanks for your help
Crispin
On Wednesday, January 28, 2015 at 10:06:52 PM UTC+8, David Nolen wrote:
I mentioned trying this in a `let` binding instead. What happens when
you try that?
David
On Wed, Jan 28, 2015 at 9:04 AM, Crispin Wellington
retrogr...@gmail.com wrote:
No, that's not it. So I tried:
(def audio-context (js/AudioContext.))
(.decodeAudioData audio-context (js/ArrayBuffer. 256) #(println ok %)
#(println error %))
and it compiled to:
;var zv = new AudioContext;
zv.Rd(new ArrayBuffer(256), function(a) {
return fo.c(mh([ok, a], 0));
}, function(a) {
return fo.c(mh([error, a], 0));
});
This has really got me stumped.
Crispin
On Wednesday, January 28, 2015 at 6:23:29 PM UTC+8, Thomas Heller wrote:
I just have a guess for you.
AudioContext.decodeAudioData parameters are declared as ArrayBuffer,
Function, Function but you are passing data which is a String not an
ArrayBuffer. Maybe the type inference thinks you are calling a method
that
is not defined in the externs?
Maybe it will work if you pass an ArrayBuffer? Other than that I see
no reason why it would munge the name.
/thomas
On Wednesday, January 28, 2015 at 2:14:31 AM UTC+1, Crispin Wellington
wrote:
Hi there,
I have been trying to compile some audio code in clojurescript in
advanced mode. I have setup the w3c_audio.js extern (from:
http://closureplease.com/externs/) into my extern list. When I
compile, it prevents the munging of AudioContext (without the extern,
this is being munged, so the extern is 'working'). But it doesn't
prevent
the munging of methods on AudioContext object.
A super minimal example (but not working code):
(def audio-context (js/AudioContext.))
(.decodeAudioData audio-context data #(println ok %) #(println
error %))
compiles with advanced to:
;var zv = new AudioContext;
zv.Rd(data, function(a) {
return fo.c(mh([a], 0));
}, function() {
return(0).call(null);
});
zv.Rd is wrong. It should be zv.decodeAudioData.
The externs file does indeed have this function prototype. here are
the excerpts:
/**
* @constructor
*/
var AudioContext = function() {};
/**
* @param {ArrayBuffer} audioData
* @param {Function} successCallback
* @param {Function=} errorCallback
*/
AudioContext.prototype.decodeAudioData = function(audioData,
successCallback,
errorCallback) {};
Why would closure compiler protect the AudioContext name, but munge
the decodeAudioData name? What am I doing wrong?
Regards
Crispin Wellington
--
You received this message because you are subscribed to the Google
Groups Clojure group.
To post to this group, send email to
Re: Help sought on issue with AOT, hadoop, classloaders, and consistency of Clojure fn classes
Hey, Just to be sure, are you loading the full uberjar to hadoop? On Wednesday, January 28, 2015 at 11:39:54 PM UTC-8, Jason Wolfe wrote: First off, I apologize in advance for not having a reduced test case, and express my sincere gratitude in advance for any assistance. I've been tearing my hair out for a day or so and not making headway, and figured someone here might recognize some keywords and have a pointer in the right direction. (I'm admittedly pretty green when it comes to class loading, and have largely exhausted my google fu). *Problem: * I'm submitting a hadoop job using clojure-hadoop. All is well with a simple job, but once I require something that transitively depends on Schema, I end up with: clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No implementation of method: :walker of protocol: #'schema.core/Schema found for class: clojure.core$long, compiling:(crane/config.clj:33:4) It works fine when run in-process with hadoop-mapreduce-client-jobclient, but not with bin/hadoop -jar. This stunk of a classloader issue, and after digging in it seems that there are multiple versions of clojure.core$long floating around. The version on which the protocol is extended is not the same class for the fn that the symbol 'long resolves to in client code. *Context: * clojure-hadoop is AOT-compiled, and after being loaded by hadoop it dynamically loads the target namespace (not AOT-compiled, nor any other of the code in question) using https://github.com/alexott/clojure-hadoop/blob/master/src/clojure_hadoop/load.clj#L3 From here, schema is transitively required, and then client namespaces attempt to use the Schema protocol to generate validators, and when the schema 'long is used (which resolves to the fn with class clojure.core$long), it fails to find the appropriate method. After repeated head-bashing, I've determined that there are (at least two) versions of the clojure.core$long class floating around -- the one used to extend the protocol, which stems from a DynamicClassLoader, and the one that 'long resolves to in client code, which stems from a URLClassLoader. The URLClassLoader is the loader of the current thread and Compiler, but not @(clojure.lang.Compiler/LOADER). *Attempts:* I've tried wrapping the clojure-hadoop loading code with .setContextClassLoader on some obvious candidates and binding *use-context-classloader* around the code doing the loading, with no avail. I've tried changing the schema code to reference the class in different ways (class (resolve 'long)), (class 'long), etc and that hasn't made a difference. I've checked and the clojure-hadoop jar doesn't contain any .class files for clojure, schema, or other offending code. *Plea:* I suspect there's something obvious I'm missing. (In retrospect it seems like the design of Schema may be suboptimal in light of this, but if possible I'd like to figure out a workaround without changing that substantially). Thanks in advance for your help -- any and all pointers are welcome. -Jason -- 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: Help sought on issue with AOT, hadoop, classloaders, and consistency of Clojure fn classes
Thanks for the help everyone. After some more fiddling, with two changes I can hack things to work but it's not pretty. First, this change to schema: https://github.com/Prismatic/schema/commit/e835d447ea2525471a40d65768b5e6435a469fc7 Second, if I just (require 'top-level-ns) things still break, but if I execute a careful sequence of steps like (require 'schema.core 'another-ns 'yet-another-ns 'top-level-ns) where the intermediate ones are the place things were breaking, then everything works fine. I'm guessing this is something to do with a nested sequence of classloaders created along the namespace loading chain, which this effectively flattens out so that the problem namespaces are loaded with the root classloader. But I'm admittedly out of my depth here. We'd obviously like to avoid such hackery; does this extra info give enough context for anyone to offer a better solution? Thanks! Jason On Wednesday, January 28, 2015 at 11:39:54 PM UTC-8, Jason Wolfe wrote: First off, I apologize in advance for not having a reduced test case, and express my sincere gratitude in advance for any assistance. I've been tearing my hair out for a day or so and not making headway, and figured someone here might recognize some keywords and have a pointer in the right direction. (I'm admittedly pretty green when it comes to class loading, and have largely exhausted my google fu). *Problem: * I'm submitting a hadoop job using clojure-hadoop. All is well with a simple job, but once I require something that transitively depends on Schema, I end up with: clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No implementation of method: :walker of protocol: #'schema.core/Schema found for class: clojure.core$long, compiling:(crane/config.clj:33:4) It works fine when run in-process with hadoop-mapreduce-client-jobclient, but not with bin/hadoop -jar. This stunk of a classloader issue, and after digging in it seems that there are multiple versions of clojure.core$long floating around. The version on which the protocol is extended is not the same class for the fn that the symbol 'long resolves to in client code. *Context: * clojure-hadoop is AOT-compiled, and after being loaded by hadoop it dynamically loads the target namespace (not AOT-compiled, nor any other of the code in question) using https://github.com/alexott/clojure-hadoop/blob/master/src/clojure_hadoop/load.clj#L3 From here, schema is transitively required, and then client namespaces attempt to use the Schema protocol to generate validators, and when the schema 'long is used (which resolves to the fn with class clojure.core$long), it fails to find the appropriate method. After repeated head-bashing, I've determined that there are (at least two) versions of the clojure.core$long class floating around -- the one used to extend the protocol, which stems from a DynamicClassLoader, and the one that 'long resolves to in client code, which stems from a URLClassLoader. The URLClassLoader is the loader of the current thread and Compiler, but not @(clojure.lang.Compiler/LOADER). *Attempts:* I've tried wrapping the clojure-hadoop loading code with .setContextClassLoader on some obvious candidates and binding *use-context-classloader* around the code doing the loading, with no avail. I've tried changing the schema code to reference the class in different ways (class (resolve 'long)), (class 'long), etc and that hasn't made a difference. I've checked and the clojure-hadoop jar doesn't contain any .class files for clojure, schema, or other offending code. *Plea:* I suspect there's something obvious I'm missing. (In retrospect it seems like the design of Schema may be suboptimal in light of this, but if possible I'd like to figure out a workaround without changing that substantially). Thanks in advance for your help -- any and all pointers are welcome. -Jason -- 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: Help sought on issue with AOT, hadoop, classloaders, and consistency of Clojure fn classes
On Thursday, January 29, 2015 at 4:18:15 PM UTC-8, shlomi...@gmail.com wrote: Hey, Just to be sure, are you loading the full uberjar to hadoop? Yes. The issue isn't too few classes being found, it's too many :). If I start an nrepl server inside the job and futz around with loading and reloading a few times I can get all the code to load, but haven't figured out yet if it's possible to turn this into a klutzy workaround... On Wednesday, January 28, 2015 at 11:39:54 PM UTC-8, Jason Wolfe wrote: First off, I apologize in advance for not having a reduced test case, and express my sincere gratitude in advance for any assistance. I've been tearing my hair out for a day or so and not making headway, and figured someone here might recognize some keywords and have a pointer in the right direction. (I'm admittedly pretty green when it comes to class loading, and have largely exhausted my google fu). *Problem: * I'm submitting a hadoop job using clojure-hadoop. All is well with a simple job, but once I require something that transitively depends on Schema, I end up with: clojure.lang.Compiler$CompilerException: java.lang.IllegalArgumentException: No implementation of method: :walker of protocol: #'schema.core/Schema found for class: clojure.core$long, compiling:(crane/config.clj:33:4) It works fine when run in-process with hadoop-mapreduce-client-jobclient, but not with bin/hadoop -jar. This stunk of a classloader issue, and after digging in it seems that there are multiple versions of clojure.core$long floating around. The version on which the protocol is extended is not the same class for the fn that the symbol 'long resolves to in client code. *Context: * clojure-hadoop is AOT-compiled, and after being loaded by hadoop it dynamically loads the target namespace (not AOT-compiled, nor any other of the code in question) using https://github.com/alexott/clojure-hadoop/blob/master/src/clojure_hadoop/load.clj#L3 From here, schema is transitively required, and then client namespaces attempt to use the Schema protocol to generate validators, and when the schema 'long is used (which resolves to the fn with class clojure.core$long), it fails to find the appropriate method. After repeated head-bashing, I've determined that there are (at least two) versions of the clojure.core$long class floating around -- the one used to extend the protocol, which stems from a DynamicClassLoader, and the one that 'long resolves to in client code, which stems from a URLClassLoader. The URLClassLoader is the loader of the current thread and Compiler, but not @(clojure.lang.Compiler/LOADER). *Attempts:* I've tried wrapping the clojure-hadoop loading code with .setContextClassLoader on some obvious candidates and binding *use-context-classloader* around the code doing the loading, with no avail. I've tried changing the schema code to reference the class in different ways (class (resolve 'long)), (class 'long), etc and that hasn't made a difference. I've checked and the clojure-hadoop jar doesn't contain any .class files for clojure, schema, or other offending code. *Plea:* I suspect there's something obvious I'm missing. (In retrospect it seems like the design of Schema may be suboptimal in light of this, but if possible I'd like to figure out a workaround without changing that substantially). Thanks in advance for your help -- any and all pointers are welcome. -Jason -- 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.
From JavaScript to ClojureScript (Doing Computers screencast)
Hey folks! I started the screencast series Doing Computers at the beginning of this month. I wanted to share what I believe is the best of the three screencasts I've released so far. https://www.youtube.com/watch?v=8UYa8PV3CXQ I managed to introduce a few obvious bugs while recording this one, so check out the youtube comments for timestamped corrections. And if you notice anything else, please reach out. Like all software, this series is a work-in-progress, so tasteful feedback on content and presentation is appreciated. Next, I'm working on giving Ruby a similar treatment; turning Ruby code into Clojure to illustrate what I feel are similarities between the way we use Sequences and our Ruby friends use Enumerables. Also, I would really appreciate content suggestions, I'm currently writing and researching for screencasts on clojure.test, core.async and core.typed. I intend to continue this series for at least the next year, so I will need a lot more ideas. Thanks for watching and also for your feedback! -- 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.
