This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-10
Channels
- # adventofcode (76)
- # announcements (7)
- # aws (3)
- # babashka (75)
- # beginners (25)
- # calva (37)
- # cider (9)
- # clara (4)
- # clj-kondo (17)
- # cljsrn (1)
- # clojure (106)
- # clojure-europe (4)
- # clojure-india (2)
- # clojure-italy (12)
- # clojure-nl (27)
- # clojure-spec (33)
- # clojure-uk (20)
- # clojurescript (103)
- # clojutre (3)
- # core-async (1)
- # cryogen (10)
- # cursive (24)
- # datomic (113)
- # dirac (5)
- # emacs (12)
- # events (4)
- # fulcro (64)
- # garden (5)
- # jobs (1)
- # kaocha (5)
- # luminus (2)
- # malli (14)
- # off-topic (53)
- # planck (11)
- # re-frame (9)
- # reagent (16)
- # reitit (26)
- # remote-jobs (2)
- # shadow-cljs (137)
- # spacemacs (34)
came across this today: https://github.com/tools4j/unix4j
Most of my scripts need json, http calls and possibly aws stuff. How difficult would it be to add e.g. cheshire, clj-http and aws-api?
ahah yeah I'm used to it, living in Singapore, not exactly the most common timezone in clojurians π
It seems simple enough to modify reflection.json
and :classes
in main.clj
, but I'm guessing it depends if those libs play well with graalvm
yes -- the difficulty varies. on a related note, iiuc, borkdude is working on some method of loading code at runtime. it may be that some things will be doable via whatever he comes up with. i'm confident he'll have a better answer than my attempt here π
Http: slurp works, but maybe adding clj-http or something would be nice. Of course you can also shell out to curl or use bash and bb inline
aws seems a bit too specific for a general purpose tool, maybe that deserves its own cli
Adding cheshire would be enough to use curl with json payloads in a relatively simple way
I haven't, but I'm more interested in using babashka by itself than calling it inline with bash. I also don't want to ask my coworkers to install/learn more than one extra tool
Yep, understandable. Iβm adding Cheshire in the next release then, probably this week
It looks like ClojureD is going to be a devops + shell scripting feast. @rahul080327 with bob, dundalek with closh and me with babashka all in the same room after each other π
@dromar56 added cheshire: <https://github.com/borkdude/babashka/releases/tag/v0.0.40>
$ bb '(json/parse-string "{\"foo bar\": 1}" (fn [x] (keyword (str/replace x " " "_"))))'
{:foo_bar 1}
looks good here too:
$ ./bb '(json/parse-string "{\"foo bar\": 1}" (fn [x] (keyword (str/replace x " " "_"))))'
{:foo_bar 1}
$ java -version
openjdk version "1.8.0_222"
OpenJDK Runtime Environment (build 1.8.0_222-8u222-b10-1ubuntu1~16.04.1-b10)
OpenJDK 64-Bit Server VM (build 25.222-b10, mixed mode)
Error: Error parsing reflection configuration in /home/nate/projects/babashka/reflection.json:
Could not resolve java.lang.UNIXProcess for reflection configuration. To allow unresolvable reflection configuration, use option -H:+AllowIncompleteClasspath
Verify that the configuration matches the schema described in the -H:PrintFlags=+ output for option ReflectionConfigurationFiles.
com.oracle.svm.core.util.UserError$UserException: Error parsing reflection configuration in /home/nate/projects/babashka/reflection.json:
Could not resolve java.lang.UNIXProcess for reflection configuration. To allow unresolvable reflection configuration, use option -H:+AllowIncompleteClasspath
Verify that the configuration matches the schema described in the -H:PrintFlags=+ output for option ReflectionConfigurationFiles.
here's running it via the uberjar:
$ java -jar target/babashka-0.0.41-SNAPSHOT-standalone.jar -e '(jt/local-time "HH:mm" "08:14")'
#object[java.time.LocalTime 0x70d63e05 "08:14"]
and via the binary:
$ ./bb -e '(jt/local-time "HH:mm" "08:14")'
java_time.graph.Types cannot be cast to java.lang.Comparable [at line 1, column 1]
$ ./bb --verbose -e '(jt/local-time "HH:mm" "08:14")'
clojure.lang.ExceptionInfo: java_time.graph.Types cannot be cast to java.lang.Comparable [at line 1, column 1]
{:type :sci/error, :row 1, :col 1, :message "java_time.graph.Types cannot be cast to java.lang.Comparable [at line 1, column 1]"}
at sci.impl.utils$rethrow_with_location_of_node.invokeStatic (utils.cljc:67)
sci.impl.interpreter$eval_call.invokeStatic (interpreter.cljc:357)
sci.impl.interpreter$interpret.invokeStatic (interpreter.cljc:391)
sci.impl.interpreter$eval_form.invokeStatic (interpreter.cljc:423)
sci.impl.interpreter$eval_string_STAR_.invokeStatic (interpreter.cljc:443)
sci.impl.interpreter$eval_string.invokeStatic (interpreter.cljc:450)
sci.core$eval_string.invokeStatic (core.cljc:131)
babashka.impl.utils$eval_string.invokeStatic (utils.clj:5)
babashka.main$main$fn__12674.invoke (main.clj:303)
babashka.main$main.invokeStatic (main.clj:296)
babashka.main$main.doInvoke (main.clj:187)
clojure.lang.RestFn.applyTo (RestFn.java:137)
clojure.core$apply.invokeStatic (core.clj:665)
babashka.main$_main.invokeStatic (main.clj:336)
babashka.main$_main.doInvoke (main.clj:336)
clojure.lang.RestFn.applyTo (RestFn.java:137)
babashka.main.main (:-1)
https://github.com/justone/babashka/tree/java-time is my in-progress tree
@U0510902N It could be that java-time uses reflection of some sort. It could be worth vendoring its source code and plug in some (set! *warn-on-reflection* true)
s if they are not there yet
don't know yet how I feel about this library. using clojure in the name is something that's culturally only reserved for official clojure libs. the single segment namespace name... and the code seems quite complex for something that should be relatively straightforward?
I thought it was going to be a thinner wrapper, but then I dove into the source this morning and saw that there's a decent amount of cleverness
writing pure Java is maybe not so horrible?
user=> (java.time.LocalTime/of 10 0)
#object[java.time.LocalTime 0x487db668 "10:00"]
user=> (java.time.LocalTime/parse "10:00")
#object[java.time.LocalTime 0x487db668 "10:00"]
I needed to parse a RFC_1123 date time, which I could only do in java.time, and then I had to convert it to a java.util.Date and then to a joda time date because the rest of our code expects that π
(->
date-text
(java.time.ZonedDateTime/parse java.time.format.DateTimeFormatter/RFC_1123_DATE_TIME)
(.toInstant)
(java.util.Date/from)
(tc/from-date))
vs:
(-> (jt/zoned-date-time (jt/formatter :rfc-1123-date-time) date-text)
(jt/to-java-date)
(tc/from-date))
java_time.graph.Types cannot be cast to java.lang.Comparable
It seems that thing doesn't implement Comparable:
https://github.com/dm3/clojure.java-time/blob/707f16daf19e04cf182cc532a2cce8db170ea178/src/java_time/graph.clj#L26
But not sure why this manifests only in native imagecould also be the result of some reflection thing, so I would first try to check that
cool, I'll open an issue to track progress, and when I get to trying out the reflection stuff, I'll ping it
I forked the repo and put :global-vars {*warn-on-reflection* true}
in project.clj.
There doesn't seem to be any reflection going on
Small quick POC / repro:
(ns time.core
(:gen-class)
(:require [java-time :as jt]))
(defn -main [& args]
(println (jt/local-time))
(println (jt/local-time "HH:mm" "08:14")))
$ native-image --no-server --no-fallback --initialize-at-build-time -jar target/time-0.1.0-SNAPSHOT-standalone.jar
$ ./time-0.1.0-SNAPSHOT-standalone
#object[java.time.LocalTime 0x4ce83ffe 23:13:22.667300]
Exception in thread "main" java.lang.ClassCastException: java_time.graph.Types cannot be cast to java.lang.Comparable
Btw, this library also seems popular and based on Java time: https://github.com/juxt/tick
It also seems to have quite good docs: https://juxt.pro/tick/docs/index.html
@U09LZR36F Have you tried tick with graal?
Not at all. I don't think it uses reflection though, I'm pretty sure it uses code generation.
I might be able to influence that away. There's not any real reason for that I think.