<gagbo>Hello, I'm trying to make a xi-editor frontend (just for context, not relevant here). I have 2 ports for IO using json-rpc with the back-end process, but I have no idea about how usually communication is done (that's why I'm trying to do this project) <gagbo>I can't have the "send" functions synchronously wait for the backend answer (it seems bad) ; but currently my "listener" thread design doesn't have the context of the "sent message" call. Should I use continuations somehow to make it work ("it" : I send a "new_view" message => I get a "view_id" response from the backend ; and somehow in Guile I can have code like (xi-msg "new_view") that evaluates at some point to the <gagbo>"view_id" response of the backend) <linas>Hey wingo or civodul, would you be interested in a patch to add Zipfian random numbers to libguile/random.c and if so, best way to submit it? <wingo>i don't know what zipfian numbers are :) <wingo>i think we could consider it but there are a few questions <wingo> - how useful is it? what fraction of random number users would want it? <wingo> - it would nice a precise but brief description in the manual with a pointer to where to learn more <wingo>RhodiumToad: good to know :) <wingo> - how would a c implementation compare to a scheme implementation? i assume you can implement on top of a linear random number implementation <linas>Yeah, its a very non-obvious implementation on top of a uniform distribution. <linas>Not a lot of cpu cycles, but .. just very non-obvious <linas>it shows up in scale-free networks: natural language, genomics, proteomics <linas>I have existing C++ code, and I was going to write a guile wrapper for that code .. anyway, cause I need it. <wingo>the c/scheme question comes from two places, one is that c code costs more to maintain so i hesitate more <wingo>and the other is that i would like for scheme to be fast enough to use as implementation for this kind of thing. <linas>ah, yes, it is easy enough I could just write it in scheme... <wingo>with unboxed floats i think it may be workable <linas>like 4-5-6 lines of scheme, I guess... <wingo>store any state you need as a f32vector / f64vector and things will pop out of the state unboxed, and will remain that way unless they hit an operator that doesn't yet have support for unboxed floats <wingo>which points to an area that we should work on :) <linas>should I send a patch on debbugs mailing list, or something else? some git pull req? *janneke is considering calling Scheme "A functional Lisp" instead of "Modern" <jcowan>All Lisps are functional Lisps. And CL is technically more recent than Scheme, though it has not turned its back on the Lisp past as Scheme has (to a degree, not entirely of course) ***wxie1 is now known as wxie