Re: Processing an array

[Derek Troy-West]

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-time (conj timed-events (assoc current :time time)) 
(rest events)))

 To:

(if-let [current (first remaining)]
  (recur (conj (+ (:duration current) time) timed-events (assoc current 
:time time)) (rest events))
  timed-events)

As a style thing, you might choose to be explicit about the loop/recur, 
rather than having a multi-arity fn, e.g

(defn to-timed-events
  [events]
  (loop [result[]
remaining events
time  0]
(if-let [current (first remaining)]
  (recur (conj result (assoc current :time time)) (rest remaining) (+ 
(:duration current) time))
  result)))

 Derek


On Sunday, April 24, 2016 at 8:01:14 PM UTC+10, Olivier Scalbert wrote:
>
> Hi all,
>
> I am a Clojure beginner 
> And I have an advice to ask !
>
> I have an array of events:
>
> (def events [
>   {:id "1" :duration 100}
>   {:id "2" :duration 200}
>   {:id "3" :duration 300}
> ])
>
> I wanted to transform this array into:
> [
>   {:id 1, :duration 100, :time 0} ; event 1 starts at 0
>   {:id 2, :duration 200, :time 100} ; event 2 starts when event 1 is 
> finished, so at 100
>   {:id 3, :duration 300, :time 300} ; event 3 starts when event 2 is 
> finished, so at 100 + 200
> ]
>
> Here is the function code:
>
> (defn to-timed-events
> ([time events] (to-timed-events time [] events))
> ([time timed-events events]
> (if (empty? events)
> timed-events
> (let [current (first events)
>   next-time (+ (:duration current) time)]
> (recur next-time (conj timed-events (assoc current :time 
> time)) (rest events))
> 
>
> It seems to work, but it looks a bit long for what it is doing. Is it 
> possible to improve it ?
>
> Thanks for your help,
>
> 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 
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.

ANN: ClojureScript 1.8.51

[David Nolen]

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 race condition with :parallel-build, improves JS module
integration, and includes a number of enhancements and fixes around
optional self hosting. A big thanks to everyone who contributed!

As always feedback welcome.

## 1.8.51

### Changes
* bump Closure Compiler to v20160315
* bump tools.reader to 1.0.0-beta1
* CLJS-1624: Avoid useage of JSC_HOME in test bash scripts

### Enhancements
* CLJS-1626: cljs.test for bootstrap

### Fixes
* CLJS-1588: defrecord satisfies? behavior under bootstrap
* CLJS-1632: docs / arglist consistency
* CLJS-1612: Resolve ns aliases in syntax-quote
* CLJS-1621: Foreign libs modules of different types don't compile together
* CLJS-1617: inlined `list` evaluation order
* :parallel-build race condition

-- 
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: Unexpected nullpointer while processing a transient vector

[Vandr0iy]

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 it running for half a hour circa, and I obtained, like ~330 
different board configurations and still counting, since there were, like, 
other ~400 still to be processed.
I simply did not believe that I'd spend THAT much of time to calculate a 
tree where the absolute maximum of times I would have to launch a worker 
would be about 16!/9! .
Now, I reduced the board to a 3x3 one with only 3 chess pieces. It's absurd 
that it has to take this much.
And my assignment was to calculate the whole tree of possibilities given a 
7x7 board with 7 chesspieces...

Since I believe that I'm doing something wrong, is there some jvm profiling 
instrument that's compatible with clojure code? Maybe I'm parrallelizing in 
a wrong way...

On Monday, April 25, 2016 at 4:44:10 AM UTC+2, James Reeves wrote:
>
> It's hard to tell for sure from your code sample, because you don't 
> include "place" or "get-free-squares", but it's possible your error is in 
> the reducing function here:
>
> (reduce #(when (not (keyword? %2))
>(conj! %1
>   (if nxt
> {:board %2 :pawns (update pwns nxt dec)}
> brd)))
> (transient [])
> (map #(place nxt (first %) (last %) brd)
>  (get-free-squares brd)))
>
> In your reducing function, if %2 is not a keyword, then you return nil. 
> This means that the next %1 will be nil, and you'll end up with a null 
> pointer exception.
>
> I wonder if you meant instead to write:
>
> (reduce #(if (not (keyword? %2))
>(conj! %1
>   (if nxt
> {:board %2 :pawns (update pwns nxt dec)}
> brd))
>%1)
> (transient [])
> (map #(place nxt (first %) (last %) brd)
>  (get-free-squares brd)))
>
> - James
>
>
> On 25 April 2016 at 01:26, Vandr0iy > 
> wrote:
>
>> Hi, Clojurists!
>>
>> I'm writing some clojure in these days, and I stumbled upon an error that 
>> I'm unable to easily understand.
>> My goal is to asynchronously process a 2D vector in order to solve a 
>> parametric version of the 8 chess queens problem (where the parameters are: 
>> the board's dimensions and the chess pieces to be put on the board).
>> My solution mainly consists in two functions: the worker and the boss. 
>> The worker takes in input a board (2d array) and yields a collection of 
>> boards that contain another chess piece placed in a certain way. This means 
>> that I:
>> > take all of the free squares from the board
>> > try to place the chesspiece on every one of them
>> > if I succeed (do not hit other pieces) - it goes to the output.
>>
>> Until I use the version without the transients - it appears to be 
>> working. 
>> But I wanted to optimize my code, because the last time I solved it using 
>> recursive pmap - when I gave it an output that's a bit larger - it went 
>> into a bats**t crazy heap overflow. So I tried to use a transient 
>> collection.
>> And here my problems began. When I try to execute this code it dies after 
>> just a couple of moves processed, giving me a nullpointer on the row where 
>> conj! is situated:
>>
>> NullPointerException   clojure.core/conj! (core.clj:3257)
>>
>> What a hellish issue may it be? Clojure is not helping - its error 
>> messages are always cryptic, and really hard to understand.
>>
>> Here is my code. It's not complete though - some functions are omitted, 
>> for the sake of brevity. Please, help me to understand what am I missing 
>> here...
>>
>> Thank you.
>> (def fw (agent {}))
>>
>> (defn worker [subj]
>>   (let [{brd :board pwns :pawns} subj
>> nxt (get-next-pawn pwns)]
>> (when (map? subj)
>>   (when (and brd pwns)
>>  (into #{}
>>(persistent!
>> (reduce #(when (not (keyword? %2))
>>(conj! %1
>>   (if nxt
>> {:board %2 :pawns (update pwns nxt 
>> dec)}
>> brd)))
>> (transient [])
>> (map #(place nxt (first %) (last %) brd)
>>  (get-free-squares brd)
>> (defn boss []
>>
>>   (send fw
>> #(into {} %2)
>> {:complete 0
>>  :coll
>>  #{{:board (blank-board 4 4)
>> :pawns
>> {:rook 1
>>  :knight 3
>>  :bishop 2
>>  )
>>  (loop []
>>(await fw)
>>@fw
>>(let [{done :complete col :coll} @fw]
>>  (if (= done (count col))
>>col
>> 

Re: Incanter 1.9 and Clojure 1.7

[myriam abramson]

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 isn't sorted then I might look at it as we use PCA a fair bit too.
>
> Do you have a small example of some code that is failing?
>
> cheers,
> Bruce
>
> On Wed, Apr 20, 2016 at 3:19 PM, myriam abramson 
> wrote:
> > I am getting the following error with Incanter 1.9 running the PCA
> example
> > from the documentation:
> >
> > CompilerException java.lang.ClassCastException: java.lang.Boolean cannot
> be
> > cast to java.lang.Number, compiling:(pca.clj:17:10)
> >
> > That works fine with Clojure 1.6. (and yes, I know that the latest is
> 1.8).
> >
> > What to do?
> >
> >
> > --
> > 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.

Porting Clojure to Native Platforms

[JvJ]

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 
, 
but they are incomplete and don't seem to be under active development any 
more.

I'm wondering about the requirements, how much work it would take, and 
whether or not it would be worth it.  My current thinking is of a 
Clojure->C/C++ compiler.

So far, I have a few topics for discussion that I'm unclear about that 
might be necessary for this kind of project:

   - Can the Immutable Persistent Data Structures be implemented with a 
   reference-counting scheme rather than a garbage collector?  This may 
   improve performance.
   - In a similar vein, can the allocation strategy be controlled for these 
   structures in such a way as to optimize cache locality?
   - Can we take advantage of tail-call optimization in existing C++ 
   compilers?
   - It wouldn't have to depend on an existing runtime environment like JVM 
   or JavaScript.
  - Could this reduce reliance on reflection and increase performance?
  - Could a new, clojure-optimized runtime be created that improves 
  performance?
   - Could certain anonymous functions be optimized or inlined in a way 
   that improves performance over JVM/JS implementations?
   - Is there a way to compile C++ code at runtime?  This would be 
   essential for the REPL and for Macros.


Let me know if anyone has any thoughts on the matter.

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: Porting Clojure to Native Platforms

[Dan Girellini]

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 been doing some looking around.

There are a few projects that are on the right track, such as TinyClojure and 
Ferret, but they are incomplete and don't seem to be under active development 
any more.

I'm wondering about the requirements, how much work it would take, and whether 
or not it would be worth it.  My current thinking is of a Clojure->C/C++ 
compiler.

So far, I have a few topics for discussion that I'm unclear about that might be 
necessary for this kind of project:
Can the Immutable Persistent Data Structures be implemented with a 
reference-counting scheme rather than a garbage collector?  This may improve 
performance.
In a similar vein, can the allocation strategy be controlled for these 
structures in such a way as to optimize cache locality?
Can we take advantage of tail-call optimization in existing C++ compilers?
It wouldn't have to depend on an existing runtime environment like JVM or 
JavaScript.
Could this reduce reliance on reflection and increase performance?
Could a new, clojure-optimized runtime be created that improves performance?
Could certain anonymous functions be optimized or inlined in a way that 
improves performance over JVM/JS implementations?
Is there a way to compile C++ code at runtime?  This would be essential for the 
REPL and for Macros.

Let me know if anyone has any thoughts on the matter.

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.

Re: Porting Clojure to Native Platforms

[Jason Felice]

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.  I can't remember which Lisp it was, but there was definitely a
lisp which had an emit-C as it's *only* special form.  It might have been
one of the embedded schemes.

Last time I looked, I also saw ClojureC:  It looked useful, but hasn't been
touched in 3 years.
https://github.com/schani/clojurec

And here's a clojure-to-scheme compiler that used Gambit to target native:
https://github.com/takeoutweight/clojure-scheme
(In fact, this might be what I was thinking about with the special form
above.)

IMHO, native is useful for embedded systems and command-line programs
(where JVM start-up time can make a comand simply unusable).


On Mon, Apr 25, 2016 at 3:47 PM, JvJ  wrote:

>
>
> 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
> ,
> but they are incomplete and don't seem to be under active development any
> more.
>
> I'm wondering about the requirements, how much work it would take, and
> whether or not it would be worth it.  My current thinking is of a
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a
>reference-counting scheme rather than a garbage collector?  This may
>improve performance.
>- In a similar vein, can the allocation strategy be controlled for
>these structures in such a way as to optimize cache locality?
>- Can we take advantage of tail-call optimization in existing C++
>compilers?
>- It wouldn't have to depend on an existing runtime environment like
>JVM or JavaScript.
>   - Could this reduce reliance on reflection and increase performance?
>   - Could a new, clojure-optimized runtime be created that improves
>   performance?
>- Could certain anonymous functions be optimized or inlined in a way
>that improves performance over JVM/JS implementations?
>- Is there a way to compile C++ code at runtime?  This would be
>essential for the REPL and for Macros.
>
>
> Let me know if anyone has any thoughts on the matter.
>
> 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.

ANN: Eventually Consistent Datatypes 0.1.0

[Christian Weilbach]

-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
datatypes for Clojure. When you do massively parallel updates on STM,
the abort rate can become prohibitive and you don't want to wait until
your transactions succeed. One example is the counter from the paper,
where each thread increments the counter in some inner loop. And you
asynchronously merge the thread-local var from time to time with the
global state.

While I haven't had a use case for them yet, I found the research
interesting and wanted to benchmark the approach against the Clojure
STM. Consider the implementation experimental for now. I think the
datatypes become interesting in many-core scenarios where you have
more than 10 (maybe 100+) threads hammering on a datastructure. Since
massive parallelism is a primary design goal of Clojure, I think they
are worth investigating then.

https://github.com/whilo/ecdts

I would be interested if people have thought in this direction already.

Christian
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXHnm3AAoJEICbLivqiPOFt2UP/3Yoi6dqJDzrpjo8l4/5DN8T
3y0njkUvKTIYI/ZrglE7Ow/IhWFO4VmOq5A+0BMJypqIlS9YGBX1qmaK9jxKg8SP
/6JTkz6J/aH2tzZc8pJnTi+tzGc39ERkreXiHxpqSRr5qtH60z/sN1N+1q4PRPGU
Dnn/52ABARlWTz4sdQOturFDToRt73THeFDFFtu6Bf1lnSjA0PzHqllAbkOYJDA6
lrbigieMemgu0fzJGMb/oIYcup2R1vuv8now9MaMsD8SWJCNwcosHI7r983nMeWY
Gwhy9qxslitoghVH+l1G878G4hNwU3mKL+68spG5QRwhILLR5IVKGpoq7EdOLp4/
h8gOIDR44Oj2iz8juSjV/4yKUFzgELG/jNLN8yjdKHOzvGiK/LITHa/HoZeMG2BL
rq/KAbuvF4BTzfZM5etxZTwXYvF9kP7dcjVUpgc+Az6Xovf546V90O1rYZ/GTeIU
MA4v8HRA3a1dpkt6olBGiLvbhvzB+KvT4NBIa0HSTdTDKgNhHRd8HhGZnHod0qCp
9hPfSxdiisyLYffvjkeCqhgNpOW8qpxzlud6PO47L+xX6bmpZ8rfqLXFtveUB3/7
7w591LEf3EZyYut0tkpvXKtsfR4ZwcckftdpHPsUyOVpalz5we3KzvX+K/kXuPFw
ek57mvP6ofrJasByt/Bi
=4B8Q
-END PGP SIGNATURE-

-- 
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.

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

[Rafał Cieślak]

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 
used -> and cond->. The code looks more or less like this, I removed a 
bunch of function calls for brevity.

(-> game-state
; This stuff happens on each move.
(reveal-cell cell-index)
; And this stuff happens only under certain conditions.
(cond->
  (zero? (:surrounding-power cell))
  (reveal-safe-cells cell-index)))

The code looks clear IMHO. But then I wanted to add another feature which 
requires me to make decisions based on the updated value of game-state (the 
one that is being threaded inside cond->).

I thought about cond-> a bit and came to the conclusion that the reason you 
can't access the currently threaded value is to keep you from writing 
order-dependent statements. But in my case, I sometimes do want to write 
order-dependent code. For example, I want to give player exp for killing a 
monster and then if the exp is above certain threshold, I want to level up 
his character.

So the problem is that I have to check the current value being threaded, 
but cond-> doesn't allow me to do that.

As I understand, I can solve it in two different ways. For both of them I 
have a couple of questions as I'm fairly new to Clojure.

1. Use a custom macro like condas-> 
 which let's you access the 
current value. In fact, there have been several threads about such macros 
on this group (example 
).

My problem with this solution is that I'm going to depend in my code on a 
new macro. If somebody else looks at this code, they'll first have to 
understand condas-> and perhaps the reason it was brought to the project. I 
think that a brand new macro for such a simple problem is a bit too much. *Is 
it usual within the Clojure community to resort to custom macros so early?*

2. Remove cond-> and use functions which check a predicate on game-state: 
if it's false, the function returns the current game-state, if it's true 
the function updates the game state.

The main body will look like this:

(-> game-state
(reveal-cell cell-index)
(reveal-safe-cells cell-index))

Here I have two problems:

a) All predicate-checking functions in the main body will have to be 
rewritten to the following form:

(if pred
  (update-state game-state)
  game-state)

That's the best case scenario, because I guess some of the more complicated 
functions may look like this:

(if-let [foo (:bar game-state)]
  (if (and
(baz? foo)
(fizz? foo))
(update-state game-state foo)
game-state)
  game-state)

Now this is not a dealbreaker. I can certainly cope with that. *Maybe there 
are better ways to express that? *I don't know. But, the second problem is 
a bit more complex for me.

b) The functions will have to be renamed.

Let's look at reveal-safe-cells. The function does what the name says. The (
zero? (:surrounding-power cell)) predicate could be put into a function 
called safe-cell?. Now I would really like to have two separate functions – 
one that checks if it's okay to do the thing and one that does the thing. *How 
do I call the function which combines the two?*

If you look at the main body, by removing cond-> I just hid the fact that 
certain actions will be performed only under certain conditions. 
reveal-safe-cells needs to combine the action and the predicate, so it'd be 
good if its name revealed the intention.

That's it. Since I'm still learning Clojure, I'd like to get some feedback 
on what things are okay or not for other Clojure developers. I'm looking 
forward to the "Elements of Clojure" release, as it already answered many 
of my questions.

-- 
Cheers,
Rafał

-- 
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: Porting Clojure to Native Platforms

[JvJ]

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 the GNU java compiler work to take byte code to native?
>
>
> On April 25, 2016 at 12:47:37 PM, JvJ (kfjwh...@gmail.com ) 
> wrote:
>
>
>
> 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 
> , 
> but they are incomplete and don't seem to be under active development any 
> more.
>
> I'm wondering about the requirements, how much work it would take, and 
> whether or not it would be worth it.  My current thinking is of a 
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that 
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a 
>reference-counting scheme rather than a garbage collector?  This may 
>improve performance. 
>- In a similar vein, can the allocation strategy be controlled for 
>these structures in such a way as to optimize cache locality? 
>- Can we take advantage of tail-call optimization in existing C++ 
>compilers? 
>- It wouldn't have to depend on an existing runtime environment like 
>JVM or JavaScript. 
>- 
>   - Could this reduce reliance on reflection and increase performance? 
>   - Could a new, clojure-optimized runtime be created that improves 
>   performance? 
>- Could certain anonymous functions be optimized or inlined in a way 
>that improves performance over JVM/JS implementations? 
>- Is there a way to compile C++ code at runtime?  This would be 
>essential for the REPL and for Macros. 
>
>
> Let me know if anyone has any thoughts on the matter.
>
> Thanks
> --
> 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 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: Porting Clojure to Native Platforms

[Raoul Duke]

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.
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: Porting Clojure to Native Platforms

[Raoul Duke]

> 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 fine performance wise
believe it or not.

-- 
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: Porting Clojure to Native Platforms

[Timothy Baldridge]

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 the speed of Clojure.

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.


On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:

> > 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 fine performance wise
> believe it or not.
>
> --
> 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: Porting Clojure to Native Platforms

[lvh]

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 out of your efforts in porting Clojure to PyPy? Did you ever get a chance 
to interact with the PyPy folks when you saw such (IMHO) pathological 
performance figures? (No blame; a genuine question!)


lvh

> 
> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  > wrote:
> > 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 fine performance wise
> believe it or not.
> 
> --
> 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: Porting Clojure to Native Platforms

[Timothy Baldridge]

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 PersistentHashMap. If you dig into that
implementation you'll see dozens of if statements that are hit in different
conditions. If you're adding a new branch, adding a new leaf, copying nodes
of different types (there are three node types). So simply adding to a
hashmap requires dozens of conditional branches and the result of those
branches changes every time you add a new item.

So what I ended up doing for Pixie is disabling the JIT when digging into
the hashmap implementations. The PHM was implemented in RPython directly
and the JIT wouldn't try to optimize it. However, sometimes the JIT calls
back into user code (equals comparisons, and hashcode calculations), so
then you have to re-enable the JIT in a place where there isn't much of a
loop context.

There's many other locations like that. You may think you have a simple
loop, but then somewhere deep in your code you have a call to update-in,
which creates a lazy seq for the path, then iterates on that while digging
into several hashmaps and boom, the JIT just bails out.


The more I read up on it though, the more I see examples of tracing JITs
working poorly for "application code". That is, normal code you'd run in a
webserver. That sort of stuff just has so many if statements that the JIT
almost always optimizes the wrong thing.

On Mon, Apr 25, 2016 at 3:12 PM, lvh <_...@lvh.io> wrote:

> 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 out of your efforts in porting Clojure to PyPy? Did you ever get a
> chance to interact with the PyPy folks when you saw such (IMHO)
> pathological performance figures? (No blame; a genuine question!)
>
>
> lvh
>
>
> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke  wrote:
>
>> > 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 fine performance wise
>> believe it or not.
>>
>> --
>> 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 

Re: Porting Clojure to Native Platforms

[JvJ]

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:25 UTC-7, tbc++ wrote:
>
> 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 PersistentHashMap. If you dig into that 
> implementation you'll see dozens of if statements that are hit in different 
> conditions. If you're adding a new branch, adding a new leaf, copying nodes 
> of different types (there are three node types). So simply adding to a 
> hashmap requires dozens of conditional branches and the result of those 
> branches changes every time you add a new item. 
>
> So what I ended up doing for Pixie is disabling the JIT when digging into 
> the hashmap implementations. The PHM was implemented in RPython directly 
> and the JIT wouldn't try to optimize it. However, sometimes the JIT calls 
> back into user code (equals comparisons, and hashcode calculations), so 
> then you have to re-enable the JIT in a place where there isn't much of a 
> loop context. 
>
> There's many other locations like that. You may think you have a simple 
> loop, but then somewhere deep in your code you have a call to update-in, 
> which creates a lazy seq for the path, then iterates on that while digging 
> into several hashmaps and boom, the JIT just bails out. 
>
>
> The more I read up on it though, the more I see examples of tracing JITs 
> working poorly for "application code". That is, normal code you'd run in a 
> webserver. That sort of stuff just has so many if statements that the JIT 
> almost always optimizes the wrong thing.
>
> On Mon, Apr 25, 2016 at 3:12 PM, lvh <_...@lvh.io > wrote:
>
>> 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 out of your efforts in porting Clojure to PyPy? Did you ever get a 
>> chance to interact with the PyPy folks when you saw such (IMHO) 
>> pathological performance figures? (No blame; a genuine question!)
>>
>>
>> lvh
>>
>>
>> On Mon, Apr 25, 2016 at 2:18 PM, Raoul Duke > > wrote:
>>
>>> > 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 fine performance wise
>>> believe it or not.
>>>
>>> --
>>> 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.
>>>
>>
>>
>>
>> -- 
>> “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 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 un

Re: Porting Clojure to Native Platforms

[Gregg Reynolds]

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 language that is not based on the JVM and comes even
close to the speed of Clojure.
>
> 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.
>

Now that's pretty darned interesting.  Next month I'm going to start doing
some serious work with the Java APIs on the Intel Edison.  Java is one of
the std environments for Edison.  But naturally I'm very interested in
finding out if what works in theory works in practice.  Running a Clojure
nrepl on an Edison is obviously a big win, in theory.  Is std Clojure fast
enough for iot stuff?  We'll see.

The other interesting doodad is the Curie.  Now in the Arduino 101, but due
to have an RTOS soon, see the zephyr project.  My pipedream is to write
Clojure code for Zephyr. Is that insane?

-g

-- 
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.

Benchmarking in Clojurescript -- Necessary or not?

[JvJ]

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 implementations.

So far, to do this, I've been using a benchmarking library called Criterium 
.  Criterium is great, but it has 
one major disadvantage as far as my project is concerned: It's 
JVM-specific, where as my project is cross-platform JVM and JS.

What I want to know is this:  Will the JVM benchmarking numbers reflect how 
the JS implementation performs?

I understand that JVM and JS are different platforms with different 
capabilities, and that in general JS is slower than JVM.  What I really 
want to know is whether or not the ratios will hold up.

For instance:  If running a set of operations my custom map takes on 
average 2.5 times longer than the same set of operations on a normal 
PersistentHashMap, will that "2.5 times" figure still approximately hold up 
across platforms?

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: Porting Clojure to Native Platforms

[Michael Ball]

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 call support, native compilation, 
and the open development CoreCLR could have a bright future as a host 
platform, even though it's not nearly as widely used as the JVM today.







On Monday, April 25, 2016 at 12:47:21 PM UTC-7, JvJ wrote:
>
>
>
> 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 
> , 
> but they are incomplete and don't seem to be under active development any 
> more.
>
> I'm wondering about the requirements, how much work it would take, and 
> whether or not it would be worth it.  My current thinking is of a 
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that 
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a 
>reference-counting scheme rather than a garbage collector?  This may 
>improve performance.
>- In a similar vein, can the allocation strategy be controlled for 
>these structures in such a way as to optimize cache locality?
>- Can we take advantage of tail-call optimization in existing C++ 
>compilers?
>- It wouldn't have to depend on an existing runtime environment like 
>JVM or JavaScript.
>   - Could this reduce reliance on reflection and increase performance?
>   - Could a new, clojure-optimized runtime be created that improves 
>   performance?
>- Could certain anonymous functions be optimized or inlined in a way 
>that improves performance over JVM/JS implementations?
>- Is there a way to compile C++ code at runtime?  This would be 
>essential for the REPL and for Macros.
>
>
> Let me know if anyone has any thoughts on the matter.
>
> 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: Benchmarking in Clojurescript -- Necessary or not?

[Francis Avila]

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, 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: Benchmarking in Clojurescript -- Necessary or not?

[JvJ]

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?
>>
>
> No 
>

-- 
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: Porting Clojure to Native Platforms

[Mark Engelberg]

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, dynamic language that is not based on the JVM and comes even
> close to the speed of Clojure.
>
>
Julia reportedly outperforms Clojure (I haven't benchmarked it myself).
Julia is designed primarily for numeric computation, but unlike a lot of
other "math languages" like Octave, R, and Matlab whose general programming
constructs are horribly slow, the overall general-purpose machinery of
Julia (function calls, looping, data structures, dispatch, etc.) is said to
be quite fast.

Speaking of numeric computation, it is, in my opinion, a real weak point of
Clojure.  There is a huge perf. penalty for boxed numbers, and since
anything in a Clojure data structure gets boxed, it's rather difficult to
work around Clojure's poor numeric performance for anything more
algorithmically complicated than a super-simple loop.  A number of dynamic
languages use tagged numbers (primitive types with a couple bits set aside
to mark the type of the number), and these are going to do much better than
Clojure for a wide variety of math-oriented computational tasks.  I've
benchmarked some specific programs in Clojure vs Racket and Racket tended
to come out ahead when there was a lot of arithmetic.

-- 
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: Porting Clojure to Native Platforms

[Ilya Ivanov]

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 looking around.
>
> There are a few projects that are on the right track, such as TinyClojure 
>  and Ferret 
> , 
> but they are incomplete and don't seem to be under active development any 
> more.
>
> I'm wondering about the requirements, how much work it would take, and 
> whether or not it would be worth it.  My current thinking is of a 
> Clojure->C/C++ compiler.
>
> So far, I have a few topics for discussion that I'm unclear about that 
> might be necessary for this kind of project:
>
>- Can the Immutable Persistent Data Structures be implemented with a 
>reference-counting scheme rather than a garbage collector?  This may 
>improve performance.
>- In a similar vein, can the allocation strategy be controlled for 
>these structures in such a way as to optimize cache locality?
>- Can we take advantage of tail-call optimization in existing C++ 
>compilers?
>- It wouldn't have to depend on an existing runtime environment like 
>JVM or JavaScript.
>   - Could this reduce reliance on reflection and increase performance?
>   - Could a new, clojure-optimized runtime be created that improves 
>   performance?
>- Could certain anonymous functions be optimized or inlined in a way 
>that improves performance over JVM/JS implementations?
>- Is there a way to compile C++ code at runtime?  This would be 
>essential for the REPL and for Macros.
>
>
> Let me know if anyone has any thoughts on the matter.
>
> 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: Porting Clojure to Native Platforms

[Mars0i]

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 use, dynamic language that is not based on the JVM and comes even 
> close to the speed of Clojure. 
>

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 
the Computer Language Benchmarks Game 

 
.  Whatever it is that those comparisons do, or don't prove, I would no 
longer be surprised.

-- 
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: Porting Clojure to Native Platforms

[Mars0i]

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 
> the Computer Language Benchmarks Game 
> 
>  
> .  Whatever it is that those comparisons do, or don't prove, I would no 
> longer be surprised.
>

I forgot how much faster Clojure got in 1.7 and 1.8.  I remember Java 
wiping the floor with Clojure on most of those benchmarks a couple of years 
ago, but now it's just a little bit faster on average 
 on those 
benchmarks.

-- 
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.