it doesn't look like that var is currently 'exposed' - as far as that usage, I think of it as almost two different contexts within the codebase - in my head, there's a "clojure context" where things get compiled and all the clojure vars are available, and there's the "sci context", where the vars available are basically those that are exposed by babashka namespace creation (that's my naive take on it)

so, https://github.com/borkdude/sci/blob/5ed2190f3c97de6d30f3aba96362bf6c68e95e90/src/sci/impl/namespaces.cljc#L741 maps all the symbols that are available in "clojure.core" within bb (as far as I know), and *flush-on-newline* isn't there

I see, thanks. I’ll have to look at how the bb prepl implementation works.

And it looks like the babashka.impl.* namespaces are not available at runtime either - so those are just compiled into the binary?

yes. babashka.impl is implementation anyway. These functions are exposed as different (non-impl) namespaces in bb. e.g. clojure.main is exposed to run a REPL. You can use prepl too.

NextJournal uses the prepl stuff for their purposes

Perhaps @U5H74UNSF can post the code they use in user space for the prepl in a gist?

In Cursive, when it connects to a socket REPL I send some code over to make the REPL work sort of like a prepl, but it’s structured in both directions rather than just one. I’m trying to reproduce that in bb which is where the series of questions are coming from.

issue(s) welcome. proxy support is currently quite limited due to restrictions in graalvm: we can't create new classes at runtime

if you can make multiple smaller issues with small repros, that would be helpful

I will do, thanks.

If you can’t create new classes at runtime, how does proxy work at all?

good question :) bb has intrinsified some usages of proxy so you should consider it unsupported, unless bb explicitly supports it for some use cases / libraries

Ok, I won’t file a bug about that one then

I suspect it’s this https://github.com/borkdude/deps.clj/issues/40

Can you make a repro + issue?

Sure

@U04V15CAJ 👉 https://github.com/babashka/babashka/issues/961

thanks!

You’re welcome to trigger the CI job with different bb versions or tmate dubugging enabled BTW (if it’s possible for someone outside the org to do that)

@U04V15CAJ thanks for taking the time to investigate. Apologies, I should have tried with just clj + git deps, I realise now I had introduced bb + git deps to the project CI at the same time and bb just happened to used first in the build.

no worries. were you able to find the issue?

I have much going on at the same time, sorry if I came across a bit blunt :)

I actually forgot we spoke on slack

No worries! 🙂 Thanks for all your great tools, I’ve been bringing clj-kondo (+ clojure-lsp) and bb into our org recently and really enjoying it. I haven’t gotten to the bottom of it yet no, but it must be something missing from the Github actions environment or something

I could replicate your issue locally with a deps.edn + clojure

Oh really, I couldn’t… strange

It all works perfectly for me locally

Oh wow, that’s very strange… on the real project it works locally but not in GH and on the repro project it doesn’t work locally for me either

perhaps you have and old clojure CLI install?

oh yes, on the repro project

Pretty close to latest locally I think Clojure CLI version 1.10.3.855

but what is strange about the repro project is that you refer to the project itself in the deps.edn right?

Yeah but the real project doesn’t do that but still fails with that error in GH

(not deps.edn, just bb.edn in the repro)

I’ll carry on debugging

try clojure + deps.edn in github perhaps

and see what happens

it fails

you can also set GITLIBS_DEBUG to true

then I believe it will print some stuff

I’m just recreating the same failure with two projects instead of importing the same project

(from: https://clojure.org/reference/deps_and_cli)

cheers for that 👍

https://clojurians.slack.com/archives/CLX41ASCS/p1627447483128500

Edited, sorry - original link was bad.

@cfleming Doesn't load-file do this for you?

No, it doesn’t accept a file name.

I don't understand. The argument is a file name?

Actually, sorry - it does, but that’s not what you need over a REPL since it requires a local file. e.g. the nREPL :load-file op sends the file contents.

Sorry, been a long day and it’s getting late here.

no worries

If you want to be able to connect to a REPL on another machine, load-file doesn’t work. So what’s required is to be able to say “load this file’s worth of code I’m passing, and its filename for metadata purposes is xxx”

let's discuss separately in an issue perhaps, we'll come back to it

perhaps `(binding [*file ...

+ load-string ?

hm

yeah, you could generate that expression perhaps

using binding + *file* and load-string

I’ll try that tomorrow and see how it works.

But the new metadata forms are useful for the case where you’re sending a single form but want the metadata to be right, e.g. you’re sending a single form from the editor to the REPL.

They were added quite recently to Clojure.

Because the previous hack that everyone did was to create a string with a whole bunch of newlines and then spaces and then the actual form, to get the form to start at the right line and column, and then to use Compiler/load

I didn't know about those vars

issue welcome

I can’t for the life of me find the JIRA discussing it.

Discussion here: https://github.com/cursive-ide/cursive/issues/2113. That’s actually the only place I can find any documentation about this. New in 1.10 apparently.

Cool! Can you post these links in an issue?

Will do.

https://github.com/babashka/babashka/issues/960

I was working on a new release of clj-kondo that can do macro-expansion: https://clojurians.slack.com/archives/C06MAR553/p1627470400150500 but I will read your issue later with more attention :)

I’ll try binding *file* and using load-string tomorrow, before filing anything about the file loading thing.

cool