Re: fn and let are special forms or macros?
Wonderful - thanks Andy! On Thursday, June 19, 2014 12:40:24 PM UTC+9:30, Andy Fingerhut wrote: > > user=> (source special-symbol?) > (defn special-symbol? > "Returns true if s names a special form" > {:added "1.0" >:static true} > [s] > (contains? (. clojure.lang.Compiler specials) s)) > nil > > user=> (keys (. clojure.lang.Compiler specials)) > (& monitor-exit case* try reify* finally loop* do letfn* if > clojure.core/import* new deftype* let* fn* recur set! . var quote catch > throw monitor-enter def) > -- 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: fn and let are special forms or macros?
user=> (source special-symbol?) (defn special-symbol? "Returns true if s names a special form" {:added "1.0" :static true} [s] (contains? (. clojure.lang.Compiler specials) s)) nil user=> (keys (. clojure.lang.Compiler specials)) (& monitor-exit case* try reify* finally loop* do letfn* if clojure.core/import* new deftype* let* fn* recur set! . var quote catch throw monitor-enter def) On Wed, Jun 18, 2014 at 8:02 PM, Mark P wrote: > Interesting - thanks! > > Looks like doing `symbol is a good way of telling whether something is a > special symbol or not. If syntax-quote results in namespace-qualification > it then it *is not* special (with the exception of import*); if it does > not namespace qualify it, then it *is* special. > > Previously I've been using the fact that (source symbol) comes up with > "Source not found" to indicate that a symbol might be special. But not > sure how reliable this method is. I imagine there might be other > situations where the source code cannot be found. > > Cheers, > > Mark. > > > On Wednesday, June 18, 2014 6:26:04 PM UTC+9:30, Ambrose Bonnaire-Sergeant > wrote: > >> Hi Mark, >> >> Here's a brief doc on special forms: http://clojure-doc.org/ >> articles/language/macros.html#special-forms-in-detail >> >> Thanks, >> Ambrose >> >> >> On Wed, Jun 18, 2014 at 12:13 PM, Mark P wrote: >> >>> Thanks Tassilo for the explanation - much appreciated! >>> >>> I have been searching the web and searching clojure text books for the >>> last two hours trying to find the answer to this same question. Finally I >>> stumbled onto this thread! >>> >>> I realize that hiding the complexity of distinctions between fn / fn* >>> and let / let* etc might make the documentation more accessible for some >>> users, but for others (like me and presumably also Plínio) it makes it >>> really hard to track down what is *really* going on. I wish this >>> distinction was part of the formal documentation. >>> >>> Does anyone know of documentation anywhere that does include these kinds >>> of distinction? >>> >>> Thanks, >>> >>> Mark. >>> >>> On Thursday, 6 March 2014 02:27:26 UTC+10:30, Tassilo Horn wrote: >>> Plínio Balduino writes: Hi Plínio, > Clojure.org says fn and let are special forms, but using the macro > sourceshows that both are macros calling fn* and let* respectivelly. > > So fn and let are "special special forms", or clojure.org is > incorrect/outdated? Well, they are correct from a user's point of view. One never uses the real special forms fn* and let*. > If fn and let are really special forms and not macros, could you > explain why? fn and let (and also loop) are macros around the real special forms fn* and let* (and loop*) that add support for destructuring. For example, (let [[a b] [1 2]] (+ a b)) expands to (let* [vec__8592 [1 2] a (clojure.core/nth vec__8592 0 nil) b (clojure.core/nth vec__8592 1 nil)] (+ a b)) where the destructuring has been transformed to "normal" code already. Bye, Tassilo >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more op
Re: fn and let are special forms or macros?
Interesting - thanks! Looks like doing `symbol is a good way of telling whether something is a special symbol or not. If syntax-quote results in namespace-qualification it then it *is not* special (with the exception of import*); if it does not namespace qualify it, then it *is* special. Previously I've been using the fact that (source symbol) comes up with "Source not found" to indicate that a symbol might be special. But not sure how reliable this method is. I imagine there might be other situations where the source code cannot be found. Cheers, Mark. On Wednesday, June 18, 2014 6:26:04 PM UTC+9:30, Ambrose Bonnaire-Sergeant wrote: > > Hi Mark, > > Here's a brief doc on special forms: > http://clojure-doc.org/articles/language/macros.html#special-forms-in-detail > > Thanks, > Ambrose > > > On Wed, Jun 18, 2014 at 12:13 PM, Mark P > > wrote: > >> Thanks Tassilo for the explanation - much appreciated! >> >> I have been searching the web and searching clojure text books for the >> last two hours trying to find the answer to this same question. Finally I >> stumbled onto this thread! >> >> I realize that hiding the complexity of distinctions between fn / fn* and >> let / let* etc might make the documentation more accessible for some users, >> but for others (like me and presumably also Plínio) it makes it really hard >> to track down what is *really* going on. I wish this distinction was part >> of the formal documentation. >> >> Does anyone know of documentation anywhere that does include these kinds >> of distinction? >> >> Thanks, >> >> Mark. >> >> On Thursday, 6 March 2014 02:27:26 UTC+10:30, Tassilo Horn wrote: >> >>> Plínio Balduino writes: >>> >>> Hi Plínio, >>> >>> > Clojure.org says fn and let are special forms, but using the macro >>> > sourceshows that both are macros calling fn* and let* respectivelly. >>> > >>> > So fn and let are "special special forms", or clojure.org is >>> > incorrect/outdated? >>> >>> Well, they are correct from a user's point of view. One never uses the >>> real special forms fn* and let*. >>> >>> > If fn and let are really special forms and not macros, could you >>> > explain why? >>> >>> fn and let (and also loop) are macros around the real special forms fn* >>> and let* (and loop*) that add support for destructuring. For example, >>> >>> (let [[a b] [1 2]] >>> (+ a b)) >>> >>> expands to >>> >>> (let* >>> [vec__8592 [1 2] >>>a (clojure.core/nth vec__8592 0 nil) >>>b (clojure.core/nth vec__8592 1 nil)] >>> (+ a b)) >>> >>> where the destructuring has been transformed to "normal" code already. >>> >>> Bye, >>> Tassilo >>> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com . >> For more options, visit https://groups.google.com/d/optout. >> > > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: ClojureScript ^:export defprotocol
That's cool. I see no reason why Clojure / ClojureScript's “reach” can't extend significantly into iOS. On Wednesday, June 18, 2014 3:58:18 PM UTC-4, Gary Trakhman wrote: > > I was just telling a local ios dev there's like five guys using clojure + > objective-c. To me it's impressive. To them, well, I don't know what > they'd think :-). > -- 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 ^:export defprotocol
I was just telling a local ios dev there's like five guys using clojure + objective-c. To me it's impressive. To them, well, I don't know what they'd think :-). On Wednesday, June 18, 2014, Mike Fikes wrote: > Right, Gary, > > Initially I simply wrote exported functions. > > The motivation for experimenting with protocols is so that I can write a > ClojureScript protocol that mimics, say the iOS UITableViewDataSource > Objective-C @protocol. Then, with that in place, I can write ClojureScript > reifications of that protocol to be passed back to Objective-C. It is then > a simple matter on the Objective-C side to make that reification *be* a > UITableView's dataSource delegate (with the help of a little reusable > wrapper Obj-C object around the JSValue.) > > In addition to perhaps keeping things tidy (keeping like methods > together), it makes it easier to pass multiple @protocol instances back to > iOS. (Imagine the case of two or more table views on one iOS screen, each > with their own distinct ClojureScriipt implementation.) > > Also, a lot of this ends up being boilerplate that needs to only be > written once, and then, I recoup the costs of fleshing out this plumbing by > simply spitting out a (reify ... ) form whenever needed. > > Arguably, none of this is required because all of the > UITableViewDataSource methods have the tableView as the first argument, > which could be used by straightforward exported functions to dispatch or > otherwise switch to the right implementation, which could in turn be a > reified protocol. It just seems that, since Objective-C *wants* an object > as a dataSource, that it would be interesting to try to satisfy that need > (more or less directly) using the facilities available in ClojureScript. > > I'll ditch all of this when Apple introduces FunctionalSwift along with > functional APIs, and the Clojure(Swift) compiler targets that new language. > :) > > - Mike > > On Wednesday, June 18, 2014 2:48:33 PM UTC-4, Gary Trakhman wrote: >> >> 'any problem.. fixed.. by another layer of indirection' >> >> You could also just make exportable functions that call the protocols, >> keeping them more as impl-details, core.cljs does this, and you gain things >> like varargs (hmm, do protocol-varargs work on cljs? nope: >> http://dev.clojure.org/jira/browse/CLJS-362 ) >> > -- > 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: ClojureScript ^:export defprotocol
Right, Gary, Initially I simply wrote exported functions. The motivation for experimenting with protocols is so that I can write a ClojureScript protocol that mimics, say the iOS UITableViewDataSource Objective-C @protocol. Then, with that in place, I can write ClojureScript reifications of that protocol to be passed back to Objective-C. It is then a simple matter on the Objective-C side to make that reification *be* a UITableView's dataSource delegate (with the help of a little reusable wrapper Obj-C object around the JSValue.) In addition to perhaps keeping things tidy (keeping like methods together), it makes it easier to pass multiple @protocol instances back to iOS. (Imagine the case of two or more table views on one iOS screen, each with their own distinct ClojureScriipt implementation.) Also, a lot of this ends up being boilerplate that needs to only be written once, and then, I recoup the costs of fleshing out this plumbing by simply spitting out a (reify ... ) form whenever needed. Arguably, none of this is required because all of the UITableViewDataSource methods have the tableView as the first argument, which could be used by straightforward exported functions to dispatch or otherwise switch to the right implementation, which could in turn be a reified protocol. It just seems that, since Objective-C *wants* an object as a dataSource, that it would be interesting to try to satisfy that need (more or less directly) using the facilities available in ClojureScript. I'll ditch all of this when Apple introduces FunctionalSwift along with functional APIs, and the Clojure(Swift) compiler targets that new language. :) - Mike On Wednesday, June 18, 2014 2:48:33 PM UTC-4, Gary Trakhman wrote: > > 'any problem.. fixed.. by another layer of indirection' > > You could also just make exportable functions that call the protocols, > keeping them more as impl-details, core.cljs does this, and you gain things > like varargs (hmm, do protocol-varargs work on cljs? nope: > http://dev.clojure.org/jira/browse/CLJS-362 ) > -- 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 ^:export defprotocol
Even without JIT available in JavaScriptCore, I have been unable to notice a difference in the on-device performance of the “view controller” code I have been writing when turning on :advanced. Thanks for the suggestion, I'll go with :simple and :static-fns. The reified protocol instance works with those optimizations. On Wednesday, June 18, 2014 2:34:45 PM UTC-4, David Nolen wrote: > > On iOS is advanced compilation really necessary? :simple + :static-fns > true should suffice. > -- 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: 56 second GC on Heroku - seems a bit long
On Monday, June 16, 2014 1:47:14 PM UTC-4, Brian Marick wrote: > > We have a small Clojure app on Heroku that performs backend tasks for a > Rails app. Low traffic (like a request a minute). Heap is 400M. We've been > having long (10 sec) GC pauses using both the default and G1 GC (both > untuned). Browsing our logs today, I found: > > [GC pause (young) 156M->36M(400M), 56.0281380 secs] > > A minute for GC seems… excessive. > > Our other Clojure apps also have GC problems. > > 1. Is this something peculiar to Heroku? Clojure in small-memory > environments? I have very little experience with non-Clojure java apps, but > a coworker says: "I've run JVMs with +20g heaps, and *never* seen 10s > pauses, let alone a whole f%#^$ing minute". > > 2. Is there lore about appropriate GC tweaks for Clojure backend server > apps? > > > If it's feasible, I would attempt to run the same Clojure application in a 400MB-constrained JVM on a developer workstation and see what kind of garbage collection times you get. Hopefully that gives you a useful point of comparison. Obviously if you see the same long pauses the problem is related to your application code or Clojure, period. If you get fast garbage collections, then it's a Heroku-specific problem. Good luck. -Mike -- 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 ^:export defprotocol
'any problem.. fixed.. by another layer of indirection' You could also just make exportable functions that call the protocols, keeping them more as impl-details, core.cljs does this, and you gain things like varargs (hmm, do protocol-varargs work on cljs? nope: http://dev.clojure.org/jira/browse/CLJS-362 ) On Wed, Jun 18, 2014 at 2:34 PM, David Nolen wrote: > On iOS is advanced compilation really necessary? :simple + :static-fns > true should suffice. > > > On Wednesday, June 18, 2014, Mike Fikes wrote: > >> Is there a way to indicate that a (ClojureScript) protocol is intended to >> be used from the host? >> >> Details: >> >> I can define a protocol and an implementation of it in ClojureScript >> using defprotocol and reify. >> >> I can also successfully call methods on reified instances returned to the >> host (Obj-C embedding JavaScriptCore on iOS). >> >> The method names are mangled: In addition to the expected and usual >> conversion of hyphens to underscores, the mangled names incorporate dollar >> signs ($) and arity encoding, an example of which is: >> >> my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1 >> >> This can be called, passing this mangled string in as the method name of >> JSValue >> -invokeMethod:withArguments:. >> >> All cool (so long as this mangling is stable from one ClojureScript >> release to the next—but it smells like the mangling could be an >> implementation detail, subject to change). >> >> The killer is if I turn on Google Closure advanced optimizations; these >> mangled names get renamed. >> >> Is there a way to indicate the protocol names should be preserved? >> (Analogous to the way ^:export can be used on function definitions.) >> >> -- >> 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: ClojureScript ^:export defprotocol
On iOS is advanced compilation really necessary? :simple + :static-fns true should suffice. On Wednesday, June 18, 2014, Mike Fikes wrote: > Is there a way to indicate that a (ClojureScript) protocol is intended to > be used from the host? > > Details: > > I can define a protocol and an implementation of it in ClojureScript using > defprotocol and reify. > > I can also successfully call methods on reified instances returned to the > host (Obj-C embedding JavaScriptCore on iOS). > > The method names are mangled: In addition to the expected and usual > conversion of hyphens to underscores, the mangled names incorporate dollar > signs ($) and arity encoding, an example of which is: > > my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1 > > This can be called, passing this mangled string in as the method name of > JSValue > -invokeMethod:withArguments:. > > All cool (so long as this mangling is stable from one ClojureScript > release to the next—but it smells like the mangling could be an > implementation detail, subject to change). > > The killer is if I turn on Google Closure advanced optimizations; these > mangled names get renamed. > > Is there a way to indicate the protocol names should be preserved? > (Analogous to the way ^:export can be used on function definitions.) > > -- > 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.
ClojureScript ^:export defprotocol
Is there a way to indicate that a (ClojureScript) protocol is intended to be used from the host? Details: I can define a protocol and an implementation of it in ClojureScript using defprotocol and reify. I can also successfully call methods on reified instances returned to the host (Obj-C embedding JavaScriptCore on iOS). The method names are mangled: In addition to the expected and usual conversion of hyphens to underscores, the mangled names incorporate dollar signs ($) and arity encoding, an example of which is: my$full$ns$MyProtocol$a_method_defined_in_this_protocol$arity$1 This can be called, passing this mangled string in as the method name of JSValue -invokeMethod:withArguments:. All cool (so long as this mangling is stable from one ClojureScript release to the next—but it smells like the mangling could be an implementation detail, subject to change). The killer is if I turn on Google Closure advanced optimizations; these mangled names get renamed. Is there a way to indicate the protocol names should be preserved? (Analogous to the way ^:export can be used on function definitions.) -- 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: Leiningen 2.4.2 upgrade causing problems
A little more data: I can reproduce the same thing on Ubuntu 12.04.3 LInux running OpenJDK 1.6.0_31, so there is nothing OS or JVM-specific about this that I can tell. Also, it happens with the following being the complete contents of my ~/.lein/profiles.clj file: {:user {:plugins [[co.paralleluniverse/pulsar "0.5.0"]]}} The common denominator seems to be a dependence on data.priority-map, even if only indirectly. core.cache and core.typed both depend on it, and I am sure there are other projects that depend on it directly or indirectly, too. Andy On Wed, Jun 18, 2014 at 9:49 AM, Andy Fingerhut wrote: > Recommendation: If you see this problem, and you have Eastwood in your > ~/.lein/profiles.clj file, upgrade Eastwood to version 0.1.4, or go back to > Leiningen 2.3.4. > > More details: > > I have been able to reproduce an exception when running 'lein help new' > outside of any Leiningen project in these conditions: > > Mac OS X 10.8.5 > JVM 1.7.0_51 > Leiningen 2.4.2 > ~/.lein/profiles.clj contains {:user {:plugins [[jonase/eastwood > "0.1.2"]]}} or an older Eastwood version > > The exception goes away if I change to Leiningen 2.3.4, or if I upgrade to > Eastwood 0.1.3 or later. > > I do not know the reason for the exception, but it makes some sense that > upgrading to Eastwood 0.1.3 or later makes a difference (0.1.4 is the > latest released version). Why? Because a change made in Eastwood version > 0.1.3 was to make a copy of all Clojure contrib libraries inside of > Eastwood itself, and renaming their namespaces. This helped eliminate some > contrib library version number conflicts when using Eastwood on some > projects that also used those contrib libraries. > > Thus Eastwood 0.1.2 depends on data.priority-map, but only indirectly > through tools.analyzer.jvm and its dependencies. Below is the output of > 'lein deps :tree' for Eastwood 0.1.2, in case it helps anyone track down > what is going on: > > % git clone https://github.com/jonase/eastwood.git > % git checkout eastwood-0.1.2 > % lein deps :tree > [clojure-complete "0.2.3" :exclusions [[org.clojure/clojure]]] > [leinjacker "0.4.1"] >[org.clojure/core.contracts "0.0.1"] > [org.clojure/core.unify "0.5.3"] > [org.clojars.brenton/google-diff-match-patch "0.1"] > [org.clojure/clojure "1.6.0"] > [org.clojure/tools.analyzer.jvm "0.1.0-beta10"] >[org.clojure/core.memoize "0.5.6"] > [org.clojure/core.cache "0.6.3"] >[org.clojure/data.priority-map "0.0.2"] >[org.ow2.asm/asm-all "4.1"] > [org.clojure/tools.analyzer "0.1.0-beta10"] > [org.clojure/tools.macro "0.1.2"] > [org.clojure/tools.namespace "0.2.4"] > [org.clojure/tools.nrepl "0.2.3" :exclusions [[org.clojure/clojure]]] > [org.clojure/tools.reader "0.8.3"] > > > Andy > > > On Wed, Jun 18, 2014 at 9:12 AM, Sean Corfield wrote: > >> I am using Eastwood 0.1.2 without problems with Leiningen 2.4.2 but >> perhaps Stefan and others are seeing conflicts because of other stuff in >> ~/.lein/profiles.clj with Eastwood? >> >> gvim seems to have isolated it to pulsar. >> >> Nearly all of the problems I see reported with Leiningen end up being due >> to having a lot of stuff in the user profile... >> >> Sean >> >> On Jun 18, 2014, at 2:08 AM, Ambrose Bonnaire-Sergeant < >> abonnaireserge...@gmail.com> wrote: >> >> Someone was having the same issue, solved by upgrading Eastwood plugin to >> 0.1.2. >> >> Hope that helps. >> >> Thanks, >> Ambrose >> >> >> On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield >> wrote: >> >>> "works for me"... >>> >>> Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new >>> works fine outside of a project and also inside the context of a >>> project that depends on Clojure 1.6.0. >>> >>> Are you running lein inside a project or outside? What do you have in >>> your profiles.clj file? >>> >>> Sean >>> >>> On Tue, Jun 17, 2014 at 10:45 AM, gvim wrote: >>> > OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE >>> Runtime >>> > Environment (build 1.8.0_05-b13) >>> > >>> > Running `lein help new` I'm getting an exception including this: >>> > >>> > Caused by: java.io.FileNotFoundException: Could not locate >>> > clojure/data/priority_map__init.class or clojure/data/priority_map.clj >>> on >>> > classpath: >>> > at clojure.lang.RT.load(RT.java:443) >>> > >>> > Everything was working before the recent Leiningen upgrade. >>> > >>> > gvim >>> > >>> >> >> >> > -- 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 sto
Re: Leiningen 2.4.2 upgrade causing problems
Recommendation: If you see this problem, and you have Eastwood in your ~/.lein/profiles.clj file, upgrade Eastwood to version 0.1.4, or go back to Leiningen 2.3.4. More details: I have been able to reproduce an exception when running 'lein help new' outside of any Leiningen project in these conditions: Mac OS X 10.8.5 JVM 1.7.0_51 Leiningen 2.4.2 ~/.lein/profiles.clj contains {:user {:plugins [[jonase/eastwood "0.1.2"]]}} or an older Eastwood version The exception goes away if I change to Leiningen 2.3.4, or if I upgrade to Eastwood 0.1.3 or later. I do not know the reason for the exception, but it makes some sense that upgrading to Eastwood 0.1.3 or later makes a difference (0.1.4 is the latest released version). Why? Because a change made in Eastwood version 0.1.3 was to make a copy of all Clojure contrib libraries inside of Eastwood itself, and renaming their namespaces. This helped eliminate some contrib library version number conflicts when using Eastwood on some projects that also used those contrib libraries. Thus Eastwood 0.1.2 depends on data.priority-map, but only indirectly through tools.analyzer.jvm and its dependencies. Below is the output of 'lein deps :tree' for Eastwood 0.1.2, in case it helps anyone track down what is going on: % git clone https://github.com/jonase/eastwood.git % git checkout eastwood-0.1.2 % lein deps :tree [clojure-complete "0.2.3" :exclusions [[org.clojure/clojure]]] [leinjacker "0.4.1"] [org.clojure/core.contracts "0.0.1"] [org.clojure/core.unify "0.5.3"] [org.clojars.brenton/google-diff-match-patch "0.1"] [org.clojure/clojure "1.6.0"] [org.clojure/tools.analyzer.jvm "0.1.0-beta10"] [org.clojure/core.memoize "0.5.6"] [org.clojure/core.cache "0.6.3"] [org.clojure/data.priority-map "0.0.2"] [org.ow2.asm/asm-all "4.1"] [org.clojure/tools.analyzer "0.1.0-beta10"] [org.clojure/tools.macro "0.1.2"] [org.clojure/tools.namespace "0.2.4"] [org.clojure/tools.nrepl "0.2.3" :exclusions [[org.clojure/clojure]]] [org.clojure/tools.reader "0.8.3"] Andy On Wed, Jun 18, 2014 at 9:12 AM, Sean Corfield wrote: > I am using Eastwood 0.1.2 without problems with Leiningen 2.4.2 but > perhaps Stefan and others are seeing conflicts because of other stuff in > ~/.lein/profiles.clj with Eastwood? > > gvim seems to have isolated it to pulsar. > > Nearly all of the problems I see reported with Leiningen end up being due > to having a lot of stuff in the user profile... > > Sean > > On Jun 18, 2014, at 2:08 AM, Ambrose Bonnaire-Sergeant < > abonnaireserge...@gmail.com> wrote: > > Someone was having the same issue, solved by upgrading Eastwood plugin to > 0.1.2. > > Hope that helps. > > Thanks, > Ambrose > > > On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield wrote: > >> "works for me"... >> >> Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new >> works fine outside of a project and also inside the context of a >> project that depends on Clojure 1.6.0. >> >> Are you running lein inside a project or outside? What do you have in >> your profiles.clj file? >> >> Sean >> >> On Tue, Jun 17, 2014 at 10:45 AM, gvim wrote: >> > OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE >> Runtime >> > Environment (build 1.8.0_05-b13) >> > >> > Running `lein help new` I'm getting an exception including this: >> > >> > Caused by: java.io.FileNotFoundException: Could not locate >> > clojure/data/priority_map__init.class or clojure/data/priority_map.clj >> on >> > classpath: >> > at clojure.lang.RT.load(RT.java:443) >> > >> > Everything was working before the recent Leiningen upgrade. >> > >> > gvim >> > >> > > > -- 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: Leiningen 2.4.2 upgrade causing problems
I am using Eastwood 0.1.2 without problems with Leiningen 2.4.2 but perhaps Stefan and others are seeing conflicts because of other stuff in ~/.lein/profiles.clj with Eastwood? gvim seems to have isolated it to pulsar. Nearly all of the problems I see reported with Leiningen end up being due to having a lot of stuff in the user profile... Sean On Jun 18, 2014, at 2:08 AM, Ambrose Bonnaire-Sergeant wrote: > Someone was having the same issue, solved by upgrading Eastwood plugin to > 0.1.2. > > Hope that helps. > > Thanks, > Ambrose > > > On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield wrote: > "works for me"... > > Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new > works fine outside of a project and also inside the context of a > project that depends on Clojure 1.6.0. > > Are you running lein inside a project or outside? What do you have in > your profiles.clj file? > > Sean > > On Tue, Jun 17, 2014 at 10:45 AM, gvim wrote: > > OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE Runtime > > Environment (build 1.8.0_05-b13) > > > > Running `lein help new` I'm getting an exception including this: > > > > Caused by: java.io.FileNotFoundException: Could not locate > > clojure/data/priority_map__init.class or clojure/data/priority_map.clj on > > classpath: > > at clojure.lang.RT.load(RT.java:443) > > > > Everything was working before the recent Leiningen upgrade. > > > > gvim > > signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Clojure equivalent of 3-level enumeration in Ruby?
Try http://clojuredocs.org/clojure_core/clojure.core/for On Wed, Jun 18, 2014 at 11:56 AM, gvim wrote: > I have a method in Ruby that involves 3-level enumeration and would like > to rewrite it in Clojure. Without asking anyone to do the job :), what is > the best equivalent to this kind of Ruby iteration in Clojure? I looked at > prewalk and postwalk but wasn't convinced that was what's required. Map > could also get a bit messy here. > > gvim > > > > SIGNS = { ar:'Aries', ta:'Taurus', ge:'Gemini', cn:'Cancer', le:'Leo', > vi:'Virgo', > li:'Libra', sc:'Scorpio', sa:'Sagittarius', cp:'Capricorn', > aq:'Aquarius', pi:'Pisces' } > RULERS = {Aries:[:Mars], Taurus:[:Venus], Gemini:[:Mercury], > Cancer:[:Moon], Leo:[:Sun], Virgo:[:Mercury], Libra:[:Venus], > Scorpio:[:Mars, :Pluto], Sagittarius:[:Jupiter], > Capricorn:[:Saturn], Aquarius:[:Saturn, :Uranus], Pisces:[:Jupiter, > :Neptune]} > ANGLES = {cnj:{orb:7.5, deg:[0], type:'g'}, squ:{orb:6, deg:[90,270], > type:'r'}, > tri:{orb:6, deg:[120,240], type:'g'}, opp:{orb:7.5, deg:[180], > type:'r'}} > PERSONALS = %i(Sun Moon Mercury Venus Mars) > ASPECTED = %i(Sun Moon Mercury Venus Mars Jupiter Saturn Uranus Neptune > Pluto) > > > def find_aspects(astro_data) > results = {} > PERSONALS.each_with_index do |p,i| > results[p] = {} > ASPECTED[i+1..9].each do |a| > next if p == a > ANGLES.each do |asp, data| > data[:deg].each do |d| > exact = astro_data[p][:long] + d > exact -= 360 if exact >= 360 > range_start = exact - data[:orb] > range_end = (exact + data[:orb] >= 360) ? (exact + data[:orb] - > 360) : (exact + data[:orb]) > target_long = astro_data[a][:long] > if target_long >= range_start && target_long <= range_end > width = target_long <= exact ? (exact - target_long) : > (target_long - exact) > results[p][a] = [asp,width] > end > end > end > end > end > return results > end > > -- > 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.
Clojure equivalent of 3-level enumeration in Ruby?
I have a method in Ruby that involves 3-level enumeration and would like to rewrite it in Clojure. Without asking anyone to do the job :), what is the best equivalent to this kind of Ruby iteration in Clojure? I looked at prewalk and postwalk but wasn't convinced that was what's required. Map could also get a bit messy here. gvim SIGNS = { ar:'Aries', ta:'Taurus', ge:'Gemini', cn:'Cancer', le:'Leo', vi:'Virgo', li:'Libra', sc:'Scorpio', sa:'Sagittarius', cp:'Capricorn', aq:'Aquarius', pi:'Pisces' } RULERS = {Aries:[:Mars], Taurus:[:Venus], Gemini:[:Mercury], Cancer:[:Moon], Leo:[:Sun], Virgo:[:Mercury], Libra:[:Venus], Scorpio:[:Mars, :Pluto], Sagittarius:[:Jupiter], Capricorn:[:Saturn], Aquarius:[:Saturn, :Uranus], Pisces:[:Jupiter, :Neptune]} ANGLES = {cnj:{orb:7.5, deg:[0], type:'g'}, squ:{orb:6, deg:[90,270], type:'r'}, tri:{orb:6, deg:[120,240], type:'g'}, opp:{orb:7.5, deg:[180], type:'r'}} PERSONALS = %i(Sun Moon Mercury Venus Mars) ASPECTED = %i(Sun Moon Mercury Venus Mars Jupiter Saturn Uranus Neptune Pluto) def find_aspects(astro_data) results = {} PERSONALS.each_with_index do |p,i| results[p] = {} ASPECTED[i+1..9].each do |a| next if p == a ANGLES.each do |asp, data| data[:deg].each do |d| exact = astro_data[p][:long] + d exact -= 360 if exact >= 360 range_start = exact - data[:orb] range_end = (exact + data[:orb] >= 360) ? (exact + data[:orb] - 360) : (exact + data[:orb]) target_long = astro_data[a][:long] if target_long >= range_start && target_long <= range_end width = target_long <= exact ? (exact - target_long) : (target_long - exact) results[p][a] = [asp,width] end end end end end return results end -- 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: BeagleBone Black Continuous Analog Reads
I would say it's not so much about programming paradigm rather than system calls. It all boils down to how often you would want to read the data. If it's not more than some times per second, and it's not super important with timing, you could probably put a reading function in a SchedulingThreadPool (you can add Clojure functions as is since they are Runnable) or have a look at the at-at library spawned from overtone. https://github.com/overtone/at-at One way to react on the incoming values are to swap! or reset! them into an atom, which has a watcher-function added which could things based on the new and old values. http://clojuredocs.org/clojure_core/clojure.core/add-watch shows an example with agents, but it works for atoms as well. If you want to store an incoming series of values for further processing, either use the clojure.lang.PeristentQueue or some Java equivalent. If you want to sample in very high frequency, (kilohertz) you'll need to fetch the values in some loop close to machine an batch it into Clojure by primitive-buffers or similar (like soundcards, UARTs and network stacks do). /Linus 2014-06-18 5:08 GMT+02:00 Jeremy Wright : > The main way of reading the inputs (analog or digital) on a BeagleBone > Black is through the Linux file system. > > http://beaglebone.cameon.net/home/reading-the-analog-inputs-adc > > I'm still pretty new to Clojure and come from an object oriented > background. I would like to do a continuous read of the BBB's analog inputs > through the file system and make decisions based on the values. There are > different ways of handling this from an OOP perspective, but I'm not sure > how to approach it from a functional perspective. Can someone point me in > the right direction? > > -- > 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: macro question
you can also use macroexpand-1 to see how your macro expands for example, having defined your macro as suggested by Gary and James above, you can write something like: (macroexpand-1 '(if-zero (- 4 2 2) (+ 1 1) (+ 2 2))) and see that it correctly to: (if (clojure.core/= (- 4 2 2) 0) (+ 1 1) (+ 2 2)) cheers, Gianluca -- 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: Leiningen 2.4.2 upgrade causing problems
On 18/06/2014 04:05, Sean Corfield wrote: Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean Running `lein help new` from ~/.lein . By process of elimination I discovered the culprit is: [co.paralleluniverse/pulsar "0.5.1"] It's still weird, though, because I'm almost certain I checked this when I set about debugging my profiles.clj file yesterday. gvim -- 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: Leiningen 2.4.2 upgrade causing problems
On 18/06/2014 04:05, Sean Corfield wrote: "works for me"... Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new works fine outside of a project and also inside the context of a project that depends on Clojure 1.6.0. Are you running lein inside a project or outside? What do you have in your profiles.clj file? Sean My ~/.lein/profiles.clj below. No problems if I remove it and run `lein help new` again. {:user {:plugins [[cider/cider-nrepl "0.7.0-SNAPSHOT"] [lein-ancient "0.5.5"] [lein-immutant "1.2.1"] [com.jakemccrary/lein-test-refresh "0.5.0"]] :dependencies [[org.clojure/clojure "1.6.0"] [nrepl-inspect "0.4.1"] [org.clojure/tools.trace "0.7.8"] [co.paralleluniverse/pulsar "0.5.1"]] :repl-options {:nrepl-middleware [cider.nrepl.middleware.classpath/wrap-classpath cider.nrepl.middleware.complete/wrap-complete cider.nrepl.middleware.info/wrap-info cider.nrepl.middleware.inspect/wrap-inspect cider.nrepl.middleware.stacktrace/wrap-stacktrace cider.nrepl.middleware.trace/wrap-trace]}}} -- 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: Leiningen 2.4.2 upgrade causing problems
Oh, great, yes, that helped. Unexpected. Thanks, stefan On Wednesday, June 18, 2014 11:09:52 AM UTC+2, Ambrose Bonnaire-Sergeant wrote: > > Rather upgrading *from* 0.1.2 fixes. > > Thanks, > Ambrose > > > On Wed, Jun 18, 2014 at 5:08 PM, Ambrose Bonnaire-Sergeant < > abonnair...@gmail.com > wrote: > >> Someone was having the same issue, solved by upgrading Eastwood plugin to >> 0.1.2. >> >> Hope that helps. >> >> Thanks, >> Ambrose >> >> >> On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield > > wrote: >> >>> "works for me"... >>> >>> Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new >>> works fine outside of a project and also inside the context of a >>> project that depends on Clojure 1.6.0. >>> >>> Are you running lein inside a project or outside? What do you have in >>> your profiles.clj file? >>> >>> Sean >>> >>> On Tue, Jun 17, 2014 at 10:45 AM, gvim > >>> wrote: >>> > OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE >>> Runtime >>> > Environment (build 1.8.0_05-b13) >>> > >>> > Running `lein help new` I'm getting an exception including this: >>> > >>> > Caused by: java.io.FileNotFoundException: Could not locate >>> > clojure/data/priority_map__init.class or clojure/data/priority_map.clj >>> on >>> > classpath: >>> > at clojure.lang.RT.load(RT.java:443) >>> > >>> > Everything was working before the recent Leiningen upgrade. >>> > >>> > gvim >>> > >>> > -- >>> > You received this message because you are subscribed to the Google >>> > Groups "Clojure" group. >>> > To post to this group, send email to clo...@googlegroups.com >>> >>> > Note that posts from new members are moderated - please be patient >>> with your >>> > first post. >>> > To unsubscribe from this group, send email to >>> > clojure+u...@googlegroups.com >>> > For more options, visit this group at >>> > http://groups.google.com/group/clojure?hl=en >>> > --- You received this message because you are subscribed to the Google >>> > Groups "Clojure" group. >>> > To unsubscribe from this group and stop receiving emails from it, send >>> an >>> > email to clojure+u...@googlegroups.com . >>> > For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> Sean A Corfield -- (904) 302-SEAN >>> An Architect's View -- http://corfield.org/ >>> World Singles, LLC. -- http://worldsingles.com/ >>> >>> "Perfection is the enemy of the good." >>> -- Gustave Flaubert, French realist novelist (1821-1880) >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com . >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Defs with %
thanks for the report, fixed On Wed, Jun 18, 2014 at 1:30 AM, Mike Thompson wrote: > > Colin, many thanks. Issue created: > https://github.com/cgrand/sjacket/issues/19 > > > On Wednesday, June 18, 2014 4:08:53 AM UTC+10, Colin Jones wrote: > >> Yeah the latter version parses as 2 symbols in sjacket, whereas the defn >> version parses as a single list. >> >> user=> (p/parser "top%") >> #net.cgrand.parsley.Node{:tag :net.cgrand.sjacket.parser/root, :content >> [#net.cgrand.parsley.Node{:tag :symbol, :content >> [#net.cgrand.parsley.Node{:tag :name, :content ["top"]}]} >> #net.cgrand.parsley.Node{:tag :symbol, :content >> [#net.cgrand.parsley.Node{:tag :name, :content ["%"]}]}]} >> >> REPLy uses sjacket to split input expressions and send them each off to >> nREPL in sequence, IIRC so that you get all results back from stuff like: >> >> user=> 1 2 3 >> 1 >> 2 >> 3 >> >> So it treats the "top%" input basically the same as if there were >> intervening whitespace, like "top %". >> >> From http://clojure.org/reader: >> - >> Symbols begin with a non-numeric character and can contain alphanumeric >> characters and *, +, !, -, _, and ? (other characters will be allowed >> eventually, but not all macro characters have been determined). '/' has >> special meaning, it can be used once in the middle of a symbol to separate >> the namespace from the name, e.g. my-namespace/foo. '/' by itself names the >> division function. '.' has special meaning - it can be used one or more >> times in the middle of a symbol to designate a fully-qualified class name, >> e.g. java.util.BitSet, or in namespace names. Symbols beginning or ending >> with '.' are reserved by Clojure. Symbols containing / or . are said to be >> 'qualified'. Symbols beginning or ending with ':' are reserved by Clojure. >> A symbol can contain one or more non-repeating ':'s. >> - >> >> So it looks to me like that function name is illegal, and it's an >> implementation detail that it currently is allowed to work. >> >> Usually parsing fixes for lein repl belong in sjacket ( >> https://github.com/cgrand/sjacket/issues), but I'm not 100% convinced >> the parser should say top% is a legitimate symbol. But I'm also not >> convinced it should ever be possible for 2 symbols to be right next to each >> other with no intervening whitespace. Not sure what the right thing to do >> is here. Let's discuss further in an issue on sjacket. >> >> Short-term workaround: `(do top%)`. >> >> >> On Tuesday, June 17, 2014 9:54:25 AM UTC-5, daveray wrote: >>> >>> I believe this is a problem with the Leiningen REPL. It works fine from >>> the built-in REPL: >>> >>> $ java -jar ~/.m2/repository/org/clojure/clojure/1.5.1/clojure-1.5.1.jar >>> Clojure 1.5.1 >>> user=> (def top% 4) >>> #'user/top% >>> user=> top% >>> 4 >>> >>> Dave >>> >>> >>> >>> >>> On Tue, Jun 17, 2014 at 1:32 AM, Mike Thompson >>> wrote: >>> At the REPL ... user=> (def top% 4) ;; an unusually named var #'user/top% But later, it I try to use this var, trouble ... user=> top% CompilerException java.lang.RuntimeException: Unable to resolve symbol: top in this context, compiling:(Local\Temp\form- init6773082655831127234.clj:1:734) CompilerException java.lang.RuntimeException: Unable to resolve symbol: % in this context, compiling:(Local\Temp\form- init6773082655831127234.clj:1:734) Not sure what to make if this. Obviously % is a bit special. And it is certainly not a significant problem for me, at all. Just seemed odd that I'm allowed to successfully do the def, if it is just going to cause problems later. -- Mike -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> > On Wednesday, June 18, 2014 4:08:53 AM UTC+10, Colin Jones wrote: >> >> Yeah the latter version parses as 2 symbols in sjacket, whereas the defn >> version parses as a single list. >> >> user=> (p/parser "top%") >> #net.cgrand.parsley.Node{:tag :net.cgrand.sjacket.parser/root, :content >> [#net.cgrand.parsley.Node{:tag :symbol, :content >> [#net.cgrand.parsley.Node{:tag :name, :content ["top"]}]} >> #net.cgrand.parsley.Node{:tag :symbol, :content >> [#net.cgrand.parsley.Node{:tag :name,
Re: Leiningen 2.4.2 upgrade causing problems
Rather upgrading *from* 0.1.2 fixes. Thanks, Ambrose On Wed, Jun 18, 2014 at 5:08 PM, Ambrose Bonnaire-Sergeant < abonnaireserge...@gmail.com> wrote: > Someone was having the same issue, solved by upgrading Eastwood plugin to > 0.1.2. > > Hope that helps. > > Thanks, > Ambrose > > > On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield wrote: > >> "works for me"... >> >> Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new >> works fine outside of a project and also inside the context of a >> project that depends on Clojure 1.6.0. >> >> Are you running lein inside a project or outside? What do you have in >> your profiles.clj file? >> >> Sean >> >> On Tue, Jun 17, 2014 at 10:45 AM, gvim wrote: >> > OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE >> Runtime >> > Environment (build 1.8.0_05-b13) >> > >> > Running `lein help new` I'm getting an exception including this: >> > >> > Caused by: java.io.FileNotFoundException: Could not locate >> > clojure/data/priority_map__init.class or clojure/data/priority_map.clj >> on >> > classpath: >> > at clojure.lang.RT.load(RT.java:443) >> > >> > Everything was working before the recent Leiningen upgrade. >> > >> > gvim >> > >> > -- >> > 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. >> >> >> >> -- >> Sean A Corfield -- (904) 302-SEAN >> An Architect's View -- http://corfield.org/ >> World Singles, LLC. -- http://worldsingles.com/ >> >> "Perfection is the enemy of the good." >> -- Gustave Flaubert, French realist novelist (1821-1880) >> >> -- >> 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: Leiningen 2.4.2 upgrade causing problems
Someone was having the same issue, solved by upgrading Eastwood plugin to 0.1.2. Hope that helps. Thanks, Ambrose On Wed, Jun 18, 2014 at 11:05 AM, Sean Corfield wrote: > "works for me"... > > Leiningen 2.4.2; Java build 1.8.0_05-b13; OS X 10.8.5 - lein help new > works fine outside of a project and also inside the context of a > project that depends on Clojure 1.6.0. > > Are you running lein inside a project or outside? What do you have in > your profiles.clj file? > > Sean > > On Tue, Jun 17, 2014 at 10:45 AM, gvim wrote: > > OS X Mountain Lion / lein 2.4.2 / clojure 1.6.0 / Java(TM) SE > Runtime > > Environment (build 1.8.0_05-b13) > > > > Running `lein help new` I'm getting an exception including this: > > > > Caused by: java.io.FileNotFoundException: Could not locate > > clojure/data/priority_map__init.class or clojure/data/priority_map.clj on > > classpath: > > at clojure.lang.RT.load(RT.java:443) > > > > Everything was working before the recent Leiningen upgrade. > > > > gvim > > > > -- > > 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. > > > > -- > Sean A Corfield -- (904) 302-SEAN > An Architect's View -- http://corfield.org/ > World Singles, LLC. -- http://worldsingles.com/ > > "Perfection is the enemy of the good." > -- Gustave Flaubert, French realist novelist (1821-1880) > > -- > 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: Leiningen 2.4.2 upgrade causing problems
Hi, FWIW... On Wednesday, June 18, 2014 5:06:09 AM UTC+2, Sean Corfield wrote: > > "works for me"... > Does *not* work for me. I see the same error inside and outside of projects: $ java -version java version "1.7.0_11" Java(TM) SE Runtime Environment (build 1.7.0_11-b21) Java HotSpot(TM) 64-Bit Server VM (build 23.6-b04, mixed mode) $ lein -version Leiningen 2.4.2 on Java 1.7.0_11 Java HotSpot(TM) 64-Bit Server VM $ lein help new Exception in thread "main" java.lang.ExceptionInInitializerError at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:421) at stencil.core$loading__4958__auto__.invoke(core.clj:1) at stencil.core__init.load(Unknown Source) at stencil.core__init.(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:512) at leiningen.new.templates$loading__4958__auto__.invoke(templates.clj:11) at leiningen.new.templates__init.load(Unknown Source) at leiningen.new.templates__init.(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:457) at leiningen.new$loading__4958__auto__.invoke(new.clj:1) at leiningen.new__init.load(Unknown Source) at leiningen.new__init.(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:264) at clojure.lang.RT.loadClassForName(RT.java:2093) at clojure.lang.RT.load(RT.java:430) at clojure.lang.RT.load(RT.java:411) at clojure.core$load$fn__5066.invoke(core.clj:5641) at clojure.core$load.doInvoke(core.clj:5640) at clojure.lang.RestFn.invoke(RestFn.java:408) at clojure.core$load_one.invoke(core.clj:5446) at clojure.core$load_lib$fn__5015.invoke(core.clj:5486) at clojure.core$load_lib.doInvoke(core.clj:5485) at clojure.lang.RestFn.applyTo(RestFn.java:142) at clojure.core$apply.invoke(core.clj:626) at clojure.core$load_libs.doInvoke(core.clj:5524) at clojure.lang.RestFn.applyTo(RestFn.java:137) at clojure.core$apply.invoke(core.clj:626) at clojure.core$require.doInvoke(core.clj:5607) at clojure.lang.RestFn.invoke(RestFn.java:408) at leiningen.help$resolve_task.invoke(he
Re: fn and let are special forms or macros?
Hi Mark, Here's a brief doc on special forms: http://clojure-doc.org/articles/language/macros.html#special-forms-in-detail Thanks, Ambrose On Wed, Jun 18, 2014 at 12:13 PM, Mark P wrote: > Thanks Tassilo for the explanation - much appreciated! > > I have been searching the web and searching clojure text books for the > last two hours trying to find the answer to this same question. Finally I > stumbled onto this thread! > > I realize that hiding the complexity of distinctions between fn / fn* and > let / let* etc might make the documentation more accessible for some users, > but for others (like me and presumably also Plínio) it makes it really hard > to track down what is *really* going on. I wish this distinction was part > of the formal documentation. > > Does anyone know of documentation anywhere that does include these kinds > of distinction? > > Thanks, > > Mark. > > On Thursday, 6 March 2014 02:27:26 UTC+10:30, Tassilo Horn wrote: > >> Plínio Balduino writes: >> >> Hi Plínio, >> >> > Clojure.org says fn and let are special forms, but using the macro >> > sourceshows that both are macros calling fn* and let* respectivelly. >> > >> > So fn and let are "special special forms", or clojure.org is >> > incorrect/outdated? >> >> Well, they are correct from a user's point of view. One never uses the >> real special forms fn* and let*. >> >> > If fn and let are really special forms and not macros, could you >> > explain why? >> >> fn and let (and also loop) are macros around the real special forms fn* >> and let* (and loop*) that add support for destructuring. For example, >> >> (let [[a b] [1 2]] >> (+ a b)) >> >> expands to >> >> (let* >> [vec__8592 [1 2] >>a (clojure.core/nth vec__8592 0 nil) >>b (clojure.core/nth vec__8592 1 nil)] >> (+ a b)) >> >> where the destructuring has been transformed to "normal" code already. >> >> Bye, >> Tassilo >> > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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.