Fork me on GitHub
#babashka
<
2020-01-03
>
borkdude00:01:36

multi-methods maybe yes, defprotocol, deftype and reify probably not. Not because I don't want to, but because that's probably not possible

borkdude00:01:16

I'm working on a port of spec right now which can be interpreted by babashka which just uses maps instead of protocols

borkdude00:01:13

maybe there's a way to avoid using those interfaces?

borkdude00:01:29

gotta go sleep now.. bye!

borkdude07:01:26

@deleted-user Ah, that's interesting. That might also help the Windows build in that regard

borkdude08:01:17

So in classes.clj there should be a conditional based on the operating system

borkdude08:01:34

PR welcome!

borkdude12:01:26

@deleted-user Maybe this approach could work:

user=> (try (Class/forName "java.lang.Exception") (catch Exception _))
java.lang.Exception
user=> (try (Class/forName "java.lang.windows.FooBar") (catch Exception _))
nil

borkdude12:01:52

not sure how graalvm handles that, but worth a try I guess

borkdude12:01:53

There are docs about this here: https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md I'm not sure what will happen if you put those calls at the top-level (which is preferred, because then it's all done at compilation time)

borkdude12:01:38

Alternatively we can try to conditionally load an OS-specific namespace by inspecting (System/getProperty "os.name")

borkdude12:01:56

On my mac that resolves to "Mac OS X"

borkdude12:01:59

maybe the second approach is less hacky

borkdude12:01:10

and also less sensitive to typos

borkdude13:01:06

no, the first approach is Class/forName

borkdude13:01:07

the second approach is requiring a namespace depending on the OS

borkdude13:01:12

which only contains OS-specific classes

borkdude13:01:22

and you merge that into the map in classes.clj

borkdude13:01:57

which will then generate the reflection.json after calling script/compile

borkdude13:01:21

another (or combined) approach is to create the OS specific classes namespace also using a script

borkdude13:01:03

that will be less confusing to graalvm analysis probably

borkdude13:01:33

but the second approach may already work fine

borkdude15:01:52

what is on line 17?

borkdude15:01:22

I think you can use (resolve 'babashka.impl.classes.windows/os-classes)

borkdude15:01:43

or maybe even requiring-resolve

borkdude15:01:55

but that's pretty new

borkdude15:01:40

user=> (case os :mac (requiring-resolve 'clojure.string/join))
#'clojure.string/join

borkdude15:01:39

ok well, what will work in any case is generating the babashka.impl.classes.os_specific_classes.clj file using a script

borkdude15:01:47

and then just require that after it has been generated

borkdude15:01:28

sure 🙂

borkdude17:01:10

> The fact that I can make libraries that work for both babashka and jvm clojure is a huge win. Nicely put. That got me thinking. Maybe we should be having a babashka.http(.client) + babashka.test + babashka.spec.alpha library that you can just use from the JVM and as a built-in in babashka. This would take away the need to include them as libraries on the classpath when using bb, while still being able to run them with the JVM if needed?

borkdude17:01:30

Kind of what @sogaiu was hinting at earlier, but now also with the external JVM possibility

borkdude17:01:19

yeah, it's good to eval these libs for a while and eventually we can incorporate it

borkdude17:01:04

the clj-http(-lite) lib has been around for ages, so that would be a good starting point maybe

borkdude17:01:41

then I could also remove some gnarly classes from the reflection config

borkdude17:01:25

and we can always bolt on the async http stuff later in the babashka.http(.client) lib

borkdude17:01:41

maybe calling the lib babashka.http is best, so we can also add an http server there later

borkdude17:01:59

or just have two different libs

borkdude17:01:04

aaaargh, options

borkdude17:01:44

I mean, the lib could have two namespaces: babashka.http.client and babashka.http.server, but they could also be two separate libs. maybe it doesn't matter

borkdude17:01:06

or maybe there could just be one library babashka.stdlib which has all of these namespaces

borkdude17:01:47

maybe that's not so nice for people who want to use small libs on the JVM

borkdude17:01:57

ok, I'll think about it. dinner time

borkdude18:01:56

Hmm, if clj-http-lite becomes babashka.http.client, should we also rebrand cheshire.core to babashka.json? Or maybe we should just map babashka.http.client to clj-http.client?

borkdude18:01:47

But then the code isn't directly portable anymore. Something to think about

borkdude19:01:37

so cheshire.core/parsed-seq would become babashka.json/parsed-seq? that would still mean that we would support everything currently in cheshire

borkdude19:01:43

(as people are used to a certain API and not to re-invent the wheel for everything)

borkdude19:01:53

(which is a looot of work)

borkdude19:01:00

and rebranding clojure.tools.cli and clojure.data.csv etc... dunno about that

borkdude19:01:10

for now, because it's a subset of spec to not surprise people that not everything works

borkdude19:01:28

it's a working title

borkdude19:01:05

probably not the generator stuff and the fdef stuff also not maybe, but maybe it's possible. we'll have to see

borkdude19:01:36

it seems to me most people are going to use it for validation / conforming in scripts, not really for instrumenting

borkdude19:01:32

I like that idea

borkdude19:01:56

there is also clojure.data.json btw, but cheshire seems more popular. I've never used the former

borkdude19:01:47

go figure 😉

borkdude19:01:04

yeah, spartan.* I guess

borkdude19:01:37

not carved in stone

borkdude19:01:39

any name works