If you wanna try:

$ bash <(curl ) --version 0.8.3-SNAPSHOT --dir .

$ ./bb schema.clj

(ns schema)

(require '[babashka.deps :as deps])
(deps/add-deps '{:deps {prismatic/schema {:mvn/version "1.2.1"}}})

(require '[schema.core :as s])

(def MySchema {:a [s/Int]})

(prn (s/validate MySchema {:a [1 2 3]}))

(try (s/validate MySchema {:a [:foo]})
     (catch Exception e
       (prn (:error (ex-data e)))))

Very nice! I'm going through the schema code to see if I can improve the bb support from there https://github.com/plumatic/schema/pull/440/files

Gonna look into that record equivalence issue now

@U055XFK8V Pushed a fix for record (non-)equivalence to babashka master now. So I think you can remove the workaround in schema

@U055XFK8V macOS binary should be installable now with the same invocation as earlier

I'm going to check out your branch, I lost my earlier work where I got the tests running :(

the defrecord fix works I think! currently investigating a locals clearing issue. something to do with the infinite-arity-fn-test test

note that my branch only runs schema.core-test atm

yeah, I've only tested that previously too

should clojure.lang.MultiFn/addMethod work in bb?

I could expose that

not currently

I worked around it just fine fwiw

Here's a witness for the locals clearing (I think) https://github.com/plumatic/schema/pull/440/files#diff-fe966952e8b139238a859638669987516020fd5f9520243788d79a1987723e3dR257

./bb test  
ERROR in (infinite-arity-fn-test) (/Users/ambrose/Projects/schema-local-dev/bb-test-suite/test/cljc/schema/core_test.cljc:)
expected: (= 5 (f 4))
  actual: java.lang.AssertionError: Assert failed: input-checker-sym local cleared!!!
G__5086
 at java.lang.reflect.Constructor.newInstance (Constructor.java:490)
    sci.impl.Reflector.invokeConstructor (Reflector.java:310)
    sci.impl.interop$invoke_constructor.invokeStatic (interop.cljc:57)
    sci.impl.analyzer$analyze_new$reify__8934.eval (analyzer.cljc:880)
    sci.impl.analyzer$analyze_throw$reify__8890.eval (analyzer.cljc:777)
    sci.impl.analyzer$return_if$reify__8849.eval (analyzer.cljc:669)
    sci.impl.analyzer$return_do$reify__8163.eval (analyzer.cljc:136)
....

Oh, interesting I get this error on JVM: Error: Exception in thread "main" java.lang.RuntimeException: Conditional read not allowed, compiling:(schema/macros.clj:243:72) Looks like bb is more lenient?

Yeah, bb is more lenient :)

Settled on checking babashka.version 🙂 if I changed it to .cljc, cljs tries to compile it...

Yeah, that works

@U055XFK8V Thanks for the issues!

About the local clearing issue, I'm not what the problem there is

For now I used a workaround that pushes the locals into the fn.

I don't even understand what the issue is, do you have a tiny repro of that, or is it not important?

Not yet, tried several times. Basic issue seems to be local being cleared in code like (let [local (delay)] (fn [] ... @local)) but I can't find a minimal reprod.

In particular local is nil at @local and throws a NPE. Assuming it's related to locals clearing.

That would be very interesting to find

Yes, I'll keep trying.

Thanks, this is really good for improving SCI. About foo.bar` resolving to user/foo.bar, that's interesting. Apparently (def foo.bar 1) is allowed, but maybe just by accident.

Weird!

Ah I see, so:

Symbols containing / or . are said to be 'qualified'.

This might be the reprod:

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

user=> (defn minimal []
  (let [f (let [cleared 1]
            (fn ([a] (inc cleared))
              ([a & bs])))]
    (assert (= 5 (f 4)))))
#'user/minimal
user=> (minimal)
java.lang.NullPointerException [at <repl>:3:22]

I'll try and reduce some more. Related to multiple (+rest) arities it seems.

Smaller:

user=> ((let [cleared 1]
          (fn ([] (assert cleared))
              ([& bs]))))
java.lang.AssertionError: Assert failed: cleared [at <repl>:1:1]

Can't make smaller. I'll open a bb issue.

https://github.com/babashka/babashka/issues/1270

That's a great find! Thanks!

Interestingly aliases can contain dots:

user=> (require '[clojure.set :as c.set])
nil
user=> `(c.set/union )
(clojure.set/union)

So it seems just "simple symbols" with dots should remain "unresolved"

Yes, I'm guessing the thinking is that it might be an unresolved reference to a class.

right, the class foo.bar (similar to foo.baz.Bar )

makes a ton of sense

OK, the reader issue is pushed to SCI and bb now. The rest I'll look into later this week

nice!

All issues fixed :)

It seems:

Ran 95 tests containing 506 assertions.
2 failures, 0 errors.

It seems Testing schema.coerce-test are also passing :)

