This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-17
Channels
- # announcements (7)
- # babashka (56)
- # beginners (114)
- # bristol-clojurians (4)
- # calva (22)
- # cider (7)
- # clara (1)
- # clj-kondo (17)
- # cljs-dev (1)
- # clojure (93)
- # clojure-europe (8)
- # clojure-italy (5)
- # clojure-nl (2)
- # clojure-uk (79)
- # clojuredesign-podcast (18)
- # clojurescript (108)
- # code-reviews (6)
- # cursive (3)
- # data-science (16)
- # datomic (151)
- # duct (7)
- # emacs (10)
- # events (1)
- # fulcro (76)
- # luminus (8)
- # off-topic (3)
- # other-lisps (2)
- # pathom (8)
- # re-frame (5)
- # reitit (8)
- # schema (9)
- # shadow-cljs (37)
- # specter (3)
- # sql (17)
- # tree-sitter (2)
- # yada (9)
some of the contents of: https://github.com/uutils/coreutils#utilities look potentially useful for cross-platform scripting with bb
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?
I use entr
all the time.
http://eradman.com/entrproject/
find src | entr -c cargo check
haven't tried it, but found this: https://github.com/aag/eagle-eye
btw, the coreutils thing from above -- looks like one can get a busybox-style single binary that contains all of the functionality.
so e.g.:
$ ./target/release/uutils hashsum --sha256 ./target/release/uutils
52c8b95bedc137bfcb272d178fae45df955762c43a2d666eead05ceeaa095073 ./target/release/uutils
or:
$ ./target/release/uutils uptime
11:05:29 up 0:07, 1 user, load average: 1.34, 2.30, 1.36
so the benefit of that project over other implementations like brew install core-utils
is Windows?
one benefit is that it's supposed to work on all 3 platforms another benefit is that it's not written in c 😜
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.
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
Watchman is quite ubiquitous in this need and I would guess no one wanted anything else?
@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
the point is that each distribution may customize how the utils behave by specifying different options at compile time.
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
here's another rust file watcher with more stars: https://github.com/grego/caretaker
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
and usually you want to invoke some external command in the watcher anyway, e.g. sass/less compiler
may be just listing some potential external binaries people could use isn't a bad start?
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 🙂
the startup of bb is like 13 ms and it has a socket-repl. Not sure what else you need?
If I add connections and stuff in userspace, I can control that cost to incur only once with a defonce
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.
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.
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.
In that case, I'll refer to this Clojureverse post: https://clojureverse.org/t/announcing-hotload-code-python-like-its-clojure/4402
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.
No good reason. Socket REPL is probably a better option for most cases. So far, I've only used nREPL with CIDER.
I want to include docs about it: https://github.com/borkdude/babashka/issues/295