Re: Processing an array

Hey Olivier, You can shorten the body of your function with nil-punning and in lining next-time (rather than explicitly letting it), e.g: (if (empty? events) timed-events (let [current (first events) next-time (+ (:duration current) time)] (recur next-t

ANN: ClojureScript 1.8.51

ClojureScript, the Clojure compiler that emits JavaScript source code. README and source code: https://github.com/clojure/clojurescript Leiningen dependency information: [org.clojure/clojurescript "1.8.51"] This release updates the Closure Compiler and tools.reader dependencies, fixes a rac

Re: Unexpected nullpointer while processing a transient vector

Jesus. You have no idea how much did you help me! That's exactly where the bug was. Now I made it work, but I simply did not expect it to be so friggin slow. As you could see, I hardcoded the paramethers in the "boss" function, because all I wanted, for now, is to make it work correctly. I left

Re: Incanter 1.9 and Clojure 1.7

How do you get the latest commit on the develop branch? On Wed, Apr 20, 2016 at 11:46 AM, Bruce Durling wrote: > Myriam, > > Would you check with the latest commit on the develop branch please? > We're trying to get a new SNAPSHOT release out that might sort a > number of issues. > > If yours is

Porting Clojure to Native Platforms

I've been wondering lately about getting Clojure to compile to native code, and so I've been doing some looking around. There are a few projects that are on the right track, such as TinyClojure and Ferret

Re: Porting Clojure to Native Platforms

Not knowing the problem you’re specifically trying to solve, would using using the GNU java compiler work to take byte code to native? On April 25, 2016 at 12:47:37 PM, JvJ (kfjwhee...@gmail.com) wrote: I've been wondering lately about getting Clojure to compile to native code, and so I've b

Re: Porting Clojure to Native Platforms

There was talk of an LLVM backend a while back, but I believe LLVM was deemed too low-level to be useful. That was, in fact, why I signed the contributor agreement. So, I'd love to see some movement on a C back-end. Gambit Scheme has a special form that emits C (or C++) code. It's very useful.

ANN: Eventually Consistent Datatypes 0.1.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hey, I was at EuroSys last week and was fascinated by a paper about in-memory eventually consistent datatypes for massive parallism, so I took a shot at them. - From the README: This is an implementation of highly-scalable eventually consistent data

Macro usage within Clojure community and naming functions which perform actions under certain conditions

Hi, I'm writing a turn-based game and one of the biggest functions is the one which handles player moves. It receives the current game state (a map) and the index of the cell that the player clicked on (an integer). It has to make a couple of decisions based on the game state. So far I just us

Re: Porting Clojure to Native Platforms

I wasn't trying to solve any particular problem. I was just wondering about the possibility of it. The main motivation would be performance gains. On Monday, 25 April 2016 12:55:20 UTC-7, Dan Girellini wrote: > > Not knowing the problem you’re specifically trying to solve, would using > using

Re: Porting Clojure to Native Platforms

things like robovm are another possible approach. -- 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. T

Re: Porting Clojure to Native Platforms

> The main motivation would be performance gains. blah? so many impedance mismatches and layers of indirection that i don't think it will gain much? i mean, it would probably be better to spend time tuning gc parameters or something. just a rant / guess. e.g. robovm is for some use cases perfectly

Re: Porting Clojure to Native Platforms

As someone who has spent a fair amount of time playing around with such things, I'd have to say people vastly misjudge the raw speed you get from the JVM's JIT and GC. In fact, I'd challenge someone to come up with a general use, dynamic language that is not based on the JVM and comes even close to

Re: Porting Clojure to Native Platforms

Hi Tim, > On Apr 25, 2016, at 3:50 PM, Timothy Baldridge wrote: > > A LLVM/C++/RPython based version of Clojure would on a good day come in at > about 1/10 the speed of Clojure on the JVM for general use cases. Whoa! The RPython one is particularly interesting; are those the figures you saw

Re: Porting Clojure to Native Platforms

I wrote Pixie and did a fair amount of benchmarking on it. As it stands tracing JITs work well on tight loops. That means in a perfect world you would only have one hot trace through a given set of functions. That's actually harder to pull off than it sounds. Take for instance the PersistentHashMa

Re: Porting Clojure to Native Platforms

Interesting point about the performance of JIT and GC on JVM. I didn't realize that they could be so highly performant. Also, I had thought "Metal Clojure" would have been a good name for this project, but you went ahead and stole it before I even thought of it! On Monday, 25 April 2016 14:49:

Re: Porting Clojure to Native Platforms

On Apr 25, 2016 3:50 PM, "Timothy Baldridge" wrote: > > As someone who has spent a fair amount of time playing around with such things, I'd have to say people vastly misjudge the raw speed you get from the JVM's JIT and GC. In fact, I'd challenge someone to come up with a general use, dynamic lang

Benchmarking in Clojurescript -- Necessary or not?

I've been implementing custom persistent map and its transient counterpart *(currently incomplete, but it won't be for long).* I would like to test how they perform compared to the default PersistentMap and TransientMap im

Re: Porting Clojure to Native Platforms

Not JVM based but I've been wondering about ClojureCLR on top of the new CoreCLR might be a potential path for native. There's a native compiler in the works (a brief mention a couple weeks ago in the standup https://youtu.be/cfxuJsZIK4A?t=1h13m32s). I have to say with the MIT license, tail ca

Re: Benchmarking in Clojurescript -- Necessary or not?

On Monday, April 25, 2016 at 6:45:13 PM UTC-5, JvJ wrote: > > What I want to know is this: Will the JVM benchmarking numbers reflect > how the JS implementation performs? > No -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group

Re: Benchmarking in Clojurescript -- Necessary or not?

Even in terms of ratios between different operations? On Monday, 25 April 2016 19:05:41 UTC-7, Francis Avila wrote: > > > > On Monday, April 25, 2016 at 6:45:13 PM UTC-5, JvJ wrote: >> >> What I want to know is this: Will the JVM benchmarking numbers reflect >> how the JS implementation performs

Re: Porting Clojure to Native Platforms

On Mon, Apr 25, 2016 at 1:50 PM, Timothy Baldridge wrote: > As someone who has spent a fair amount of time playing around with such > things, I'd have to say people vastly misjudge the raw speed you get from > the JVM's JIT and GC. In fact, I'd challenge someone to come up with a > general use, d

Re: Porting Clojure to Native Platforms

I have no first-hand experience with it, but isn't Excelsior JET what you're looking for? They claim to provide AOT compilation to native binaries. > > > I've been wondering lately about getting Clojure to compile to native > code, and so I've been doing some loo

Re: Porting Clojure to Native Platforms

On Monday, April 25, 2016 at 3:50:45 PM UTC-5, tbc++ wrote: > > As someone who has spent a fair amount of time playing around with such > things, I'd have to say people vastly misjudge the raw speed you get from > the JVM's JIT and GC. In fact, I'd challenge someone to come up with a > general u

Re: Porting Clojure to Native Platforms

On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote: > > I was going to say that I'd be surprised if Clojure were as fast as SBCL > (overall, on average, depends on your application, depends on how you code > it, ymmv, etc. ...). Then I stopped back to check the little benchmarks on >