Thanks! I have separately compiled jsch tool, but thought it would be nice to somehow combine bb and jsch into single binary

If you can explain more about this I would be open to it

E.g. a link to your repo

It’s not open source now, but basically I connect to remote host by ssh (just for forwarding) but before that I check that 22 port is open and do some basic scripting. It’s a good fit for bb, but I don’t want to use system ssh, so I compiled jsch

Actually problem could be formulated more broadly, If I know that some tool could be graal compiled maybe there is a generic way to use it within bb?

@romantsopin Yes, classes can be added in babashka/impl/classes.clj.

But you cannot use it with an existing version of bb, it has to be compiled together with it

Thank you! Will try it out

check out https://github.com/borkdude/babashka/blob/master/doc/dev.md for some pointers. Note that you have to use git clone --recursive to clone the repo.

Fine with me. We can also do a thread.

Syntax error compiling at (which.clj:12:17).
No such namespace: io

Full report at:
/var/folders/2m/h3cvrr1x4296p315vbk7m32c0000gp/T/clojure-2111109642317177985.edn

use the flag

-d io

you now select which ones you want, if you want to use all of them because you're lazy you can use -d all

if you want to use multiple -d io,str,json

why don't I just get an option to compile my script unmodified? that seems less to think about?

[which:99014]     analysis:  14,457.98 ms
Error: com.oracle.svm.hosted.substitute.DeletedElementException: Unsupported method java.lang.ClassLoader.defineClass(String, byte[], int, int) is reachable: The declaring class of this element has been substituted, but this element is not present in the substitution class

I'll make that an option now

which one are you compiling? the last one you sent?

I was working with this one

This one: https://clojurians.slack.com/archives/CLX41ASCS/p1586726958051700

Can you add H:+ReportExceptionStackTraces to the graalvm options?

oh that just doesn't seem like the way you'd normally write a script, is it?

I'm not sure where the graalvm options go, lemme check

in the jvm-opts of the deps.edn I suppose

no in the options passed to clj native-image

so here: https://github.com/MnRA/nativity/blob/700d3e88c44d54ed1233a90eaddf7e1d75c4eaa7/nativity.clj#L57

oooh I see, like the other -H with the anme

yep

done, I hope

I don't think wrapping all of the code in a large -main is a great idea, but we already discussed that. I think you should leave most things on the top level of the script. I tend to believe that most scripts require a few minor tweaks to make them work with graalvm. E.g. adding type hints to prevent reflection. It will be a major headache on your side to deal with these sorts of issues. Just a project which generates a skeleton in which you can paste your script code and take it from there is what I would go for. This can just be a template for instance on https://clj-templates.com/

I'll try again

Hmm, I'm getting:

Unrecognized option: -H:+ReportExceptionStackTraces
Error: Could not create the Java Virtual Machine.

Yeah I wanna have this quick and dirty version running sorta decent, then I'll make other packaging solutions

maybe it doesn't like the leading space?

I accidentally left another option in the jvm options

already pushed the fix I hope

ok, trying again

so this version is if you just made a bb script with inline stuff really quick and dirty and you have to pass it off to someone else next I'll make the more skeleton version which will leave everything except 1 function out of the main

I keep getting the same exception. I think it doesn't like functions being defined in the -main. When I do this, it works:

borkd[email protected] /tmp $ cp which.clj src/which.clj
[email protected] /tmp $ clj -A:native-image

$ ./which rg
/usr/local/Cellar/ripgrep/12.0.0/bin/rg

yeah it's not meant to use scripts formatted this way

I normally wouldn't add a namespace to a bb script, because, why?

that is pretty common. why not.

I'll make another processing option which just grabs the script as si

You don't need to, since it has the implicit requires..

there's no real point unless you plan on compiling it, or at least I haven't found one

most of your gallery doesn't have a ns, so I assumed that was the common pattern

like I said, the implicit requires are only used for one-liners. e.g. cat foo.json | bb '(json/parse-stream *in*)'. Not for scripts. Although that works, you should NOT rely on it.

for namespaces: you don't have to, but you can use a namespace. and bb libraries will most certainly have them

hmmm okidoke then I'll leave this mode as the one-liner mode, and make another one that leaves it completely untouched

makes sense

There will be other issues, but people can figure those out once they have their generated skeleton, which is the strength of this project imho

oh in that case should I make it keep the source files by default? right now it deletes the generated clj and deps.edn

I think so yes

and new version! that compiles your script by not fucking it up!

Awesome. Maybe we can add some hints to what people can do to make their script compatible with both native-image and babashka itself. Using the which script as an example maybe? - use a namespace form and explicit requires - add (:gen-class) to the namespace form (bb will just ignore this) - add a -main function and call it using a conditional (like the which.clj script).

also adding (set! *warn-on-reflection* true) (which bb also ignores)

I think that will help scripts a lot to be compatible with graalvm

okidoke! I'll add a Hints section to the readme along with examples for each mode

cool! did I miss something or did you miss the clean flag here? https://github.com/MnRA/nativity#clean-files

ah, good catch yeah I forgot to update that

I'm considering making clean remove the .classes and .cpcache directories

And also compatible with Clojure, so no weird errors from clj-kondo 😉

Haha. Too true.

I mean, when we would introduce custom variables for this like joker has, *main-file* or something, this would break clj-kondo

I really appreciate the clojure compatibility as I use clojure to write bb scripts.

I noticed when reading your script repo!

Although bb itself now also has nREPL, that's still a sane approach

I do want to try out bb's nrepl stuff when I give the new conjure a try.

Your project is now the top post on Reddit Clojure 😉

Added a link to your project here: https://github.com/borkdude/babashka/#nativity

Oh wow, how did that happen?

Can you give me the deps.edn you are using so I can try locally?

it could be that you should also bump edamame

project.clj:

(defproject playing "0.1.0-SNAPSHOT"
  :dependencies [[org.clojure/clojure "1.10.1"]
                 [org.clojure/core.async "1.1.587"]
                 [org.clojure/spec.alpha "0.2.187"]
                 [metosin/malli "0.0.1-SNAPSHOT"]
                 [borkdude/sci "0.0.13-alpha.14"]]
  :profiles {:dev {:source-paths ["dev"]
                   :dependencies [[org.clojure/tools.namespace "1.0.0"]]}}
  :global-vars {*warn-on-reflection* true})

Do I need to add edamame?

I've now included [borkdude/edamame "0.0.11-alpha.6"] and it works

Yes, I think malli explicitly depends on an older version. When I add [borkdude/edamame "0.0.11-alpha.6"] it works:

user=> (require '[sci.core :as sci])
nil
user=> (sci/eval-string "(+ 1 2 3)")
6

Oh, so malli won the transitive dependency

Thanks!

also apparently the order matters:

[borkdude/sci "0.0.13-alpha.14"]
                 [metosin/malli "0.0.1-SNAPSHOT"]

in maven it's first come first serve apparently

Yes. I'll just add the latest edamame as a top level dependency.