Re: Embedded systems and transpiling Clojure to Nim

[Herwig Hochleitner]

I think Nim is pretty cool (conceptionally, haven't used it yet) and full
of wonderous features: From the hands down awesome, like the a la carte GC,
its AST - based macros and optimizations and effect system to positively
weird stuff like its partial case-insensitivity (foo-bar == fooBar ==
foo_bar == foobar == fOOBAr; wat?) or its method calls (obj.foo(bar) ==
foo(obj, bar); I don't even). Overall it's appealing to me and certainly
seems easier than rust. And, of course, I'm interested in new
implementations of clojure.

I'm optimistic about is the possibility to optimize the common case of
dynamic features by term-rewriting macros.

However, I have some concerns about it:
- How will nim's static types interact with dynamic features; can enough
types for the compiler be generated by inference?
- Could it be that nim is too rich a base as a host language? For the added
indirection and complexity: What do we gain over transpiling to C and
generating an accurate type map for BoehmGC?

Concerning porting Clojure: I think ClojureScript's experiment of putting
protocols/deftypes first in the bootstrapping chain has proven out, so I'd
start with figuring out how protocols are best represented (nim's
multimethods?). Since nim already has first-class functions, special care
has to be taken how they interact with the IFn protocol.

What do you think?

-- 
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: Embedded systems and transpiling Clojure to Nim

[Gary Trakhman]

Have you guys seen pixie yet?

It seems like there's overlap for the requirements here.

https://github.com/pixie-lang/pixie

On Fri, May 1, 2015 at 5:46 AM, Herwig Hochleitner 
wrote:

> I think Nim is pretty cool (conceptionally, haven't used it yet) and full
> of wonderous features: From the hands down awesome, like the a la carte GC,
> its AST - based macros and optimizations and effect system to positively
> weird stuff like its partial case-insensitivity (foo-bar == fooBar ==
> foo_bar == foobar == fOOBAr; wat?) or its method calls (obj.foo(bar) ==
> foo(obj, bar); I don't even). Overall it's appealing to me and certainly
> seems easier than rust. And, of course, I'm interested in new
> implementations of clojure.
>
> I'm optimistic about is the possibility to optimize the common case of
> dynamic features by term-rewriting macros.
>
> However, I have some concerns about it:
> - How will nim's static types interact with dynamic features; can enough
> types for the compiler be generated by inference?
> - Could it be that nim is too rich a base as a host language? For the
> added indirection and complexity: What do we gain over transpiling to C and
> generating an accurate type map for BoehmGC?
>
> Concerning porting Clojure: I think ClojureScript's experiment of putting
> protocols/deftypes first in the bootstrapping chain has proven out, so I'd
> start with figuring out how protocols are best represented (nim's
> multimethods?). Since nim already has first-class functions, special care
> has to be taken how they interact with the IFn protocol.
>
> What do you think?
>
> --
> 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: Embedded systems and transpiling Clojure to Nim

[Herwig Hochleitner]

I have seen it.

PyPy (the platform for pixie) hasn't the reach of even LLVM, let alone
plain C, so while there might be overlap in other areas, pixie is a
no-starter for non-mainstream hardware.

-- 
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: Embedded systems and transpiling Clojure to Nim

[Timothy Baldridge]

Well RPython (what pixie is built on) is C...so you get quite a bit of
reach there. And I'd be tempted to say that it would be easier to adapt the
existing RPython PPC backend to Freescale PPC than it would be to get Nim
to play nice with Clojure semantics.

And let's not forget, RPython can be fastsuper fast. Stuff like
transducers are slow on non-JIT'ed platforms, work well on JITs like the
JVM, and absolutely scream on tracing JITs (like RPython's JITs)

Anyway, just some thoughts.

Timothy

On Fri, May 1, 2015 at 9:10 AM, Herwig Hochleitner 
wrote:

> I have seen it.
>
> PyPy (the platform for pixie) hasn't the reach of even LLVM, let alone
> plain C, so while there might be overlap in other areas, pixie is a
> no-starter for non-mainstream hardware.
>
> --
> 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: Embedded systems and transpiling Clojure to Nim

[Alan Moore]

You have clearly looked into this more in depth than I have... Thanks for 
sharing your thoughts. I missed the part about the wonky case insensitivity 
(truly bizarre and hazard prone IMHO) and have not looked into the type 
system/inference so I can't comment just yet.

I'm not partial to Nim in particular but I really would like *something* I 
could use. I wouldn't mind going direct to C if there were some existing GC and 
immutable DS libraries we could lean on. I think there are enough issues with 
the transpiling that I wouldn't want to take on those as well.

I too was thinking of following ClojureScript's lead on this but was hoping to 
have macros available but now that I say it out loud dragging the compiler 
along for the ride seems like a bad choice given the target environment. Maybe 
that could be an optional feature for those who have the memory/proc resources.

Let me know how much interest you are likely to have (passing, involved, 
committed) for this. I appreciate your thoughtful comments - thanks!

Alan

-- 
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: Embedded systems and transpiling Clojure to Nim

[Alan Moore]

Agreed re: PyPy, Pixie. I got excited when I first saw that project...

As an alternative to straight C I've thought about targeting Lua but also 
wonder how much that buys you... TBD. I thought I remember reading someone 
going down that route - anyone?

Alan

-- 
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: Embedded systems and transpiling Clojure to Nim

[Herwig Hochleitner]

Tim,

I went with what I saw on http://pypy.org/features.html "... runs on Intel
x86 (IA-32) , x86_64 and ARM platforms, with PPC being stalled ...". Not
sure if that's just for the JIT, but if it were, they would list non-JIT
platforms separately, no?

I'm aware, that you use RPython directly, but you still reuse a lot of
RPython from PyPy, right? Has pixie been tested on any non-x86 platform yet?
​
Alan,

have you seen https://github.com/raph-amiard/clojurescript-lua ?

-- 
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: Embedded systems and transpiling Clojure to Nim

[Timothy Baldridge]

Yes, I when we finally get around to doing binary releases I plan on
shipping x86_64, x86 and ARM7 binaries, as those are the platforms I have
access to.

The other thing that would hinder adoption to other platforms is most
likely the stacklet library (lightweight threads), Pixie uses this fairly
heavily and it would probably need to be ported to PPC.

And yes there is a LuaJIT version of Clojure with support for Terra:
https://github.com/ohpauleez/cljs-terra

Doesn't look like it's been maintained recently however.

Timothy



On Fri, May 1, 2015 at 10:18 AM, Herwig Hochleitner 
wrote:

> Tim,
>
> I went with what I saw on http://pypy.org/features.html "... runs on
> Intel x86 (IA-32) , x86_64 and ARM platforms, with PPC being stalled ...".
> Not sure if that's just for the JIT, but if it were, they would list
> non-JIT platforms separately, no?
>
> I'm aware, that you use RPython directly, but you still reuse a lot of
> RPython from PyPy, right? Has pixie been tested on any non-x86 platform yet?
> ​
> Alan,
>
> have you seen https://github.com/raph-amiard/clojurescript-lua ?
>
> --
> 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: [ANN] Clojure 1.7.0-beta2

[shlomivaknin]

I tried playing around with the new primitive type hints and got the 
following weird behavior on [org.clojure/clojure "1.7.0-beta2"]:

(defn ^longs init-state []  (long-array 1))

(defn ^long store-state [^longs c ^long a] (aset c 0 a))

running the following line resulted in an exception:

(let [x (init-state)]
  (store-state x 5))

1. Caused by java.lang.VerifyError
   (class: clojure_7/core$eval13270, method: invoke signature:
   ()Ljava/lang/Object;) Unable to pop operand off an empty stack

Class.java:   -2 
 java.lang.Class/getDeclaredConstructors0
Class.java: 2671 
 java.lang.Class/privateGetDeclaredConstructors
Class.java: 3075  java.lang.Class/getConstructor0
Class.java:  412  java.lang.Class/newInstance
 Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval
 Compiler.java: 6791  clojure.lang.Compiler/eval
 Compiler.java: 7237  clojure.lang.Compiler/load
  REPL:1  reverse-index.main/eval13258
 Compiler.java: 6792  clojure.lang.Compiler/eval
 Compiler.java: 6755  clojure.lang.Compiler/eval
  core.clj: 3079  clojure.core/eval
  main.clj:  240  clojure.main/repl/read-eval-print/fn
  main.clj:  240  clojure.main/repl/read-eval-print
  main.clj:  258  clojure.main/repl/fn
  main.clj:  258  clojure.main/repl
   RestFn.java: 1523  clojure.lang.RestFn/invoke
interruptible_eval.clj:   58 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
  AFn.java:  152  clojure.lang.AFn/applyToHelper
  AFn.java:  144  clojure.lang.AFn/applyTo
  core.clj:  628  clojure.core/apply
  core.clj: 1866  clojure.core/with-bindings*
   RestFn.java:  425  clojure.lang.RestFn/invoke
interruptible_eval.clj:   56 
 clojure.tools.nrepl.middleware.interruptible-eval/evaluate
interruptible_eval.clj:  188 
 clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
interruptible_eval.clj:  157 
 clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
  AFn.java:   22  clojure.lang.AFn/run
   ThreadPoolExecutor.java: 1142 
 java.util.concurrent.ThreadPoolExecutor/runWorker
   ThreadPoolExecutor.java:  617 
 java.util.concurrent.ThreadPoolExecutor$Worker/run
   Thread.java:  745  java.lang.Thread/run

while the following line worked just fine:

(store-state (init-state) 5)

and also this works fine:

(def a (init-state))
(store-state a 5)

(aget a 0) ;; 5

What do you think?

On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote:
>
> Clojure 1.7.0-beta2 is now available.
>
> Try it via
> - Download: 
> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/
> - Leiningen: [org.clojure/clojure "1.7.0-beta2"]
>
> Regression fixes since 1.7.0-beta1:
>
> 1) CLJ-1711 - structmap iterator broken
> 2) CLJ-1709 - range wrong for step != 1
> 3) CLJ-1713 - range chunks are not serializable
> 4) CLJ-1698 - fix reader conditional bugs
>
> Additional enhancements to new features since 1.7.0-beta1:
>
> 1) CLJ-1703 - Pretty print #error and new public function Throwable->map
> 2) CLJ-1700 - Reader conditionals now allowed in the REPL
> 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj
>   
> For a full list of changes since 1.6.0, see:
> https://github.com/clojure/clojure/blob/master/changes.md
>
> Please give it a try and let us know if things are working (or not)!
>
> - Alex
>
>

