chlorine-clover 2019-11-05

@sogaiu also, for ClojureCLR the load-file command is not yet supported, that's why it doesn't appear. It doesn't appear also for Joker/bb/Lumo/Plank

for repls without a load file, its best to just load forms one by one?

Probably. Maybe I'll add a function to do it

cool. i'm trying to learn chlorine and it seems quite nice πŸ™‚

Maybe select all then evaluate selection?

πŸ‘ 1

This should work πŸ™‚. I'll probably add a command to it πŸ™‚

(I hope it works on CLJS, unfortunately ClojureScript adds lots of limitations for multiple operations)

fwiw, babashka has load-file

fwiw, for clojure clr, select all followed by evaluate selection doesn't work here:

user=> #object[Namespace 0x12983669 "sample"]
Syntax error (InvalidOperationException) compiling at (REPL:4:642).
Unable to resolve symbol: str in this context
sample=> 
the source of the file is:
(ns sample)

(def a 1)
this seems similar to previous situation -- there is no clojure.core/str yet. possibly the in-ns is occuring before the ns?

here is some output from wireshark's follow tcp stream:

user=> 
#?(:cljs :using-cljs-repl :clj :using-clj-repl :cljr :using-cljr-repl :joker :using-joker-repl :bb :using-bb-repl)
:using-unknown-repl
user=> :using-cljr-repl
user=> :using-unknown-repl
user=> (in-ns 'sample)(try  (clojure.core/let [res (do (ns sample) (def a 1) )  res (clojure.core/cond  #?(:cljs false :default (clojure.core/ratio? res))  (clojure.core/symbol  (clojure.core/str "#repl-tooling/literal-render \""  (clojure.core/pr-str res) "\""))  (clojure.core/symbol? res)  (clojure.core/symbol (clojure.core/str "#unrepl/bad-symbol [nil "  (clojure.core/pr-str (clojure.core/str res))  "]"))  (clojure.core/keyword? res)  (clojure.core/symbol (clojure.core/str "#unrepl/bad-keyword ["  (clojure.core/pr-str (clojure.core/namespace res)) " "  (clojure.core/pr-str (clojure.core/name res))  "]"))  (clojure.core/->> res type str (clojure.core/re-find #"Big(Decimal|Float)"))  (clojure.core/symbol (clojure.core/str "#unrepl/bigdec "res))  (clojure.core/->> res type str (clojure.core/re-find #"BigInt"))  (clojure.core/symbol (clojure.core/str "#unrepl/bigint "res))  :else res)]  ['tooling$eval-res 'G__22 {:result (clojure.core/pr-str res)}])  (catch System.Exception e  ['tooling$eval-res 'G__22 {:error (clojure.core/pr-str e)}])) 
#object[Namespace 0x12983669 "sample"]
Syntax error (InvalidOperationException) compiling at (REPL:4:642).
Unable to resolve symbol: str in this context
sample=> 

it looks like in-ns is happening before the first ns. perhaps the try is compiled in that context and that affects how things (e.g. clojure.core/str) are resolved in its body?

re: beta channel -- i wonder if this could be faked by having a chlorine-beta plugin...i guess that could get messy with settings

I once though about something like that. Problem is that it makes deploy awfully complicated... Like, it is already kinda hard to deploy Chlorine because I need to version all compiled code (well, currently I configured CircleCI to do it)

I could generate a chlorine-beta, but then I would have to or have two repositories, or keep changing the name on package-json so it would deploy to the right place. This could pose a problem to automate

may be it's not worth the trouble then

@mauricio.szabo I just updated to 0.3.1, connected to a Clojure Socket REPL, and can't load file any more (not supported in that type of REPL). Known issue?

(looks like it based on your comments above)

(I just switched my keymap so ctrl-; y is chlorine:connect-socket-repl which seems to work with my REBL setup and load-file does work with that REPL)

Great, any problems tell me πŸ™‚. This new way to connect changes a lot of code on the way to treat the socket connection, so it can be possible to control backpressure on the future πŸ™‚

Yes, there's a problem with that :(

I'll publish a fix

Just got it working again, will publish a new version after the CI run πŸ™‚

πŸ‘ 1

@henrik I think this last release fixes the problem you mentioned too πŸ™‚

ok, load file seems to work after "chlorine: connect socket repl" πŸ‘ this is with 0.3.2 -- that's the latest, right?

Load file worked for me with the generic connect, but not with the Clojure connect, in 0.3.1. Just FYI @sogaiu

(I haven't tried 0.3.2 yet)

i can connect with clojure clr using "chlorine: connect socket repl" πŸ‘ "chlorine: load file" doesn't show up for me in the command palette and "chlorine: evaluate selection" gives me:

Syntax error (InvalidOperationException) compiling at (REPL:5:636).
Unable to resolve symbol: str in this context
when the selection is for (def a 1)

it looks like there is no (ns ...) (or something to arrange for clojure.core to be available) being evaluated before (in-ns ...) -- under those conditions, perhaps clojure.core/str isn't available?

Yes, that's probably the case. I think you need to evaluate the ns form before anything else. I'll see if I can find a solution that doesn't involve creating new namespaces all the time...

(for example, for ClojureScript in lumo or plank there's no way to solve this problem)

(i'm using wireshark to observe the network traffic)

connecting to babashka via "chlorine: connect socket repl" works fine as well as "chlorine: evaluate selection" πŸ™‚

@dpsutton has joined the channel

The new connection method seems to work well! Awesome!

I’m getting some warnings about Reagent (which I don’t have in my CLJS project) when connecting.

And some more when just typing in the current file. (All this in CLJS)

Okay, this is some leaking code, I'll try to fix it too...

This is happening in shadow-cljs, or on some other cljs implementation?

No, this is shadow-cljs. I don’t know if it has anything to do with it, but I run shadow programmatically:

(shadow-server/start!)
(shadow/watch :client)

No, it doesn't. The problem is probably because, on autocomplete, there's lots of evaluation commands being emitted, and outputs can become overlapped

Like, I'm expecting: [<eval-id> <result>]\n and i get: [<eval-id> <result>][<eval-id result>]\n\n

Ah, so it’s being hammered in, not queued

Yes, I'm trying to somehow make a single implementation that's able to ignore these cases. The sad part is that it is really hard to test these issues...

@mauricio.szabo do you need anything special for autocomplete in bb?

All my autocomplete uses ns-mappings, aliases, and other code that inspects the current namespace. As bb doesn't have namespaces, I don't know how it could be implemented...

OK. If users really want it, I can see what can be done about this. But it's already great it works with Chlorine without it. Thanks

Yes, the thing is that when I added support for multiple REPLs, I also configured some commands to return different implementations for known Clojure implementations

The thing that really surprised me is that both ClojureCLR and Joker's autocompletes worked on the first try