Fork me on GitHub
Slack Archive

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

2020-01-06

Channels

#babashka
<
2020-01-06
>
sogaiu05:01:19

got to the expected error during compilation on windows: https://pastebin.com/5hm68xZM graal 19.3.1 should be out soon (jan 14th or so?) -- hopefully including the fix for the stdlibc++ error

borkdude09:01:59

Is this because of the SSL stuff?

borkdude09:01:03

Does turning it off work?

sogaiu13:01:50

don't remember :) will investigate and report

sogaiu15:01:24

just tested -- looks like that was it (removed the https and related part about security) so there is a bit less to do for a java 8 based build (because the reflection part doesn't need to be altered) compare with: https://github.com/borkdude/babashka/issues/138#issuecomment-562260963

sogaiu16:01:01

the ordinary repl and socket repl started nicely 🙂

sogaiu16:01:22

btw, it appears there is a version of netcat available via scoop

borkdude16:01:32

we don't need netcat anymore

sogaiu16:01:37

i used that to test the socket repl

sogaiu16:01:41

ok, just saying 🙂

borkdude16:01:57

you can now use bb itself to test the socket REPL 🙂

sogaiu16:01:31

yes, that's nice!

borkdude16:01:36

so can the Windows version now run a small script?

sogaiu05:01:56

iiuc, lein with-profile +reflection run did generate a reflection.json, and the compilation process didn't complain about its content.

borkdude10:01:47

After some more testing / feedback I'll write some docs + announcement

borkdude12:01:00

Nice alternative to python -m SimpleHTTPServer

jeroenvandijk15:01:12

Really cool btw!

jeroenvandijk14:01:33

I'm playing with spartan.spec and babashka . I noticed babashka fails when I have commented sections e.g. 

GOOD
(s/def ::short-option any?)

BAD 
(s/def ::short-option any? #_(s/or :nil nil?
                            :v (s/and symbol? #(> 1 (count (str %))))))

borkdude14:01:44

Hmm, that's weird. I'd have to look into that...

borkdude14:01:51

Feel free to post an issue

jeroenvandijk14:01:26

yeah I'm not completely sure yet what it is. I'll investigate more

jeroenvandijk14:01:35

I thought I did 

bb --version
babashka v0.0.61-SNAPSHOT

jeroenvandijk14:01:48

but will test again before posting here

borkdude14:01:07

yeah, I can reproduce it with the master version. but that already has any?

borkdude14:01:05

I think.. 🙂

borkdude14:01:15

Got it: 

$ bb --verbose -cp src -e "(require '[spartan.spec :as s]) (s/def ::short-option #_(s/or :nil nil? :v (s/and symbol? #(> 1 (count (str %)))))) (s/valid? ::short-option :foo)"
java.lang.NullPointerException: null
 at clojure.core$namespace.invokeStatic (core.clj:1603)
    clojure.core$namespace.invoke (core.clj:1597)

borkdude14:01:31

this is a bug in edamame

borkdude14:01:46

@jeroenvandijk Short repro: 

bb --verbose -cp src -e "#_:nil"

borkdude14:01:44

Funny. This works: $ bb '#(:foo)', but this doesn't: $ bb '#(:nil)'

borkdude14:01:31

Aah, it turns out it's not related to uneval at all! bb ':nil' already does the trick

borkdude14:01:59

I think I know why this fails. While parsing keywords, we first parse a colon and then a symbol. But nil is not a valid symbol

borkdude15:01:05

Thanks for finding this edge case

borkdude15:01:04

::nil does work 🙂

metal 4
borkdude15:01:31

so does :nil* which may be a workaround for now

borkdude15:01:36

Printing the name of the Exception would be an improvement, like Nate suggested.

borkdude15:01:43

when a an exception happens

jeroenvandijk15:01:45

I added the ::nil workaround now. Works!

borkdude15:01:02

(NullPointer exceptions do not have a message)

jeroenvandijk15:01:09

Yes I think so too. Without the --verbose option I often don't even realize there is an exception

jeroenvandijk15:01:32

At some point I just start to wonder why I'm getting nil as output 🙈

borkdude15:01:02

if you get an explicit nil as output, then you can be pretty darn sure it's a nullpointer, since a literal nil doesn't get printed as output

borkdude15:01:43

that has confused me also a couple of times

jeroenvandijk15:01:56

TLDR; on above thread we found two issues, but something is working https://gist.github.com/jeroenvandijk/6740c1ef7194cb65d0c6c9c5342273f2 🙂

metal 4
jeroenvandijk15:01:21

I'm noticing there is quite some overhead of the parsing of the options with spartan.spec : 123 ms 

(deftask options
  "Demonstrate the task options DSL."
  [a a-option VAL  kw    "The option."

   ]
  *opts*)
293 ms 
(deftask options
  "Demonstrate the task options DSL."
  [a a-option VAL  kw    "The option."
   c counter       int   "The counter."
   e entry    VAL  sym   "An entrypoint symbol."
   f flag          bool  "Enable flag."
   o o-option VAL  str   "The other option."
   z nil VAL  str   "The other option."
   nil yy VAL  str   "The other option."
   ]
  *opts*)

jeroenvandijk15:01:13

I'm guessing that just the way clojure.spec is implemented in combination with the interpreting parts of sci

borkdude15:01:13

you could try to compare with normal spec on the JVM. I assume it's much faster, but you pay the startup time penalty of 1.5s there

borkdude15:01:06

I envision the following schedule: spartan.spec (= spec1), spartan.spec2 (= spec2), bb with built-in spec2

borkdude15:01:30

the built-in version should be as fast as the JVM one without the startup penalty

borkdude15:01:49

or maybe we could add the things that are not going to change already, but I'm not sure under which namespace and how much guarantees there are about what's not going to change

borkdude15:01:55

@jeroenvandijk 

bb tasks.cljc   0.11s  user 0.04s system 93% cpu 0.154 total
clojure tasks.cljc   2.44s  user 0.25s system 241% cpu 1.115 total

borkdude15:01:11

I assume with a built-in version of spec this is going to be cut in half at least

jeroenvandijk15:01:43

yeah those sound like good options. I'll do some testing with the clj version as well. The parsing of options with spartan.spec versus handwritten code is much nicer and more robust anyway!

borkdude16:01:25

since spec is macro heavy a lot of the code is going to be interpreted anyway, even if it's a builtin I now realize

borkdude16:01:55

but you will save time on not interpreting the code for spartan.spec itself

jeroenvandijk16:01:18

And let's say we have native libs in the future (🤞), you could define the specs in the library and the user would benefit from the precompiled code

jeroenvandijk16:01:01

I'm assuming spartan.spec compiles with GraalVM? That would already be a win for normal clj code compared to clojure.spec

borkdude16:01:34

I assume it does, I don't see why it wouldn't

borkdude16:01:58

@jeroenvandijk Using this lib: https://github.com/borkdude/graal.locking and this patch: https://github.com/taylorwood/clojurl/blob/locking-fix/src/clojurl.clj#L22-L33 you can now also monkey-patch spec and compile with graalvm in clojure 1.10.1

borkdude16:01:37

where locking* should be borkdude.graal.locking/locking if you're using that lib

borkdude16:01:34

basically everything that uses locking has to be patched that way

borkdude16:01:41

and can then be GraalVM compiled

jeroenvandijk18:01:11

Got something working like deftask in boot-clj (needs some more testing) https://gist.github.com/jeroenvandijk/c6cb6cdecfd5aa8e990c3765f3411c0f 

time bb src/adgoji/application/tasks.cljc options -a my-key
:my-key
bb src/adgoji/application/tasks.cljc options -a my-key  0.19s user 0.07s system 95% cpu 0.269 total

👀 4
👍 4