Fork me on GitHub
#babashka
<
2019-10-28
>
mauricio.szabo03:10:32

Hi, why does clojure.core/str works but not clojure.core/namespace?

mauricio.szabo03:10:45

For example:

bb=> namespace
#object[clojure.core$namespace 0x7282191a "clojure.core$namespace@56034e7c9220"]
bb=> clojure.core/namespace
Could not resolve symbol: clojure.core/namespace [at line 2, column 1]

borkdude08:10:28

@mauricio.szabo because babashka doesn't have namespaces yet 🙂

borkdude10:10:39

@mauricio.szabo the issues you mentioned yesterday are fixed in 0.0.23

borkdude13:10:30

oh sorry, I see your issue above

borkdude13:10:37

I misunderstood 🙂

borkdude13:10:39

I see the issue @mauricio.szabo: There's a difference between providing values via :bindings and :namespaces. Babashka still uses the :bindings for binding clojure.core stuff that sci doesn't know about by default But you can not refer to these values using clojure.core/..., only unqualified

borkdude13:10:57

This is a bit messy and should be fixed, thanks for notifying me about it

borkdude13:10:41

Here are the default values from clojure.core that are packed with sci: https://github.com/borkdude/sci/blob/master/src/sci/impl/namespaces.cljc Actually namespace could just be added there, I see no problem with that

mauricio.szabo13:10:27

Great, thanks! I found the problem because I was doing some "setup" for evaluating code that could be re-used for multiple REPL envs

borkdude13:10:21

I assume it's not a blocking issue?

mauricio.szabo13:10:21

It is not a blocking issue now that reader conditionals is fixed 🙂. It can just turn things "flaky" if, for example, someone decides to (def namespace ...)

borkdude13:10:56

true, it will be fixed nonetheless

mauricio.szabo13:10:20

But there's still work to be done until I can publish a new version of Chlorine that will support Babashka, so it can wait