-- 
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: [ANN] Clojure 1.7.0-beta2

[Nicola Mometto]

The type-hint on init-state is wrong.

It has to be either

(defn {:tag 'longs} init-state [] (long-array 1))
or (preferred)
(defn init-state ^longs [] (long-array 1))


shlomivak...@gmail.com writes:

> I tried playing around with the new primitive type hints and got the
> following weird behavior on [org.clojure/clojure "1.7.0-beta2"]:
>
> (defn ^longs init-state []  (long-array 1))
>
> (defn ^long store-state [^longs c ^long a] (aset c 0 a))
>
> running the following line resulted in an exception:
>
> (let [x (init-state)]
>   (store-state x 5))
>
> 1. Caused by java.lang.VerifyError
>(class: clojure_7/core$eval13270, method: invoke signature:
>()Ljava/lang/Object;) Unable to pop operand off an empty stack
>
> Class.java:   -2
>  java.lang.Class/getDeclaredConstructors0
> Class.java: 2671
>  java.lang.Class/privateGetDeclaredConstructors
> Class.java: 3075  java.lang.Class/getConstructor0
> Class.java:  412  java.lang.Class/newInstance
>  Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval
>  Compiler.java: 6791  clojure.lang.Compiler/eval
>  Compiler.java: 7237  clojure.lang.Compiler/load
>   REPL:1  reverse-index.main/eval13258
>  Compiler.java: 6792  clojure.lang.Compiler/eval
>  Compiler.java: 6755  clojure.lang.Compiler/eval
>   core.clj: 3079  clojure.core/eval
>   main.clj:  240  clojure.main/repl/read-eval-print/fn
>   main.clj:  240  clojure.main/repl/read-eval-print
>   main.clj:  258  clojure.main/repl/fn
>   main.clj:  258  clojure.main/repl
>RestFn.java: 1523  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   58
>  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
>   AFn.java:  152  clojure.lang.AFn/applyToHelper
>   AFn.java:  144  clojure.lang.AFn/applyTo
>   core.clj:  628  clojure.core/apply
>   core.clj: 1866  clojure.core/with-bindings*
>RestFn.java:  425  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   56
>  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:  188
>  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
> interruptible_eval.clj:  157
>  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
>   AFn.java:   22  clojure.lang.AFn/run
>ThreadPoolExecutor.java: 1142
>  java.util.concurrent.ThreadPoolExecutor/runWorker
>ThreadPoolExecutor.java:  617
>  java.util.concurrent.ThreadPoolExecutor$Worker/run
>Thread.java:  745  java.lang.Thread/run
>
> while the following line worked just fine:
>
> (store-state (init-state) 5)
>
> and also this works fine:
>
> (def a (init-state))
> (store-state a 5)
>
> (aget a 0) ;; 5
>
> What do you think?
>
> On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote:
>>
>> Clojure 1.7.0-beta2 is now available.
>>
>> Try it via
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/
>> - Leiningen: [org.clojure/clojure "1.7.0-beta2"]
>>
>> Regression fixes since 1.7.0-beta1:
>>
>> 1) CLJ-1711 - structmap iterator broken
>> 2) CLJ-1709 - range wrong for step != 1
>> 3) CLJ-1713 - range chunks are not serializable
>> 4) CLJ-1698 - fix reader conditional bugs
>>
>> Additional enhancements to new features since 1.7.0-beta1:
>>
>> 1) CLJ-1703 - Pretty print #error and new public function Throwable->map
>> 2) CLJ-1700 - Reader conditionals now allowed in the REPL
>> 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj
>>
>> For a full list of changes since 1.6.0, see:
>> https://github.com/clojure/clojure/blob/master/changes.md
>>
>> Please give it a try and let us know if things are working (or not)!
>>
>> - Alex
>>
>>

