This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # architecture (6)
- # beginners (41)
- # boot (4)
- # cider (38)
- # cljsrn (9)
- # clojure (362)
- # 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 (53)
- # 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'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.
@anmonteiro So, I have some cljs which has
:target :nodejs, after startup, it should be of comparable speed to lumo though yes?
if you're asking if speed of compiled JS executed in Node vs CLJS in Lumo is 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
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 :smile:
Hi, is it possible to do an eval of some code and supply some bindings to take effect at the same time?
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.
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
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
In fact, it wouldn't be a bad idea to only launch a socket server in lumo, but auto start unravel for convenience...
the client that talks to the socket server is written in lumo, using node's readline lib (like lumo's repl)
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
in one terminal I run
in the other terminal I run
and I have to say that node is a good environment for network programming and even for cli tools
node's readline module lacks a
^R for reverse-history-search, I'm planning to add that as well
Yeah we do that but it requires lazy-loading of those modules via indirection and such
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
@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
A lot of things don't really support it. So you get more code around wrapping promises.
>>> 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.
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))
@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.
Could do. Yes. It works, most of the time, but it feels… weird to use. Because it's automatic.
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?