Fork me on GitHub
#babashka
<
2020-05-08
>
sogaiu00:05:50

saw redbush mentioned in #vim -- there's this piece for bencode in rust: https://github.com/jasilven/redbush/blob/master/src/nrepl/bencode.rs

borkdude06:05:33

I used that. See the issue in that repo

borkdude06:05:33

I asked if he could extract it into a library

borkdude06:05:43

There is one Rust example of a pod already

borkdude06:05:11

but the code is very boilerplatey. I wonder if it can be made nicer with the serde crate

sogaiu06:05:32

i had briefly looked at the examples but didn't realize it was the same code ๐Ÿ˜…

sogaiu06:05:46

i haven't resumed my rust studying yet -- currently trying to absorb c first ๐Ÿ™‚

Crispin10:05:12

I would like to make spire also a pod. Without needing a separate binary build. could there be a way to have babashka launch the existing bin with and arg, say spire --pod?

borkdude11:05:53

The command line option seems good to me

Crispin10:05:57

or maybe by babashka setting the OS environment?

jeroenvandijk10:05:16

You would wrap your spire binary with some babashka wrapper code. I think something goes wrong in the return value

Crispin10:05:42

ok cool. so there could be a pod.epiccastle.spire thatwraps and launches spire.

borkdude11:05:32

No. Spier itself can behave as a pod. Pods can declare their namespaces to babashka. No need to create a wrapper or other binary

๐Ÿ‘ 4
borkdude11:05:59

Sorry for the typo - on mobile

jeroenvandijk10:05:00

I think so. Iโ€™m a bit lost in the protocol. But Iโ€™m guessing this should be possible

jeroenvandijk10:05:23

Iโ€™m very new to this too. I was just trying something ๐Ÿ˜…

borkdude11:05:30

See doc/pods.md and the 4 examples

borkdude11:05:58

The command line option โ€”pod for spire seems good to me

borkdude11:05:20

The pod-babashka-hsqldb might be the best example since itโ€™s more defensive and propagates exceptions to babashka

borkdude11:05:47

I can help but mostly afk today

Crispin11:05:10

All good. need to have a muck around first.

borkdude20:05:35

Updated the hsqldb + clj-kondo example here to use the pod-babashka-hsqldb pod: https://github.com/borkdude/babashka/blob/master/doc/examples.md#find-unused-vars

borkdude20:05:23

Maybe we can add some syntactic sugar as metadata in the ns form for loading pods... On second thought. Probably too much magic for now.

borkdude20:05:48

Not sure about this metadata magic yet. Cc @U0502D2GL

nate20:05:33

hm, wouldn't that make it incompatible with clojure?

borkdude20:05:32

babashka.pods/load-pod would already be incompatible with clojure (unless I release babashka.pods as a library for the JVM, which might be a good idea)

borkdude20:05:47

The above is just adding some metadata on the namespace btw. It's not incompatible with Clojure, you can add any metadata on any namespace.

nate20:05:40

ah, I see what you mean

nate20:05:35

I agree that it might be a good idea to make babashka.pods a library that can be used in the jvm

nate20:05:44

#scopecreep

borkdude20:05:42

what about scope creep?

borkdude20:05:36

pods are all about keeping things outside of babashka ๐Ÿ˜‰

nate20:05:47

haha, too true

nate20:05:55

keep the scope bottled up in pods

borkdude21:05:25

so with scope creep you mean: using metadata adds too much scope or creep?

borkdude21:05:58

I think it might be too much for now. I'll just abandon the idea until someone brings it up again

borkdude21:05:48

It's just that it's nice to have all namespace requires into one ns form and pods kind of break that

nate21:05:13

oh, I'm sorry, I meant that adding the "feature" of making a separate babashka.pods lib and making it compatible with clojure was feature creep

borkdude21:05:08

the code in babashka.impl.pods is nearly JVM compatible with the exception of defining namespaces and interning vars

borkdude21:05:31

so it's really not that much work

nate21:05:54

ah, that's cool