Nice thanks!

@U055XFK8V Exciting stuff. Let me know if there's anything left to do. If not, maybe we can launch a new bb soon which will be able to run schema!

I guess we could wait for the PR to be merged and a new version of schema to be released

😄 Yes, I'll work on the PR. I'm a maintainer on schema now, should be lower friction.

Another problem related to marker protocols: https://github.com/babashka/sci/issues/743

Thanks! Will fix now

Another issue with syntax quote https://github.com/babashka/sci/issues/744

maybe that last one isn't a bug. LMK

Yeah actually, it's unrelated to the "problem" I saw.

It's an edge case, records aren't really classes in SCI, since SCI cannot create new classes, so those things are implemented differently

Is there a way to get the original class from a fake record class symbol?

I mean, the original class name.

That symbol is the name

but these are a bit implementation-detail-ish, I don't know if I might change this in the future

let's see

yeah, so:

user=> (defrecord Foo [])
#'user/Foo
user=> Foo
user/Foo

I mean, something equivalent to .getName on a class.

yes, the record "var" is bound to a symbol, which is the name

user=> (str Foo)
"user/Foo"

Yes, but I want the "fake" JVM name.

That would be a string replace / to .

user=> user.Foo
user/Foo

Hmm dashes=>underscores though?

yeah, munge

hmm, that's not something SCI does correctly at the moment

Are you using records with hyphens in them?

yeah schema.core_test.Foo

oh, so the ns name... lemme test

yeah, that works:

user-foo=> (defrecord Foo [])
#'user-foo/Foo
user-foo=> user_foo.Foo
user-foo/Foo

Maybe I should invent a new type for this which prints as the java name

or so

can you make a magic type that responds to (.getName ^Class %) ?

I don't think that'll work... since then I would have to create something of type Class that can give a different name

of course we can special-case the interop, but that feels a bit hacky

Does this relate to the two remaining failing tests btw?

It relates to schema.core-test/record-test which I just uncommented

It's just a printing problem I think.

(not (= (record schema.core_test.Foo {:x Any, (optional-key :y) Int})
        (record schema.core-test/Foo {:x Any, (optional-key :y) Int})))

testing s/explain

Why is the var #'Foo needed here? Could we just return a symbol 'schema.core_test.Foo from defrecord and class references like Foo?

The var is necessary so I can store things on it, like the print-method

but the symbol stored in the var could be more like the class

and then it will likely print the same

Is defrecord returning #'Foo instead of 'Foo an oversight? I was hoping for a general pattern like "record classes in bb are like clj, except sometimes they are symbols". Here it's a var.

the return value we could change

cool. I think returning a symbol naming the class is a good solution.

ok we'll do that

still figuring out the satisfies one

Might be worth testing how symbol resolution works on a record that's imported from another ns.

That should already work correctly

Tried it, syntax quoting it doesn't work, resolves in the current ns on an imported record.

bar=> (import user.Foo)
user/Foo
bar=> `Foo
bar/Foo

Ah you mean in syntax quote

ok, another thing to fix

can you also post an issue about that?

yep https://github.com/babashka/sci/issues/745

ok, the satisfies? change is up now

Pushed this change now:

(defrecord Foo [])
user.Foo

satisfies? change works!

🎉

will (= Foo 'user.Foo) ?

yes

Double-checked:

$ clojure -M:babashka/dev -e "(defrecord Foo []) (= Foo 'user.Foo)"
true

woop! should be just those 2 tests left. no idea what they are about yet.

744 pushed

nice, that fixed one test. another popped up due to Explainer => schema.core-test/Explainer`

Not sure what you mean with "another ...", a new problem or a problem solved?

good question...

how can I download the previous snapshot?

I deleted the bb.old LOL

It should be fixed by the current build anyway https://github.com/babashka/babashka/commit/6089496d9c8c1a58941c884d8ebc715382412bf9

The test fancy-explain-test started failing. I think it's because the left side of the (is = uses class resolution for the record class name, and the right side uses syntax quote. So was "working" before you "broke" one side. Just a coincidence, if you'd have fixed both problems at once, it would have passed.

