Re: Tiny fix for LispReader

In addition to what Andy said, this same behavior was recently implemented in tools.reader (the Clojure impel of lisp reader) http://dev.clojure.org/jira/browse/TRDR-36 Erik. -- i farta > Den 27. apr. 2016 kl. 07.13 skrev Andy Fingerhut : > > Frank: > > I am

Re: Tiny fix for LispReader

Frank: I am pretty sure that the intent is that strings like 077 are read as octal, and in Clojure 1.8.0 this is what happens, e.g. (read-string "077") evaluates to the integer 63 (decimal), not 77. Thus it is intentional that (read-string "08") and (read-string "09") throw exceptions. Andy On

Tiny fix for LispReader

I believe the following line should replace the current 1.8.0 jvm/clojure/lang/LispReader.java line 68: static Pattern intPat = Pattern.compile( "([-+]?)(?:(0)|(0*[1-9][0-9]*)|0[xX]([0-9A-Fa-f]+)|([0-7]{3})|([1-9][0-9]?)[rR]([0-9A-Za-z]+)|0[0-9]+)(N)?"); Without this

Callback fn in core.async/put!

The docs for put! say (put! port val) (put! port val fn0) (put! port val fn0 on-caller?) Asynchronously puts a val into port, calling fn0 (if supplied) when complete. nil values are not allowed. Will throw if closed. If on-caller? (default true) is true, and the put is immediately accepted,

Re: Porting Clojure to Native Platforms

Thanks for the detailed write up! I guess a carefully chosen subset of Clojure can make sense then, but definitely not all of Clojure. On Tue, Apr 26, 2016 at 5:45 PM, Timothy Baldridge wrote: > >> would you consider a Clojure port to Erlang VM a viable idea for >

Re: Porting Clojure to Native Platforms

LISP Flavoured Erlang: http://lfe.io/ On Tue, Apr 26, 2016 at 9:45 PM, Timothy Baldridge wrote: > >> would you consider a Clojure port to Erlang VM a viable idea for > production workloads? I know Elixir comes pretty close, but I still prefer > Lisp : ) . > > I looked into

Re: Porting Clojure to Native Platforms

>> would you consider a Clojure port to Erlang VM a viable idea for production workloads? I know Elixir comes pretty close, but I still prefer Lisp : ) . I looked into that at one point, but sadly the Erlang VM is a really poor platform for a Clojure port. Here are a few reasons why: Unit of

Re: Compile ClojureScript in Java application

On Tuesday, April 26, 2016 at 4:38:02 PM UTC-5, Martin Grześlowski wrote: > > I'm trying to compile String that contains Clojure Script code in > Java/Groovy. > > I'm not really happy with using *"java -jar ...".execute()*. > > > Is there any way to invoke clojurescript library (version 1.8.51)

Re: Porting Clojure to Native Platforms

Hi, J Based on my yet small experience: Can the Immutable Persistent Data Structures be implemented with a reference-counting scheme rather than a garbage collector? This may improve performance. - Yes, using Smart Pointers. I'm trying something like this, but I'm still in the very beginning. I

Re: Porting Clojure to Native Platforms

Of course, most people using Lua seriously use LuaJit, which is surprisingly fast. However it's very prone to the branching problems you described earlier for complex application code. I believe LuaJit does optimise hashmaps when they're used as arrays etc. LuaJit really shines when used for

Re: Lazy evaluation of arguments

Here is a nice discussion about fexprs: http://lambda-the-ultimate.org/node/3640 On Tuesday, 26 April 2016 23:04:09 UTC+2, tbc++ wrote: > > Congradulations! You've discovered Fexprs! An ancient technology from a > by-gone age: https://en.wikipedia.org/wiki/Fexpr > > On Tue, Apr 26, 2016 at

Re: Lazy evaluation of arguments

Wow ;-) now I know that I'm talking about fexprs ;-) So my propose is to back them alive again. Let the new community consume them in new manner and judge theirs usefulness. On Tuesday, 26 April 2016 23:04:09 UTC+2, tbc++ wrote: > > Congradulations! You've discovered Fexprs! An ancient

Re: Porting Clojure to Native Platforms

tbc++ - given your experience, would you consider a Clojure port to Erlang VM a viable idea for production workloads? I know Elixir comes pretty close, but I still prefer Lisp : ) . On Monday, April 25, 2016 at 1:50:45 PM UTC-7, tbc++ wrote: > > As someone who has spent a fair amount of time

Compile ClojureScript in Java application

I'm trying to compile String that contains Clojure Script code in Java/Groovy. I'm not really happy with using *"java -jar ...".execute()*. Is there any way to invoke clojurescript library (version 1.8.51) to compile code? -- You received this message because you are subscribed to the

Re: Porting Clojure to Native Platforms

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 25.04.2016 22:02, Jason Felice wrote: > 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

Re: Porting Clojure to Native Platforms

I wouldn't underestimate ClojureScript running on V8. That's another platform that's quite fast. And there are a lot of people trying very hard to make JS engines fast, could consider leveraging that. On Tue, Apr 26, 2016 at 3:09 PM, Raoul Duke wrote: > > Sorry, never heard of

Re: ANN: Eventually Consistent Datatypes 0.1.0

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26.04.2016 15:46, Ashish Negi wrote: > Nice.. I was going through the Readme.. but it looked complicated. > Can you write simple cases where this would be useful ? First of all, one should try the Clojure STM first ofc. It also allows to mark