--

-- 
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: [ANN] Clojure 1.7.0-beta2

[shlomivaknin]

Right you are, silly me :)

thanks!

On Friday, May 1, 2015 at 11:17:42 AM UTC-7, Nicola Mometto wrote:
>
>
> The type-hint on init-state is wrong. 
>
> It has to be either 
>
> (defn {:tag 'longs} init-state [] (long-array 1)) 
> or (preferred) 
> (defn init-state ^longs [] (long-array 1)) 
>
>
> shlomi...@gmail.com  writes: 
>
> > I tried playing around with the new primitive type hints and got the 
> > following weird behavior on [org.clojure/clojure "1.7.0-beta2"]: 
> > 
> > (defn ^longs init-state []  (long-array 1)) 
> > 
> > (defn ^long store-state [^longs c ^long a] (aset c 0 a)) 
> > 
> > running the following line resulted in an exception: 
> > 
> > (let [x (init-state)] 
> >   (store-state x 5)) 
> > 
> > 1. Caused by java.lang.VerifyError 
> >(class: clojure_7/core$eval13270, method: invoke signature: 
> >()Ljava/lang/Object;) Unable to pop operand off an empty stack 
> > 
> > Class.java:   -2 
> >  java.lang.Class/getDeclaredConstructors0 
> > Class.java: 2671 
> >  java.lang.Class/privateGetDeclaredConstructors 
> > Class.java: 3075  java.lang.Class/getConstructor0 
> > Class.java:  412  java.lang.Class/newInstance 
> >  Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval 
> >  Compiler.java: 6791  clojure.lang.Compiler/eval 
> >  Compiler.java: 7237  clojure.lang.Compiler/load 
> >   REPL:1  reverse-index.main/eval13258 
> >  Compiler.java: 6792  clojure.lang.Compiler/eval 
> >  Compiler.java: 6755  clojure.lang.Compiler/eval 
> >   core.clj: 3079  clojure.core/eval 
> >   main.clj:  240 
>  clojure.main/repl/read-eval-print/fn 
> >   main.clj:  240  clojure.main/repl/read-eval-print 
> >   main.clj:  258  clojure.main/repl/fn 
> >   main.clj:  258  clojure.main/repl 
> >RestFn.java: 1523  clojure.lang.RestFn/invoke 
> > interruptible_eval.clj:   58 
> >  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn 
> >   AFn.java:  152  clojure.lang.AFn/applyToHelper 
> >   AFn.java:  144  clojure.lang.AFn/applyTo 
> >   core.clj:  628  clojure.core/apply 
> >   core.clj: 1866  clojure.core/with-bindings* 
> >RestFn.java:  425  clojure.lang.RestFn/invoke 
> > interruptible_eval.clj:   56 
> >  clojure.tools.nrepl.middleware.interruptible-eval/evaluate 
> > interruptible_eval.clj:  188 
> > 
>  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn 
> > interruptible_eval.clj:  157 
> >  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn 
> >   AFn.java:   22  clojure.lang.AFn/run 
> >ThreadPoolExecutor.java: 1142 
> >  java.util.concurrent.ThreadPoolExecutor/runWorker 
> >ThreadPoolExecutor.java:  617 
> >  java.util.concurrent.ThreadPoolExecutor$Worker/run 
> >Thread.java:  745  java.lang.Thread/run 
> > 
> > while the following line worked just fine: 
> > 
> > (store-state (init-state) 5) 
> > 
> > and also this works fine: 
> > 
> > (def a (init-state)) 
> > (store-state a 5) 
> > 
> > (aget a 0) ;; 5 
> > 
> > What do you think? 
> > 
> > On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote: 
> >> 
> >> Clojure 1.7.0-beta2 is now available. 
> >> 
> >> Try it via 
> >> - Download: 
> >> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/ 
> >> - Leiningen: [org.clojure/clojure "1.7.0-beta2"] 
> >> 
> >> Regression fixes since 1.7.0-beta1: 
> >> 
> >> 1) CLJ-1711 - structmap iterator broken 
> >> 2) CLJ-1709 - range wrong for step != 1 
> >> 3) CLJ-1713 - range chunks are not serializable 
> >> 4) CLJ-1698 - fix reader conditional bugs 
> >> 
> >> Additional enhancements to new features since 1.7.0-beta1: 
> >> 
> >> 1) CLJ-1703 - Pretty print #error and new public function 
> Throwable->map 
> >> 2) CLJ-1700 - Reader conditionals now allowed in the REPL 
> >> 3) CLJ-1699 - Allow data_readers.cljc as well as data_readers.clj 
> >> 
> >> For a full list of changes since 1.6.0, see: 
> >> https://github.com/clojure/clojure/blob/master/changes.md 
> >> 
> >> Please give it a try and let us know if things are working (or not)! 
> >> 
> >> - Alex 
> >> 
> >> 
>
> -- 
>

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

