Fork me on GitHub
#babashka-sci-dev
<
2022-02-16
>
Crispin09:02:19

Doing the pod work on spire and there's an interesting little difference that I'm not sure of how best to tackle. When the script is run under sci, inside spire, I naughtily deref sci.impl.vars/current-file to get a string representation of the present file being processed by sci.

Crispin09:02:01

On the pod side (that is the clojure code I send to the pod with the describe step to be evaluated by bb) I rewrite this function to use *file*

Crispin09:02:21

the difference is sci.impl.vars/current-file gives me a relative path. And *file* gives me a full path (like clojure does). Is there a sneaky way to get a relative path of the currently executing bb file?

borkdude09:02:53

You naughty boy! :). I think a less naughty way of doing this would be to use sci.core/file

borkdude09:02:05

if the behavior is different than JVM Clojure, then I consider that a bug. please report using a repro it so we can fix it

borkdude09:02:59

@retrogradeorbit but thinking more about it, I don't think SCI binds the value of file itself, this is always done by the environment using SCI, so you should probably take care of this yourself?

Crispin10:02:28

ah thats interesting. That would explain why its relative. I would be binding to that. It's been a while I looked in these guts...

Crispin10:02:06

is sci.core/file available inside bb?

Crispin10:02:23

I need something inside bb if there is one

borkdude10:02:47

in bb this var is just *file*

borkdude10:02:44

so in bb you would do it exactly like in clojure:

(binding [*file* ...] ...)
and outside of the env you would do it via SCI:
(sci/binding [sci/file ...] ...)

Crispin10:02:26

yeah... I need that relative.

Crispin10:02:34

maybe I just need to relativise it

Crispin10:02:29

(it just needs to be relative for printing purposes...)

Crispin10:02:18

yep I am binding to sci/file in my sci implementation

Crispin10:02:08

and then I rebind in my load-file implementation.

borkdude10:02:14

sounds good!