Fork me on GitHub
#babashka
<
2020-03-17
>
sogaiu10:03:41

some of the contents of: https://github.com/uutils/coreutils#utilities look potentially useful for cross-platform scripting with bb

borkdude10:03:28

is there maybe some tool that can be used to watch directories and invoke a command, as a way to escape the java Watcher mess?

teodorlu11:03:35

I use entr all the time. http://eradman.com/entrproject/

find src | entr -c cargo check

borkdude11:03:53

cool! adding to the issue!

🙂 4
borkdude11:03:40

that looks very useful

sogaiu11:03:10

haven't tried it, but found this: https://github.com/aag/eagle-eye

sogaiu11:03:18

btw, the coreutils thing from above -- looks like one can get a busybox-style single binary that contains all of the functionality.

sogaiu11:03:00

so e.g.:

$ ./target/release/uutils hashsum --sha256 ./target/release/uutils
52c8b95bedc137bfcb272d178fae45df955762c43a2d666eead05ceeaa095073  ./target/release/uutils

sogaiu11:03:44

or:

$ ./target/release/uutils uptime
 11:05:29 up   0:07, 1 user,  load average: 1.34, 2.30, 1.36

borkdude11:03:04

so the benefit of that project over other implementations like brew install core-utils is Windows?

sogaiu11:03:36

one benefit is that it's supposed to work on all 3 platforms another benefit is that it's not written in c 😜

borkdude11:03:26

yeah, cool reference implementation repo

sogaiu11:03:12

one other possible benefit is that it may be easier to align the specific functionality of each utility -- by that i mean, using coreutils for linux vs homebrew version might be extra work for getting the versions of various things (and options?) to line up may be? i know many linux distributions will customize their specific takes on something and i don't imagine homebrew is any dfiferent. here you are really compiling the same thing (i'm guessing) for all 3 platforms.

borkdude11:03:19

I think relying on some external tool for dir watching may not be a bad idea. I just tried to compile eagle and it seemed to work. Why does that thing only have 1 star on Github

lispyclouds11:03:23

Watchman is quite ubiquitous in this need and I would guess no one wanted anything else?

borkdude11:03:56

yeah, might be!

sogaiu11:03:55

good question -- relatively unknown perhaps?

borkdude11:03:59

@sogaiu brew install coreutils will install things like gdate, etc which are then the same GNU tools as on linux. with some extra flag it will override the system ones

sogaiu11:03:00

appears to go back to 2015, fwiw

sogaiu11:03:30

the point is that each distribution may customize how the utils behave by specifying different options at compile time.

sogaiu11:03:00

i need to verify whether that's true for coreutils ofc 🙂

borkdude11:03:07

well, relying on one language that can be cross-compiled, is a good way to get the same behavior. it seems things are converging and a lot is happening in the Rust space

sogaiu11:03:43

here's another rust file watcher with more stars: https://github.com/grego/caretaker

sogaiu11:03:14

but is it cross-platform...

borkdude11:03:30

so was eagle

borkdude11:03:46

they both rely on the notify crate

sogaiu11:03:31

am compiling caretaker on windows now

sogaiu11:03:46

seems to work

borkdude11:03:26

we could even theoretically use a small rust library inside babashka to take care of this. not sure what the size of that rabbit hole would be since you need to invoke callbacks, but this seems possible using JNI

borkdude11:03:23

delegating to an external CLI is much simpler from a technical perspective

borkdude11:03:38

and usually you want to invoke some external command in the watcher anyway, e.g. sass/less compiler

sogaiu11:03:17

may be just listing some potential external binaries people could use isn't a bad start?

borkdude11:03:35

yeah, I've done that in the issue. if you have more, you can add them

sogaiu11:03:42

understood

teodorlu12:03:56

Live-developing a bb-script with entr

borkdude12:03:12

great idea 🙂

teodorlu12:03:34

entr will incur graal startup cost, which probably isn't a problem.

teodorlu12:03:41

I wrote a thing to avoid the Python interpreter startup cost: https://github.com/teodorlu/hotload bb port might be interesting to discuss. Not sure if that would be possible to implement in userspace. Just tossing some ideas out there 🙂

borkdude12:03:48

what would be the benefit of that over a REPL?

borkdude12:03:59

the startup of bb is like 13 ms and it has a socket-repl. Not sure what else you need?

teodorlu12:03:09

If I add connections and stuff in userspace, I can control that cost to incur only once with a defonce

teodorlu12:03:51

I generally prefer a REPL, but this is the workflow that tends to work best for me when hacking on Python-things I don't know that well.

teodorlu12:03:45

As I mentioned, I don't know if this is needed. But I've found the idea to be novel when working with Python, and I don't have REPL access.

borkdude13:03:58

I need some time to grok your Python idea, I'm not too familiar with Python. If you can explain the concept in Clojure terms, what existing problem it solves and how it would benefit bb, I'm all for it.

teodorlu14:03:21

Why hotload: • In Clojure, I prefer the REPL • In Python, I don't have the REPL, so I use hotload. Hotload avoids Python interpreter restarts, and I can keep my state in-memory between reloads • For bb scripts as of now, I think would use entr • Disadvantage with entr+bb: In-memory state is lost between reloads. The Github thread mentions some Clojure/java file watchers. Implementing something like hotload for bb shouldn't be much more than connecting some Clojure/java file watcher to a way to reload your namespace, and adding a CLI. I'd be happy to walk you through the code if you're interested.

borkdude14:03:02

why not use the bb socket-repl?

teodorlu14:03:32

No good reason. Socket REPL is probably a better option for most cases. So far, I've only used nREPL with CIDER.

teodorlu15:03:15

inf-clojure doesn't appear to be included int the Spacemacs Clojure layer. Installing it is probably simple, though.