This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (20)
- # babashka (125)
- # beginners (170)
- # calva (1)
- # clojure (102)
- # clojure-europe (1)
- # clojure-nl (13)
- # clojure-uk (5)
- # clojuredesign-podcast (19)
- # code-reviews (10)
- # core-async (9)
- # cursive (7)
- # datomic (8)
- # fulcro (3)
- # malli (5)
- # mount (1)
- # off-topic (23)
- # overtone (1)
- # reagent (2)
- # reitit (2)
- # spacemacs (2)
- # sql (4)
- # tools-deps (5)
*file* wish has come true in v0.0.46:
it would be interesting to see if this is reproducable on linux as well (using the issue I posted)
compilation was successful for me. i checked my java version before and after compiling and made sure to use a java 11 graal, fwiw.
This commit mentions some java nio stuff: https://github.com/oracle/graal/commit/cfef71c13cab78d5fafeaed20ef0828e83503bc1
i guess we are less than a month away from 19.3.1 -- jan 14th (https://www.graalvm.org/docs/release-notes/version-roadmap/)
if i had a better setup, i might consider building off of their current work -- that would let us check whether some of their fixes actually work. i have this feeling that building is likely to be resource and time intensive though...
i think that would be helpful for people trying to test -- don't know how much work that would be for them though...
I was asking about this in the #general channel of their slack, but like you say, it's probably a time consuming rabbit hole
The only reason I'm holding off on adding clj-http.lite is that JDK 11 might add something interesting, it has a built-in HTTP client with async support. But a working JDK 11 might take some time. Do you think it's worth the wait, or shall I go ahead with clj-http.lite?
I guess not, but I don't want to clutter babashka and make too many breaking changes I guess?
Adding support for the raw classes is always an option. I was looking at this lib which leverages the new JDK 11 async stuff: https://github.com/schmee/java-http-clj
if it's not too hard, i wonder if adding some interface whose implementation might be swapped out later might be a possibility.
I think, if anything, http request handling would be a candidate for multiple libs. Simple with http-lite, a sync with the jdk 11 stuff.
on a related note, in general when faced with "should x be added", one of the concerns seems to be "is the specific implementation what we're going to want eventually?". as a hedge against later changes and related incompatibilities, some amount of shielding using an interface might be helpful?
ofc, some thought about the interface becomes necessary...but may be that's not so bad?
@sogaiu Some amount of shielding takes away the option to run the scripts on the JVM
The problem with adding another interface is that makes it babashka only. And compatibility with clojure is a great benefit.
and I want to give people something they're already used to. most people already know clj-http
i guess it would be nice if some of the potential additions could not necessarily be built in.
maybe there can be support for the classes that clj-http-lite uses, so you can make your own implementations that look like it, but it's not so trivial to make it idiomatic for clojure like that library does I think
Adding support for these classes seems the first step: https://github.com/martinklepsch/clj-http-lite/blob/a884410c93e93c7acd8a0cb465c4b28268bf731b/src/clj_http/lite/core.clj#L5
This seems to work so far, except that
defn- doesn't exist yet:
(load-file "/Users/borkdude/Downloads/clj_http_lite_core.clj") #'clj-http.lite.core/request
I found several issues in sci that I will fix later, e.g. the absence of defn- and some ns form parsing error
so apart from git pull, switching to the jdk-url branch and git submodule update, is there some other prep i need to do?
because i get:
Syntax error (ClassNotFoundException) compiling at (babashka/impl/classes.clj:153:16). javax.xml.bind.DatatypeConverter
I can probably get rid of that class though: https://github.com/borkdude/clj-http-lite/blob/babashka/src/clj_http/lite/util.clj#L31
it seems java.util.Base64 was added in jdk 8(?) and is the way of the future regarding base64 in java iiuc
may be i can grumble a bit about how the reader conditionals for clojure don't feel like an "open system" 🙂
do you know if things other than :clj, :cljr, :cljs, and :default are just ignored by the various implementations?
Btw, adding more and more classes to the reflection config does make the binary a little bigger every time. It has grown about 5MB since the last few releases. I'm not sure if I should worry about that. Zipped it's still around 10MB.
Awesome article mentioning several Clojure "startup" solutions: https://stuartsierra.com/2019/12/21/clojure-start-time-in-2019
Why would that be useful to you? And do you have any ideas on how to implement this?
I would love that so much. I could distribute binaries onto a remote system without needing a runtime
you can already do this with clojurescript and pkg https://github.com/zeit/pkg
I am writing a script and getting delusions of grandeur that others might want to easily install and use it.
no idea how to implement except maybe automating a process which writes scripts into static strings that get compiled into graalvm-produced binary.
This looks like a relevant article: https://unix.stackexchange.com/questions/287032/combining-bash-script-and-script-resources-into-one-executable
Just scp-ing a zip file with all the stuff in it, unzipping it and then run it might not be too bad. You could probably even write a script for it 😉
i wonder whether there's some stuff here: https://github.com/BrunoBonacci/lein-binplus that might be usefully applied to this situation
:status 403 :message You have triggered an abuse detection mechanism. Please wait a few minutes before you try again. 😁
Cool, thanks! I saw your PR. I wasn't sure if you used the
./update-babashka script, so I just did it myself.
Next time if I forget to update the brew package, just throw a message in the channel
It's easier for me to run the script than to accept a PR, because I have to check it anyway 🙂