FWIW, the expression

(go (let [c (async/chan)] (async/>! c 666) (println (async/<! c ))))

@mfikes yes I can confirm that. Andre seems to be behaving exacly the same as core.async. I need sanity check, so I ask at the #core-async what's going on.

unrelated to lumo but some core.async 101 knowledge missed my conciousness. (chan) always has room for one value, so when I put something on it >!, it waits blockingly for someone to take it, so this needs to be either two go statements to print from a channel, or using the number 1 (chan 1), actually adds a buffer, so how I see it, it has space for one value before it starts blocking.

for those of you wondering what the next version of Lumo would include: https://twitter.com/anmonteiro90/status/834064263245279233

🙂 🙂

This is fantastic!

Does lumo support defmacro in version 1.2.0?

Lumo has supported defmacro since its first release

@doglooksgood but know that macros have ClojureScript semantics

Which means they need to be defined in a separate compilation stage than when they're used

Mike Fikes has a number of posts on this, I'll link to them when I'm at a computer

@anmonteiro that is awsome, I was working on the exact same thing and we endend up implementing things pretty similarly

one key difference is that I decided to make the classpath an atom

that can be updated at any point to allow for flexibility in loading dependencies at any point

@anmonteiro then how can I get this separate compilation stage? writing macro in another file or writing some code in lumo's source code then recompile it?

@doglooksgood The usual way is to write macros in another file. Self-hosted ClojureScript is essentially like regular ClojureScript in this respect, with the salient difference being that macros namespaces are compiled as ClojureScript instead of as Clojure—even if the macros namespace is in a file named foo.clj

@anmonteiro @mfikes thanks, I'm going to have a try.

wow - just tried 1.2, JVM-less advanced compilation is pretty awesome!

@stbgz I wanted to put in some of the legwork so that we can all collaborate on one thing now 🙂

the classpath can also be updated dynamically. I’ll merge @npeckman ‘s work soon

@doglooksgood http://blog.fikesfarm.com/posts/2015-09-07-messing-with-macros-at-the-repl.html

@mikebelanger thanks! there’s a lot of stuff to iron out still but it’s a start

great! that’ll go a long way I think , my idea with the atom was to have listeners on it so that if you update it it’ll trigger a recompile, etc

If the target optimization to :none, is there a way of dialing into a repl? Doesn't look like lumo --classpath src build.cljs --repl does it.

not at the moment

@anmonteiro ah cool, no probs

@anmonteiro Nice post, thanks!

@anmonteiro still feels great to just compile cljs with so little project configuration.

I agree. I still can’t believe it myself, thanks 🙂

Excited to play around with the compilation soon! It's so cool to be close to a groundbreaking project like this

@anmonteiro did you benchmark performance at all?

nothing serious

@dominicm the same project takes like 55 seconds in Lumo and 5 seconds on the JVM

small project with advanced optimizations

which is a lot

I think this is something we need to take upstream with the Google Closure Compiler team

Yeah, not a huge surprise to me. Nodejs is generally slow for this kind of work.

Mostly curious.

Just to be even more meta, would it be possible to create an embedded repl using lumo-compiled clojurescript?

who knows 🙂

You can do any sorts of meta stuff now

the problem I had (and still didn’t solve) is that I couldn’t compile clojure.browser.repl

maybe we can just include a precompiled one or something but I haven’t given it any more thought

@anmonteiro no problem, good to know its theoretically possible, that clojure.browser.repl is the next thing to look at