This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-01-03
Channels
- # announcements (2)
- # babashka (66)
- # beginners (225)
- # braveandtrue (1)
- # calva (14)
- # circleci (1)
- # clj-kondo (36)
- # cljsrn (3)
- # clojure (423)
- # clojure-finland (7)
- # clojure-nl (1)
- # clojure-spec (14)
- # clojure-survey (41)
- # clojure-sweden (2)
- # clojure-uk (13)
- # clojurescript (59)
- # community-development (10)
- # cursive (2)
- # datascript (14)
- # datomic (63)
- # events (3)
- # expound (8)
- # figwheel-main (6)
- # kaocha (8)
- # luminus (6)
- # malli (1)
- # nrepl (2)
- # off-topic (51)
- # other-lisps (3)
- # reagent (16)
- # shadow-cljs (44)
- # spacemacs (7)
- # sql (22)
- # vrac (1)
multi-methods maybe yes, defprotocol, deftype and reify probably not. Not because I don't want to, but because that's probably not possible
I'm working on a port of spec right now which can be interpreted by babashka which just uses maps instead of protocols
@deleted-user Ah, that's interesting. That might also help the Windows build in that regard
@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
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)
Alternatively we can try to conditionally load an OS-specific namespace by inspecting (System/getProperty "os.name")
another (or combined) approach is to create the OS specific classes namespace also using a script
Might be nice to share your experiences with babashka here: https://clojureverse.org/t/how-do-you-think-of-clojure-like-interpreters-for-scripting/5316
user=> (case os :mac (requiring-resolve 'clojure.string/join))
#'clojure.string/join
ok well, what will work in any case is generating the babashka.impl.classes.os_specific_classes.clj
file using a script
> 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?
Kind of what @sogaiu was hinting at earlier, but now also with the external JVM possibility
the clj-http(-lite) lib has been around for ages, so that would be a good starting point maybe
and we can always bolt on the async http stuff later in the babashka.http(.client) lib
maybe calling the lib babashka.http is best, so we can also add an http server there later
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
or maybe there could just be one library babashka.stdlib which has all of these namespaces
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
?
so cheshire.core/parsed-seq
would become babashka.json/parsed-seq
? that would still mean that we would support everything currently in cheshire
for now, because it's a subset of spec to not surprise people that not everything works
probably not the generator stuff and the fdef stuff also not maybe, but maybe it's possible. we'll have to see
it seems to me most people are going to use it for validation / conforming in scripts, not really for instrumenting