Re: [ANN] Clojure 1.7.0-beta2

[Fluid Dynamics]

On Friday, May 1, 2015 at 2:17:42 PM UTC-4, Nicola Mometto wrote:
>
>
> The type-hint on init-state is wrong. 
>
> It has to be either 
>
> (defn {:tag 'longs} init-state [] (long-array 1)) 
> or (preferred) 
> (defn init-state ^longs [] (long-array 1)) 
>

That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...).

It also doesn't negate the original bug report. That VerifyError means that 
the Clojure compiler emitted invalid bytecode, instead of either emitting 
valid bytecode or reporting a sensible error. Any way you slice it the 
compiler is buggy if it can quietly emit broken bytecode.

-- 
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: Gamma, GLSL shaders made simple

[kovas boguta]

Gamma is a substrate for graphics software, such as games and data
visualization tools. It presents a simple, composable language for
representing GLSL shaders. It allows using Clojurescript to abstract
shaders.

https://github.com/kovasb/gamma

Technically, Gamma is an EDSL that hosts GLSL within Clojurescript. It is
inspired by Carlos Scheidegger's Lux and Conal Elliot's Vertigo and Pan.
Gamma targets the WebGL subset of the OpenGL ES 1.0 Shading Language.

This is a 0.1 release; work remains to get to 100% coverage of GLSL.

-- 
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: ANN: Gamma, GLSL shaders made simple

[Sean Grove]

I was literally just looking over this right before you sent the
announcement, and it looks fantastic. Really looking forward to playing
with it over the next few weeks.

On Fri, May 1, 2015 at 12:39 PM, kovas boguta 
wrote:

> Gamma is a substrate for graphics software, such as games and data
> visualization tools. It presents a simple, composable language for
> representing GLSL shaders. It allows using Clojurescript to abstract
> shaders.
>
> https://github.com/kovasb/gamma
>
> Technically, Gamma is an EDSL that hosts GLSL within Clojurescript. It is
> inspired by Carlos Scheidegger's Lux and Conal Elliot's Vertigo and Pan.
> Gamma targets the WebGL subset of the OpenGL ES 1.0 Shading Language.
>
> This is a 0.1 release; work remains to get to 100% coverage of GLSL.
>
>
>
> --
> 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: [ANN] Clojure 1.7.0-beta2

[Andy Fingerhut]

I am not sure why you say "new primitive type hints".  Primitive type hints
have been around for several Clojure released versions, 1.6.0 and earlier.

The error you are seeing is because of a property of the Clojure compiler
that as far as I know is not documented.  I asked back in Nov 2014 whether
it was, but didn't get any response [1].

Clojure eval's type tags on def'd names, and since 'long', 'longs', 'int',
'ints', etc. are also the names of functions in clojure.core, type tags of
the kind you tried to use, _when applied to the def'd or defn'd symbols_,
are treated as the values of those functions, and in most cases are ignored
by the Clojure compiler.  You found a case where they are not ignored.
This is not new in Clojure 1.7.0-beta2.  I verified your example gives the
same results with Clojure 1.6.0, and I would guess it would also do that
for a few earlier Clojure releases, too.

Either do this:

(defn ^{:tag 'longs} init-state []  (long-array 1))

or put the type tag on the argument vector instead:

(defn init-state ^longs []  (long-array 1))

The latest release of the Eastwood lint tool [2] will warn about type tags
of the kind you used:

(defn ^longs init-state []  (long-array 1))

Andy


[1] https://groups.google.com/d/msg/clojure-dev/u3mcy7iiQ40/ZUP8nglwVDsJ
[2] https://github.com/jonase/eastwood

On Fri, May 1, 2015 at 11:13 AM,  wrote:

> I tried playing around with the new primitive type hints and got the
> following weird behavior on [org.clojure/clojure "1.7.0-beta2"]:
>
> (defn ^longs init-state []  (long-array 1))
>
> (defn ^long store-state [^longs c ^long a] (aset c 0 a))
>
> running the following line resulted in an exception:
>
> (let [x (init-state)]
>   (store-state x 5))
>
> 1. Caused by java.lang.VerifyError
>(class: clojure_7/core$eval13270, method: invoke signature:
>()Ljava/lang/Object;) Unable to pop operand off an empty stack
>
> Class.java:   -2
>  java.lang.Class/getDeclaredConstructors0
> Class.java: 2671
>  java.lang.Class/privateGetDeclaredConstructors
> Class.java: 3075  java.lang.Class/getConstructor0
> Class.java:  412  java.lang.Class/newInstance
>  Compiler.java: 4843  clojure.lang.Compiler$ObjExpr/eval
>  Compiler.java: 6791  clojure.lang.Compiler/eval
>  Compiler.java: 7237  clojure.lang.Compiler/load
>   REPL:1  reverse-index.main/eval13258
>  Compiler.java: 6792  clojure.lang.Compiler/eval
>  Compiler.java: 6755  clojure.lang.Compiler/eval
>   core.clj: 3079  clojure.core/eval
>   main.clj:  240  clojure.main/repl/read-eval-print/fn
>   main.clj:  240  clojure.main/repl/read-eval-print
>   main.clj:  258  clojure.main/repl/fn
>   main.clj:  258  clojure.main/repl
>RestFn.java: 1523  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   58
>  clojure.tools.nrepl.middleware.interruptible-eval/evaluate/fn
>   AFn.java:  152  clojure.lang.AFn/applyToHelper
>   AFn.java:  144  clojure.lang.AFn/applyTo
>   core.clj:  628  clojure.core/apply
>   core.clj: 1866  clojure.core/with-bindings*
>RestFn.java:  425  clojure.lang.RestFn/invoke
> interruptible_eval.clj:   56
>  clojure.tools.nrepl.middleware.interruptible-eval/evaluate
> interruptible_eval.clj:  188
>  clojure.tools.nrepl.middleware.interruptible-eval/interruptible-eval/fn/fn
> interruptible_eval.clj:  157
>  clojure.tools.nrepl.middleware.interruptible-eval/run-next/fn
>   AFn.java:   22  clojure.lang.AFn/run
>ThreadPoolExecutor.java: 1142
>  java.util.concurrent.ThreadPoolExecutor/runWorker
>ThreadPoolExecutor.java:  617
>  java.util.concurrent.ThreadPoolExecutor$Worker/run
>Thread.java:  745  java.lang.Thread/run
>
> while the following line worked just fine:
>
> (store-state (init-state) 5)
>
> and also this works fine:
>
> (def a (init-state))
> (store-state a 5)
>
> (aget a 0) ;; 5
>
> What do you think?
>
> On Friday, April 24, 2015 at 11:27:40 AM UTC-7, Alex Miller wrote:
>>
>> Clojure 1.7.0-beta2 is now available.
>>
>> Try it via
>> - Download:
>> https://repo1.maven.org/maven2/org/clojure/clojure/1.7.0-beta2/
>> - Leiningen: [org.clojure/clojure "1.7.0-beta2"]
>>
>> Regression fixes since 1.7.0-beta1:
>>
>> 1) CLJ-1711 - structmap iterator broken
>> 2) CLJ-1709 - range wrong for step != 1
>> 3) CLJ-1713 - range chunks are not serializable
>> 4) CLJ-1698 - fix reader conditional bugs
>>
>> Additional enhancements to new features since 1.7.0-beta1:
>>
>> 1) CLJ-1703 - Pretty print #error and new public function Throwable->map
>> 2) CLJ-1700 - Reader conditionals now allowed in the REPL
>> 3) CLJ-1699 - 

