On 12/09/13 11:04 +0200, Moritz Heidkamp wrote:
Hey Richo,thanks for your contribution to the Chicken ecosystem! richo <[email protected]> writes:I'd love a) For people to use it, and b) feedback on the code.As for a), I'm not an OS X user so I can't but as for b) I figured I can give you a small hint:(define (send datum thunk) (call/next-id (lambda (id) (register-callback id thunk) (with-output-to-port zeph-out (lambda () (let* ((payload (apply vector id datum)) (json-payload (json->string payload))) (write-string json-payload) (write-string "\n")))) id)))Here you can just immediately serialize JSON into the output port using `(write-json payload)`. Also, I would advise you not to use `with-output-to-port` but instead pass the port to write calls explicitly as implicitly redirecting output can be a source of very subtle bugs :-)
I missed that in the refactor. The original protocol required you to send the number of bytes in the json, as an ascii string, then a newline, then the json. I'll fix it in a sec. I'll also start explicitly using the port. Where can I read more about these subtle bugs?
I'm not sure I understand how `send-get-value` works. It kind of looks too clever to me but maybe I'm missing something.
Potentially. There are a ton of future'esque excamples, but this seemed
simplest. Basically a value (or more than one) will be returned by the
backend. This procedure just exposes a sync api on top of it.
The reason for the (mainloop) call is that otherwise the initial call returns
a garbage value and breaks everything. I've implemented the same logic with
the call/foo and foo implementations, and they seem equal (but I might be
missing something).
Thanks for the feedback
--
richo || Today's excuse:
Our ISP is having {switching,routing,SMDS,frame relay} problems
http://blog.psych0tik.net
signature.asc
Description: Digital signature
_______________________________________________ Chicken-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/chicken-users