confirmed, fixed! 2 failures left.

ok, 745 in progress, going to take a small break now

there's a problem with the pprint changes (just uncommented the test), getting a SOE. investigating..

maybe you can make sense of the trace https://github.com/plumatic/schema/runs/6514340379?check_suite_focus=true#step:9:21

@U055XFK8V Will continue tomorrow, I'm out of dev budget for today :)

If you manage to make a repro, I'll look at it tomorrow

@borkdude thanks! have a great one

@U055XFK8V All solved now, I think

Just tried it, SOE is fixed but:

FAIL in (pprint-test) (/Users/ambrose/Projects/schema-local-dev/bb-test-suite/test/cljc/schema/core_test.cljc:)
expected: (= "(maybe Int)" (str/trim (with-out-str (pprint/pprint (s/maybe s/Int)))))
  actual: (not (= "(maybe Int)" "{:schema\n {:p?\n  #object[clojure.core$integer_QMARK_ 0x2104eb01 \"[email protected]\"],\n  :pred-name integer?}}"))

I'll look into it later

Aha

So somehow the print-method isn't correctly registered... wonder where that's defined

or rather, simple-dispatch

https://github.com/plumatic/schema/blob/1116d1c68347b980ca03a7d4458213b4e13323ae/src/cljc/schema/core.cljc#L125-L130

It's an indirect extension, via a protocol interface

that's fine

So this example works:

(defrecord Foo [x])

