Fork me on GitHub
#chlorine-clover
<
2020-02-20
>
mauricio.szabo12:02:45

Well, after some other bugfixes, I just published Chlorine. It drops Ink, but is still behind experimental features. It seems that it made Atom a little bit faster. When it becomes stable, I'll also add a config to not render the inline results too đŸ™‚

seancorfield12:02:07

I'm testing it by having Chlorine's Experimental Features enabled and Ink Disabled completely. Seems to be working nicely!

seancorfield12:02:57

Of course, then I tried cmd-i cmd-c to clear inline results and it didn't work đŸ™‚ Soon found chlorine:clear-inline-results and bound it to ctrl-; K

mauricio.szabo12:02:33

Great! I remember you told me that there were some glitches while evaluating Clojure code with experimental features on. Please let me know if they still appear

mauricio.szabo12:02:09

I've also double-checked, and there should be no difference between evaluating Clojure with experimental features on or off. Also, I'm trying to find a way to also disable UNREPL (with a config or something) so there are less "moving parts" that I need to be aware of đŸ™‚

seancorfield13:02:11

If you disable unrepl, what features would be tied to that?

seancorfield13:02:51

(I'm pleased by the idea of no longer relying on unrepl -- of course! -- you know my mantra about spartan tooling!)

mauricio.szabo13:02:19

Break evaluation, rendering (things like {(keyword "foo bar") 10} will need treatment), some inspections of Java objects, capturing stdout / stderr, and also long strings / long objects can lock up Atom

mauricio.szabo13:02:43

Also, it'll lose the ability to render infinite sequences (these will also probably lock Atom). Not that these problems do not exist today - they just don't occur with Clojure, but can occur with ClojureScript, Joker, Babashka, Clojerl, ClojureCLR and so on. So maybe not a big deal đŸ™‚

seancorfield13:02:19

I suspect the stdout/stderr capture will be a deal breaker -- test output, for example?

mauricio.szabo14:02:21

Yes, currently I'm analyzing how UNREPL works, so I can replicate parts of its code. So far, I'm getting a StackOverflow error đŸ˜…

mauricio.szabo14:02:43

(just found some errors on invalidation / update / detection of inline results without Ink, I'll check if I can publish a fix)

seancorfield15:02:11

Looks like clear inline results does not clear exception/error output?

seancorfield16:02:04

Hmm, clear inline results do not reliably clear all inline results @mauricio.szabo Sometimes they go away, sometimes they stay around.

mauricio.szabo16:02:40

Yes, it's exactly the problem I'm having

mauricio.szabo16:02:35

Debugging it, it seems that the Atom API is not really reliable on what the "last line" of an inline result. I'll probably just accumulate then all and clear then at once.

seancorfield16:02:53

Sounds good. I'm just left with odd docstring output and exceptions scattered around my files now, until I close & reopen the file đŸ™‚

seancorfield16:02:04

(I can live with that until you figure out a fix)

mauricio.szabo16:02:39

Great, I'll see if I can do a fix today đŸ™‚.