Re: Clojure, Java 9, and you

Nothing? On Monday, June 5, 2017 at 6:24:46 PM UTC-5, Matching Socks wrote: > > Reading between the tea leaves, what does the delay in Java 9 (in > connection with modularity) portend for Clojure? > > > http://www.infoworld.com/article/3198912/java/java-9-delayed-due-to-modularity-controversy.htm

Re: Clojure, Java 9, and you

Reading between the tea leaves, what does the delay in Java 9 (in connection with modularity) portend for Clojure? http://www.infoworld.com/article/3198912/java/java-9-delayed-due-to-modularity-controversy.html -- You received this message because you are subscribed to the Google Groups "Clojur

Re: Clojure <-> Java

2014-11-08 3:32 GMT+01:00 Blake McBride : > Greetings, > Hi, I am an old lisp guy that is new to Clojure. > Welcome! Lisp can't do that without a real lot of work (make generic functions > evaluate the arguments and then execute the applicable method). > This is exactly what Clojure does, via

Re: Clojure <-> Java

Hi Blake, Also, I presume that a Closure program has immediate access to all Java > classes and methods without any work. Is that true? Clojure embraces the JVM by providing a number of interoperability features that allow you to do alm

Re: Clojure <-> Java

Hey Blake, Yeah, Clojure sits atop the JVM and has access to all its core classes. So just fire up a repl and evaluate "*java.io.File/pathSeparator*" or "*(java.lang.Math/abs -37)*" or something. You can get those Java Interop details here. As for the Clojure / J

Re: Clojure + Java Interop + Gnome Interop -- KeyPressEvent fails

On 12/03/2011 10:16 AM, Henrik Lundahl wrote: Hi Rett There is no such type as org.gnome.gtk.Window$__KeyPressEvents, at least not in 4.1 of the Java Gnome API . org.gnome.gtk.Window$__KeyPressEvent exists though. I'd gue

Re: Clojure + Java Interop + Gnome Interop -- KeyPressEvent fails

Hi Rett There is no such type as org.gnome.gtk.Window$**KeyPressEvents, at least not in 4.1 of the Java Gnome API . org.gnome.gtk.Window$**KeyPressEvent exists though. I'd guess you have a typo somewhere, perhaps in the impo

Re: Clojure, Java JIT, and inlining

> I don't think Vars are thread-local. They're one of the shared > mutable state primitives. They can be defacto thread local if only > used by a single thread but you need a "sufficiently smart compiler" > to notice that. "Vars provide a mechanism to refer to a mutable storage location that

Re: Clojure, Java JIT, and inlining

It is my experience also, that inlining gives the greatest performance gain for functions that expect primitive arguments. As Chouser said, doing this eliminates the boxing/unboxing overhead. Here's my take on this: The Java method signatures created by Clojure will always be Objects in order to

Re: Clojure, Java JIT, and inlining

On Wed, Aug 12, 2009 at 3:03 PM, Andy Fingerhut wrote: > > My apologies for the noise if this is well known in the Clojure > community, but I'll ask anyway. > > One of the tweaks to my Clojure benchmarks that people have suggested > for improving performance, and that does help, is changing some >

Re: Clojure, Java JIT, and inlining

On Wed, Aug 12, 2009 at 4:24 PM, Richard Newman wrote: > >> I may be wrong, but doesn't a typical function invocation involve >> dereferencing the Var holding the object that implements "IFn" and >> calling invoke?  It seems pretty intuitive to me that this would be >> difficult to inline by the J

Re: Clojure, Java JIT, and inlining

> I may be wrong, but doesn't a typical function invocation involve > dereferencing the Var holding the object that implements "IFn" and > calling invoke? It seems pretty intuitive to me that this would be > difficult to inline by the JIT, there is a little bit of > synchronization going on every

Re: Clojure, Java JIT, and inlining

On Aug 12, 2009, at 3:59 PM, Richard Newman wrote: >> Is there some reason that the Java JIT is not doing this, with the >> original code using defn, as fast as it works when using defmacro? > > The macro expands into bytecode within the same Java method, rather > than a method invocation. Some m

Re: Clojure, Java JIT, and inlining

On Wed, Aug 12, 2009 at 3:59 PM, Richard Newman wrote: > >> Is there some reason that the Java JIT is not doing this, with the >> original code using defn, as fast as it works when using defmacro? > > The macro expands into bytecode within the same Java method, rather > than a method invocation. S

Re: Clojure, Java JIT, and inlining

> Is there some reason that the Java JIT is not doing this, with the > original code using defn, as fast as it works when using defmacro? The macro expands into bytecode within the same Java method, rather than a method invocation. Some method blocks are too big to inline, and perhaps the JIT

Re: Clojure + Java compilation and IntelliJ IDEA plugin

On Thu, Mar 26, 2009 at 6:33 AM, AlamedaMike wrote: > >>> It's very good question, and to be honest I don't know exact question for > it. I may imagine both cases from Clojure to Java and vise versa. > Making > first variant default I was followed by one letter I had received. It > was > about so

Re: Clojure + Java compilation and IntelliJ IDEA plugin

>> It's very good question, and to be honest I don't know exact question for it. I may imagine both cases from Clojure to Java and vise versa. Making first variant default I was followed by one letter I had received. It was about some project written in IDEA, where Clojure is used for core funcati

Re: Clojure + Java compilation and IntelliJ IDEA plugin

Hi, Stuart. I would like to be able to demo the sample code from the book in IDEA That's great, I'm really happy to hear it. As for all three issues you've mentioned, all of them have same origin and related to so-called evaluator API. What you can see now using debugger is nothing but vanilla

Re: Clojure + Java compilation and IntelliJ IDEA plugin

Hello, Christian Could you explain the reasoning behind compiling the Clojure code > before the Java code? It's very good question, and to be honest I don't know exact question for it. I may imagine both cases from Clojure to Java and vise versa. Making first variant default I was followed by on

Re: Clojure + Java compilation and IntelliJ IDEA plugin

Hello, Mark. The easiest way to updae plugin from within the idea is to use plugin manager (see File -> Settings -> Plugins), find Clojure plugin in the list, right-click on it and hit "update". AFAIK, you also must see kind of blinking gear in the bottom right corener of IDEA main screen, which a

Re: Clojure + Java compilation and IntelliJ IDEA plugin

If we've already downloaded the first plugin, what's the best way to upgrade? Do you have to delete the first one, or just install the second on top? Is there a way to update the plugin from within the IDE? Thanks. --~--~-~--~~~---~--~~ You received this message

Re: Clojure + Java compilation and IntelliJ IDEA plugin

Hi Ilya, I would like to be able to demo the sample code from the book in IDEA. Here are a few things I am seeing so far: (1) When I set a breakpoint, I get a warning icon that says "no executable code found at..." but the breakpoint does in fact seem to work. (2) The variable window corr

Re: Clojure + Java compilation and IntelliJ IDEA plugin

Sounds great :) On Wed, Mar 25, 2009 at 4:42 PM, Ilya Sergey wrote: > Hello, all. > > I've just uploaded new version of La Clojure plugin for IntelliJ IDEA. Among > several bugfixes and minor changes I have to note several essential moments. > > 1. Now Clojure support is added as so-called `face