This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-05-20
Channels
- # announcements (16)
- # babashka (104)
- # beginners (77)
- # bristol-clojurians (1)
- # calva (3)
- # chlorine-clover (50)
- # cider (19)
- # clojure (73)
- # clojure-australia (1)
- # clojure-europe (37)
- # clojure-france (3)
- # clojure-nl (3)
- # clojure-norway (13)
- # clojure-spec (21)
- # clojure-uk (79)
- # clojurescript (225)
- # conjure (102)
- # cursive (11)
- # datascript (1)
- # datomic (1)
- # defnpodcast (1)
- # events (3)
- # figwheel-main (2)
- # fulcro (49)
- # ghostwheel (10)
- # helix (1)
- # kaocha (17)
- # leiningen (10)
- # meander (1)
- # off-topic (26)
- # other-lisps (3)
- # pathom (5)
- # re-frame (40)
- # reagent (6)
- # reitit (33)
- # shadow-cljs (107)
- # testing (3)
- # tools-deps (68)
- # xtdb (16)
- # yada (3)
I'm having my first real interaction with sci
this evening, via the new extension machinery in Chlorine, that lets you write editor extensions in Clojure, that are executed via sci
... and I have a question: how do you try/catch exceptions?
I tried (try ... (catch Throwable t ...))
but I get errors that Throwable
is unknown (as has every class name I've tried).
Hmm, (catch Error e ...)
seems acceptable...
Chlorine is probably using the ClojureScript version of Sci @seancorfield. So all interop-ish code should be with the expectations of JavaScript.
@didibus Thanks. That makes sense. I hadn't thought about the Clojure/Script dialect issue. I stumbled across catch Error
pretty much by accident.
Chlorine is using a variant that has special semantics for let
so it does automatic await
on promises, to improve interop with the editor primitives.
I'm digging into getting the oracle jdbc driver working with babashka (potentially a pod-to-be, right now just trying to get the basics working) and running into this:
clojure.lang.ExceptionInfo: Can't call public method of non-public class: public synchronized void oracle.jdbc.driver.PhysicalConnection.close() throws java.sql.SQLException [at /home/mbjarland/projects/clojure/babashka/matias/jdbc-test.clj, line 26, column 3]
when trying to close a connection using next-jdbc
and with-open
. The connection class is actually a T4CConnection
which inherits from PhysicalConnection
and neither of those classes are public (i.e. they are package private). I have run a fairly large number of permutations on the reflection settings (i.e. allDeclaredClasses
, allDeclaredMethods
, etc), recompiling babashka etc including setting all the reflection settings I could find to true for these classes. If anybody knows of a way to fix the above in graalvm it would be much appreciated.should be noted that the query works, just the closing of the connection that fails
I could naturally try to instantiate the class myself etc, but that would not match a normal use case I think
the relevant close method signature:
public synchronized void close() throws SQLException {
i.e. something like this:
(let [ds (jdbc/get-datasource {:jdbcUrl url :user "core" :password "core"})]
(with-open [c (jdbc/get-connection ds)]
(prn :connection c)
(println "result:" (jdbc/execute! c ["select 1 from dual"]))))
there is some code related to private class issues here: https://github.com/borkdude/babashka/blob/9b966920a06e361b98c129ca3fb0f97b5f80176a/src/babashka/impl/classes.clj#L227
but if you are going to make this into a pod, you should not have to run the code through sci/babashka.
right, I'm with your there, I just did a branch with oracle as a feature and completed it to 90% and wanted to see it working before embarking on the next thing
so if the type hint doesn't work (which I think won't since the usage of type hints in sci is not so good yet), then take a look at this: https://clojurians.slack.com/archives/CLX41ASCS/p1589970216129000?thread_ts=1589969930.126200&cid=CLX41ASCS
ah, so I could have something saying if it implements java.sql.Connection
cast it to one
yeah, think so. I think it's better to extend the hsqldb pod code to accommodate more drivers.
so instead of compiling one binary pod.babashka.hsqldb the same code can compile both binaries pod.babashka.oracle, using feature flags similar to bb
also oracle is somewhat of a pain with the reflection stuff and also requires things like this:
"--allow-incomplete-classpath"
"--initialize-at-run-time=oracle.jdbc.driver.OracleTimeoutThreadPerVM"
"--initialize-at-run-time=oracle.sql.LnxLibServer"
"--initialize-at-run-time=oracle.sql.LoadCorejava"
but you are in-line with essentially creating one 'jdbc-pod' based on the hsqldb one which would then compile multiple binaries, one per driver?
PRs to babashka.pod.hsqldb are welcome. we can change the name of the repo eventually
ok, we'll see, I occasionally have to spend time on my day job, but I'll start digging
I'll save the oracle insanity away on a branch for reference. Ok thanks for the input, was stuck on that one for a while
I'm wondering about the performance aspects of shuffling large amounts of data over bencode and stdin etc
Made one change to the async way of working with pods: the :done
callback should be independent from the :success
callback since the :done
message may be sent after the last value has already been sent.
https://github.com/babashka/babashka.pods#async
Last chance for feedback until I release this. Core.async has been removed from pods. cc @retrogradeorbit
I havent had a chance to actually work with the async yet. But the docs look good. I like the simplicity. done being separate from success is good. reminds me of the step/completion seperation in transducers. And of nrepl proto.
One thing I'm still bike-shedding about: should on-success receive the value directly, or a map with :value
so we can add more to it later (prevent breaking)
backwards compatability could be preserved later without a hashmap in the callback by changing the invoke
call itself
like invoke calls back on-success with just the answer. Then later its realised something more must be added. invoke2 calls back with sheep and wood. or :opts :v2. ot :success2 yeah
so you have :error
which does receive a map with :ex-message
, etc. :success
which receives the "naked" return vals and :done
which receives one map with undefined vals currently?
I'm not worried about the implementer not being able to bolt values on. I'm worried about us not being able to bolt new values on. all callbacks currently receive maps which is uniform
just thinking about other event callbacks in other systems, and the success callback is just directly handed the value
we could also have one giant callback which receives all the data possible... just the bencode message basically...
you can also implement invoke as a call to invoke-v2 later with :success (fn [{:keys [value foo]}] (success-v1 value))
on the flipside, its not that big a deal having hashmaps to all. It's not like you are writing a tonne of these.
note that the pod itself won't expose :value
to the caller. it will just provide a wrapper function that does this on behalf of the user and passes the value on to the user's callback (or async channel, if it wishes to work with core async)
example: https://github.com/babashka/pod-babashka-filewatcher/blob/callbacks/src/main.rs#L50-L62
so what the user of that pod sees is:
[path cb opts]
where cb directly gets the valuebut we can make it easier for pod implementers too. just provide the convenience callbacks and one :raw
callback with basically all the data
It will be very common to receive values which probably deserves its own callback, like error and done. Then raw can contain all of these things and more, basically a representation of the bencode response
I am looking to use clojure.zip
from within babashka. I see https://github.com/borkdude/babashka#babashkaclasspath but am unclear exactly how I would bring in clojure.zip with it?
@kolhar730 clojure.zip is part of the latest babashka
Also, I have a bunch of bb
scripts sitting at https://github.com/samedhi/ctci for "Cracking the Coding Interview" that I have done using bb
. I like the instant feedback loop of using bb
+ entr
and just running my test in the ns in which I do the problem. Much appreciated.

@U0532BYNC I mentioned your project here: https://twitter.com/borkdude/status/1263158788367974402
Might make sense to mention how to run them in the README, like with babashka and entr
babashka v0.0.97: https://github.com/borkdude/babashka/releases/tag/v0.0.97 Notable change: asynchronous pod functions may now take callbacks instead of being coupled to core.async. See https://github.com/babashka/babashka.pods#async. One example of a pod taking a callback is the filewatcher pod: https://github.com/babashka/pod-babashka-filewatcher