Re: [ANN] Clojure 1.7.0-beta2

[Nicola Mometto]

Fluid Dynamics writes:

> That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...).

It can be surprising behaviour, but it's not an inconsistency.
As per the documentation, metadata on the symbol being def'd *is*
evaluated, metadata on the argvec isn't.
Evaluating `String` produces the java.lang.String Class -- a valid tag,
evaluating `longs` produces the clojure.core/longs function -- not a
valid tag. OTOH 'longs is a valid tag that the compiler understands.

> It also doesn't negate the original bug report. That VerifyError means that
> the Clojure compiler emitted invalid bytecode, instead of either emitting
> valid bytecode or reporting a sensible error. Any way you slice it the
> compiler is buggy if it can quietly emit broken bytecode.

The reported exception is not all of what happens.
If you try to execute that code you'll see that you get two exceptions,
the first one being "java.lang.IllegalArgumentException: Unable to
resolve classname: clojure.core$longs@3f91beef" which tells you exactly
what I told you before -- clojure.core/long is not a valid type hint.

The VerifyError is thrown later and is caused by the fact that the
compiler emits partial bytecode as it gets interrupted by the
IllegalArgumentException.

Now, if you want to argue that the compiler should immediately throw an
error as soon as the wrong type hint is used rather than silently ignore
it and fail when the type-hinted form is used, I'll agree with you and
I've proposed to make the compiler stricter a number of times on the
clojure-dev ML and talked about it on IRC but I guess either it's not a
priority for the clojure/core team or they're simply not interested in
more compile-time checks.
Either way the reported issue was a user error, not a compiler bug.

--

-- 
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: [ANN] Clojure 1.7.0-beta2

[Fluid Dynamics]

On Friday, May 1, 2015 at 3:54:08 PM UTC-4, Nicola Mometto wrote:
>
>
> Fluid Dynamics writes: 
>
> > That's weirdly inconsistent with e.g. (defn ^String prefix [s n]...). 
>
> It can be surprising behaviour, but it's not an inconsistency. 
> As per the documentation, metadata on the symbol being def'd *is* 
> evaluated, metadata on the argvec isn't. 
> Evaluating `String` produces the java.lang.String Class -- a valid tag, 
> evaluating `longs` produces the clojure.core/longs function -- not a 
> valid tag. OTOH 'longs is a valid tag that the compiler understands. 
>
> > It also doesn't negate the original bug report. That VerifyError means 
> that 
> > the Clojure compiler emitted invalid bytecode, instead of either 
> emitting 
> > valid bytecode or reporting a sensible error. Any way you slice it the 
> > compiler is buggy if it can quietly emit broken bytecode. 
>
> The reported exception is not all of what happens. 
> If you try to execute that code you'll see that you get two exceptions, 
> the first one being "java.lang.IllegalArgumentException: Unable to 
> resolve classname: clojure.core$longs@3f91beef" which tells you exactly 
> what I told you before -- clojure.core/long is not a valid type hint. 
>
> The VerifyError is thrown later and is caused by the fact that the 
> compiler emits partial bytecode as it gets interrupted by the 
> IllegalArgumentException. 
>
> Now, if you want to argue that the compiler should immediately throw an 
> error as soon as the wrong type hint is used rather than silently ignore 
> it and fail when the type-hinted form is used, I'll agree with you and 
> I've proposed to make the compiler stricter a number of times on the 
> clojure-dev ML and talked about it on IRC but I guess either it's not a 
> priority for the clojure/core team or they're simply not interested in 
> more compile-time checks. 
> Either way the reported issue was a user error, not a compiler bug. 
>

