@mfikes I was playing with abio and wondering what is the status...

@richiardiandrea not to be used yet I believe

the goal is to include it in Lumo & Planck eventually

well I have tried in lumo exactly, it works but it is not deployed on clojars that is why I was wondering 😄

Right... it is more or less of the start of an idea, but it hasn't been pushed very far yet

are there any good examplse of using lumo for shell scripting, for example?

Is it’s core just cljs core?

@erichmond here’s an example https://gist.github.com/yogthos/d9d2324016f62d151c9843bdac3c0f23

there are a few bundled libraries with Lumo but no docs yet

working on it…

thanks! It’s a ton of work, I understand. Just thankful you’re working on such great stuff 🙂

would it maybe be easier to just hook into node’s child_process if I need to execute binary exes?

definitely

@anmonteiro is there a list of bundled libraries?

actually I've been thinking about lumo for shell scripting, and it seems to be post a dilemma

You can use the sync versions of functions (e.g. spawnSync). That's great for shell scripting, but you miss out on the bulk of functionality of node.

If you want to use any but a few functions from the stdlib, you can use the (universally preferred) async versions. However, shell scripts are by their nature synchronous, an imperative sequence of commands to follow. So you risk using a programming style (callbacks, promises, core.async) that is more appropriate for network programming, with little advantage for the use case.

Both horns of the dilemma are probably viable. Picking the first option would turn node into a much less rich platform, basically reduced to reading files and spawning processes, but it would resemble a conventional shell like bash more.

Going the second route could work as well. Ideally we could come up with some kind of DSL that makes the async system less of a pain for this type of use case. That abstraction would make simple scripts as convenient as bash scripts, but I'm worried that the abstraction would leak through once you turn to more advanced use cases (conditionals, loops, pipes...).

@pesterhazy I have always found that the best async abstraction, if you want to compose, is channels..that is why piping works so well in bash, basically every process "exposes" a channel. Of course this needs to take advantage of the underlying OS stuff...I don't think it is something solvable in lumo itself...probably piping edn in and out is a good idea...maybe a switch can select a function (`-d my-ns.decoder`) that does the conversion from the input to something clojurescript can understand

@richiardiandrea I'm not sure I'm buying the usefulness of channels here. Essentially bash scripts have sequential form "cmd1; cmd2, cmd3". I think it makes sense to think about scripting in terms of this simple use case first, and add advanced concepts -- even pipes -- later.

How does the concept of a channel help capturing such a sequential process?

yeah forget about channels, I was probably thinking more about piping

the concept of pipe and channels is related...not that useful in this case

yeah, node streams give you a pipe functionality, so that could actually be a useful building block

so the problems I see here then are two: task concatenation/abstraction(?) ... if data is coming not in edn, the conversion to cljs data structures

and again, I wish my Google Summer Of Code idea of porting boot to lumo had been accepted 😄

Now it'll have to be mach ;)

Yes that is my go to option for new-ish things 😄