This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-09
Channels
- # beginners (41)
- # boot (4)
- # cider (36)
- # cljsrn (9)
- # clojure (365)
- # clojure-dev (1)
- # clojure-dusseldorf (1)
- # clojure-nl (1)
- # clojure-russia (3)
- # clojure-spain (1)
- # clojure-spec (19)
- # clojure-uk (1)
- # clojurescript (159)
- # code-reviews (7)
- # core-async (51)
- # cursive (2)
- # datascript (1)
- # datomic (1)
- # emacs (5)
- # figwheel (3)
- # hoplon (18)
- # incanter (1)
- # lein-figwheel (1)
- # leiningen (3)
- # lumo (145)
- # off-topic (26)
- # onyx (21)
- # re-frame (2)
- # reagent (45)
- # rum (4)
- # uncomplicate (10)
- # untangled (23)
- # yada (6)
@anmonteiro Are you aware of the planck feature whereby fipp is somehow convinced to break inbetween printing and check if you've hit Ctrl-C? That would be pretty great for infinite sequences.
I wanna get that implemented in Lumo
@dominicm but we have something that Planck doesn't now 🙂
https://github.com/anmonteiro/lumo/commit/6b1b5a15dd455c7015f2a310cb7ceb323b2b741d
just landed that yesterday
unfortunately that doesn't work with (range)
, I'm still investigating why
but you can now kill stuff that would block Lumo before, things like (while true)
I'm also about to land some perf improvements that bring Lumo down to the startup speeds we had in first releases
Great. I had noticed a little bit of a lag when I started lumo. Wasn't sure if I was just remembering how fast it had been.
perf was definitely worse when I landed the Closure Compiler stuff
next release will be fast again 🙂
@anmonteiro So, I have some cljs which has :target :nodejs
, after startup, it should be of comparable speed to lumo though yes?
@dominicm I don't understand the question
if you're asking if speed of compiled JS executed in Node vs CLJS in Lumo is comparable
the answer is probably "no"
because Lumo will still have the overhead of compiling the CLJS
startup time should be comparable
anyway, almost midnight here, gonna get some sleep. these are the perf improvements if you're curious https://github.com/anmonteiro/lumo/pull/122
Mostly curious as this particular script is pretty slow for me, and I was curious about whether I could just port it to lumo and it would be faster. I wondered if your cached functions would be better optimized
@anmonteiro I'll see how much I can understand. G'night 🙂
I'd be curious to see benchmarks of that
Not a quick thing to port, as it's tied to the vim remote plugin api. So I'd need to write some glue code for rplugin's & lumo. Not that I don't want to do that anyway 😄
Hi, is it possible to do an eval of some code and supply some bindings to take effect at the same time?
@jonpither what do you mean "bindings" ?
@anmonteiro have you seen how unravel handles infinite ranges?
I could wrap an arbitrary expr with a bindings form prior to passing it to eval.. wondering if Im missing anything that exists already
@jonpither I doubt there's anything built in, I think you are looking to wrap code in the bindings macro.
I'm also interested in executing cljs code from lumo
Is manually calling (cljsjs.js/eval (cljs/empty-state) ..)
the best option?
Or is it possible to re-use lumo's compiler state? I'd also like to have access to vars defined in my lumo code.
@pesterhazy you can surely reuse the state in Lumo if you need to, just pass it to eval
I think the only gotcha is that lumo's init function must be called, but if you use eval from within an already launched Lumo Repl that's already good
The function to call would be lumo.repl/execute
@pesterhazy I have not. Can you link me to it?
I think it may be hard in any case, given we're also fighting the Node.js battle
only works with Clojure's socket server at the moment, but we'll add support for lumo's Socket Server in the future
I've definitely looked around Unravel, I was asking about handling infinite ranges
Essentially unrepl implements a custom printer which a print-length (in this case 10) and a continuation, which allows the user to go back to an earlier incomplete sequence and request the next 10 elements
IMO it's a good user experience when the user is faced with a ton of output -- at least better than the REPL crashing because of pretty-printing overhead, or the user being overwhelmed by too much output
@dominicm, that's planned for unravel as well! Adding a small web server that opens a web browser for interactive exploration and expansion of (potentially incomplete) EDN
@pesterhazy s/unrepl/unravel
In fact, it wouldn't be a bad idea to only launch a socket server in lumo, but auto start unravel for convenience...
That's interesting, but I also agree that Lumo shouldn't handle this
It's definitely an interesting idea though
@cgrand right 🙂
@pesterhazy so what are you using Lumo for in Unravel?
Does Lumo act as the client to Clojure's socket server?
the client that talks to the socket server is written in lumo, using node's readline lib (like lumo's repl)
That's amazing
lumo is great for this because it understands EDN and it has fast startup time (an essential feature for a repl client)
It's going to be even faster in the next release, as I was telling Dominic yesterday
frankly the development experience so far has been amazing
didn't run into any issues with lumo really
I discovered a nice dev pattern on the way
I hope my Euroclojure talk gets accepted so I can mention all these cool projects
in one terminal I run loop
(https://github.com/pesterhazy/unravel/blob/master/scripts/loop)
which basically runs the project
in the other terminal I run watch
https://github.com/pesterhazy/unravel/blob/master/scripts/watch
which watches src
for changes and kills (restarts) the loop instance
because lumo is so fast, this works really well
and I have to say that node is a good environment for network programming and even for cli tools
Definitely
I'm planning to submit a talk for euroclojure about unravel as well
The fact that JS engines are optimized for latency helps a lot with that
I just wish readline
were a little more pluggable
yeah but... it's javascript so you can just go in and override any methods
Sure, another concern is the event based API
node's readline module lacks a ^R
for reverse-history-search, I'm planning to add that as well
Yeah, Planck has that
There's an issue to add it to Lumo too
I saw that the readline work is implemented in js in lumo
is there a particular reason for that?
or just a historical artifact
It's because of the custom V8 snapshots
but some parts of lumo are implemented in cljs, correct?
Correct
The ones that don't require Node.js stuff to be there
do you mean they don't call js/require
?
Or that aren't in the critical path and can lazy-load them
require
, module
, console
, process
, all that stuff
Because the snapshot is loaded into V8 way before it knows about Node's existence
wouldn't it be possible to pass those primitives in somehow to the cljs code?
(n.b. I'm in the dark about how lumo bootstraps itself)
Yeah we do that but it requires lazy-loading of those modules via indirection and such
in my experience I use js/require
and js/process
in very few placs
So I choose to keep the critical path in JS for perf but also for readability
I see
although perhaps the readline UI wouldn't be critical?
re: readability, that's a good point, I haven't found a good way to write callback-heavy code in cljs without very long lines: https://github.com/pesterhazy/unravel/blob/master/src/unravel/loop.cljs#L211
@cgrand, have a look at make-edn-stream: https://github.com/pesterhazy/unravel/blob/master/src/unravel/network.cljs#L35
not sure if that's what you mean?
@pesterhazy you could probably make the code more readable with core.async
, although I don't know if it's worth it taking on the dependency
yeah I'm reluctant to use core.async in clojurescript
it may be better to use promises in some way
@pesterhazy no promises in cljs (unless you mean es6 ones)
yeah es6/node promises
A lot of things don't really support it. So you get more code around wrapping promises.
what about goog
promises?
I think I have used them in replumb
actually
isn't promises where javascript-land in general, and node-land in particular, is going? and generators?
yes -> https://github.com/Lambda-X/replumb/blob/master/test/cljs/replumb/test_helpers.cljs
>>> NOTE: This class was created in anticipation of the built-in Promise type being standardized and implemented across browsers. Now that Promise is available in modern browsers, and is automatically polyfilled by the Closure Compiler, by default, most new code should use native Promise instead of goog.Promise. However, goog.Promise has the concept of cancellation which native Promises do not yet have. So code needing cancellation may still want to use goog.Promise.
@dominicm can you give an example of what is hard about it?
Maybe cljs can make it super easy (in a similar way to how bluebird does) with a macro or something.
This works in lumo out of the box:
(-> (js/Promise. (fn [resolve reject] (resolve "foo"))) (.then prn))
@dominicm I'm not familiar with bluebird, what magic does it provide?
@pesterhazy take the fs module for example, for each function you want to use you have to create a "promisified" version which does (js/Promise. (fn [resolve reject] (fs.readFile "/tmp/log" (fn [val err] (if err (reject err) (resolve val))))))
@pesterhazy bluebird assumes that all callbacks are the form val, err, and wraps them automatically.
I guess we could just use bluebird?
for node apis like fs
Could do. Yes. It works, most of the time, but it feels… weird to use. Because it's automatic.
thanks this is super valuable info for me as a node-newb
oh god
both Linux and Windows CIs are running out of memory with the PR to make Lumo start faster
I don't know what to do... does anyone know CIs that provide VMs with lots of memory?
@anmonteiro I wonder if that's a request you could make? How much memory are they eating up?
I don't know exactly
definitely more than 3GB (in Appveyor's case, I think that's their limit)
Travis's might be 4GB, not sure
it's the C++ compilation
I added more stuff to the startup snapshot, and V8's mksnapshot
occupies a whole bunch of memory