This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2021-03-25
Channels
- # babashka (77)
- # beginners (107)
- # calva (20)
- # cider (2)
- # clj-kondo (7)
- # clojure (63)
- # clojure-australia (2)
- # clojure-europe (75)
- # clojure-germany (10)
- # clojure-italy (3)
- # clojure-nl (3)
- # clojure-serbia (15)
- # clojure-spain (2)
- # clojure-uk (24)
- # clojurescript (54)
- # clojureverse-ops (3)
- # cursive (20)
- # datahike (4)
- # datalog (5)
- # datascript (8)
- # datomic (13)
- # emacs (2)
- # fulcro (1)
- # graalvm (2)
- # instaparse (1)
- # jobs (2)
- # luminus (1)
- # malli (7)
- # off-topic (28)
- # pathom (6)
- # pedestal (2)
- # re-frame (5)
- # reagent (9)
- # remote-jobs (4)
- # rewrite-clj (4)
- # ring (19)
- # shadow-cljs (2)
- # spacemacs (2)
- # sql (10)
- # tools-deps (6)
- # xtdb (12)
Rewrote task DSL to a more hiccup-style syntax: https://github.com/babashka/babashka/discussions/757#discussioncomment-529074
This is especially convenient for inline tasks:
[:do
[:shell "clojure" "-M:outdated:nop:1.8" "--exclude=clojure/brew-install"]
[:shell "clojure" "-M:dev:1.9:test"]
[:shell "clojure" "-M:dev:test"]]
Yeah looks good! And I guess you can have :and
or :or
this way too. Very concise!
:do
is :and
as in, it will shortcut on the first failing job.
not sure about :or
since or
in clojure shortcuts on the first truthy value which is not common with tasks
ah yeah I see. :&&
and :||
also seem to be valid symbols. But might be to bash-y for babashka :)
I considered those, but they don't work inside the command line as they will be picked up by bash
Will this syntax also be usable from the command line?
I’m guessing the following will also be valid? (the last :do
part)
{:paths ["test-resources/bb-edn"]
:deps {medley/medley {:mvn/version "1.3.0"}}
:tasks {:shell1 ^{:description "Echo hello"}
[:shell "echo" "hello"]
:shell2 ^{:description "Echo bye"}
[:shell "echo" "bye"]
:medley ^{:description "Show off medley"}
[:babashka -e (do (require (quote [medley.core :as m]))
(m/index-by :id [{:id 1} {:id 2}]))]
:shell-all [:do :shell1 :shell2]}
,}
Nice 🙂
I just want to say how cool, easy and incredible was to implement integration-tests in clojure-lsp using babashka:
(BTW It's really incredible how fast sci return an error if there is something not right in your code)
I want to do this at work but there would be too much opposition 😢
@U01KUQRDMLG sounds like you are at the wrong place 🙂 what's your opposition's reasoning, btw? maybe there wouldn't be that much opposition, you are just assuming it? also, try it for yourself first on some of the work problems you have and maybe you will realize that some of the reluctance is well-founded... for example in the company i work for, we still have tension because of the different editors and the lack of consistent code-formatting tools for clojure.
just bringing in a new language is always difficult. I use babashka for my own purposes
(not sure whether its better to ask here on in #calva, but I'll try this channel first, as the question is also very bb-specific)
When I open bb --nrepl-server
and then connect to nrepl port 1667 in calva, the editor is offering code completion for namespaces, imports of java classes, function names etc. But it's not able to offer function parameter names/positions, function docs etc. Is there any way of getting this functionality in calva when connected against bb
's nrepl server?
I think this issue is related to this: https://github.com/babashka/babashka.nrepl/issues/30
These nrepl ops are currently supported:
#{"clone" "close" "eval" "load-file"
"complete" "describe" "ls-sessions"
"eldoc"}
I think eldoc comes relatively close and might offer you some insight in how to implement the other one^ @U0ETXRFEW is the above issue still relevant?
It took me a while to figure out how to prepare a REPL-driven-development experience where I can make modifications to the code and see the result in a few seconds, but it's slowly starting to work. It's a bit buggy, but quite awesome. Developing scripts against bb --nrepl-server
with calva will be way better with parameter support and docs.
Found posible issues:
1. when you use (:require
with :as
aliasing of some namespace, function name completion of that namespace will get duplicated. Perhaps there's already some error present in current version in :complete
message handling or something similar?
2. if I use such aliasing, (such as s/includes?
where s is alias for clojure.string), this new info
functionality works fine in function name completions only when you use full namespace, not when you use the prefix form. If prefix is used, a bit weird combination of namespace and symbol seems to be passed in the message. In mentioned case namespace=clojure.string
and symbol=s/includes?
. I don't know what's the contract of this message, but this combination doesn't feel right (I'd expect that the symbol shouldn't include the s/
prefix). But as I said, I don't know the contract.
3. some of the functions seems to be missing their docs, such as
, possibly because protocols are implemented in a bit different way in babashka?
It might also be possible to get some really basic information about java class methods (even without reflection), such as the types and positions of their parameters. But I'll have to look more into that.
Here's a short video of current status. Will need to clean that up a bit tomorrow or some following day and file a PR.
https://www.youtube.com/watch?v=MmZps7FvMSg
Awesome. Don’t hesitate to ask me for help if there is anything on the VS Code end of that that you think I can shed some light on. The nrepl “contract” I don’t know as much about as one would think. It has mostly just worked for me and I’ve been reverse engineering CIDER when I wonder about how to do some particular thing.
The info op doesn't seem to be documented. https://nrepl.org/nrepl/ops.html @U051BLM8F should it be?
I was mostly trying to look up the structure and value types from cider-nrepl
's tests
https://github.com/clojure-emacs/cider-nrepl/blob/a7d24bc91028b78eda2f73a6d3f17c53495a84da/test/clj/cider/nrepl/middleware/info_test.clj#L85-L255
@U04V15CAJ There's no info
op in nREPL - that's in cider-nrepl
. The nREPL op is named lookup
.
@U051BLM8F should calva then use the lookup op if info is not available? and what should be in this map? > Returns :info A map of the symbol’s info. The doc is pretty handwavey here.
Everyone should use lookup
if info
is not available. As for the :info
map - I agree it needs more documentation.
@U051BLM8F So maybe it's best if @brdloush exposed his new op as both info
and lookup
? Are they drop-in replacements?
The API is the same and I think it's fine to expose both as aliases. Eventually I'll rename cider-nrepl
's op cider/info
to it's clearer that it's not built-in, but I don't have any concrete roadmap for this. Not sure how many client have been updates to support lookup
by now, as it's still pretty new.
@U04V15CAJ copy @U0ETXRFEW I have some issue with calva not showing the docs on code completion. At some point, I managed to see the completion options in that way, that both the argument list and documentation reside in their own popup window (first screenshot). But now I'm always getting just a single-window code completion popup, where the parameters are included in that single window. (second screenshot)
And I just don't see why the code completion is now getting rendered in that single-window form instead of two-window form. Any hint appreciated 🙂
aaaaah, I am soooo stupid 😄. All I had to do was to CLICK that area with params 😄
aaah, the shortcut to switch between the single-window and multi-window code completion is ctrl+space. Now I understand how it happened that I accidently switched between the two modes 🙂
After a few fixes, It's starting to behave as I'd like. https://www.youtube.com/watch?v=BxR5oE9pKAI I'll do some more testing in the evening and hopefully file a PR.
@brdloush Calva relies on cider-nrepl and clojure-lsp for these things. So far there is no cider-nrepl in babashka's nrepl server, and clojure-lsp needs dependency info. You might get away with creating a deps.edn file with the dependencies you use. At least for some of the functionality.
I tried running the following script on Windows under Git Bash, but using Windows-native bb.exe
as installed by Scoop:
#!/usr/bin/env bb
(println "Hello, world")
This script failed for me with the following error:
Message: File does not exist: /cygdrive/c/Users/blah/bin/hello
The problem is that the native bb doesn’t recognize Cygwin paths. My solution was to create a script called bbw
on my Cygwin path:
#!/bin/bash
SCRIPT=$1
shift
bb.exe $(cygpath -w $SCRIPT) $@
Maybe your script can just be called bb
so you can run scripts cross platform without changing the shebang
I think adding it to the book might be good. Maybe we can have a troubleshooting chapter
yeah, makes sense and so your wrapper script is only available in the cygwin shell right?
ok, so maybe calling the script just bb
is nice so the shebang is the same in bash as it is in cygwin
Hrm, the problem is the wrapper assumes the first arg is the name of a script. Naming the wrapper bb would prevent me from doing bb one-liners from bash.
We can’t install WLS2 on our work machines so Git Bash is the only way to hold onto a little bit of sanity 🙂
you can either make a PR for the book, or post the snippets here: https://github.com/babashka/book/discussions/categories/ideas
@U0DTSCAUU this sounds like a niche problem caused by social/organizational issues ("We can’t install WLS2 on our work machines"). instead of silently trying to overcome a social issue with software workarounds (further complicating the existing software, what's already hyper complicated, i guess), i would try to attack this problem from a social angle and solve it that way. and if you can't change the organization around you, then u should probably start looking for other ventures, which value your lifetime more and let you solve more impactful problems. these kind of rigid companies deserve to wither away; better u don't help keeping them alive... :)
I dunno, I think restricting admin access is just prudent security policy, not necessarily the sign of a rigid company that deserves to wither away.
i've excused myself from the ms windows world decades ago, so i don't have up-to-date insights on this topic. what's wrong with allowing the installation of WSL2? @U0DTSCAUU do you agree that it's a "prudent security policy" to disallow installing WSL2 (which is an official part of the OS, just not installed by default, if i understood correctly)? are you sure that they specifically disallow WSL2 or you were just denied by reflex? is there any documentation available about this decision to the employees? if not, then sorry, it's a shit company; let
@U086D6TBN Please don't be rude and respect other people's choices, or not, but I don't see a need to nag them about it.
all im saying is, don't just give in so easily. many limitations are self-imposed. often u just have to ask and you will receive. and DO be a bit of a pain in the ass sometimes, because that little extra push is all that's necessary for other people to realize their own self-imposed limitations. meaning, however is the gatekeeper for the WSL2 installation, might give in and think about it for a few minutes, if asked every week 4 times in a row. demand a clear explanation the very least. @U04V15CAJ is it less rude if i put it this way? i've noticed that my threshold for directness and abrasiveness differs from other nations' thresholds. i never had such issues with ppl from eastern-europe...
Fair points, but you don't always know the situation people are in and they might have good reasons to be very conservative with what people can install on certain systems with e.g. sensitive information. My wife works for a company that deals with patient information and some environments she works in are very strictly controlled. I think you made your point well, thanks for clarifying.