This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-12-19
Channels
- # adventofcode (18)
- # announcements (1)
- # babashka (153)
- # beginners (73)
- # bristol-clojurians (4)
- # calva (1)
- # cider (6)
- # clj-kondo (38)
- # clojure (154)
- # clojure-dev (12)
- # clojure-europe (7)
- # clojure-finland (11)
- # clojure-nl (70)
- # clojure-spec (13)
- # clojure-uk (101)
- # clojuredesign-podcast (2)
- # clojurescript (15)
- # core-async (30)
- # cryogen (1)
- # cursive (5)
- # devops (1)
- # duct (4)
- # figwheel-main (1)
- # fulcro (19)
- # jobs (12)
- # kaocha (17)
- # luminus (2)
- # malli (8)
- # music (5)
- # nrepl (13)
- # off-topic (20)
- # overtone (3)
- # re-frame (7)
- # reagent (38)
- # shadow-cljs (13)
- # specter (3)
- # tools-deps (6)
- # vim (7)
Any opinions on this? Note: breaking change, need your input! https://github.com/borkdude/babashka/issues/171
Probably not that many. There might be a few blog posts up there that need changing (cc @plexus).
Another one to discuss: https://github.com/borkdude/babashka/issues/172
the few times i've encountered conflicts, my resolution has been to choose between the alternatives. i.e. don't install conflicts. in nixos, there might be good ways to do this as iirc there's ways to live with multiple versions.
i guess you may be in luck here, as although the repository's name is bbk, the command appears to involve the letters "cli"
I'm not planning to make a debian package myself, not looking forward to the bureaucracy
in option 1, it looks like some of the implementation is being exposed (because of the existence of the @) -- is that potentially an issue if there is a decision later to change the underlying implementation?
we can also just leave the magic as it is and only rename *in*
to stdin
(or some other name, I'll call that option 0)
So maybe option 0 is best with the least amount of breakage. Does someone object to the new name <stdin>
instead of *in*
?
btw, thank you @borkdude for the java.time.* inclusion, I'm still noodling on the idea of including tick
, I need to check and see if the raw java objects are quickly usable or if a wrapper would be needed (or just nice)
luckily not, the idea is to chose a non-conflicting name because *in*
is already taken
I only worry because < and > are important characters in bash and could be a source of confusion
@nate Feel free to experiment, but taking on specific libs is a bit of a commitment. I'm not sure if I want to make that commitment if there's not really a need for it. Some libs like cheshire are pretty battle tested and uncontroversial, it seems like the java time area is still a bit developing
I don't know tick vs java-time well enough to make a good judgement, but it would be good to know what works and what doesn't
@borkdude I totally understand about taking on the commitment. I think that java.time.*
is a great place to be for a while
I think the addition of classpath handling really makes it not matter what library is there, because you can just hide it behind a function
I think that leads back to the *in*
thing, as having it be as compatible as possible with mainline clojure is a real benefit
but shadowing core symbols is confusing, so it's probably better to move that to user/stdin
or something
I like some sort of surrounding characters to indicate it's a special variable put there by bb
I've tried that in the very beginning, but that really messes with string interpolation in bash
I renamed it in the stdin
branch: https://github.com/borkdude/babashka/tree/stdin#quickstart
Mac binary: https://2583-201467090-gh.circle-artifacts.com/0/release/babashka-0.0.44-SNAPSHOT-macos-amd64.zip Linux binary: https://2585-201467090-gh.circle-artifacts.com/0/release/babashka-0.0.44-SNAPSHOT-linux-amd64.zip Feel free to try this change
good point. maybe <input>
is better than <stdin>
since input can also be parsed EDN, instead of raw text
i am wondering what are the benefits of having a single thing for both parsed edn and raw text...is it not a bit entwining?
i understand that they tend to be used separately -- but is there benefit in having a single thing refer to both?
well, the -i
and -o
flags control how input and output is read/printed. That plays well with bash text stdin/stdout. Having a separate input value to match edn/text could conflict with that
if you were starting from scratch, would you do the same? i thought learning to use, as well as reading the source might be less confusing.
we could do without magic input values and flags, but then your one-liners would become something like:
$ echo '{:a 1} {:a 2}' | bb -e '(vec (take-while #(not= % ::eof) (repeatedly #(edn/read {:eof ::eof} clojure.core/*in*))))'
[{:a 1} {:a 2}]
and btw, you still get to do this, you don't have to use <input>
if you just want to use (read-line)
i think i'm good as long as i don't have to use the magical symbols -- although i used to heavily use perl in a previous life 🙂
@plexus wrote about them here: https://lambdaisland.com/blog/2019-12-05-advent-of-parens-5-clojure-in-the-shell
$ echo '{:a 1} {:a 2}' | bb -I '(json/generate-string (vec <input>))'
"[{\"a\":1},{\"a\":2}]"
$ echo '{:a 1} {:a 2}' | bb -I -o '(json/generate-string (vec <input>))'
[{"a":1},{"a":2}]
looks good -- those examples ran fine here (oddly enough my usual python change for the testing may not be working)
$ lein test :only babashka.main-test/wait-for-port-test
==== Testing JVM version
lein test babashka.main-test
seems to be hung herecommenting out the wait-for-port-test lets all complete from that ns:
$ lein test :only babashka.main-test
==== Testing JVM version
lein test babashka.main-test
Ran 33 tests containing 67 assertions.
0 failures, 0 errors.
there are now two instances of "python" to change -- or somehow it used to work only changing one?
i looked into nasus a bit, btw, but i didn't immediately figure out how to use it. may take another look.
it seemed straight-forward enough to start it from the command line:
clj -Sdeps '{:deps {nasus {:mvn/version "0.1.5"}}}' -m http.server 8001
but i figured for the tests it would be nicer not to have to do that. especially on windows where the assumption of an existing installation of clj
might not be a good one.the point of using python in the wait-for-port test is that it is single-threaded so it will block if the socket isn't closed
in any case, starting to look for some crossplatform alternative seems like it might be good?
we can just make a flag to skip those python tests if you haven't got it installed. it will be tested on CI anyway
and python starts fast, whereas starting a JVM process inside a test is a bit heavy imo
we can of course make a static binary web server for this purpose, but then we would have to make another project out of that and people would have to install that
i thought we discussed before that may be a jvm-based web server would just work off of the jvm process running the test...or may be that was for some other situation?
always fun to look at lists like these: https://gist.github.com/willurd/5720255