Clojurians Log v2

Have ended up encountering more issues here.

The inability to call any pod function from within a pod "method"

hangs bb in a deadlock

Im in the middle of invstigations...

oh, sorted it. My future for the callback had to encompass the method apply aswell... just moved my future a little further up...

Hey, now looking at this message.

Can you describe the problem to me in terms of examples / requirements instead of proposed code changes?

Is it related to https://github.com/babashka/pods#async?

hey! yeah. its the pod async callback

It would be awesome to make it possible for your callback to return a value, and that value could be sent to the pod, and used there

it's a while ago since I looked at it so maybe you can explain the idea to me in more general terms 😅

I have this bbssh pod underway. And in the pod I need to make a UserInfo class instance. And this is used by JSch to do things like, get the users password. Or ask for a passphrase for a key decryption. or some other things.

so when JSch calls a method on this class, like getPassword, I could fire an async callback in the bb code... maybe it would return a string. Or maybe it would prompt at the terminal. Or maybe it would open a window with a text prompt. The end user could determine that

but when that callback returns a value, it is just dropped

Its not a complete blocker, but if it were possible it would lead to a really elegant bbssh api

and if it is implemented, you could do even more with a pod

it would be pretty rarely used, but very useful to have

To recap for myself: In the case of the async watch function, what happens: The client calls watch, which is implemented as a client side function that calls the low level async pod api, which allows you to register a callback that gets called on 1 or more async replies (or an error handler). Those replies get sent back to the client. This is basically the same as a synchronous function call: client asks, pod sends back.

And now are asking beyond this, what exactly?

as it's not there I have to hard code the behavior here into the pod. This is the old spire UserInfo part: https://github.com/epiccastle/spire/blob/master/src/clj/spire/ssh.clj#L48-L60

so what Im asking is, you register the callback

that gets called one or more async replies (or an error handler). Those replies get sent back to the client as arguments on a :success, or a :error callback

yes. this already exists.. right?

and then... the return value of those callbacks is then send back to the pod along with the id

(this could be configurable somehow... or only if its not nil. Details could be worked out)

why - the pod sent those values to the client, why do you want to send them from the client to the pod?

because the client has now used those values to go and do something and return an answer that the pod needs

hmmmm...

or I could invoke again?

shouldn't the client just call another pod function then?

yes. that seems obvious... 🤔

thats basically what the response is going to do anyway

yep thats a good idea. a continuations style. call on with the answer

thanks! I don't know why I didn't think of that

too down in the weeds

happy to help :)

While I have you, one other thing I notice...

Is there an issue with async callback with {:transport :socket}

When I call it I get No matching clause

hmmm

don't know...

could be!

I'll just point at the code... 1 sec

it ends up here https://github.com/babashka/pods/blob/66867eee7f050af0126c83c876f8031e0eae709a/src/babashka/pods/impl.clj#L93 but pod is nil

and then it fails on the subsequent case for the encoding

and what is the encoding?

format you mean, right?

yes format

maybe you could insert some debugging

Im not sure why its nil. I just started digging into this

thanks

just checking its not something you know about?

doesn't ring a bell

ok cool. I'll find out whats going on

thanks again for the clarity

OK. Its not a bug.

its even in the docs, but maybe it's not as clear as it could be

https://github.com/babashka/pods#async The arguments to babashka.pods/invoke are: a pod identifier string derived from the first described namespace.

Maybe a better error when you get that wrong would be good?

I could add that if you would accept it

Sounds good, if there's not much of a performance impact

https://github.com/babashka/pods/blob/master/src/babashka/pods/impl.clj#L448 be just here. If this returns nil it raises an exception

bedtime for me. I'll continue this tomorrow. Thanks for your help

seems good, sleep well!

taking a return value from here: https://github.com/babashka/pods/blob/66867eee7f050af0126c83c876f8031e0eae709a/src/babashka/pods/impl.clj#L231

and encoding it and sending it back to the pod. with an id. and maybe into the pod with a new bencode command like retval

it would be up to the pod to get it to where it needs to go, with a promise or something.

would we make a new id and send with the invoke (this is your retval id, use it to deliver the return value)? Or could we use the existing invoke id?

What are your feelings on this kind of addition @borkdude? Assuming it could be done, is it something you would consider merging?

ok. amazingly I got this round trip pod->client->pod working! 🎉

its a bit of a dead-lock trap for the unwary

in particular I had to call the client->pod "return the result" call inside a future to prevent a deadlock in bb. For the brave and true who follow along in the future: https://github.com/epiccastle/bbssh/blob/0958baa17c42cb0b22f73852dcbd05a5639015dc/src/bb/pod/epiccastle/bbssh/user_info.clj#L27

I also had to improve my own pod mainloop code. I had some similar issues in it.

it's quite amazing to see. so this code: https://github.com/epiccastle/bbssh/blob/0958baa17c42cb0b22f73852dcbd05a5639015dc/test/bb.clj#L34-L61

defined all the "methods" on the object (that lives over in the pod)

and they will be called in your bb code as they are called over in the pod, and your return values will be returned

pretty cool stuff

good to hear!