Seems to me it's both. Certainly if the compiler were bug-free there would 
never be a VerifyError while running clojure, other than maybe when 
dynamically loading a buggy class that originated somewhere else. (e.g. 
(eval '(.some.pkg.BuggyClass 42 606)) with a broken 
some/pkg/BuggyClass.class in the classpath.)
 

-- 
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: [ANN] Clojure 1.7.0-beta2

[Alex Miller]

On Fri, May 1, 2015 at 2:53 PM, Nicola Mometto  wrote:
>
>
> Now, if you want to argue that the compiler should immediately throw an
> error as soon as the wrong type hint is used rather than silently ignore
> it and fail when the type-hinted form is used, I'll agree with you and
> I've proposed to make the compiler stricter a number of times on the
> clojure-dev ML and talked about it on IRC but I guess either it's not a
> priority for the clojure/core team or they're simply not interested in
> more compile-time checks.
>

Is there a ticket?

-- 
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: Newbie

[Brett Morgan]

I second,  http://www.braveclojure.com.  It's a great tutorial.  I've 
switch from using Emacs as IDE to Cursive, an Intellij plugin. 
 https://cursiveclojure.com

On Thursday, April 30, 2015 at 4:03:47 PM UTC-4, Jeff Heon wrote:
>
> I quite like these two resources for total beginners.
>
> (Starts up assuming you know nothing about Lisp.)
> aphyr.com/tags/Clojure-from-the-ground-up
>
> (Quite humorous)
> http://www.braveclojure.com/
>
>

-- 
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: [ANN] Clojure 1.7.0-beta2

[Nicola Mometto]

Alex Miller writes:

> On Fri, May 1, 2015 at 2:53 PM, Nicola Mometto  wrote:
>>
>>
>> Now, if you want to argue that the compiler should immediately throw an
>> error as soon as the wrong type hint is used rather than silently ignore
>> it and fail when the type-hinted form is used, I'll agree with you and
>> I've proposed to make the compiler stricter a number of times on the
>> clojure-dev ML and talked about it on IRC but I guess either it's not a
>> priority for the clojure/core team or they're simply not interested in
>> more compile-time checks.
>>
>
> Is there a ticket?

There are a number of tickets reporting errors caused by the compiler
silently ignoring invalid type hints
http://dev.clojure.org/jira/browse/CLJ-1674
http://dev.clojure.org/jira/browse/CLJ-1232

or type hints inconsistencies
http://dev.clojure.org/jira/browse/CLJ-1577
http://dev.clojure.org/jira/browse/CLJ-1533

There are no open tickets open that I'm aware of about making the
compiler stricter on :tag values.

I would open one but there's this clojure-dev thread
https://groups.google.com/forum/#!msg/clojure-dev/hRZFuaiB_50/mzKLirgZWmUJ
where I ask what should be the allowed :tag values and I got no
clarification on it -- I see no point in spending my time working on a
patch/enhancement proposal that would break contrib libraries used by
clojure itself (there's no way to make the compiler throw on e.g. (defn
^doubles foo ..) and not throw on test.generative usages) until I know
for a fact that I would not be wasting my 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 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: Clojure Async/State Machine/Workflow Libraries?

[Brett Morgan]

>
> but one would need option to stop the execution in some point of "go" 
> block, persist it, and continue it later.
>
 
Why would you need to stop execution?  You could just have a chan, put what 
you need to persist on it, then then have different go block persist it. 
 Main processing continues on happily.  



On Thursday, April 30, 2015 at 1:11:43 PM UTC-4, Vjeran Marcinko wrote:
>
> If you're looking for something similar to some BPM (BPMN, BPEL...) 
> engines in Clojure land, I *think* there is nothing similar here. I'm 
> actually researching that area occasionally, and thinking wishfully about 
> implementing one in Clojure someday.
>
> When core.async appeared first, since it also comes from "process area" of 
> IT (CSP, actors, process algebra...), I thought it would be sufficient for 
> that case also, but unfortunately it seems it has some strong differences 
> between BPM engines which are "session-based", meaning, each message that 
> is received over channel marked as 'session creator' spawns new async 
> process which is long, very long running (potentially years), and all 
> subsequent messages that have correlation value for that process are routed 
> to that session afterwards. 
>
> Biggest similarity is that both approaches (BPM enginer and core.async) 
> invert control of execution, meaning, you write easy-to-grasp sequential 
> code which is executed asynchronously, but one would need option to stop 
> the execution in some point of "go" block, persist it, and continue it 
> later. In Java, Apache ODDE, which is BPEL engine, uses Pi-calculus engine 
> underneath, that uses continuations queue and is able to persist the 
> session on demand, and dehydrate it again when needed, even if that moment 
> comes a year later..
>
> In other words, we need something like durable, restartable, GO blocks, 
> for each indivudual long-running session, and there can be hundreds of 
> thousands of them active in a system simultaneously (think about hundred k 
> of active purchase orders...).
>
> -Vjeran
>
> On Thursday, April 30, 2015 at 1:35:25 PM UTC+2, Tim Visher wrote:
>>
>> Hey All,
>>
>> Anyone have any tips on clojure 'workflow' libraries? 
>> https://github.com/relaynetwork/impresario is very close, but lacks some 
>> basic features like exception transitions, etc. 
>>
>> Basically, I'm looking for a library that allows me to create a workflow 
>> that will happen asynchronously, recording it's progress in a db. I think i 
>> could probably whip something together without _too_ much trouble using 
>> core.async but this feels like something that's probably already been 
>> written.
>>
>> Thanks in advance!
>>
>> --
>>
>> In Christ,
>>
>> Timmy V.
>>
>> http://blog.twonegatives.com/
>> http://five.sentenc.es/ -- Spend less time on mail
>>
>

-- 
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: Embedded systems and transpiling Clojure to Nim

[Christopher Small]

Another possibility is https://github.com/takeoutweight/clojure-scheme. It 
compiles Clojure to Gambit Scheme to C to metal. It's been a couple of 
years since there was any activity on that project, but it's possible some 
attention there could get it where you need it. 

Nim seems interesting though. I wasn't really aware of it; only the 
combinatorial game by the same name.

In any case, I think this is an awesome goal. I'd particularly like to see 
an option for running Clojure of some ilk on Arduino and the like.

Cheers

Chris

-- 
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: Embedded systems and transpiling Clojure to Nim

[Raoul Duke]

> Another possibility is https://github.com/takeoutweight/clojure-scheme. It
> compiles Clojure to Gambit Scheme to C to metal.

another possibility is to stab oneself in the eye with a sharp stick.

just sayin'.

:-)

-- 
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: Embedded systems and transpiling Clojure to Nim

[Christopher Small]

Hah; I have no experience with it. Is it that bad?

At least there's another Lisp in there. Lisps all the way down!

On Fri, May 1, 2015 at 1:58 PM, Raoul Duke  wrote:

> > Another possibility is https://github.com/takeoutweight/clojure-scheme.
> It
> > compiles Clojure to Gambit Scheme to C to metal.
>
> another possibility is to stab oneself in the eye with a sharp stick.
>
> just sayin'.
>
> :-)
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Embedded systems and transpiling Clojure to Nim

[Raoul Duke]

I just would guess that anything other than an embedded JVM would
be... poor r.o.i., to be polite.

-- 
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: Embedded systems and transpiling Clojure to Nim

[Christopher Small]

Well... Correct me if I'm wrong, but this entire thread is about compiling 
Clojure to native targets. Are folks here really talking about embedding a 
JVM?

