***sneek_ is now known as sneek
<manumanumanu>after one week trying to re-learn german, english exits my brain <taylan>I'm mostly picking low-hanging fruits :) <manumanumanu>well, for one thing those fruit start looking bad if they are hanging for too long. I am slowly digging my way through guiles internals to hope I can do it myself some day <mwette>taylan: working ffi-heper stuff today ... ***zap1 is now known as zzappie
<soda__hobart>does anybody know why after calling scm_init_guile in a C++ program, the expected behavior of char* strings (received from a network socket and sent by a guile program) changes? i think it has something to do with whether they are null-terminated. does some environment variable get changed by calling scm_init_guile? i'm getting a few characters of cruft on the end of the strings. <soda__hobart>i bet it's a geiser/emacs thing, probably different environment vars than what you get from scm_init_guile <lampilelo>"expected behavior changes" from what to what? <soda__hobart>ok, for example: i comment stuff out so i DON'T call scm_init_guile in my program. while the program (it's a server) is running, i use the guile REPL to send a data serialized to bytes (using rnrs bytevectors, etc.) through a local socket to the server. the server de-serializes the bytes and initializes a struct, and then dispatches some functions based on string lookups ("quit" makes it exit, etc.) --this all works as expected <soda__hobart>but if i do call scm_init_guile, then all the strings i send have to be written like "quit\0" or else there is cruft on the end <mwette>locale issue? I'd try env LANG=C . <wingo>soda__hobart: either as mwette says, or GUILE_INSTALL_LOCALE=0 in environment <wingo>see Environment Variables in the manual <soda__hobart>oh ok, cool, i was just looking at it, but this clears it up for me i thnk <soda__hobart>hm, no luck. well, i'll just have to study the documentation more but i'm going to play outside now :) o/ <mwette>wingo: If you are interested, taylan and I are dealing with generating FFI code in situations where C declarations do not provide enough size information to indicate how large a containing bytevector should be. Examples are where C pointers provide an address of an unknown vector size, or pointer to struct where latast element is something like "foo_t x[];" This is somewhat analygous to using "char *" for strings. <mwette>One option to handle this is to have unsafe-bytevector where set and ref are not checked for size. Another option is to force the user to somehow deal with the size, but that would take some work in the type handling and could be inefficient. Thoughts? <ArneBab>wingo: thank you for working on the core of Guile! It’s awesome where you already took it! — no special reason for saying it now, except that now is always a good time to say thank you.