Adding a new nice feature to the console REPL: tailtip completions
Planned release: Tuesday morning
Just tested. Thank you!!
Now my Rebel Readline muscle memory can continue unhindered 🙂
You may want to try this out with the dev build folks. I added many REPL niceties but I hope nothing broke.
bash <(curl ) --dev-build --dir /tmp
/tmp/bb
cc @lee @seancorfield @highpressurecarsalesm and anyone else who want to test doc support (C-x C-x), eldoc (signature shows while you type) and trailtip completionsC-x C-d for docs, you mean?
yes sorry
after the function name
Works great!
Would be nice to have C-x C-m to submit the whole expression for evaluation -- when you are doing mult-line editing, otherwise you have to navigate to the end of the form to press ENTER
(I guess I can use alt-a...)
Ctrl-e
that works in browsers etc too
I actually just changed this behavior. Normally the whole form would be submitted when you would press enter. But then there's no way to insert whitespace in the middle with enter, unless you use Alt-Enter. But Alt-Enter was already used on Windows to maximize the window. Do you prefer that I revert this?
No, I'm used to being able to enter newlines with enter in the middle of editing (like Rebel).
Ah wait, I actually just discovered that rebel-readline also doesn't submit
nice
But I'm also used to C-x C-m from Rebel. Knowing there's C-e is good enough for now.
ok
keyword completion is coming up
that's probably the final thing
Ah, C-e ENTER -- because C-e moves the cursor to the end (of the multi-line expression). C-x C-m in Rebel just submits the whole thing, no matter where you are.
correct
I'm fine with adopting that
Hard to tell what's Jline vs Rebel 🙂
does it not currently work?
then it's not jline
Right. C-e is jline (then press ENTER). C-x C-m is Rebel.
Merged keyword completions. Available in 10 minutes as dev build
should be there now
Oh, the keyword completion is a nice touch! I didn't know I needed that.
Wowzies! Feels great @borkdude!
After merging ^ I think bb has enough new stuff for a release...
This is going to be the most exciting release in a while!!!
I'm continuing to do some odd things, pencilling quite far outside the lines. Here's an odd question: I have a script that loads classes from an AOT jar. Why? For most operations, I want fast startup of Babashka, but for one particular thing (this long running web server), I have the Babashka script launch a Java process to run that code. Oddity: when I run my script, there's a bunch of extra stuff on the classpath.
$ pwd
/tmp/build
$ ll
.rw-r--r-- 64 howard.lewisship 13 Feb 11:14 bb.edn
.rw-r--r-- 948 howard.lewisship 13 Feb 11:14 CHANGES.md
.rwxr-xr-x 159 howard.lewisship 13 Feb 11:25 dgt
.rw-r--r-- 14M howard.lewisship 13 Feb 11:14 dialog-tool-test.jar
.rw-r--r-- 11k howard.lewisship 13 Feb 11:14 LICENSE
.rw-r--r-- 9.2k howard.lewisship 13 Feb 11:14 README.md
$ cat dgt
#!/usr/bin/env bb
(require '[dialog-tool.main :as main])
(prn :bb-classpath (babashka.classpath/get-classpath))
(apply main/-main *command-line-args*)
$ cat bb.edn
{:deps {uber/dialog-tool {:local/root "dialog-tool-test.jar"}}}
$ ./dgt version
:bb-classpath "/private/tmp/build/dialog-tool-test.jar:/Users/howard.lewisship/.m2/repository/babashka/fs/0.5.27/fs-0.5.27.jar:/Users/howard.lewisship/.m2/repository/babashka/process/0.6.23/process-0.6.23.jar:/Users/howard.lewisship/.m2/repository/org/babashka/cli/0.8.67/cli-0.8.67.jar:/Users/howard.lewisship/.m2/repository/org/clj-commons/humanize/1.1/humanize-1.1.jar:/Users/howard.lewisship/.m2/repository/org/clj-commons/pretty/3.6.7/pretty-3.6.7.jar:/Users/howard.lewisship/.m2/repository/org/clojure/tools.cli/1.2.245/tools.cli-1.2.245.jar:/Users/howard.lewisship/.m2/repository/selmer/selmer/1.12.69/selmer-1.12.69.jar:/Users/howard.lewisship/.m2/repository/com/widdindustries/cljc.java-time/0.1.21/cljc.java-time-0.1.21.jar:/Users/howard.lewisship/.m2/repository/com/widdindustries/cljs.java-time/0.1.20/cljs.java-time-0.1.20.jar"
test
The dialog-tool-test.jar should be the only thing on the classpath, so where are the rest coming from? Some of these seem specific-ish to my project (humanize, pretty), but not the others.
So I don't get why those particular things are present on the classpath? Did some kind of dependency information get recorded into the uberjar? These are not in my dgt script downloads them. I'm at a loss as to where these things could be coming from.It depends. in what directory do you run dgt
does it have a bb.edn
Yes, I copied things to /tmp and executed from there. You can see the bb.edn above. It's just the one dependency.
does dialog-tool-test.jar have those dependencies? I don't know if jars can have dependencies in deps.edn - doesn't make sense right? what happens if you don't load this local root thing
$ ./dgt -h
----- Error --------------------------------------------------------------------
Type: java.io.FileNotFoundException
Message: Could not locate dialog_tool/main.bb, dialog_tool/main.clj or dialog_tool/main.cljc on classpath.
Location: /private/tmp/build/./dgt:3:1
I mean, what does bb-classpath print in that case
$ ./dgt
:bb-classpath "/Users/howard.lewisship/workspaces/dialog/dialog-tool/src:/Users/howard.lewisship/workspaces/dialog/dialog-tool/generated-resources:/Users/howard.lewisship/workspaces/dialog/dialog-tool/resources:/Users/howard.lewisship/.m2/repository/io/github/hlship/cli-tools/0.16.0-beta-3/cli-tools-0.16.0-beta-3.jar:/Users/howard.lewisship/.m2/repository/org/clj-commons/humanize/1.1/humanize-1.1.jar:/Users/howard.lewisship/.m2/repository/org/clj-commons/pretty/3.6.7/pretty-3.6.7.jar:/Users/howard.lewisship/.m2/repository/com/widdindustries/cljc.java-time/0.1.21/cljc.java-time-0.1.21.jar:/Users/howard.lewisship/.m2/repository/com/widdindustries/cljs.java-time/0.1.20/cljs.java-time-0.1.20.jar"
If I'm in /tmp, where else would Babashka be looking for bb.edn files?
Ok, if I remove the bb.edn file entirely, then I get:
:bb-classpath nil
bb only looks for a bb.edn in the current directory
have to run out for a bit ...
no wait, this isn't the full answer. bb looks at bb.edns adjacent to scripts that you execute
and else in the current directory
ok talk later
It's really strange, like, even if it worked up from current dir looking for bb.edn it doesn't make sense
that it certainly won't do
I don't like mysteries. Almost certainly something on my system , but what. Any debugging I can enable?
• can you try from another directory not in tmp? tmp may be weird since its a symlinked dir (on mac). • what happens in a regular clojure JVM project when you depend on that local/root jar?
Invoking jar via Java, only that jar on class path (as per Java.class.path sys property)
that's not what I asked
I mean with deps.edn
sorry for not being clear
I'm out to lunch so it'll be a bit.
np
Ok, so if I rename bb.edn to deps.edn ...
$ clojure -Srepro -Stree
org.clojure/clojure 1.12.4
. org.clojure/spec.alpha 0.5.238
. org.clojure/core.specs.alpha 0.4.74
uber/dialog-tool /Users/howard.lewisship/workspaces/dialog/dialog-tool/out/build/dialog-tool-test.jar
. selmer/selmer 1.12.69
. org.clojure/tools.cli 1.2.245
. org.babashka/cli 0.8.67
. babashka/process 0.6.23
X babashka/fs 0.4.18 :older-version
. org.clj-commons/humanize 1.1
. com.widdindustries/cljc.java-time 0.1.21
. com.widdindustries/cljs.java-time 0.1.20
. babashka/fs 0.5.27
. org.clj-commons/pretty 3.6.7
$
So those are deps from when I built the Uberjar. So maybe those dependencies are recorded as meta-data of the Uberjar? And something is unpackging that metadata and adding it to the dependencies and classpath?Well, not MANIFEST.MF:
Manifest-Version: 1.0
Created-By: org.clojure/tools.build
Build-Jdk-Spec: 25
Main-Class: dialog_tool.main
Multi-Release: trueso if deps.edn reports those as deps, the same will happen in bb, same dependency logic
Yes, but where are those dependencies coming from?
{:deps {uber/dialog-tool {:local/root "dialog-tool-test.jar"}}}
A bare JAR file doesn't have dependencies, does it? The dependency tree should just be the one file.is there a pom.xml in the jar? I don't know. this seems to be a deps.edn/tools-deps question now
$ fd pom.xml
META-INF/maven/babashka/fs/pom.xml
META-INF/maven/babashka/process/pom.xml
META-INF/maven/borkdude/dynaload/pom.xml
META-INF/maven/borkdude/edamame/pom.xml
META-INF/maven/cheshire/cheshire/pom.xml
META-INF/maven/com.fasterxml.jackson.core/jackson-core/pom.xml
META-INF/maven/com.fasterxml.jackson.dataformat/jackson-dataformat-cbor/pom.xml
META-INF/maven/com.fasterxml.jackson.dataformat/jackson-dataformat-smile/pom.xml
META-INF/maven/com.widdindustries/cljc.java-time/pom.xml
META-INF/maven/com.widdindustries/cljs.java-time/pom.xml
META-INF/maven/commons-codec/commons-codec/pom.xml
META-INF/maven/commons-io/commons-io/pom.xml
META-INF/maven/crypto-equality/crypto-equality/pom.xml
META-INF/maven/crypto-random/crypto-random/pom.xml
META-INF/maven/dev.data-star.clojure/http-kit/pom.xml
META-INF/maven/dev.data-star.clojure/sdk/pom.xml
META-INF/maven/fipp/fipp/pom.xml
META-INF/maven/http-kit/http-kit/pom.xml
META-INF/maven/io.github.escherize/huff/pom.xml
META-INF/maven/io.github.hlship/cli-tools/pom.xml
META-INF/maven/io.github.tonsky/clj-simple-router/pom.xml
META-INF/maven/mvxcvi/arrangement/pom.xml
META-INF/maven/org.apache.commons/commons-fileupload2-core/pom.xml
META-INF/maven/org.clj-commons/humanize/pom.xml
META-INF/maven/org.clj-commons/pretty/pom.xml
META-INF/maven/org.clojure/clojure/pom.xml
META-INF/maven/org.clojure/core.async/pom.xml
META-INF/maven/org.clojure/core.cache/pom.xml
META-INF/maven/org.clojure/core.memoize/pom.xml
META-INF/maven/org.clojure/core.rrb-vector/pom.xml
META-INF/maven/org.clojure/core.specs.alpha/pom.xml
META-INF/maven/org.clojure/data.priority-map/pom.xml
META-INF/maven/org.clojure/spec.alpha/pom.xml
META-INF/maven/org.clojure/test.check/pom.xml
META-INF/maven/org.clojure/tools.analyzer/pom.xml
META-INF/maven/org.clojure/tools.analyzer.jvm/pom.xml
META-INF/maven/org.clojure/tools.cli/pom.xml
META-INF/maven/org.clojure/tools.reader/pom.xml
META-INF/maven/org.ring-clojure/ring-core-protocols/pom.xml
META-INF/maven/org.ring-clojure/ring-websocket-protocols/pom.xml
META-INF/maven/ring/ring-codec/pom.xml
META-INF/maven/ring/ring-core/pom.xml
META-INF/maven/selmer/selmer/pom.xml
META-INF/maven/tigris/tigris/pom.xml
Those were all put there by tools.build / compile-clj and/or the uber. Might need to dig through that. But these are a partial overlap (subset and superset) of what's on the classpath at runtime. So there's lots of pom.xml Mystery remains.maybe post in #tools-deps?
Yep. Thanks for duckie .