Has cljs been poor roi? :-)

Chris


On Friday, May 1, 2015 at 2:25:27 PM UTC-7, raould wrote:
>
> I just would guess that anything other than an embedded JVM would 
> be... poor r.o.i., to be polite. 
>

-- 
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: Embedded systems and transpiling Clojure to Nim

[Raoul Duke]

all i'm trying to say is that the more layers of indirection you add,
the more i won't give you any money on kickstarter.

-- 
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: Embedded systems and transpiling Clojure to Nim

[Christopher Small]

Both Nim and Pixie ultimately compile to C, and would have just as many
layers of indirection.

On Fri, May 1, 2015 at 2:37 PM, Raoul Duke  wrote:

> all i'm trying to say is that the more layers of indirection you add,
> the more i won't give you any money on kickstarter.
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Embedded systems and transpiling Clojure to Nim

[Ben Wolfson]

I'd assumed that pixie, like other projects using the RPython toolchain,
was itself compiled, but ran as an interpreter. Is that not the case?

On Fri, May 1, 2015 at 2:43 PM, Christopher Small 
wrote:

> Both Nim and Pixie ultimately compile to C, and would have just as many
> layers of indirection.
>
> On Fri, May 1, 2015 at 2:37 PM, Raoul Duke  wrote:
>
>> all i'm trying to say is that the more layers of indirection you add,
>> the more i won't give you any money on kickstarter.
>>
>> --
>> 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 a topic in the
>> Google Groups "Clojure" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
>> To unsubscribe from this group and all its topics, 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.
>



-- 
Ben Wolfson
"Human kind has used its intelligence to vary the flavour of drinks, which
may be sweet, aromatic, fermented or spirit-based. ... Family and social
life also offer numerous other occasions to consume drinks for pleasure."
[Larousse, "Drink" entry]

-- 
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: Embedded systems and transpiling Clojure to Nim

[Alan Moore]

On Fri, May 1, 2015 at 1:58 PM, Raoul Duke  wrote:

> > Another possibility is https://github.com/takeoutweight/clojure-scheme.
> It
> > compiles Clojure to Gambit Scheme to C to metal.
>
> another possibility is to stab oneself in the eye with a sharp stick.
>

Yeah... well, I do that on a daily basis working in C/C++ so just about
anything is better than what I have going on ATM.

Not all of us have the luxury of day jobs in Clojure. The embedded world is
sorely lacking when it comes to levels of abstraction and the world is
asking more and more from it. Not everything in the IoT is a phone with an
expensive processor and lots of memory, well, unless you want to buy a $700
toaster *on contract*. After slogging mutation around for [self edit] years
I'll do just about anything to get me some of that Clojure goodness,
starting with a REPL!

I really like Clojure and prefer it over Scheme, if nothing more than to
get better data structures... kinda half the point of Lisp to begin with
and a huge selling point for Clojure IMO.

Aside - I'm bummed that when I was originally introduced to Lisp there were
only car, cdr, etc. Really?! What a turn off. Went down the mutation rat
hole and am just now coming out... register access acronyms for function
names!?!? What *genius* thought up that bright idea? ;-)

Alan

-- 
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: Embedded systems and transpiling Clojure to Nim

[Raoul Duke]

> Both Nim and Pixie ultimately compile to C, and would have just as many
> layers of indirection.

aand they are all insane for anything other than learning
themselves at this point, i'd hazard to guess. but i'm a realist, who
knows. i'd rather go for a real jvm e.g. azul's embedded stuff, or
something like that first if at all possible. :-)

-- 
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: Embedded systems and transpiling Clojure to Nim

[Raoul Duke]

My goodness, there are other things than Clojure in the universe.
People have been making "native" software with "real" languages for
ages. There's probably even some that are fpish or heck go get an
actual lisp that's been used for ever (franz, allegro, ecl, gambit,
chicken, clozure, tinyscheme, etc.). Or an async or sync dataflow
langauge. Or just lua. etc. etc. etc. :-)

-- 
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: Embedded systems and transpiling Clojure to Nim

[Christopher Small]

I hear you Alan.

I'm just a hardware hobbyist, but I've been working on a Clojure library
for abstracting away some of the differences between different boards
(Raspberry Pi, BeagleBone Black, etc): https://github.com/clj-bots/pin-ctrl.
Currently, my best bet for Arduino is to use Firmata, but I would love to
be able to provide native compilation targets, since that would open up a
whole lot.

I'd love to have you join the group, if only to provide feedback (which
given your professional experience would be invaluable). We have a chat
here: https://gitter.im/clj-bots/chat.

Cheers

Chris


PS Gave a talk about this at ClojureWest, if you're interested:
https://www.youtube.com/watch?v=0EQMrpZb7-Y. Most of the talk is actually
about the automatic chicken coop door I set up, but a good chunk of it is
introduction of pin-ctrl and call to arms for hardware developers as well.



On Fri, May 1, 2015 at 2:50 PM, Alan Moore 
wrote:

> On Fri, May 1, 2015 at 1:58 PM, Raoul Duke  wrote:
>
>> > Another possibility is https://github.com/takeoutweight/clojure-scheme.
>> It
>> > compiles Clojure to Gambit Scheme to C to metal.
>>
>> another possibility is to stab oneself in the eye with a sharp stick.
>>
>
> Yeah... well, I do that on a daily basis working in C/C++ so just about
> anything is better than what I have going on ATM.
>
> Not all of us have the luxury of day jobs in Clojure. The embedded world
> is sorely lacking when it comes to levels of abstraction and the world is
> asking more and more from it. Not everything in the IoT is a phone with an
> expensive processor and lots of memory, well, unless you want to buy a $700
> toaster *on contract*. After slogging mutation around for [self edit] years
> I'll do just about anything to get me some of that Clojure goodness,
> starting with a REPL!
>
> I really like Clojure and prefer it over Scheme, if nothing more than to
> get better data structures... kinda half the point of Lisp to begin with
> and a huge selling point for Clojure IMO.
>
> Aside - I'm bummed that when I was originally introduced to Lisp there
> were only car, cdr, etc. Really?! What a turn off. Went down the mutation
> rat hole and am just now coming out... register access acronyms for
> function names!?!? What *genius* thought up that bright idea? ;-)
>
> Alan
>
>  --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
> To unsubscribe from this group and all its topics, 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: Embedded systems and transpiling Clojure to Nim

