Turns out edamame might not be the right tool for me. At least not for this step in the pipeline. It either rewrites (coerces?) stuff or refuses to deal with them, I’m now experimenting with rewrite-clj instead, which sort of is natural since I want to re-arrange forms w/o rewriting/coercing. I do like the rewrite of #() to (fn []) that edamame gives me automatically, though. I don’t like to be contributing to more use of the function literal.

@pez #() simply isn't expressible as an s-expression, there is no way to keep it as it is

edamame is a tool to read strings to s-expressions / data structures

> refuses to deal with them This should not be the case, you're either using it wrong or there is bug. In both cases I'd like to hear about it ;)

if you want a richer format than s-expressions, and for example, keep whitespace, then rewrite-clj is a tool designed for that purpose. did you know it's also available in babashka? :-D

I think bugs should be relatively rare with edamame since it's used in babashka and I haven't heard of any bugs in the reader in a long time

I didn't mean it as a bug report. More thinking out loud about what tool I needed, and in the process I revealed my lack of understanding of the problem. 😀

rewrite-clj is an excellent tool, I'm a big fan of it

@pez I think @mitesh did a video on how he transformed the 4clojure code with rewrite-clj in fact, for https://github.com/oxalorg/4ever-clojure

https://youtu.be/b7NPKsm8gkc

I've solved my problem using rewrite-clj, maybe I forgot to mention. 😀

yes, you didn't mention that :P

When I get an error while connected to the babashka nrepl, it does print the error message, but I can't seem to get a stack trace, https://gist.github.com/phronmophobic/58b607e48e6ca6d2b82187e6b3d2ddfc I've tried requiring clojure.stacktrace in my main file before compiling with graalvm, but that didn't seem to help.

@smith.adriane what kind of stacktrace did you expect?

can I get the stack trace of the sci code?

I know there are some improvements possible in babashka nrepl here, but the SCI stacktrace as it appears on the console in e.g. babashka when you make a mistake is not a normal Java stacktrace, but a stacktrace from the interpreter.

it is part of the exception info under the key :sci.impl.stacktrace which contains a delay

of probably some useful data

and this needs to be sent to the nREPL client I think

but I haven't worked on that part yet, it's worth investigating a bit if you have time

I want to make this stacktrace public, that's also been a request at https://github.com/oxalorg/4ever-clojure so we can have better errors there

but I just need a few hours to sit down and polish things a bit

ok, no worries. I just wasn’t sure if there was some easy setup I was missing

made an issue for it: https://github.com/babashka/babashka.nrepl/issues/42

heh, Github says sci has exactly 1000 commits in master 🙂

hacked a bit on this https://github.com/viesti/nrepl-cljs-sci, was wondering how to expose js/ forms, for example js/process.version

@viesti you can allow all JS interop by adding {:classes {'js goog/global :allow :all}}

that's really cool btw :)

oh wau, that worked! thanks! 🙂

user=> (with-open [conn (nrepl/connect :port 7788)]
  #_=>   (let [response (nrepl/message (nrepl/client conn 1000) {:op "eval" :code "js/process.version"})]
  #_=>     (println response)))
({:id e36bd792-1152-4d52-bbe6-bce98603ad41, :ns user, :status [done], :value v14.16.0})

@viesti you can even compile this with CLJS advanced and publish to the npm ecosystem as an npm library. And then you can lein repl :connect into your node application ;)

yeah, I tried npm publishing a bit last summer, it was quite nice actually, have to test as local npm dep first before publish 😄

but yes, nrepl into node app would be interesting, have to see what one can do with interop 🙂 I have a one example to test, a https://github.com/viesti/cypress-clojurescript-preprocessor, where the Cypress runner runs the preprocessor as a node subprocess, and at times I wish I could nrepl into it to see what is happening. But even though if this doesn't work for that use, this nrepl server + sci experiment was really cool to make :)

indeed, nREPL can be very handy for runtime inspections, this is how I use it in production as well ;)

🙂

I'm trying to run some code that uses clojure.core.async and take!,`put!`, go, <!, and >! seem to work, but when I try to use alts!, I get: "Assert failed: alts! used not in (go ...) block"

(go
  (alts! [(timeout 300)]))

@smith.adriane the go macro doesn't work (yet) in SCI since it's very complex and relies on tool.analyzer, etc. so it was polyfilled by async/thread instead. Perhaps a bad idea but it allows for some compatibility with existing code

assuming you were using the mappings from babashka

yea

I ended up converting the alts! to alt! and that worked!

so I'm good to go

sorry, should updated when I found a workaround

I'm considering to remove that shim but when I asked feedback most people were ok with it.

as long as you're not creating thousands of go blocks it should be ok

yea, there aren't that many. I'm trying to port https://github.com/shaunlebron/t3tr0s-bare to mobile