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).
>
> It has to make a co
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 say
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 version
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 b
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 get from
>> the JVM's
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 points. The JVM is very hard to b
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 what
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 fr
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, ym
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 thre
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 pr
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 cou
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 post
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
fir
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
> e
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
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 GC. In fact, I'd chall
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 with
> 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 a
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 performance isn't s
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 arguments destruction as already prop
> 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 new
-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 part
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 horses for courses
-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 on
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 Go
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 pla
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 technolo
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 2:2
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 someth
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
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) t
>> 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 comp
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 that at one point, but
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
> production workloads? I know El
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, wil
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 ch
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
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 pretty sure that the intent is t
39 matches
Mail list logo