[Alan Moore]

In my world the JVM is a non-starter. I don't care if it fits in a ring (
http://www.javaworld.com/article/2076641/learn-java/an-introduction-to-the-java-ring.html),
culturally it just won't fly. Even Forth has a better chance of making it
than the JVM.

Re: Zulu embedded - "Intel/AMD x86. Please contact us for availability of
ARM, SPARC or other support packages." doesn't work for us.

Re: Lua, and other lisps, sure we could go that route. We already have Lua
in our devices.  I have a very specific use case in mind that I
think Clojure would be especially well suited for that Lua just doesn't
help me in the same way. YMMV.

I'm sorry you don't like this question. I can assure you that I'm not some
naive wild eyed Clojure fanboy as your responses suggest. I'm simply asking
if anyone else is interested in making this possible, I'll put you down in
the "no" and "hell no" columns. ;-)

I'm sure Rich got a lot of "aren't there already enough actual Lisps that
have been used forever" when he started Clojure. I'm glad they did not
deter him.

Take care.

Alan


On Fri, May 1, 2015 at 2:51 PM, Raoul Duke  wrote:

> > Both Nim and Pixie ultimately compile to C, and would have just as many
> > layers of indirection.
>
> aand they are all insane for anything other than learning
> themselves at this point, i'd hazard to guess. but i'm a realist, who
> knows. i'd rather go for a real jvm e.g. azul's embedded stuff, or
> something like that first if at all possible. :-)
>
> --
> 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 a topic in the
> Google Groups "Clojure" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/clojure/VhemHGGCcVY/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> clojure+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>



-- 
-- 
*"Whatever you can do, or dream you can do, begin it. Boldness has genius,
power, and magic in it. Begin it now."* - *Goethe*

-- 
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: Embedded systems and transpiling Clojure to Nim

[Alan Moore]

Chris,

I'll watch the video and then head on over - talk to you soon.

Alan

-- 
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: Embedded systems and transpiling Clojure to Nim

[gvim]

I've looked around intermittently for something Clojure-esque to fill 
the scripting/sysadmin void and Pixie is the only thing I've come across 
which inspires hope. The only remaining issue for me is whether it can 
tap into existing (Python) libraries as that's what tends to swing the 
vote for scripting languages. With more languages fragmenting the 
landscape building a community and sizeable selection of libraries is 
that much harder but I hope Pixie rises above the legions of 
Lisp-in-language-X exercises one finds on Hacker News by the dozen.


gvim



On 01/05/2015 18:10, Timothy Baldridge wrote:

Yes, I when we finally get around to doing binary releases I plan on
shipping x86_64, x86 and ARM7 binaries, as those are the platforms I
have access to.

The other thing that would hinder adoption to other platforms is most
likely the stacklet library (lightweight threads), Pixie uses this
fairly heavily and it would probably need to be ported to PPC.

And yes there is a LuaJIT version of Clojure with support for Terra:
https://github.com/ohpauleez/cljs-terra

Doesn't look like it's been maintained recently however.

Timothy



On Fri, May 1, 2015 at 10:18 AM, Herwig Hochleitner
mailto:hhochleit...@gmail.com>> wrote:

Tim,

I went with what I saw on http://pypy.org/features.html "... runs on
Intel x86 (IA-32) , x86_64 and ARM platforms, with PPC being stalled
...". Not sure if that's just for the JIT, but if it were, they
would list non-JIT platforms separately, no?

I'm aware, that you use RPython directly, but you still reuse a lot
of RPython from PyPy, right? Has pixie been tested on any non-x86
platform yet?
​
Alan,

have you seen https://github.com/raph-amiard/clojurescript-lua ?

--
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: Embedded systems and transpiling Clojure to Nim

[Fluid Dynamics]

On Friday, May 1, 2015 at 4:58:37 PM UTC-4, raould wrote:
>
> > Another possibility is https://github.com/takeoutweight/clojure-scheme. 
> It 
> > compiles Clojure to Gambit Scheme to C to metal. 
>
> another possibility is to stab oneself in the eye with a sharp stick. 
>
> just sayin'. 
>
> :-) 
>

Hear, hear. After cdring down a language-path that long you'll be lucky to 
get anything more sensible out the other end than "hexapodia is the key 
insight". ;) 

-- 
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: flip in clojure

[Ruslan Prokopchuk]

And do not miss https://github.com/LonoCloud/synthread for more complex 
cases ;-)

пятница, 1 мая 2015 г., 2:31:05 UTC+3 пользователь Vagmi Mudumbai написал:
>
> Hi, 
>
> I was introducing one of my colleagues to clojure[1] and we were 
> trying to parse the reddit json as an exercise. 
>
> (require '(clj-http.client :as client)) 
> (require '(clojure.data.json :as json)) 
>
> (def ^:const REDDIT-URL "http://reddit.com/r/clojure.json?limit=100";) 
> (def ^:const headers {:headers {"User-Agent" "showoffclojure.core by 
> vagmi"}}) 
>
> (let [entries_ (-> REDDIT-URL 
>(client/get headers) 
>(:body) 
>(json/read-str :key-fn keyword) 
>(:data) 
>(:children))] 
>   (map :data entries)) 
>
> It would have been nice if we were able to write the map as a part of 
> the threading macro. So if there were a flip function like in haskell, 
> we could flip the args to the function hand have the map in the 
> threading macro. I could not find one so I wrote one. 
>
> (defn flip [fn_] 
>   (fn [x y & args] 
> (apply fn_ (into [y x] args 
>
> Now I can bring in the map as a part of the -> threading macro. 
>
> (-> REDDIT-URL 
> (client/get headers) 
> (:body) 
> (json/read-str :key-fn keyword) 
> (:data) 
> (:children) 
> ((flip map) :data)) 
>
> This seems to be rather easy and useful and gets rid of the let block. 
> Are there any implications to performance or impact to laziness by 
> using flip? This would be useful even on the transduced version of 
> map like ((flip transduce) (map :data)) on the last expression. 
>
> Regards, 
> Vagmi 
>
>
> [1]: (
> http://blog.tarkalabs.com/2015/04/30/experience-report-introducing-an-experienced-ruby-developer-to-clojure/)
>  
>
> and 
>

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