Re: Porting Clojure to Native Platforms

> Sorry, never heard of horses for courses. Does it mean sth like different > strokes for different folks? yessir. -- 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

Re: Lazy evaluation of arguments

Congradulations! You've discovered Fexprs! An ancient technology from a by-gone age: https://en.wikipedia.org/wiki/Fexpr On Tue, Apr 26, 2016 at 2:23 PM, Olek wrote: > Yes, the delay and force does the job. Now it would be nice to hide delay > declaration in

Re: Porting Clojure to Native Platforms

On Apr 26, 2016 3:30 PM, "Raoul Duke" wrote: > > Horses for courses. Ask all the game people who use Lua big time. :-) > Sorry, never heard of horses for courses. Does it mean sth like different strokes for different folks? Re: big time users of Lua, I don't know any. I guess

Re: Porting Clojure to Native Platforms

> Ask all the game people who use Lua big time See that's the problem. When we say "horses for courses" we have to actually dig down into what we're saying there. The reason Lua is used in the gaming community is that it's quite fast, very very small, and simple for what it does. It also has

Re: Porting Clojure to Native Platforms

Horses for courses. Ask all the game people who use Lua big time. :-) -- 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

Re: Porting Clojure to Native Platforms

On Apr 26, 2016 12:19 AM, "Mars0i" wrote: > > 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

Re: Lazy evaluation of arguments

Yes, the delay and force does the job. Now it would be nice to hide delay declaration in arguments destruction as already proposed: (den mycrazyif [ statement ~onsuccess ~onfailure ] ; nonsuccess and on failure becomes delay objects (if statement ; just evalutated with mycrazyif call

Re: Lazy evaluation of arguments

I'm not sure I fully understand your proposal, but when I really need lazy evaluation (which is pretty rare) I reach for `delay` and `force`. On Tuesday, 26 April 2016 16:41:08 UTC+1, Olek wrote: > > Hi! > > In short: > > I have noticed that in most cases I use macros only for lazy arguments >

Re: Processing an array

Thanks to all of you for your interesting answers ! Olivier -- 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

Re: Porting Clojure to Native Platforms

RC & GC might complement. Don't throw out RC. Also, there are different kinds of 'performance'. Horses for courses, you know. https://www.google.com/search?q=bacon+gc+reference+counting+equation -- You received this message because you are subscribed to the Google Groups "Clojure" group. To

Lazy evaluation of arguments

Hi! In short: I have noticed that in most cases I use macros only for lazy arguments evaluation. Why not to make something to use only this feature? It would be light version of macro for clojurescript/clojure and easy to grasp for newcomers and still powerful in programming (with that you

[ANN] Specter 0.10.0 released

Happy to announce the release of Specter 0.10.0. If you're unfamiliar with Specter, it's a library that supercharges your ability to query and manipulate data structures and has performance rivaling hand-optimized code. The README and my talk at Clojure/west are the best introductions to the

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

I wrote packthread to avoid needing threading counterparts of a bunch of control forms - it rewrites threading through control forms. https://github.com/maitria/packthread It doesn't (yet) solve when you need the threaded value in the middle of a threading form. I've had some thoughts about

Re: Porting Clojure to Native Platforms

On Tuesday, April 26, 2016 at 12:23:48 AM UTC-5, Mars0i wrote: > > 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,

Re: ANN: Eventually Consistent Datatypes 0.1.0

Nice.. I was going through the Readme.. but it looked complicated. Can you write simple cases where this would be useful ? -- 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

Re: Porting Clojure to Native Platforms

My 2¢ on the subject, Ferret is not dead, I've been working on it for sometime now. Latest builds/docs are available at [1]. > Can the Immutable Persistent Data Structures be implemented with a reference-counting scheme rather than a garbage collector? This may improve performance. That is

Re: Porting Clojure to Native Platforms

A scala native port is due to be announced soon. It would be interesting to see whats their approach and performance characteristics are: http://www.scala-native.org/ Cheers, Aleksander On 26 April 2016 at 09:47, Mikera wrote: > I would definitely second Tim's

Re: Porting Clojure to Native Platforms

On Tuesday, April 26, 2016 at 5:53:42 AM UTC+2, puzzler wrote: > > 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

Re: Porting Clojure to Native Platforms

I would definitely second Tim's points. The JVM is very hard to beat once you factor in the GC and JIT requirements. Worth noting that persistent data structures with structural sharing are used pretty much ubiquitously in Clojure and that these are *exactly* the kinds of data structures that

Re: Porting Clojure to Native Platforms

This is true of a lot of those benchmarks, especially for functional languages. I haven't looked recently, but back in the day Haskell seemed very fast on the shootout game. However the code that actually runs that fast is very very far from idiomatic. Again, I haven't looked at the Clojure

Re: Porting Clojure to Native Platforms

The only conclusion I can draw from these benchmarks over the years is that the speed of Clojure is inversely proportional to it's idiomaticity On Tuesday, April 26, 2016 at 7:23:48 AM UTC+2, Mars0i wrote: > > On Tuesday, April 26, 2016 at 12:19:23 AM UTC-5, Mars0i wrote: >> >> I was going to

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

On 25 April 2016 at 21:03, Rafał Cieślak wrote: > 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). >