InvokeDynamic
Hi! Did someone ever look at supporting InvokeDynamic for Clojure? I've read a couple of blogs and it seemed interesting, would be cool to know if there actually were any advantages in practice. -- 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: How to troubleshoot FileNotFoundException: Could not locate clojure/tools/namespace/parse...?
Thank you all! @Stuart Great to know that 0.2.1 is backwards compatible. @Sean You are right about running it separately. But I am lazy and it is easier to be able to just run (sdoc) from repl and get the ns browser up. On the other hand, it is perhaps not so smart to pollute one's profile with all possible tools and then spend hours debugging conflicts :) 2014-04-03 23:34 GMT+02:00 Stuart Sierra : > > > On Wednesday, April 2, 2014 7:49:07 AM UTC-4, Jakub Holy wrote: >> >> When starting lein (namely lein ring server) I got a little helpful >> exception and stack trace with the key line being: >> >> FileNotFoundException: Could not locate >> clojure/tools/namespace/parse__init.class >> or clojure/tools/namespace/parse.clj on classpath >> > > > This could be caused by different libraries or plugins depending on > different versions of tools.namespace. > > clojure.tools.namespace.parse is present starting with tools.namespace > version 0.2.0. > > Note: In tools.namespace version 0.2.0 I removed the namespace > `clojure.tools.namespace` which was present in 0.1.x. After learning that > this caused problems, I added the deprecated namespace back in version > 0.2.1. > > You can use `lein deps :tree` to figure out which version is getting > included in your project. > > You can add an explicit dependency in your project.clj on a version that > you know is compatible with all the libraries/plugins you want to use. > > In this case, the latest version of tools.namespace is backwards > compatible with 0.1.X versions. If that were not the case, you'd be out of > luck. > > > > -- > 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 a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/h3U0zx9kEvo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- *Forget software. Strive to make an impact, deliver a valuable change.* * (**Vær så snill og hjelp meg med å forbedre norsken **min –** skriftlig og muntlig. Takk!**)* Jakub Holy Solutions Engineer | +47 966 23 666 Iterate AS | www.iterate.no The Lean Software Development Consultancy - http://theholyjava.wordpress.com/ - -- 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: Integration with Mutable Object-Oriented Eventing Hell
Hi Luca, On Thursday, April 3, 2014 11:57:27 AM UTC+2, icamts wrote: > > Hi Christian, > I think you are looking for this. > > http://en.wikipedia.org/wiki/Facade_pattern > > In clojure you can use a def for each private member of the facade. > Alternatively you can write a function to instantiate and return private > members. Use a defn for each facade's methods. > > I'm not sure in how the facade pattern would help me on the conceptual level. I'm pretty confident that I can work out the technical details of how to get my fingers at the existing objects or how to interface from the OO world into Clojure code. The question is more like, how should I model the integration? It seems pretty useless and/or dangerous to me to put the mutable objects into Clojure's immutable data structures and work on the them directly. Would I kind of extract the objects' data (value-like) into my data structures, perform operations an these and in the end retransform those values onto the objects? That's more like the patterns I am searching for. Thanks, Christian -- 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: InvokeDynamic
Hi, Hansen Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 Plinio Balduino 11 982 611 487 > On 04/04/2014, at 05:42, Robin Heggelund Hansen wrote: > > Hi! > > Did someone ever look at supporting InvokeDynamic for Clojure? I've read a > couple of blogs and it seemed interesting, would be cool to know if there > actually were any advantages in practice. > -- > 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: InvokeDynamic
Yeah, those were the blog posts I've read, but I can't see that this is actually being worked on for Clojure? 4. apr. 2014 kl. 11:43 skrev Plínio Balduino : > Hi, Hansen > > Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. > > http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ > > http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 > > Plinio Balduino > 11 982 611 487 > > On 04/04/2014, at 05:42, Robin Heggelund Hansen wrote: > >> Hi! >> >> Did someone ever look at supporting InvokeDynamic for Clojure? I've read a >> couple of blogs and it seemed interesting, would be cool to know if there >> actually were any advantages in practice. >> >> -- >> 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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. > To unsubscribe from this group and all its topics, 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: InvokeDynamic
The guys from core team will correct me if I say any bs, but I think it's not possible to keep Clojure compatible with Java 6, as Clojure 1.6 is, and use InvokeDynamic bytecode in the same binary. DynJS, for example, is not compatible with Java 6. Anyway, it would be nice to see any experiment with that bytecode and Clojure, maybe evolving to some form of Clojure 2.0. It would be nice to hear the core team and/or Hickey's position about it. Regards Plinio Balduino > On 04/04/2014, at 06:44, Robin Heggelund Hansen wrote: > > Yeah, those were the blog posts I’ve read, but I can’t see that this is > actually being worked on for Clojure? > >> 4. apr. 2014 kl. 11:43 skrev Plínio Balduino : >> >> Hi, Hansen >> >> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. >> >> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ >> >> http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 >> >> Plinio Balduino >> 11 982 611 487 >> >>> On 04/04/2014, at 05:42, Robin Heggelund Hansen >>> wrote: >>> >>> Hi! >>> >>> Did someone ever look at supporting InvokeDynamic for Clojure? I've read a >>> couple of blogs and it seemed interesting, would be cool to know if there >>> actually were any advantages in practice. >>> >>> -- >>> 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 a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. >> To unsubscribe from this group and all its topics, 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: InvokeDynamic
You may find this thread enlightening: https://groups.google.com/d/msg/clojure-dev/PuV7XTps9vo/SkkNuiynKfUJ /Ragnar On Friday, 4 April 2014 10:44:42 UTC+1, Robin Heggelund Hansen wrote: > > Yeah, those were the blog posts I’ve read, but I can’t see that this is > actually being worked on for Clojure? > > 4. apr. 2014 kl. 11:43 skrev Plínio Balduino > >: > > Hi, Hansen > > Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. > > > http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ > > > http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 > > Plinio Balduino > 11 982 611 487 > > On 04/04/2014, at 05:42, Robin Heggelund Hansen > > > wrote: > > Hi! > > Did someone ever look at supporting InvokeDynamic for Clojure? I've read a > couple of blogs and it seemed interesting, would be cool to know if there > actually were any advantages in practice. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. > To unsubscribe from this group and all its topics, 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: InvokeDynamic
Thank you! 4. apr. 2014 kl. 12:35 skrev Ragnar Dahlén : > You may find this thread enlightening: > > https://groups.google.com/d/msg/clojure-dev/PuV7XTps9vo/SkkNuiynKfUJ > > /Ragnar > > On Friday, 4 April 2014 10:44:42 UTC+1, Robin Heggelund Hansen wrote: > Yeah, those were the blog posts I've read, but I can't see that this is > actually being worked on for Clojure? > > 4. apr. 2014 kl. 11:43 skrev Plínio Balduino : > >> Hi, Hansen >> >> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. >> >> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ >> >> http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 >> >> Plinio Balduino >> 11 982 611 487 >> >> On 04/04/2014, at 05:42, Robin Heggelund Hansen wrote: >> >>> Hi! >>> >>> Did someone ever look at supporting InvokeDynamic for Clojure? I've read a >>> couple of blogs and it seemed interesting, would be cool to know if there >>> actually were any advantages in practice. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google Groups >>> "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. >> To unsubscribe from this group and all its topics, 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 a topic in the Google > Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. > To unsubscribe from this group and all its topics, 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: InvokeDynamic
I agree that we cannot (yet) cut support for Java 6 but we continue to watch polls and usage closely. Java 6 has been EOL'ed for a while now and usage continues to drop. However, there are a few minor JDK-specific bits already in Clojure and it would be entirely possible to handle separate paths for 6 and 7. The major concern is with the stability and *predictability* of invokedynamic. indy has undergone major revisions between Java 7 and 8 so it may be that what needs to be done is substantially different between the two. My impression from watching the work of people like Charles Nutter is that it requires a lot of flag tweaking to make it work reliably. It also seems that when you go off the fast path, you can go over a cliff with performance. **These are my impressions - they could be wrong.** For these reasons, it has not been high on the priority list, but having more work or data on this would be great. I am not speaking for Rich here, but my guess is that this is compatible with his thoughts. One of my first efforts for 1.7 is going to be working out how to support multiple Clojure builds for different purposes (such as lean runtime, Android, whatever) - this is foundational work that can open up the possibility of specialized Clojure builds, such as an invokedynamic-aware version. Alex On Friday, April 4, 2014 5:09:16 AM UTC-5, Plinio Balduino wrote: > > The guys from core team will correct me if I say any bs, but I think it's > not possible to keep Clojure compatible with Java 6, as Clojure 1.6 is, and > use InvokeDynamic bytecode in the same binary. DynJS, for example, is not > compatible with Java 6. > > Anyway, it would be nice to see any experiment with that bytecode and > Clojure, maybe evolving to some form of Clojure 2.0. > > It would be nice to hear the core team and/or Hickey's position about it. > > Regards > > Plinio Balduino > > On 04/04/2014, at 06:44, Robin Heggelund Hansen > > > wrote: > > Yeah, those were the blog posts I’ve read, but I can’t see that this is > actually being worked on for Clojure? > > 4. apr. 2014 kl. 11:43 skrev Plínio Balduino > >: > > Hi, Hansen > > Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. > > > http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ > > > http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 > > Plinio Balduino > 11 982 611 487 > > On 04/04/2014, at 05:42, Robin Heggelund Hansen > > > wrote: > > Hi! > > Did someone ever look at supporting InvokeDynamic for Clojure? I've read a > couple of blogs and it seemed interesting, would be cool to know if there > actually were any advantages in practice. > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to a topic in the > Google Groups "Clojure" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > clojure+u...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com . > For more options, visit https://groups.google.com/d/optout. > > -- You r
Re: InvokeDynamic
Great to hear, I'm looking forward to progress :) 4. apr. 2014 kl. 14:45 skrev Alex Miller : > I agree that we cannot (yet) cut support for Java 6 but we continue to watch > polls and usage closely. Java 6 has been EOL'ed for a while now and usage > continues to drop. However, there are a few minor JDK-specific bits already > in Clojure and it would be entirely possible to handle separate paths for 6 > and 7. > > The major concern is with the stability and *predictability* of > invokedynamic. indy has undergone major revisions between Java 7 and 8 so it > may be that what needs to be done is substantially different between the two. > My impression from watching the work of people like Charles Nutter is that it > requires a lot of flag tweaking to make it work reliably. It also seems that > when you go off the fast path, you can go over a cliff with performance. > **These are my impressions - they could be wrong.** For these reasons, it has > not been high on the priority list, but having more work or data on this > would be great. I am not speaking for Rich here, but my guess is that this is > compatible with his thoughts. > > One of my first efforts for 1.7 is going to be working out how to support > multiple Clojure builds for different purposes (such as lean runtime, > Android, whatever) - this is foundational work that can open up the > possibility of specialized Clojure builds, such as an invokedynamic-aware > version. > > Alex > > On Friday, April 4, 2014 5:09:16 AM UTC-5, Plinio Balduino wrote: > The guys from core team will correct me if I say any bs, but I think it's not > possible to keep Clojure compatible with Java 6, as Clojure 1.6 is, and use > InvokeDynamic bytecode in the same binary. DynJS, for example, is not > compatible with Java 6. > > Anyway, it would be nice to see any experiment with that bytecode and > Clojure, maybe evolving to some form of Clojure 2.0. > > It would be nice to hear the core team and/or Hickey's position about it. > > Regards > > Plinio Balduino > > On 04/04/2014, at 06:44, Robin Heggelund Hansen wrote: > >> Yeah, those were the blog posts I've read, but I can't see that this is >> actually being worked on for Clojure? >> >> 4. apr. 2014 kl. 11:43 skrev Plínio Balduino : >> >>> Hi, Hansen >>> >>> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. >>> >>> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need-invokedynamic-but-it-might-be-nice/ >>> >>> http://blog.headius.com/2011/10/why-clojure-doesnt-need-invokedynamic.html?m=1 >>> >>> Plinio Balduino >>> 11 982 611 487 >>> >>> On 04/04/2014, at 05:42, Robin Heggelund Hansen wrote: >>> Hi! Did someone ever look at supporting InvokeDynamic for Clojure? I've read a couple of blogs and it seemed interesting, would be cool to know if there actually were any advantages in practice. -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clo...@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+u...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Clojure" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/clojure/vNXIfkgRRkI/unsubscribe. >>> To unsubscribe from this group and all its topics, send an email to >>> clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with your >> first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You r
Re: Integration with Mutable Object-Oriented Eventing Hell
Hi Christian, I've been a bit too technical. What I mean is give your OO system a new interface made of functions. Choose functions according to your needs and develop a layer of functions that can create and access your objects instances. It's my opinion this is the stateful bridge in your first e-mail. Develop new features in clojure over this layer. This is a way to "use" your OO system. If you need to "extend" your objects the excellent clojure type selection flowchart by Chas Emerick will help to understand options clojure gives to you. https://github.com/cemerick/clojure-type-selection-flowchart/ Il giorno venerdì 4 aprile 2014 11:24:18 UTC+2, Christian Eitner ha scritto: > > Hi Luca, > > On Thursday, April 3, 2014 11:57:27 AM UTC+2, icamts wrote: >> >> Hi Christian, >> I think you are looking for this. >> >> http://en.wikipedia.org/wiki/Facade_pattern >> >> In clojure you can use a def for each private member of the facade. >> Alternatively you can write a function to instantiate and return private >> members. Use a defn for each facade's methods. >> >> > I'm not sure in how the facade pattern would help me on the conceptual > level. > > I'm pretty confident that I can work out the technical details of how to > get my fingers at the existing objects or how to interface from the OO > world into Clojure code. > > The question is more like, how should I model the integration? > > It seems pretty useless and/or dangerous to me to put the mutable objects > into Clojure's immutable data structures and work on the them directly. > Would I kind of extract the objects' data (value-like) into my data > structures, perform operations an these and in the end retransform those > values onto the objects? > I don't think you'll be able to restore clojure processed values in all objects. Maybe you'll need to extend Java types in clojure (see before). > > That's more like the patterns I am searching for. > > Thanks, > > Christian > I hope this helps, Luca -- 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.
Thoughts on a curly-infix reader macro?
Proposal:
For an *odd* number of forms a, x, b, ...
{a x b x c ...} => (x a b c ...)
{a x b y c ...} => (*nfx* a x b y c ...)
Reasoning:
Even after a lot of practice, prefix math is still harder (at least for
me...) to read than non-prefix math. The [], () and <> matching delimiters
are already taken, but {} is only used for an even number of forms (and, in
fact, throws an exception on an odd number of forms.)
; trumped-up examples
(defn harmonic-mean [x1 x2]
{{2 * x1 * x2} / {x1 + x2}})
(defn fib [n]
(cond
{n = 0} 1
{n = 1} 1
:else {(fib {n - 1}) + (fib {n - 2})}))
Basically, I'm claiming a solid win on readability, and no risk of breaking
any existing code.
I realize there's a certain risk of mistaking curly-infix for a map literal
when reading code, but I think it's minimal. To me, at least, {x + y} just
doesn't look like a map.
Thoughts?
--
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.
Proxy vs. glue class
Hi, I am trying to understand what the best course of action would be in the following scenario: I have a Java base class that I need to extend. The class is fundamental to my application and will be running fairly hot compared to other bits of code in the application. Therefore I want it to execute as fast as possible. The way I see it there are two options; 1) Use proxy 2) Create a class in Java that provides the glue between Java and Clojure and removes the need for extending the base class in Clojure. I would prefer to use option 1 but I am a little bit worried about the performance implications of doing so, especially adding a level of indirection by using map-lookup for accessing methods so I suspect I will have to go with option 2. Any recommendations or alternatives? 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.
Re: Integration with Mutable Object-Oriented Eventing Hell
Christian Eitner <7enderh...@gmail.com> writes: >> >> Hi Christian, >> I think you are looking for this. >> >> http://en.wikipedia.org/wiki/Facade_pattern >> >> In clojure you can use a def for each private member of the facade. >> Alternatively you can write a function to instantiate and return private >> members. Use a defn for each facade's methods. >> >> > I'm not sure in how the facade pattern would help me on the conceptual > level. > > I'm pretty confident that I can work out the technical details of how to > get my fingers at the existing objects or how to interface from the OO > world into Clojure code. > > The question is more like, how should I model the integration? > > It seems pretty useless and/or dangerous to me to put the mutable objects > into Clojure's immutable data structures and work on the them directly. > Would I kind of extract the objects' data (value-like) into my data > structures, perform operations an these and in the end retransform those > values onto the objects? I've been through this with by Tawny-OWL library https://github.com/phillord/tawny-owl. I wanted clojure for the flexible syntax and evaluative environment, but I am driving an stateful, event driven API (namely the OWL API http://owlapi.sourceforge.net/). In the end, I have basically ignored a lot of what people feel makes clojure nice. Most of my functions have side-effects, I use state. I even make use of Stuart Sierra's top clojure anti-pattern. I just use Clojure to drive the event-driven framework underneath. The practical upshot of it is that some of clojure's clever features, like the concurrency support are relatively useless, and some of them (lazy sequences) are nothing other than a pain in the ass. I still, found Clojure to be a good choice. Lazy sequences are irritating, but not a major disaster, just requiring typing doall a lot. And I think my approach was still the right one. For instance, I can use Clojure to drive a Java application that is built with the OWL API just by sharing the underlying data structures with Tawny (http://vimeo.com/79136990). Doing this if there was two sets of data structures that I was keeping in sync would not be good. And all was relatively easy to achieve because of the Clojure ecosystem -- nrepl, cider, maven (dependencies) and pomegranate. I've just been very careful NOT to replicate in the Clojure what the API will do for me; I most don't store mutable objects Clojure data structures (for any length of time), and on the odd occasion that I do, I do not depend on their state. I have been toying with turning the mutable objects into Clojure data structures; originally, to support a form of user documentation, but I am toying with idea of querying and searching over them. I think this is going to work, but it's going to be slow. For my use case, I don't think the slow performance will be a disaster. Phil -- 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: Proxy vs. glue class
Anvar Karimson writes: > I am trying to understand what the best course of action would be in the > following scenario: > > I have a Java base class that I need to extend. The class is fundamental to > my application and will be running fairly hot compared to other bits of > code in the application. Therefore I want it to execute as fast as > possible. The way I see it there are two options; > > 1) Use proxy > 2) Create a class in Java that provides the glue between Java and Clojure > and removes the need for extending the base class in Clojure. > > I would prefer to use option 1 but I am a little bit worried about the > performance implications of doing so, especially adding a level of > indirection by using map-lookup for accessing methods so I suspect I will > have to go with option 2. > > Any recommendations or alternatives? Or Option 3, create a class in Clojure which extends the Java. My suggestion, try number 1 which is easy, then performance test it. Phil -- 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: Thoughts on a curly-infix reader macro?
The desire (and rejection) of infix notation for Lisp is as old as the hills. "Therefore we expect future generations of Lisp programmers to continue to reinvent Algol-style syntax for Lisp, over and over and over again, and we are equally confident that they will continue, after an initial period of infatuation, to reject it. (Perhaps this process should be regarded as a rite of passage for Lisp hackers.)" -- Steele and Gabriel, [1]. The full paper "The Evolution of Lisp" [2] is definitely worth reading. See also the video presentation [3]. As far as Clojure goes, it's highly unlikely that the Clojure language will accept your proposal. I suggest that you write a macro or use a data-reader [4]. [1] http://www.paulgraham.com/syntaxquestion.html [2] http://www.dreamsongs.com/Files/HOPL2-Uncut.pdf [3] http://www.infoq.com/presentations/Lisp-Guy-Steele-Richard-Gabriel [4] https://gist.github.com/miner/5224709 -- 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: Proxy vs. glue class
Is that via gen-class? I have to admit that I am not very familiar with gen-class, is it still possible to use the class from Clojure? Yes, that is probably the most pragmatic choice, premature optimization and all that. On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: > > Anvar Karimson > writes: > > I am trying to understand what the best course of action would be in the > > following scenario: > > > > I have a Java base class that I need to extend. The class is fundamental > to > > my application and will be running fairly hot compared to other bits of > > code in the application. Therefore I want it to execute as fast as > > possible. The way I see it there are two options; > > > > 1) Use proxy > > 2) Create a class in Java that provides the glue between Java and > Clojure > > and removes the need for extending the base class in Clojure. > > > > I would prefer to use option 1 but I am a little bit worried about the > > performance implications of doing so, especially adding a level of > > indirection by using map-lookup for accessing methods so I suspect I > will > > have to go with option 2. > > > > Any recommendations or alternatives? > > Or Option 3, create a class in Clojure which extends the Java. > > My suggestion, try number 1 which is easy, then performance test it. > > Phil > -- 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: Thoughts on a curly-infix reader macro?
Odd-entry-count maps would have corner cases: One would need to use an even number of unary operators. If an odd number of unary operators were used, what looked like a valid expression would become a map, and that might be hard to figure out. Also, since the order of entries in a map is not guaranteed, the reader would need to store the map entries in an intermediate form and decide when it gets to the end whether it becomes a map or a macro call. There's nothing special about curly braces in terms of being able to read math - in fact, parentheses make more sense. So a macro in position one of a list seems like a much better answer. Even if you'd like to avoid spelling out a macro name like "infix", you could make it "i", and this handles unary operators: (infix 2 + 4 * - x) -- 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: Proxy vs. glue class
Yeah, gen-class is the thing. Proxy, well, proxies, but genclass produces a statically compiled ahead of time class. It's a real Java class, so yes, you can use it from Clojure like any other Java class. Genclass is a little more painful than proxy, but probably a little less painful than having a combined Java/Clojure build. Phil Anvar Karimson writes: > Is that via gen-class? I have to admit that I am not very familiar with > gen-class, is it still possible to use the class from Clojure? > > Yes, that is probably the most pragmatic choice, premature optimization and > all that. > > On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: >> >> Anvar Karimson > writes: >> > I am trying to understand what the best course of action would be in the >> > following scenario: >> > >> > I have a Java base class that I need to extend. The class is fundamental >> to >> > my application and will be running fairly hot compared to other bits of >> > code in the application. Therefore I want it to execute as fast as >> > possible. The way I see it there are two options; >> > >> > 1) Use proxy >> > 2) Create a class in Java that provides the glue between Java and >> Clojure >> > and removes the need for extending the base class in Clojure. >> > >> > I would prefer to use option 1 but I am a little bit worried about the >> > performance implications of doing so, especially adding a level of >> > indirection by using map-lookup for accessing methods so I suspect I >> will >> > have to go with option 2. >> > >> > Any recommendations or alternatives? >> >> Or Option 3, create a class in Clojure which extends the Java. >> >> My suggestion, try number 1 which is easy, then performance test it. >> >> Phil >> -- Phillip Lord, Phone: +44 (0) 191 222 7827 Lecturer in Bioinformatics, Email: phillip.l...@newcastle.ac.uk School of Computing Science, http://homepages.cs.ncl.ac.uk/phillip.lord Room 914 Claremont Tower, skype: russet_apples Newcastle University, twitter: phillord NE1 7RU -- 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: Proxy vs. glue class
Ok, thanks! I will have a look! On Friday, 4 April 2014 16:43:20 UTC+1, Phillip Lord wrote: > > > Yeah, gen-class is the thing. Proxy, well, proxies, but genclass > produces a statically compiled ahead of time class. It's a real Java > class, so yes, you can use it from Clojure like any other Java class. > > Genclass is a little more painful than proxy, but probably a little less > painful than having a combined Java/Clojure build. > > Phil > > Anvar Karimson > writes: > > > Is that via gen-class? I have to admit that I am not very familiar with > > gen-class, is it still possible to use the class from Clojure? > > > > Yes, that is probably the most pragmatic choice, premature optimization > and > > all that. > > > > On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: > >> > >> Anvar Karimson > writes: > >> > I am trying to understand what the best course of action would be in > the > >> > following scenario: > >> > > >> > I have a Java base class that I need to extend. The class is > fundamental > >> to > >> > my application and will be running fairly hot compared to other bits > of > >> > code in the application. Therefore I want it to execute as fast as > >> > possible. The way I see it there are two options; > >> > > >> > 1) Use proxy > >> > 2) Create a class in Java that provides the glue between Java and > >> Clojure > >> > and removes the need for extending the base class in Clojure. > >> > > >> > I would prefer to use option 1 but I am a little bit worried about > the > >> > performance implications of doing so, especially adding a level of > >> > indirection by using map-lookup for accessing methods so I suspect I > >> will > >> > have to go with option 2. > >> > > >> > Any recommendations or alternatives? > >> > >> Or Option 3, create a class in Clojure which extends the Java. > >> > >> My suggestion, try number 1 which is easy, then performance test it. > >> > >> Phil > >> > > -- > Phillip Lord, Phone: +44 (0) 191 222 7827 > Lecturer in Bioinformatics, Email: > philli...@newcastle.ac.uk > School of Computing Science, > http://homepages.cs.ncl.ac.uk/phillip.lord > Room 914 Claremont Tower, skype: russet_apples > Newcastle University, twitter: phillord > NE1 7RU > -- 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.
Changing a value in let
Hi there I wrote this code expecting an error, but it worked: (let [x 3 x (* valor 2)] x) ; 6 Is It the expected behavior or, considering that a local binding could not be modified, it should really raise an error? Thank you Plínio -- 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: Changing a value in let
This is not modifying the value it's creating a new scope with a new version of x. The binding above is shorthand for: (let [x 3] (let [x 42] (println x)) (println x)) ;; prints: 42 3 Timothy On Fri, Apr 4, 2014 at 10:23 AM, Plínio Balduino wrote: > Hi there > > I wrote this code expecting an error, but it worked: > > (let [x 3 > x (* valor 2)] > x) > ; 6 > > Is It the expected behavior or, considering that a local binding could not > be modified, it should really raise an error? > > Thank you > > Plínio > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Changing a value in let
Thank you I imagined something like that. Anyway, as the second binding is shadowing the first, there's no way to access the first value, right? Plínio On Fri, Apr 4, 2014 at 1:26 PM, Timothy Baldridge wrote: > This is not modifying the value it's creating a new scope with a new > version of x. The binding above is shorthand for: > > (let [x 3] > (let [x 42] > (println x)) > (println x)) > > ;; prints: > > 42 > 3 > > > Timothy > > > On Fri, Apr 4, 2014 at 10:23 AM, Plínio Balduino wrote: > >> Hi there >> >> I wrote this code expecting an error, but it worked: >> >> (let [x 3 >> x (* valor 2)] >> x) >> ; 6 >> >> Is It the expected behavior or, considering that a local binding could >> not be modified, it should really raise an error? >> >> Thank you >> >> Plínio >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > "One of the main causes of the fall of the Roman Empire was that-lacking > zero-they had no way to indicate successful termination of their C > programs." > (Robert Firth) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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: Changing a value in let
That's correct, and often clojure compilers (like ClojureScript) many actually completely rename the variable to something else. Timothy On Fri, Apr 4, 2014 at 10:34 AM, Plínio Balduino wrote: > Thank you > > I imagined something like that. Anyway, as the second binding is shadowing > the first, there's no way to access the first value, right? > > Plínio > > > On Fri, Apr 4, 2014 at 1:26 PM, Timothy Baldridge wrote: > >> This is not modifying the value it's creating a new scope with a new >> version of x. The binding above is shorthand for: >> >> (let [x 3] >> (let [x 42] >> (println x)) >> (println x)) >> >> ;; prints: >> >> 42 >> 3 >> >> >> Timothy >> >> >> On Fri, Apr 4, 2014 at 10:23 AM, Plínio Balduino wrote: >> >>> Hi there >>> >>> I wrote this code expecting an error, but it worked: >>> >>> (let [x 3 >>> x (* valor 2)] >>> x) >>> ; 6 >>> >>> Is It the expected behavior or, considering that a local binding could >>> not be modified, it should really raise an error? >>> >>> Thank you >>> >>> Plínio >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> "One of the main causes of the fall of the Roman Empire was that-lacking >> zero-they had no way to indicate successful termination of their C >> programs." >> (Robert Firth) >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- "One of the main causes of the fall of the Roman Empire was that-lacking zero-they had no way to indicate successful termination of their C programs." (Robert Firth) -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Thoughts on a curly-infix reader macro?
Incanter supports this with the $= prefix:
($= 7 + 8 - 2 * 6 / 2)
http://data-sorcery.org/2010/05/14/infix-math/
Might be worth looking at...
On Thursday, April 3, 2014 11:17:32 PM UTC-5, Joshua Brulé wrote:
>
> Proposal:
>
> For an *odd* number of forms a, x, b, ...
>
> {a x b x c ...} => (x a b c ...)
> {a x b y c ...} => (*nfx* a x b y c ...)
>
> Reasoning:
>
> Even after a lot of practice, prefix math is still harder (at least for
> me...) to read than non-prefix math. The [], () and <> matching delimiters
> are already taken, but {} is only used for an even number of forms (and, in
> fact, throws an exception on an odd number of forms.)
>
> ; trumped-up examples
> (defn harmonic-mean [x1 x2]
> {{2 * x1 * x2} / {x1 + x2}})
>
> (defn fib [n]
> (cond
> {n = 0} 1
> {n = 1} 1
> :else {(fib {n - 1}) + (fib {n - 2})}))
>
> Basically, I'm claiming a solid win on readability, and no risk of
> breaking any existing code.
>
> I realize there's a certain risk of mistaking curly-infix for a map
> literal when reading code, but I think it's minimal. To me, at least, {x +
> y} just doesn't look like a map.
>
> Thoughts?
>
--
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: InvokeDynamic
I strongly recommend to talk with dynjs guys about invokedynamic. Dynjs is a ECMAScript engine written in Java 7 that was intended to use all the power of invokedynamic. Again, they can correct me if I'm saying bananas, but it looks lie Java 7 has some issues in invokedynamic implementation and the result is quite slower than expected. Douglas Campos, aka qmx, father of dynjs presented some talks about that specific feature and the problems that dynjs core team found. https://www.youtube.com/watch?v=bw-NBcFKNtc I hope that it can be useful in our discussion. Plínio On Fri, Apr 4, 2014 at 9:49 AM, Robin Heggelund Hansen wrote: > Great to hear, I'm looking forward to progress :) > > 4. apr. 2014 kl. 14:45 skrev Alex Miller : > > I agree that we cannot (yet) cut support for Java 6 but we continue to > watch polls and usage closely. Java 6 has been EOL'ed for a while now and > usage continues to drop. However, there are a few minor JDK-specific bits > already in Clojure and it would be entirely possible to handle separate > paths for 6 and 7. > > The major concern is with the stability and *predictability* of > invokedynamic. indy has undergone major revisions between Java 7 and 8 so > it may be that what needs to be done is substantially different between the > two. My impression from watching the work of people like Charles Nutter is > that it requires a lot of flag tweaking to make it work reliably. It also > seems that when you go off the fast path, you can go over a cliff with > performance. **These are my impressions - they could be wrong.** For these > reasons, it has not been high on the priority list, but having more work or > data on this would be great. I am not speaking for Rich here, but my guess > is that this is compatible with his thoughts. > > One of my first efforts for 1.7 is going to be working out how to support > multiple Clojure builds for different purposes (such as lean runtime, > Android, whatever) - this is foundational work that can open up the > possibility of specialized Clojure builds, such as an invokedynamic-aware > version. > > Alex > > On Friday, April 4, 2014 5:09:16 AM UTC-5, Plinio Balduino wrote: >> >> The guys from core team will correct me if I say any bs, but I think it's >> not possible to keep Clojure compatible with Java 6, as Clojure 1.6 is, and >> use InvokeDynamic bytecode in the same binary. DynJS, for example, is not >> compatible with Java 6. >> >> Anyway, it would be nice to see any experiment with that bytecode and >> Clojure, maybe evolving to some form of Clojure 2.0. >> >> It would be nice to hear the core team and/or Hickey's position about it. >> >> Regards >> >> Plinio Balduino >> >> On 04/04/2014, at 06:44, Robin Heggelund Hansen >> wrote: >> >> Yeah, those were the blog posts I've read, but I can't see that this is >> actually being worked on for Clojure? >> >> 4. apr. 2014 kl. 11:43 skrev Plínio Balduino : >> >> Hi, Hansen >> >> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. >> >> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need- >> invokedynamic-but-it-might-be-nice/ >> >> http://blog.headius.com/2011/10/why-clojure-doesnt-need- >> invokedynamic.html?m=1 >> >> Plinio Balduino >> 11 982 611 487 >> >> On 04/04/2014, at 05:42, Robin Heggelund Hansen >> wrote: >> >> Hi! >> >> Did someone ever look at supporting InvokeDynamic for Clojure? I've read >> a couple of blogs and it seemed interesting, would be cool to know if there >> actually were any advantages in practice. >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+u...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clo...@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+u...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "Clojure" group. >> To unsubscribe from this topic, visit https://groups.google.com/d/ >> topic/clojure/vNXIfkgRRkI/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> clojure+
Online Gorilla REPL worksheet viewer
Hi folks, I've got a very simple online viewer for Gorilla REPL worksheets going here: http://gorilla-repl.org/viewer.html It's free, with no registration or other burdensome business. You use it by uploading your worksheet to GitHub, either as part of a project, or to a Gist, and then constructing the appropriate link as detailed on the page above. Here are couple of examples to get the idea: A symbolic regression tutorial: http://viewer.gorilla-repl.org/view.html?source=github&user=JonyEpsilon&repo=sr-basics&path=ws/introduction.clj Some graph examples: http://viewer.gorilla-repl.org/view.html?source=github&user=JonyEpsilon&repo=gorilla-test&path=ws/graph-examples.clj I think it's a nice easy way to evangelise/teach/collaborate/generally-show-off with Clojure! Looking forward to seeing what you have to share ... Jony -- 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: Changing a value in let
Ouch. Now I realized that it's exactly what happens when you do this to debug a sequential binding. (let [x 35 _ (println "x is" x) y (* 35 3) _ (println "y is" y)] ; some code ) Thank you for the elucidation. Plínio On Fri, Apr 4, 2014 at 1:36 PM, Timothy Baldridge wrote: > That's correct, and often clojure compilers (like ClojureScript) many > actually completely rename the variable to something else. > > Timothy > > > On Fri, Apr 4, 2014 at 10:34 AM, Plínio Balduino wrote: > >> Thank you >> >> I imagined something like that. Anyway, as the second binding is >> shadowing the first, there's no way to access the first value, right? >> >> Plínio >> >> >> On Fri, Apr 4, 2014 at 1:26 PM, Timothy Baldridge >> wrote: >> >>> This is not modifying the value it's creating a new scope with a new >>> version of x. The binding above is shorthand for: >>> >>> (let [x 3] >>> (let [x 42] >>> (println x)) >>> (println x)) >>> >>> ;; prints: >>> >>> 42 >>> 3 >>> >>> >>> Timothy >>> >>> >>> On Fri, Apr 4, 2014 at 10:23 AM, Plínio Balduino wrote: >>> Hi there I wrote this code expecting an error, but it worked: (let [x 3 x (* valor 2)] x) ; 6 Is It the expected behavior or, considering that a local binding could not be modified, it should really raise an error? Thank you Plínio -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> "One of the main causes of the fall of the Roman Empire was that-lacking >>> zero-they had no way to indicate successful termination of their C >>> programs." >>> (Robert Firth) >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clojure@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+unsubscr...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+unsubscr...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Clojure" group. >> To post to this group, send email to clojure@googlegroups.com >> Note that posts from new members are moderated - please be patient with >> your first post. >> To unsubscribe from this group, send email to >> clojure+unsubscr...@googlegroups.com >> For more options, visit this group at >> http://groups.google.com/group/clojure?hl=en >> --- >> You received this message because you are subscribed to the Google Groups >> "Clojure" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to clojure+unsubscr...@googlegroups.com. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > "One of the main causes of the fall of the Roman Empire was that-lacking > zero-they had no way to indicate successful termination of their C > programs." > (Robert Firth) > > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clojure@googlegroups.com > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+unsubscr...@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 - pleas
Re: Thoughts on a curly-infix reader macro?
Why bother with a reader macro, when you can use a normal macro?
(infix (2 * x1 * x2) / (x1 + x2))
IMO, the times when it makes sense to use infix notation are fairly few,
anyway. One could write the above as:
(/ (* 2 x1 x2)
(+ x1 x2))
Which to me actually seems more readable than the infix version.
The other problem with your proposal is that Clojure's reader is almost all
about parsing data. What data does this infix notation represent? It
doesn't represent anything new, just a different way of writing lists.
Imagine if you proposed something similar for JSON. Would it make sense to
have an infix notation syntax for a data-only syntax? If not, then it
probably doesn't make sense for Clojure.
- James
On 4 April 2014 05:17, Joshua Brulé wrote:
> Proposal:
>
> For an *odd* number of forms a, x, b, ...
>
> {a x b x c ...} => (x a b c ...)
> {a x b y c ...} => (*nfx* a x b y c ...)
>
> Reasoning:
>
> Even after a lot of practice, prefix math is still harder (at least for
> me...) to read than non-prefix math. The [], () and <> matching delimiters
> are already taken, but {} is only used for an even number of forms (and, in
> fact, throws an exception on an odd number of forms.)
>
> ; trumped-up examples
> (defn harmonic-mean [x1 x2]
> {{2 * x1 * x2} / {x1 + x2}})
>
> (defn fib [n]
> (cond
> {n = 0} 1
> {n = 1} 1
> :else {(fib {n - 1}) + (fib {n - 2})}))
>
> Basically, I'm claiming a solid win on readability, and no risk of
> breaking any existing code.
>
> I realize there's a certain risk of mistaking curly-infix for a map
> literal when reading code, but I think it's minimal. To me, at least, {x +
> y} just doesn't look like a map.
>
> Thoughts?
>
> --
> 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: Thoughts on a curly-infix reader macro?
I prefer Unfix --> http://fogus.me/fun/unfix/ ;-)
On Fri, Apr 4, 2014 at 12:45 PM, Alex Miller wrote:
> Incanter supports this with the $= prefix:
> ($= 7 + 8 - 2 * 6 / 2)
>
> http://data-sorcery.org/2010/05/14/infix-math/
>
> Might be worth looking at...
>
>
> On Thursday, April 3, 2014 11:17:32 PM UTC-5, Joshua Brulé wrote:
>>
>> Proposal:
>>
>> For an *odd* number of forms a, x, b, ...
>>
>> {a x b x c ...} => (x a b c ...)
>> {a x b y c ...} => (*nfx* a x b y c ...)
>>
>> Reasoning:
>>
>> Even after a lot of practice, prefix math is still harder (at least for
>> me...) to read than non-prefix math. The [], () and <> matching delimiters
>> are already taken, but {} is only used for an even number of forms (and, in
>> fact, throws an exception on an odd number of forms.)
>>
>> ; trumped-up examples
>> (defn harmonic-mean [x1 x2]
>> {{2 * x1 * x2} / {x1 + x2}})
>>
>> (defn fib [n]
>> (cond
>> {n = 0} 1
>> {n = 1} 1
>> :else {(fib {n - 1}) + (fib {n - 2})}))
>>
>> Basically, I'm claiming a solid win on readability, and no risk of
>> breaking any existing code.
>>
>> I realize there's a certain risk of mistaking curly-infix for a map
>> literal when reading code, but I think it's minimal. To me, at least, {x +
>> y} just doesn't look like a map.
>>
>> Thoughts?
>
> --
> 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.
--
-- http://blog.fogus.me
-- http://github.com/fogus
--
--
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: cljsbuild dev/release, different debug levels
I'd love to know the "correct" answer to this too, but in the meantime, here's how I've been doing it: I define the "release" version in some namespace. To use it, I require this namespace. Eg release-namespace/func Then I create a separate file for the debug build and I require the release namespace and overwrite the function (remember, they're compiled to normal javascript variables): (defn debug-func ...) (set! release-namespace/func debug-func) Finally, in my project.clj (or profile.clj), I add the debug file to the :source-paths in the debug build settings. Though I haven't tried it, I believe you can do something similar in normal clojure using alter-var-root. On 3 April 2014 16:06, t x wrote: > The correct statement should be: "I *no longer* use cljx." :-) > > On Thu, Apr 3, 2014 at 8:05 AM, t x wrote: > > I don't use cljx. It slows down "lein cljsbuild auto." > > > > I'm using pure clojurescript. Is there a way to get the "dev" / > > "release" tag passed somehow? > > > > On Thu, Apr 3, 2014 at 6:58 AM, Alex Robbins > > wrote: > >> If you used cljx, you could probably use the feature expressions to do > what > >> you want. > >> > >> https://github.com/lynaghk/cljx > >> > >> You'd need to set up a custom rule for it, but it seems well within the > >> scope of the project. > >> > >> > >> On Thu, Apr 3, 2014 at 8:50 AM, t x wrote: > >>> > >>> Hi, > >>> > >>> I'm trying to figure out how to do the following: > >>> > >>> Have a shared cljs/* ... > >>> > >>> For the "dev" build, have (debug ...) compile to (js/console.log ...) > >>> > >>> For the "release" build, have (debug ...) compile to (do). > >>> > >>> Basically, I want different things to happen depending on whether > >>> the build is dev or release. > >>> > >>> Does anyone have an example of how to do this? > >>> > >>> 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. > -- 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: Thoughts on a curly-infix reader macro?
I knew there was another one out there, but couldn't remember whose... !
Thanks...
On Friday, April 4, 2014 2:36:59 PM UTC-5, Fogus wrote:
>
> I prefer Unfix --> http://fogus.me/fun/unfix/ ;-)
>
> On Fri, Apr 4, 2014 at 12:45 PM, Alex Miller
> >
> wrote:
> > Incanter supports this with the $= prefix:
> > ($= 7 + 8 - 2 * 6 / 2)
> >
> > http://data-sorcery.org/2010/05/14/infix-math/
> >
> > Might be worth looking at...
> >
> >
> > On Thursday, April 3, 2014 11:17:32 PM UTC-5, Joshua Brulé wrote:
> >>
> >> Proposal:
> >>
> >> For an *odd* number of forms a, x, b, ...
> >>
> >> {a x b x c ...} => (x a b c ...)
> >> {a x b y c ...} => (*nfx* a x b y c ...)
> >>
> >> Reasoning:
> >>
> >> Even after a lot of practice, prefix math is still harder (at least for
> >> me...) to read than non-prefix math. The [], () and <> matching
> delimiters
> >> are already taken, but {} is only used for an even number of forms
> (and, in
> >> fact, throws an exception on an odd number of forms.)
> >>
> >> ; trumped-up examples
> >> (defn harmonic-mean [x1 x2]
> >> {{2 * x1 * x2} / {x1 + x2}})
> >>
> >> (defn fib [n]
> >> (cond
> >> {n = 0} 1
> >> {n = 1} 1
> >> :else {(fib {n - 1}) + (fib {n - 2})}))
> >>
> >> Basically, I'm claiming a solid win on readability, and no risk of
> >> breaking any existing code.
> >>
> >> I realize there's a certain risk of mistaking curly-infix for a map
> >> literal when reading code, but I think it's minimal. To me, at least,
> {x +
> >> y} just doesn't look like a map.
> >>
> >> Thoughts?
> >
> > --
> > 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.
>
>
>
> --
> -- http://blog.fogus.me
> -- http://github.com/fogus
> --
>
--
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.
list all functions in namespace?
Is there some trick Clojure command to list all functions defined in a namespace? -- 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: list all functions in namespace?
On Apr 4, 2014, at 7:53 PM, Christopher Howard wrote: > Is there some trick Clojure command to list all functions defined in a > namespace? http://clojure.github.io/clojure/clojure.core-api.html#clojure.core/ns-publics is a good start. --Steve -- 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: Proxy vs. glue class
FWIW, in Cursive, which is a big ball of mixed Clojure + Java, I've given up trying to use gen-class and have started using Java shims for everything. I like it a lot more than gen-class, which I always feel like I'm fighting. With the new Java->Clojure API in 1.6 (or the equivalent using RT.var() and friends for earlier versions) it's really not that hard, tool support is much better and IMO it's much cleaner. gen-class will always indirect method calls through a var but if you're worried about performance you can get the underlying function object with Java and call it directly, with the caveat that you then lose the ability to update it dynamically at the REPL. I'd dearly love a deftype-style extend-type or similar which would allow base class extension. I know it's not encouraged in Clojure but one of Clojure's fundamental principles is exposing the host where it's pragmatic to do so, and both proxy and gen-class have some pretty serious warts for this purpose. On 5 April 2014 04:47, Anvar Karimson wrote: > Ok, thanks! I will have a look! > > > On Friday, 4 April 2014 16:43:20 UTC+1, Phillip Lord wrote: > >> >> Yeah, gen-class is the thing. Proxy, well, proxies, but genclass >> produces a statically compiled ahead of time class. It's a real Java >> class, so yes, you can use it from Clojure like any other Java class. >> >> Genclass is a little more painful than proxy, but probably a little less >> painful than having a combined Java/Clojure build. >> >> Phil >> >> Anvar Karimson writes: >> >> > Is that via gen-class? I have to admit that I am not very familiar with >> > gen-class, is it still possible to use the class from Clojure? >> > >> > Yes, that is probably the most pragmatic choice, premature optimization >> and >> > all that. >> > >> > On Friday, 4 April 2014 15:03:00 UTC+1, Phillip Lord wrote: >> >> >> >> Anvar Karimson > writes: >> >> > I am trying to understand what the best course of action would be in >> the >> >> > following scenario: >> >> > >> >> > I have a Java base class that I need to extend. The class is >> fundamental >> >> to >> >> > my application and will be running fairly hot compared to other bits >> of >> >> > code in the application. Therefore I want it to execute as fast as >> >> > possible. The way I see it there are two options; >> >> > >> >> > 1) Use proxy >> >> > 2) Create a class in Java that provides the glue between Java and >> >> Clojure >> >> > and removes the need for extending the base class in Clojure. >> >> > >> >> > I would prefer to use option 1 but I am a little bit worried about >> the >> >> > performance implications of doing so, especially adding a level of >> >> > indirection by using map-lookup for accessing methods so I suspect I >> >> will >> >> > have to go with option 2. >> >> > >> >> > Any recommendations or alternatives? >> >> >> >> Or Option 3, create a class in Clojure which extends the Java. >> >> >> >> My suggestion, try number 1 which is easy, then performance test it. >> >> >> >> Phil >> >> >> >> -- >> Phillip Lord, Phone: +44 (0) 191 222 7827 >> Lecturer in Bioinformatics, Email: philli...@newcastle.ac.uk >> School of Computing Science,http://homepages.cs.ncl.ac. >> uk/phillip.lord >> Room 914 Claremont Tower, skype: russet_apples >> Newcastle University, twitter: phillord >> NE1 7RU >> > -- > 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: InvokeDynamic
My understanding is that invokedynamic was very problematic in Java 7, but is quite a different design and works much better in Java 8. I'd expect it to be much more heavily optimised in Java 8 since it's used by a core Java feature (lambdas). Unfortunately targeting Java 8 only is probably not feasible for some time. On 5 April 2014 05:46, Plínio Balduino wrote: > I strongly recommend to talk with dynjs guys about invokedynamic. > > Dynjs is a ECMAScript engine written in Java 7 that was intended to use > all the power of invokedynamic. Again, they can correct me if I'm saying > bananas, but it looks lie Java 7 has some issues in > invokedynamic implementation and the result is quite slower than expected. > > Douglas Campos, aka qmx, father of dynjs presented some talks about that > specific feature and the problems that dynjs core team found. > > https://www.youtube.com/watch?v=bw-NBcFKNtc > > I hope that it can be useful in our discussion. > > Plínio > > > On Fri, Apr 4, 2014 at 9:49 AM, Robin Heggelund Hansen < > skinney...@gmail.com> wrote: > >> Great to hear, I'm looking forward to progress :) >> >> 4. apr. 2014 kl. 14:45 skrev Alex Miller : >> >> I agree that we cannot (yet) cut support for Java 6 but we continue to >> watch polls and usage closely. Java 6 has been EOL'ed for a while now and >> usage continues to drop. However, there are a few minor JDK-specific bits >> already in Clojure and it would be entirely possible to handle separate >> paths for 6 and 7. >> >> The major concern is with the stability and *predictability* of >> invokedynamic. indy has undergone major revisions between Java 7 and 8 so >> it may be that what needs to be done is substantially different between the >> two. My impression from watching the work of people like Charles Nutter is >> that it requires a lot of flag tweaking to make it work reliably. It also >> seems that when you go off the fast path, you can go over a cliff with >> performance. **These are my impressions - they could be wrong.** For these >> reasons, it has not been high on the priority list, but having more work or >> data on this would be great. I am not speaking for Rich here, but my guess >> is that this is compatible with his thoughts. >> >> One of my first efforts for 1.7 is going to be working out how to support >> multiple Clojure builds for different purposes (such as lean runtime, >> Android, whatever) - this is foundational work that can open up the >> possibility of specialized Clojure builds, such as an invokedynamic-aware >> version. >> >> Alex >> >> On Friday, April 4, 2014 5:09:16 AM UTC-5, Plinio Balduino wrote: >>> >>> The guys from core team will correct me if I say any bs, but I think >>> it's not possible to keep Clojure compatible with Java 6, as Clojure 1.6 >>> is, and use InvokeDynamic bytecode in the same binary. DynJS, for example, >>> is not compatible with Java 6. >>> >>> Anyway, it would be nice to see any experiment with that bytecode and >>> Clojure, maybe evolving to some form of Clojure 2.0. >>> >>> It would be nice to hear the core team and/or Hickey's position about >>> it. >>> >>> Regards >>> >>> Plinio Balduino >>> >>> On 04/04/2014, at 06:44, Robin Heggelund Hansen >>> wrote: >>> >>> Yeah, those were the blog posts I've read, but I can't see that this is >>> actually being worked on for Clojure? >>> >>> 4. apr. 2014 kl. 11:43 skrev Plínio Balduino : >>> >>> Hi, Hansen >>> >>> Fogus (from here) and Nutter (from JRuby) wrote nice posts about it. >>> >>> http://blog.fogus.me/2011/10/14/why-clojure-doesnt-need- >>> invokedynamic-but-it-might-be-nice/ >>> >>> http://blog.headius.com/2011/10/why-clojure-doesnt-need- >>> invokedynamic.html?m=1 >>> >>> Plinio Balduino >>> 11 982 611 487 >>> >>> On 04/04/2014, at 05:42, Robin Heggelund Hansen >>> wrote: >>> >>> Hi! >>> >>> Did someone ever look at supporting InvokeDynamic for Clojure? I've read >>> a couple of blogs and it seemed interesting, would be cool to know if there >>> actually were any advantages in practice. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> To unsubscribe from this group, send email to >>> clojure+u...@googlegroups.com >>> For more options, visit this group at >>> http://groups.google.com/group/clojure?hl=en >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to clojure+u...@googlegroups.com. >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Clojure" group. >>> To post to this group, send email to clo...@googlegroups.com >>> Note that posts from new members are moderate
Re: list all functions in namespace?
On Fri 4 Apr 2014 at 03:53:54PM -0800, Christopher Howard wrote:
> Is there some trick Clojure command to list all functions defined in a
> namespace?
I use these functions to create cheatsheets on the fly:
(defn fn-var? [v]
(let [f @v]
(or (contains? (meta v) :arglists)
(fn? f)
(instance? clojure.lang.MultiFn f
(defn cheat-sheet [ns]
(let [nsname (str ns)
vars (vals (ns-publics ns))
{funs true
defs false} (group-by fn-var? vars)
fmeta (map meta funs)
dmeta (map meta defs)
flen (apply max 0 (map (comp count str :name) fmeta))
dnames (map #(str nsname \/ (:name %)) dmeta)
fnames (map #(format (str "%s/%-" flen "s %s") nsname (:name %)
(string/join \space (:arglists %)))
fmeta)
lines (concat (sort dnames) (sort fnames))]
(str ";;; " nsname " {{{1\n\n"
(string/join \newline lines
which produces output like this:
user=> (println (cheat-sheet 'clojure.java.io))
;;; clojure.java.io {{{1
clojure.java.io/Coercions
clojure.java.io/IOFactory
clojure.java.io/default-streams-impl
clojure.java.io/as-file[x]
clojure.java.io/as-relative-path [x]
clojure.java.io/as-url [x]
clojure.java.io/copy [input output & opts]
clojure.java.io/delete-file[f & [silently]]
clojure.java.io/file [arg] [parent child] [parent child & more]
clojure.java.io/input-stream [x & opts]
clojure.java.io/make-input-stream [x opts]
clojure.java.io/make-output-stream [x opts]
clojure.java.io/make-parents [f & more]
clojure.java.io/make-reader[x opts]
clojure.java.io/make-writer[x opts]
clojure.java.io/output-stream [x & opts]
clojure.java.io/reader [x & opts]
clojure.java.io/resource [n] [n loader]
clojure.java.io/writer [x & opts]
Combine (cheat-sheet) with a regex filter on (all-ns), and presto, you
have instant, up-to-date Clojure references on command.
guns
pgpy9lPrkKL1Q.pgp
Description: PGP signature
Re: Online Gorilla REPL worksheet viewer
This may be a dumb question, but is there a way to set up something like this on my own server, without github ? Or is the code for the github viewer in the project itself ? These notebooks look great! I'm really impressed by the work you've been doing on this. -- 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: anyone in Santa Cruz?
I'm also in Santa Cruz, and interested. -- 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: list all functions in namespace?
(doc dir) - clojure.repl/dir ([nsname]) Macro Prints a sorted directory of public vars in a namespace On Friday, April 4, 2014 6:53:54 PM UTC-5, Christopher Howard wrote: > > Is there some trick Clojure command to list all functions defined in a > namespace? > -- 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.
