Fork me on GitHub

Turns out that zprint is (mostly) compatible with babashka :)

šŸŽ‰ 3
bananadance 1

Also the expectations library (need to define clojure-version only for the tests)

$ BABASHKA_PRELOADS="(intern 'clojure.core 'clojure-version (fn []))" bb test:bb

Testing expectations.clojure.test-test

Running inline tests

Ran 22 tests containing 82 assertions.
0 failures, 0 errors.

šŸŽ‰ 1

Adding clojure-version now for next release


And hugsql.core sqlvec fns also works in babashka :) (from the next release on)

(deftest sqlvec-test
  (is (= ["select name, specialty from characters\nwhere id in (?,?)" 1 2]
         (characters-by-ids-specify-cols-sqlvec {:ids [1 2], :cols ["name" "specialty"]}))))

šŸ‘ 2
šŸŽ‰ 2

$ bb -e '(clojure-version)'
$ bb -e '*clojure-version*'
{:major 1, :minor 11, :incremental 0, :qualifier "beta1-SCI"}


I'm very to close to making specter run from source now...

Ran 135 tests containing 465 assertions.
0 failures, 6 errors.
{:test 135, :pass 459, :fail 0, :error 6, :type :summary}
Just a nasty reflection issue in a combination of clojure.lang.IReduce and clojure.lang.IReduceInit + reify

šŸ¤Æ 1

thanks for keep making babashka more and more awesome šŸ™‚

Sam Ritchie23:03:48

Deftype is off the table for babashka, right? Just double checking

Bob B03:03:51

as I understand it, deftype dynamically defines a new Java class, and GraalVM doesn't allow for the creation (as in definition) of classes at runtime, so they're incompatible

Sam Ritchie05:03:46

interesting, I have deftypes all over #sicmutils but Iā€™d be happy to compile classes instead, or use some form graal, js and jvm would be happy with. Is there an alternative?


Deftype isn't implemented since people usually use it for low level stuff and implement more than 1 java interfaces in them which is hard to support since you need to know all combinations at babashka compile time. Defrecord is the closest alternative


We could add support for a subset of deftype usages, but it would have the same restriction as defrecord: only 1 Java interface may be implemented at a time


Wait, I thought #sicmutils already worked on #sci? Have I missed something?


It works with SCI bindings, but this is a different usage than running it entirely from source in SCI


You can make almost any library work by plugging in the right SCI bindings


Ah, ok. So the deftypes don't actually run in sci. Thanks for explaining šŸ‘


yes. we could support deftype for some cases, similar to how we support defrecord but usually people implement all kinds of interfaces on those things that make it very hard to pull it off correctly

šŸ‘ 1
Sam Ritchie16:03:38

In sicmutils the usual pattern is to make something feel like a vector, but override IFn and add more SICM-specific protocols


that might be supported

Sam Ritchie16:03:46

Okay, I'll make a task to get the full list of deftypes together and we'll see what we can do


$ bb -e '(def x (reify clojure.lang.IFn (invoke [_] :dude))) (x)'


on records it doesn't work currently I think

Sam Ritchie14:03:55

here is the sort of thing @U04V15CAJ that we are dealing with. most look very similar to this

Sam Ritchie14:03:41

I also wanted to ask if you have a suggested way that I could incrementally make this conversion; for example, make a, or something and start growing up toward sicmutils.env


That sort of deftype is similar to the one from instaparse: it implements a bunch of stuff to make it a custom data structure with lots of interfaces which isn't possible in bb.


You can use either reader conditionals, :bb or the .bb extension to override code for bb


bb accepts both :clj and :bb reader conditionals, if you are using :bb you must place it before the :clj one

Sam Ritchie14:03:53

Is the answer perhaps to write the class in Java?


Babashka cannot execute Java classes


The answer, if you want to make your code bb compatible, is probably to use reader conditionals and support a subset


or you could write a pod that you can load from babashka, that's also an option. I don't know enough about SICMutils API to say if that's a good fit


Pods's arguments are serialized as json, edn or transit.


If you want to serialize functions, that's usually a problem


So maybe the subset approach could work. In your Structure example, this would mean: implement Structure as a record and remove the non-protocol implementations except Object using :bb reader conditionals