@hlolli can you rebase your PR?

Sorry introduced conflicts

I'm also thinking we should print Node.js instead of Node

Otherwise looks good!

@anmonteiro yes, I'll do it, if there's no stress then I'll do it on monday or Thuesday. I'm taking few days off work to prepare a music performance this weekend (that I use Lumo for like you may have noticed).

Take your time

@hlolli oh wow! That's awesome

Let me know if you ever write about it

Yes will do. Also, on first glance at Lumo 1.3, I feel like the macros are performing better (or blocking less), but need further testing to confirm that. Yes, I will write about that, it's been bumpy road few weeks getting used to node.js, many things I took for granted using JVM.

if someone is in Belgium and wants to see Lumo on stage 😛 https://www.facebook.com/events/428669254139430/

hi! do you know if someone has attempted to have lumo socket repl running in Electron?

@cgrand hey!

I don’t think anyone has tried

I may be able to help if you provide more details into what you’re trying to do

I'm experimenting with unrepl prototyping an electron based repl client. At some point I thought it would be cool to have the ability to connect the client repl to itself (or rather "itselves" as there are two processes)

hrm, but is Lumo anywhere in the picture?

Not yet. I would be interested in having the whole thing powered by self hosted cljs. Hence the idea of reusing some parts of lumo.

An unrepl server implementation for lumo would be amazing

Why is the lower layer of the socket repl in JavaScript?

@cgrand Lumo relies on V8 startup snapshots to have really fast startup

this means we pass a big JS file to the V8 compilation when building Lumo

that file can’t have any Node stuff because V8 doesn’t know about Node at that point

So, if I follow, the parts written in JS are not part of the snapshot.

exactly

the snapshot is the compiled CLJS

https://twitter.com/thosmos/status/850454240283639808