I got pretty close with "yyyy-MM-dd'T'HH:mm:ss[.SSS]ZZZZZ" pattern + parseBest but rfc3339 includes leap seconds which means seconds can go to 60 and causes it to fail 😞

Leap seconds are only valid at certain times, the end of June or December, have you been testing your parsering with date times where leap seconds are valid?

Testing with 1990-12-31T15:59:60-08:00

Execution error (DateTimeException) at java.time.temporal.ValueRange/checkValidIntValue (ValueRange.java:330).
Invalid value for SecondOfMinute (valid values 0 - 59): 60

Hmm https://stackoverflow.com/questions/55304194/java-instant-parse-on-date-java-8/55310635#55310635

> java.time does support the parsing of a (valid) leap second.

I think this works!

(.withResolverStyle
  (DateTimeFormatter/ofPattern "yyyy-MM-dd'T'HH:mm:ss[.SSS]ZZZZZ")
  ResolverStyle/LENIENT)

For those interested, this is the final code that seems to work with all my examples

(def rfc-3339-formatter
  (.withResolverStyle
    (DateTimeFormatter/ofPattern "yyyy-MM-dd'T'HH:mm:ss[.SSS]ZZZZZ")
    ResolverStyle/LENIENT))

(defn parse-rfc-3339-to-instant
  [date-string]
  (-> (LocalDateTime/parse date-string rfc-3339-formatter)
      (.atZone (ZoneId/of "UTC"))
      (.toInstant)))

Just use keyword?

Try #tools-deps channel But i know that by design, all auth settings are on git.

Thanks for the pointer to the #tools-deps channel 🙂

you are mixing lazy sequences (map) with side effects (swap!), this is very very bad

use run! instead of map

great recommendation

Because we are talking about this, I am using async and I use map. Should I use run! instead for the following example?

(defn upsert-legs!
  [legs]
  (let [leg-chan (chan 1024)
        match-chan (chan 1024)
        upsert-chan (chan 1024)]
    (onto-chan leg-chan legs)
    (pipeline-blocking 16 match-chan (map match-leg) leg-chan)
    (pipeline-blocking 16 upsert-chan (map upsert-leg!) match-chan)))

ah, thats not lazy sequences, thats transducers

makes sense

System/in is InputStream, you should be able to use it for reading

yay, that worked!

$ echo "{:a 1}" | jet --to transit | ./bb '(transit/read (transit/reader System/in :json))'
{:a 1}

here is how you detect, that something was passed on stdin: https://github.com/xsc/lein-ancient/commit/9c973ce589f09c1ef026a92d112e5ad74911e881#diff-49011372f9f79f94fddac7b48e625774R170-R171

thanks. that's good to know

Spec is a great use case for this! I do that in my defn-spec library https://github.com/Provisdom/defn-spec/blob/f0dd33d9b16674a2f1209a19f02ccb9eb2ca037f/src/defn_spec/core.cljc#L35

good point actually there's a lot in clojure.core, I'll check out sci next, thanks!

(I just stole the destructure implementation in sci for something else actually) 🙂

that implementation was stolen from clojure.core in the first place

yeah I figured

a combination of clojure.core and cljs.core actually. sometimes I find the code in cljs.core a little bit clearer

I didn't actually look how close they were. Just needed it to work on pure cljs

then you might as well copy it from clojurescript

If you import the relevant Java class (e.g., ExpectedFooClass), you can provide a hint to your function call: (CIs/foo ^ExpectedFooClass foo)

Alternatively, if foo is being passed in as an argument, you can provide the hint there:

(defn foo-wrapper [^ExpectedFooClass foo]
  (CIs/foo foo))

the problem is somehow in Cls/foo itself. it's static method inherited from ClsSuper/foo and it's looking up the caller stack to make sure Cls extends ClsSuper but somehow fails that check. clojure uses invokeStatic to call Cls/foo and that makes it not be in the stacktrace somehow? i don't know..

at com.almasb.fxgl.app.GameApplication.launch(GameApplication.java:62) at xyz$eval6024.invokeStatic(form-init1514362494284450037.clj:19) supposedly there should be a line with Cls.launch in between here, right?

GameApplication is the "ClsSuper" here

no of course there shouldn't be, i don't override .launch

I strongly suspect that if the lib relies on implementation details of how java implements inheritance and superclass method invocation, the simplest and least error prone thing is to write a java stub that invokes clojure functions in all its method bodies

each method would use clojure.java.api.Clojure to look up an ns and call a function https://clojure.org/reference/java_interop#_calling_clojure_from_java

or just write it all in java if that's easier

just in case anybody else stumbles across this, the problem was in implicit assumption that caller of .launch is a class that extends a certain super, which it is not if .launch is invoked directly from clojure code

If you’re looking for UI-building tools, these are the two I’m aware of : https://github.com/fulcrologic/fulcro-native, https://github.com/drapanjanas/re-natal

(both based on React Native)

so it's cljs/react rather than clj/java?

Correct

how different is it to work with as somebody only used to desktop java clojure?

I’d assume very. But I’m assuming desktop java clojure involves a lot of imperative code. Do you use a particular library or framework for desktop java/clojure UI dev?

well, I mostly write CLI apps on the desktop, but I've used seesaw for UI in the past

I'm mostly thinking in terms of actual language differences/workflow

react native is pretty different in terms of work flow

there’s a whole other React Native toolchain you use, along with the ClojureScript toolchain

that being said, it’s pretty useful to know. you can currently build UIs for windows, macOS, iOS and Android with React Native, and it gets more feature complete and advanced as time goes on

ah, ok

is cljs + react native the current best way to build clojure apps for android then?

yes, i would say so

fundamentally, getting clojure to run on android is difficult; there are differences between mainstream JVMs and the android runtime. and the Clojure startup time is a big UX problem on smaller devices

alright, thanls

If you only worked with Java, adjusting to JavaScript as host might require some learning. That being said React Native + shadow.cljs is becoming really nice app-development platform. Resulting applications also work quite nice, and there’s more and more useful bridges to native code. The biggest problem, probably, is that you’re gonna have to read documentations and issues of JavaScript tools, you might not be familiar with