In bb new features will never shadow old usage
So it wonβt break users. Users will simply not have access to the new feature if their usage shadows it, which is not breaking since they didnβt use the new feature yet.
babashka 0.3.8 now comes with the Selmer templating library built-in Other than that, minor enhancements. Ramping up to a 0.4.0 release where tasks will be available as a stable feature. No other changes to tasks are planned, feedback still welcome.
Does bb have a parsing library in there? Instaparse or something? I have a few plaintext scripts that might be nice to have be fast.
It might be nice to add Instaparse at some point (it's pure Clojure and has no deps, so seems alright, but must be carefully considered) but right now it's not there
@dominicm
I have now added the java.text.ParseException
class to babashka so from master (check #babashka-circleci-builds) you can now run https://github.com/rm-hull/jasentaa as is. I will try to fix support for kern too, but meanwhile, you can look at the above gists which uses my forks of both libs. I'm surprised it works this well.
Added all the unit tests from jasentaa to bb CI and all are passing :)
FSM parsing is definitely the best. I did some work a while back on improving bidi performance that compiled bidi to a FSM and saw massive speedups. You can do some pretty neat stuff with it.
I gotta say that I find a bit concerning keep adding libraries to babashka like this, I understand the idea is to be batteries included, how do you see those affecting size and start time in the future? for instance, imagine if somebody wants to use babashka for some less capable processor/memory devices, how would go? compile bb itself removing those? if that's easy may be ok, also I wonder if adding those can affect the boot time of babashka, would love to hear your thoughts on those
I have the same concerns. I do a careful analysis when adding something. For the selmer dependency: I had been considering this for a while, several people asked for this. Yesterday my colleague needed this for his devops tasks and I finally did a POC for adding it. The lib only adds 0.6-1.5mb to the binary which I find reasonable for what it does. I usually take into consideration how useful it is for scripting tasks (or in combination with the built-in webserver) and I think a templating lib like this is useful enough. So adding everything up, I made the decision that it's good to add it. As for Instaparse this is far less clear, but if it's a light weight dependency and doesn't add much size, I might be open to it, depending on how often this comes up.
I did several PRs over the last two days to Selmer to make all dependencies optional btw. see #announcements
There is an issue about adding malli to bb which also isn't clear yet, so I'll leave that open for feedback. If people suggest I should add Instaparse to bb, they can open an issue to it can collect feedback. cc @dominicm
Adding libs doesn't impact startup time btw, at least, I haven't seen a noticeable effect
There is a BABASHKA_LEAN environment variable which can be used to strip non-essentials to have the most bare bb possible, but so far I haven't had many requests to make such a distribution
I sometimes spend days to keep the size of bb in check when adding something. E.g. with clojure.pprint I did this. https://github.com/borkdude/pprint
But thanks for expressions you concern, it's good to be concerned about that.
Sometimes when I upgrade GraalVM (e.g. now from 21.0 to 21.1) it adds 5mb for no reason, while I spend days trying to save 1 or 2 mbs when adding a clojure lib. This is very frustrating sometimes.
I am not enough of an advocate for instaparse to actually advocate for it. I wrote a parser for http://todotxt.org/ using it so I could do some scripting on my todo file. And I have to wait a whole 2s for it to run! I'd happily have used another library if it were included in bb already though (kiev I think you tried @borkdude?). I would say that one of bb's value propositions is that it allows adding structure to the unstructured data we often get in text streams, so I think there's value to something that can handle that. But I'm not sure if that's the same as my problem or not.
For structured things people usually use JSON or EDN already
Recently bb added support for the https://github.com/helins/binf.cljc library (by adding appropriate Java classes), that might also come in handy, but is more geared towards parsing e.g. MIDI files, etc)
There is a complete web-assembly parsing library available which also works with bb from source based on that lib
ls
(LS) doesn't output json, that's the kind of thing I mean. Input from other tools.
As for parsing, you can go a long way with a Reader, .read
and a loop:
https://github.com/babashka/process/blob/eba04e6c35814296e5bb383804f801aee912cba1/src/babashka/process.clj#L10
That function parses shell invocations like ls 'foo "bar"' \"hello\"
and also works with bb from source even
it's low level, but this is how many parsing things work. just a state machine and loop through chars
what is kiev?
You're a monster :D Yeah. I think there's value to the higher-level thing though. Parsing todo.txt is not trivial because you have to go through many characters before you realize it's not a date, and it's part of the todo, stuff like that.
There might be parser combinators compatible with bb (or can be made so): https://github.com/rm-hull/jasentaa https://github.com/blancas/kern I haven't tried, but I'm curious
kern, that's the one you've tried :D
https://github.com/borkdude/aoc2017/blob/master/src/day16.clj here we are
yeah, I remember, it was a pretty good experience. also, the conclusion was: manual parsing always wins in terms of performance
bb currently trips over this defrecord with a Comparable interface: https://github.com/blancas/kern/blob/3ef65e559658c06a321a9ca7c85a541edc7b9ff2/src/main/clojure/blancas/kern/core.clj#L108
wow, removing that, it works
let me push the fork
@dominicm https://gist.github.com/borkdude/bbc78b34e77ef91510ace75862d23aeb
@dominicm The other one works too: https://gist.github.com/borkdude/4e66410b09894b544d4d26483014815b
Just found out that with slight modifications, two parser combinator libraries work with babashka: Kern: https://gist.github.com/borkdude/bbc78b34e77ef91510ace75862d23aeb Jacentaa: https://gist.github.com/borkdude/4e66410b09894b544d4d26483014815b /cc @dominicm
Is babashka not available for Apple Silicone chips?
@cdimara If you can find a (free) CI that can build native binaries for Apple Silicon, I would be happy to support that. Until then, Rosetta can run the amd64 binaries as well.