@U45SLGVHV Hey welcome! I recommend taking a look at the built-in babashka.process library

https://github.com/babashka/process

I see there's also an ffmpeg library which does this for you in bb: https://github.com/luissantos/ffclj

Thanks! So stream is 24/7 and i want to chunk it. i couldn't find a way to stop ffclj. wait task - will just hang because i am recording a stream process - i also couldn't fin a way to stop the process. Did i miss anything in the documentation? My idea was to have a loop, read the stream and store it to file, after 1h stop and repeat (but to new file).

do you want to kill the ffmpeg process?

you can do this using fs/destroy

yes i want to kill ffmpeg process periodically. Aha! Alright i will try it out

Thanks

you can try:

(catch ^:sci/error Exception e)

Trying to come up with an example, hold on

(require '[sci.core :as sci])


(defn foo [x]
  (/ 1 x))

(defn bar []
  (foo 0))

(try (bar)
     (catch ^:sci/error Exception e
       (->> e
            (sci/stacktrace)
            (sci/format-stacktrace)
            (run! prn))))

Use the newest version if this doesn't work for you

I'll give this a try when I can; it may involve throwing an exception just to catch it for its stack trace, which is not great performance-wise, but that's a lesser concern. I'm sure even in the JVM getting the current stack trace is relatively expensive.

Remember back in the day where people convinced themselves that the best way to write an efficient loop was to write an infinite loop that throws an exception, and to catch the exception outside the loop? I try not to be that person. One of my big Tapestry regrets is that I used a little bit of throwing exceptions for flow of control, something I would never do now.

The above is just to expose the error handling that SCI normally offers outside of the interpreter to within the interpreter e.g. in a -main function. Throwing and immediately catching probably results in an empty stack trace due to how this is implemented.

I'll have to experiment; alternately, is there a way to know the namespace and fn name in Babashka at macro expansion time? I wish Clojure exposed this, but of course due to order of operations, it might not even know.

> is there a way to know the namespace and fn name in Babashka at macro expansion time? Not sure what you mean here, got an example?

Calls to trace output something like:

{:in my.example.ring-handler/handle-request,
 :line 6,
 :thread "nREPL-session-c3dde1ce-ca19-4e78-95ad-d0e4beda61eb",
 :method :get,
 :uri "/status"}

Well, the line and column are available as metadata on &form and *file* has the current file, I guess the only thing missing is the parent function then right?

we could stuff something into &env like ClojureScript does

I tested humanize and it doesn't work due to the dependency on joda time. If the project maintainer can be convinced to java.time it might work.

Commenting out the date-related functions, then it seems to work:

$ bb --classpath $(lein classpath) -e "(require '[clojure.contrib.humanize :as h]) (h/intcomma 1000) "
"1,000"

$ bb --classpath $(lein classpath) -e "(require '[clojure.contrib.humanize :as h]) (h/numberword 1000) "
"one thousand"

No longer actively maintained: https://github.com/trhura/clojure-humanize/issues/26#issuecomment-1087023364

woah!! thanks!

You're welcome! Nice project

whoa

I hadn't considered json to edn and then using eql

amazing!!

@lilactown Why does your example contain --no-pretty?

I haven't used eql that much, but it's good, maybe it's also an option to bake into jet eventually

The reason I use —no-pretty is because the CLI I wrote expects the EDN passed via stdin to be on one line

It does (edn/read *in*)

That should work with multiline strings as well?

it should read until stdin is closed right?

$ echo '[\n\n1 2 3]' | bb -e '(edn/read *in*)'
[1 2 3]

I thought so too but recall running into issues. I'll try again when I'm back at my computer

oh yeah it works without --no-pretty

For now I'm doing this

cat ~/.config/bb.edn my-bb.edn | jet --collect --func "(fn [edns] (apply merge edns))"

$ bb -e "(babashka.deps/merge-deps ['{:deps {a 1}} '{:deps {a 2 b 3}}])"
{:deps {a 2, b 3}}

Oh I see, thank you your dudeness

Pinging @UKFSJSM38, @U4NGX0FHN and @UFDRD93RR

I have no idea why :(

@U050CT4HR Looks fine for me, at least looking at the hydra logs

Maybe I’m using hydra-check wrong? I’m pretty new to this.

It did fail the staging-next-22.05 build, but I would say this is unrelated

Please check the unstable channel, it doesn't make much sense to check master

Well, this is also failing for me, but: https://hydra.nixos.org/build/186540565

This is the last build I think

So it should be fine

Yeah, I was going to say — I think it’s also broken on unstable.

How did you find that build?

This question might belong in #nix, but I don’t yet understand how to find a working nixpkgs SHA for n packages and m architectures.

> How did you find that build? I generally just search in the Web interface directly. It list the latest builds

Like so? https://hydra.nixos.org/search?query=babashka

Works for one individual package, but not for n packages. We’re just using Nix to create reproducible development environments. Should I be pinning different versions of nixpkgs for each package we need?

(I realize this conversation has gone off topic.)

Let me move the conversation to #nix

I was confused as to why bb test was failing for me on babashka/fs on Windows. The which tests rely on on-path being on the PATH. It seemed that the bb.edn test tasks was https://github.com/babashka/fs/blob/111894217039261c45e4b9f415e6371ae41cf148/bb.edn#L8-L9:

:tasks
 {:requires ([babashka.fs :as fs])
  test (clojure {:extra-env {"PATH" (str "on-path" fs/path-separator (System/getenv "PATH"))}}
                "-M:test")

set PATH=on-path;%PATH%;

:tasks
 {:requires ([babashka.fs :as fs])
  test (clojure {:extra-env {"Path" (str "on-path" fs/path-separator (System/getenv "PATH"))}}
                "-M:test")

This is a bit confusing.

Can someone with a Windows box/vm try a bb test on babashka/fs and report back?

I can try this tomorrow. You could also make a change in the Github action right?

or appveyor

Yah could do…

Running tests in #{"test"}

Testing babashka.fs-test

FAIL in (list-dirs-and-which-test) (fs_test.clj:292)
expected: (fs/which "foo.foo")
  actual: (not (fs/which "foo.foo"))

Ran 42 tests containing 144 assertions.
1 failures, 0 errors.
Error while executing task: test

Running tests in #{"test"}

Testing babashka.fs-test

Ran 42 tests containing 144 assertions.
0 failures, 0 errors.

Huh! Yes! Thanks @UBLU3FQRZ!

Ok… here’s an interesting test on Windows:

bb
Babashka v0.9.161 REPL.
Use :repl/quit or :repl/exit to quit the REPL.
Clojure rocks, Bash reaches.

user=> (require '[babashka.tasks :as t])
nil
user=> (t/shell {:extra-env {"pAtH" "foo"}} "clojure")
Clojure 1.11.0
user=> (System/getenv "PATH")
"C:\\Program Files\\Parallels\\Parallels Tools\\Applications;...etc...etc..."
user=> (System/getenv "pAtH")
"C:\\Program Files\\Parallels\\Parallels Tools\\Applications;...etc...etc..."

user=> (get (System/getenv) "PATH")
nil
user=> (get (System/getenv) "Path")
"C:\\Program Files\\Parallels\\Parallels Tools\\Applications;...etc...etc..."
user=> (get (System/getenv) "pAtH")
"foo"

From https://docs.oracle.com/javase/tutorial/essential/environment/env.html: > There are many subtle differences between the way environment variables are implemented on different systems. For example, Windows ignores case in environment variable names, while UNIX does not.

Ok, so maybe the way babashka/process is merging :extra-env environment vars needs to be tweaked for Windows. It seems that the Windows shells match case insensitively when overriding: cmd.exe:

C:\Users\lee>set foo=bar
C:\Users\lee>echo %FOO%
bar
C:\Users\lee>echo %fOo%
bar
C:\Users\lee>set FOO=gum
C:\Users\lee>echo %fOo%
gum
C:\Users\lee>echo %FOO%
gum
C:\Users\lee>set | grep -i FOO
foo=gum

PS C:\Users\lee> $env:foo = "bar"
PS C:\Users\lee> echo $env:foo
bar
PS C:\Users\lee> echo $env:FoO
bar
PS C:\Users\lee> $env:FOO = "gum"
PS C:\Users\lee> echo $env:foo
gum
PS C:\Users\lee> echo $env:FoO
gum
PS C:\Users\lee> Get-ChildItem Env: | grep -i FOO
foo                            gum

Happy to do an issue/PR if this seems right.

Should probably do a look-see on macOS and Linux too….

macOS on default zsh:

❯ foo=bar
❯ echo $foo
bar
❯ echo $FoO

❯ FOO=gum
❯ echo $FOO
gum
❯ echo $foo
bar

@U04V15CAJ, when you have a moment to read the above, lemme know if you'd like an issue/PR on babashka/process

I don't think fs has to account for Windows flakes this much, Java also doesn't do that right?

Java does not seem to handle this well for process builder environment on Windows. Behaviour does not match Windows shell behaviour. System/getenv seems to behave like you'd expect though.

This is the first time I hear about this. Perhaps with Path/PATH it's more common, but I'd rather just fix our tests than having to do a str/lower comparison etc.

Might change my mind if this comes up more often

Well not many Clojure users use Windows, so there's that too... Path on Windows is normally updated via PATH when setting, but not for :extra-env . I personally think it is worth fixing, but of course, your call. I could do a little poking around to see examples of what others have done around process builder environment for Windows.

Can you formulate a clear problem statement and a proposed solution? I'm not sure I get it entirely.

Isn't the environment variable in Windows called PATH? Is it always called Path?

It's Path on my Windows VM, and apparently on @UBLU3FQRZ's Windows too.

Then maybe we should update Path and not PATH in the programs on Windows

I'm assuming Path is the default name of path on Windows. Could double-check that, but it seems to be the case.

If you do extra-env then you automatically merge the already set Path, so I don't see how that could go wrong

But technically (I'll also have to double-check this), PATH would be valid on Windows.

This is a snapshot of Control Panel (system environment setup) if it helps a bit

sorry for :flag-cz: UI but I don't have a different one 😄

Yah, thanks @UBLU3FQRZ, that helps.

Here's an openjdk bug someone raised around the issue: https://bugs.openjdk.org/browse/JDK-8245431

Windows on brand again

yeah ok. So I'm not going to compensate for JDK bugs more than I already have ;)

It might be practical to do so in this case?

but to add more confusion... if you run env command from powershell or cmd.exe there is PATH not Path... :thinking_face:

But if you run set in cmd.exe you'll see Path.

confirmed

So I think the JDK does not handle this well for Windows.

well, in such case I think well documented way to run programs. I mean to communicate requirements is a way to go.

Problem statement + proposed solution + considered alternatives welcome. My favorite alternative is "leave it" right now, unless I learn more in a digestible format that isn't a long-threaded conversation. ❤️

Ok, I think it is worth raising as an issue to consider in babashka/process. Will invest the time to do so.

I see Stackoverflow has a few issues on that one too. An example: https://stackoverflow.com/questions/48686267/windows-10-system-environment-variables-path-vs-path

Case sensitivity is the endless source of unexpected behaviour, not just on Windows, but also on Mac.

In a company where I work we have a 20+GB repo, that you cannot clone with Git on Mac because case sensitivity issue.

Ya, lotsa time spent on these inconsistencies and nuances.

Ok, fwiw, issue raised: https://github.com/babashka/process/issues/79

It’s never exciting to raise an issue about a Windows quirk nor an issue the project owner is not excited about! But I felt I should put in the work.

For interested lurkers, we decided to simply document the behaviour for now.