(require '[clojure.pprint :refer [simple-dispatch]])

(defn print-awesome [_foo]
  (println "<<<<foo>>>>"))

(defmethod simple-dispatch Foo [o]
  (print-awesome o))

(clojure.pprint/pprint (->Foo 1))

This works too:

(defrecord Foo [x])

(require '[clojure.pprint :as pprint])

(clojure.core/defmethod pprint/simple-dispatch Foo [_]
  (pprint/write-out "<<<<foo>>>>"))

(clojure.pprint/pprint (->Foo 1))

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

user=> (defprotocol P)
#'user/P
user=> (defrecord R [])
user.R
user=> (defmethod clojure.pprint/simple-dispatch user.P [_] (println "PRETTY"))
#object[clojure.lang.MultiFn 0x6c3bc635 "[email protected]"]
user=> (clojure.pprint/pprint (R.))
{}
nil

Right! I was just trying:

(ns foo)
(defrecord Foo [x])

(ns bar
  (:require [clojure.pprint :as pprint]))

(clojure.core/defmethod pprint/simple-dispatch foo.Foo [_]
  (pprint/write-out "<<<<foo>>>>"))

(clojure.pprint/pprint (foo.Foo. 1))

This still works for me:

(ns user
  (:require [clojure.pprint :as pprint]))

(defrecord Foo [x])

(clojure.core/defmethod pprint/simple-dispatch user.Foo [_]
  (pprint/write-out "<<<<foo>>>>"))

(clojure.pprint/pprint (->Foo 1))

I'll try yours

doh, I forgot to extend the protocol 🙂

multitasking sorry

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

user=> (defprotocol P)
#'user/P
user=> (defrecord R [] P)
user.R
user=>  (defmethod clojure.pprint/simple-dispatch user.P [_] (println "PRETTY"))
#object[clojure.lang.MultiFn 0x6c3bc635 "[email protected]"]
user=> (clojure.pprint/pprint (R.))
{}
nil

clj                                                                                                                               
Clojure 1.11.1
user=> (require 'clojure.pprint)
nil
user=> (defprotocol P)
P
user=> (defrecord R [] P)
user.R
user=> (defmethod clojure.pprint/simple-dispatch user.P [_] (println "PRETTY"))
#object[clojure.lang.MultiFn 0x7cedfa63 "[email protected]"]
user=> (clojure.pprint/pprint (R.))
Execution error (IllegalArgumentException) at user/eval171 (REPL:1).
Multiple methods in multimethod 'simple-dispatch' match dispatch value: class user.R -> interface user.P and interface clojure.lang.IPersistentMap, and neither is preferred

Right, so :

(ns user
  (:require [clojure.pprint :as pprint]))

(defprotocol Schema)
(defrecord ASchema []
  Schema)

(defrecord Foo [x])

(defmethod clojure.pprint/simple-dispatch user.Schema [_] (println "PRETTY"))

(prefer-method clojure.pprint/simple-dispatch user.Schema clojure.lang.IRecord)
(prefer-method clojure.pprint/simple-dispatch user.Schema java.util.Map)
(prefer-method clojure.pprint/simple-dispatch user.Schema clojure.lang.IPersistentMap)

(clojure.pprint/pprint (ASchema.))

exactly

Oh, so a simple-dispatch on a protocol... damn, I only supported it for a record now I think ;)

the same logic is used for print-method, is there anything special in sci to handle that? https://github.com/plumatic/schema/blob/1116d1c68347b980ca03a7d4458213b4e13323ae/src/cljc/schema/core.cljc#L123-L124

yes, protocols aren't really types in SCI, because again, SCI cannot really create new JVM types

so it's all custom

but I can probably apply the same trick as I did with records to protocols

I added another test, this branch isn't being hit either https://github.com/plumatic/schema/pull/440/commits/e79497a4dc32171129b189572d1088292ae18270

FAIL in (print-method-test) (/Users/ambrose/Projects/schema-local-dev/bb-test-suite/test/cljc/schema/core_test.cljc:)
expected: (= "(maybe Int)" (str/trim (with-out-str (println (s/maybe s/Int)))))
  actual: (not (= "(maybe Int)" "#schema.core.Maybe{:schema #schema.core.Predicate{:p? #object[clojure.core$integer_QMARK_ 0x2104eb01 [email protected]], :pred-name integer?}}"))

This is going to take me some more time, maybe later this weekend

isa? might be the root cause https://github.com/babashka/sci/issues/750#issuecomment-1133075809

Assuming bb uses the same multimethod impl as clojure

Yeah, it's a little bit more complicated than that

Currently the SCI context in bb uses the global print-method / simple-dispatch

and those global methods use the global core's isa?

I'll have to think a little bit more about this, my brain hurts ;)

Why doesn't this print "P"?

(ns dude
  (:require [clojure.pprint :as pprint :refer [simple-dispatch]]))

(defprotocol P)

(defrecord R [] P)

(defmethod simple-dispatch dude.P [_]
  (println "P"))

(prefer-method simple-dispatch dude.P clojure.lang.IRecord)
(prefer-method simple-dispatch dude.P java.util.Map)
(prefer-method simple-dispatch dude.P clojure.lang.IPersistentMap)
(prefer-method simple-dispatch dude.P java.lang.Long)

(extend-protocol P
  java.lang.Long
  (explain [_] "yo"))

(pprint/pprint 1)

I think it's a bad idea to change the pprint-ing of types you don't own anyway. It seems schema has to attach the pprint-method to something in order to trigger explain. And that something seems to be records.... right?

So would it be sufficient if (for now) if SCI made simple-dispatch + protocol work only for records that implement that protocol?

I guess a workaround for the current version would be to do:

(defmethod simple-dispatch Maybe [x] (pprint/write-out (explain x)))

E.g. this works as is in clojure and bb (master) without prefer-methods:

(require '[clojure.pprint :as pprint :refer [simple-dispatch]])

(defprotocol Schema
  (explain [_]))

(defrecord Maybe []
  Schema
  (explain [_]
    "M"))

(defmethod simple-dispatch Maybe [x] (pprint/write-out (explain x)))

(pprint/pprint (->Maybe))

> Why doesn't this print "P"? I believe it's because isa? uses Class/isAssignableFrom, not clojure.core/extends?.

> So would it be sufficient if (for now) if SCI made simple-dispatch + protocol work only for records that implement that protocol? That's a good start yes. I can manually add that code in schema.

You would only have to add code as of now, not if SCI would support the "good start", then it would work as is, I think?

Doh I misread your proposal twice xD

Your proposal sounds perfect, I can't think of any other cases that are important tbh?

So to recap: 1. schema could make it work with bb master by adding the explicit record print-methods 2. SCI could potentially fix protocol printing for records, then you would not have to change anything

I will try 2 but not sure how easy it is, but we'd still have 1 as a fallback and it would not be incorrect to add it

I'm going to try 1), I think this approach is needed for CLJS support for these two multimethods (currently the extensions are #?(:clj ..).

I can then just delete the :bb branch if/when support works in sci.

but 1 already works in bb (master)

so then 2 becomes less important (for schema)

yep exactly. Only important for libs that provide new schemas. Probably can revisit this if we find another library that needs this pattern.

Right, so in CLJS:

(require '[clojure.pprint :as pprint])

(defprotocol Dude
  (explain [_]))

(extend-protocol IPrintWithWriter
  Dude
  (-pr-writer
    [_this w _]
    (.write w "hello")))

(defrecord DudeR []
  Dude)

(pprint/pprint (->DudeR))

yes I don't think this shortcut exists in cljs

ok, lucky for SCI then ;)

looks like print-method doesn't exist in cljs and cljs.pprint/simple-dispatch is basically a closed system..

so it'll be sci-specific for now, but potentially useful for cljs if those restrictions are lifted.

What about extending IPrintWithWriter on each record, or does schema already do that?

that's AFAIK how you make pretty-printing work in CLJs

No sorry, prn I mean

for pprint, I found this: https://stackoverflow.com/a/15183440/6264

amirite that Schema does not do the pretty printing stuff for CLJS right now?

I guess so:

cljs.user=> (cljs.pprint/pprint (s/maybe s/Int))
{:schema {:p? #object[cljs$core$integer_QMARK_], :pred-name integer?}}

I guess people could just use:

(str (s/explain (s/maybe s/Int)))
"(maybe Int)"

yeah, no cljs printing support at all except explain. thanks, I'll use those two approaches!

for pprint: cljs.pprint/simple-dispatch uses a fixed dispatch table, I don't think the same approach works as clojure.pprint/simple-dispatch. Can't see any handy alternatives.

Maybe summon the #clojurescript people? I also don't know...

oh, it defaults to pr-str. That's probably fine.

the good news is that the bb support is almost done, but I can't figure out why IPrintWithWriter doesn't work in cljs:

./bb test
....
FAIL in (simple-validated-defn-test) (/Users/ambrose/Projects/schema-local-dev/bb-test-suite/test/cljc/schema/core_test.cljc:)
expected: (= +simple-validated-defn-schema+ (s/fn-schema simple-validated-defn))
  actual: (not (= (=> (both Str (pred odd-str?)) (both (pred odd?) long)) (=> (=> (maybe (=> Any Any)) (protocol s/Schema)) [(=> (maybe (=> Any Any)) (protocol s/Schema))])))

FAIL in (simple-primitive-validated-defn-test) (/Users/ambrose/Projects/schema-local-dev/bb-test-suite/test/cljc/schema/core_test.cljc:)
expected: (= +primitive-validated-defn-schema+ (s/fn-schema primitive-validated-defn))
  actual: (not (= (=> long (both (pred odd?) long)) (=> (=> (maybe (=> Any Any)) (protocol s/Schema)) [(=> (maybe (=> Any Any)) (protocol s/Schema))])))
....
Ran 113 tests containing 587 assertions.
2 failures, 0 errors.

notice the pretty output 🙂

@U055XFK8V Looking good. But now what, still failing tests for bb? ;)

Everytime I fix something, there are still 2 failing tests, bwhaha

LOL yes, the 2 remaining tests looked a real pain to debug without pretty printing, so they've been failing this whole time.

we've been making progress, I kept uncommenting tests and we've been knocking them over 🙂

Ok I think the problem is that schema holds a global registry of Class => schema to lookup defn schemas. I assume all defn's in bb are the same class and every defn just clobbers each other. This is probably the most fragile part of schema IMO.

yeah, each same-arity function is re-using the same JVM function object

I think I can just use the cljs approach in bb, which is to associate fn identity with a schema instead of its class.

./bb test

Testing schema.core-test

Testing schema.macros-test

Testing schema.coerce-test

Testing schema.experimental.abstract-map-test

Testing schema.test-test

Testing schema.utils-test

Ran 113 tests containing 587 assertions.
0 failures, 0 errors.

wwwwwww00000t!!!!!

😄 😄

congrats!

you too!!!

now I just need to figure out the cljs pprinting then I'll get this merged

So, how reliant is schema on record "classes" being a symbol etc in bb? I'll be back tomorrow, need to sleep now

it may be impossible actually, the map implementation takes over. I'll just comment it out.

do a grep for :bb in my branch, you'll see some class? calls broadened to (some-fn class? symbol?). it's not too bad.

the class is mostly kept around for printing purposes.

I wonder if we could/should make SCI/bb user code more resilient against this implementation choice. What if we want to move the record representation from a Symbol to a deftype later on for example

That's the only thing I worry about with this PR

I guess a more cross-platform way would be to do:

(-> (str klazz) (str/split #" ") last)

and we could promise that as a stable API...

(not completely satisfying either maybe)

I guess SCI could offer an API to interrogate this, like:

sci.core/record-class?

babashka.core/record-type?

babashka.core/type-name

@borkdude yes that sounds much better than symbol? checks.

OK, so maybe sci itself could expose such things in all SCI environments

then it would also work for nbb, etc

I'm trying to implement type-name now...

(defn type-name [x]
  (if (and (symbol? x)
           (-> x meta :sci.impl/record))
    (str x)
    #?(:clj (class x))
    #?(:cljs (.-name x))))

but how do I do this in CLJS properly, I wonder

maybe nil should be interpreted as: don't know, you're on your own. it seems getting the name from (defrecord Foo []) is impossible in CLJS right now

Btw, this looks suspicious:

#?(:clj java.util.regex.Pattern :cljs nil) 'Regex

Perhaps record-type-name is a better API name and then I'll only give back a string for records and nil for other things

user=> (sci/eval-string "(defrecord Foo []) (sci.runtime/record-type? Foo)")
true
user=> (sci/eval-string "(defrecord Foo []) (sci.runtime/record-type-name Foo)")
"user.Foo"

Pushed that to master now (sci + bb)

Let me know if that works for you

> but how do I do this in CLJS properly, I wonder It looks like schema just gives up in this case and returns the entire prototype https://github.com/plumatic/schema/blob/1116d1c68347b980ca03a7d4458213b4e13323ae/src/cljc/schema/core.cljc#L199

> Let me know if that works for you it feels like this abstraction could be a bit cleaner. it seems too tied to records, I think I want an abstraction over 1. "is this a fake class/prototype created due to limitations of sci" and 2. "what is the name of this class/prototype, if any?". could we reify these metadata symbols as records themselves? like provide a sci.runtime.Type record that responds to a type-name fn that returns a nilable string. That way if you decide to fake classes for other things (definterface, defprotocol, deftype etc), you can build on top of Type without requiring changes in schema. and anywhere you normally do (extend-protocol ... Class) you can do (extend-protocol ... sci.runtime.Type) also, without clashing with existing (extend-protocol ... Symbol).

https://github.com/babashka/sci/issues/753

Let me know if that sounds good

https://github.com/babashka/process#clojurepprint

The docs says either works.

Then the docs need updating

PR welcome, let's remove the second suggestion

Is it confirmed or my personal false test?

I think the first suggestion works more reliably

Yet, I don’t understand why a prefer is added but still the warning occurs.

Me neither

This may give you some ideas: https://gist.github.com/borkdude/82dcdd36a1e61ef36f19221876e7b1b6

oh I see

you may just do :in :inherit I think

then you will not use the *in* from Clojure yet

E.g.

$ bb -e '(babashka.tasks/shell "fzf") (read-line)'
wotbrw.clj
1
"1"

^ @U09QBCNBY

Thanks, that's perfect! Out of curiosity what am I'm doing wrong below. task below waits for fzf input, but then does not wait for read-line input:

;; Invoked with `find * -type f | bb some-task`
  some-task {:requires ([babashka.process :as p])
             :task
             (let [fzf (p/process ["fzf" "-m" "--print-query"]
                                  {:in :inherit
                                   :err :inherit
                                   :out :string})
                   proc (:proc fzf)
                   pick (:out (deref fzf))
                   _ (prn "pick result" pick)
                   _ (do (print "input: ") (flush)) 
                   read-input (read-line)]
               (prn "read-line-input: " read-input))}

you need to deref the process

so it will block

the fzf process is being deref'd, I believe

I'll be back tonight

Thanks again!

ok, so what's up

So this works:

{:tasks {some-task {:requires ([babashka.process :as p]
                               [babashka.fs :as fs]
                               [clojure.string :as str])
                    :task
                    (let [fzf (p/process ["fzf" "-m" "--print-query"]
                                         {:in (str/join "\n"
                                                        (map str (remove fs/directory? (fs/list-dir ""))))
                                          :err :inherit
                                          :out :string})
                          proc (:proc fzf)
                          pick (:out (deref fzf))
                          _ (prn "pick result" pick)
                          _ (do (print "input: ") (flush)) 
                          read-input (read-line)]
                      )}}}

I think you could do the input argument to fzf via a command line args rather than via stdin

You can get command line args with *command-line-args*

I need to allow the user to use the fuzzy finding interface of fzf ... where they type and see how the list filters. (as opposed to passing a string before hand via command-line-args

yes. you can do that like in the above?

yes, absolutely, just tried it! thanks so much for your time!

Alright, I will try that, thanks!