Re: Porting Clojure to Native Platforms

That could be hidden from the user by tooling though, perhaps by recompiling the previous version of the namespace with just the form the user wants to load modified. That would also fix one serious problem with per-form evaluation, which is that the line numbers for subsequent forms get messed up

Re: Tiny fix for LispReader

The clojure docs say numbers are "generally represented as per Java" with some additions (ratio, variable radix, M and N suffixes, etc.) For reference, the integer literals for Java are documented here: http://docs.oracle.com/javase/specs/jls/se8/html/jls-3.html#jls-3.10.1 There are some items

Re: Callback fn in core.async/put!

Thanks for the update. I verified the true/false behavior and submitted a JIRA: http://dev.clojure.org/jira/browse/ASYNC-167 Alan On Wed, Apr 27, 2016 at 12:34 AM, Leon Grapenthin wrote: > It is true if the put did succeeded, false if the channel was already > closed.

[JOB] Clojure/ClojureScript Web Developer @ Kira Systems

Hey all, We're hiring some more clojure developers. We prefer near Toronto Canada, but remote is welcome. You can apply here: https://kirasystems.com/careers#op-117143-clojureclojurescript-web-developer Best, Alex -- Clojure/ClojureScript Web Developer Kira Inc. is a

Re: Porting Clojure to Native Platforms

Racket has this feature. On Wed, Apr 27, 2016 at 11:29 AM, Jason Felice wrote: > > > On Tue, Apr 26, 2016 at 7:42 PM, Plínio Balduino > wrote: > >> >> * Is there a way to compile C++ code at runtime? This would be essential >> for the REPL and

Re: Encapsulating Local Mutable State

One thing you can do is use 'reify', which will allow you to implement a protocol but also have your state atom hidden in a closure. You'll still be passing an 'object' to all of the protocol methods (obviously), but it won't be the atom itself. -- You received this message because you are

Re: Porting Clojure to Native Platforms

He happens to be one of the original Erlang authors/designers. There's also a side project of LFE that attempts to make things more clojur'esque in LFE https://github.com/lfex/clj. As for right now LFE shares more similarities with Common Lisp than with Clojure or Racket (lfe is a Lisp2).

Re: Porting Clojure to Native Platforms

On Tue, Apr 26, 2016 at 7:42 PM, Plínio Balduino wrote: > > * Is there a way to compile C++ code at runtime? This would be essential > for the REPL and for Macros. > - I never heard about on demand native code generation and execution. I > think it could be a paradise for

Re: Porting Clojure to Native Platforms

You can watch Robert Virding's talk about creating Lisp Flavored Erlang (LFE). https://www.youtube.com/watch?v=Br2KY12LB2w It is really informative. It tells you a lot about Erlang and the BEAM. And it explains why LFE is not Clojure and why Clojure would not work. Virding really likes his

Re: Tiny fix for LispReader

I was acting with respect to what is said here: http://clojure.org/reference/reader. On Tuesday, April 26, 2016 at 10:19:59 PM UTC-7, Erik Assum wrote: > > In addition to what Andy said, this same behavior was recently implemented > in tools.reader (the Clojure impel of lisp reader) >

Re: Porting Clojure to Native Platforms

Colin Fleming writes: > Unit of compilation is the module, not sure how that all plays out with > the Elixir repl, but it's not optimal. From what I can tell, re-deffing a > defn would require re-loading an entire namespace (module)... > > Reloading a

ANN: clj-spss 0.0.2 - a lightweight SPSS file reader for Clojure

Hi all, In the (unlikely?) event that someone else also faces the problem of reading / importing SPSS files within Clojure, I've released a small library that does exactly that. https://github.com/mikera/clj-spss Nothing fancy here: it is mostly just a Clojure wrapper for some old Open Data

Re: Porting Clojure to Native Platforms

> > Unit of compilation is the module, not sure how that all plays out with > the Elixir repl, but it's not optimal. From what I can tell, re-deffing a > defn would require re-loading an entire namespace (module)... > Reloading a whole namespace on an evaluation doesn't seem like a

Re: Callback fn in core.async/put!

It is true if the put did succeeded, false if the channel was already closed. Should be clarified in the docstr. "Will throw if closed." is also not true. On Wednesday, April 27, 2016 at 5:48:09 AM UTC+2, Alan Thompson wrote: > > The docs for put! say > > (put! port val) > (put! port val fn0) >