<Aurora_v_kosmose>manumanumanu: Incidentally, I found out you don't need full paths for open-pipe*. ***sneek_ is now known as sneek
***sneek_ is now known as sneek
<efraim>having a slow brain day, in the guile REPL (getcwd) returns a path, what magic am I missing from guile -c '(getcwd)' to have that same path printed in the terminal? <daviid>efraim: guile -c "(display (getcwd)) (newline)" <efraim>thanks. I knew it wasn't printf or echo <RhodiumToad>grumble. just had guile randomly abort when run from configure. for no reason I can detect <RhodiumToad>unfortunately this was in a bulk build and the core file was deleted <rekado_>hmm, Guile keeps crashing when I use char*->string on the result of (make-char*) that has been modified by a procedure in C. ***rekado_ is now known as rekado
*janneke has just bisected the first bug, and now hit another one, a hang <janneke>combine that with rekado's efforts and i guess it's our lucky day <rekado>I’m pretty sure it’s just my failure to understand the DRMAA C API and how the Guile FFI works. <civodul>janneke: compiling your reproducer with -O1 is another to make the bug go away :-) <janneke>yay, /me got the hang'er reproduced with static input <civodul>the GOOPS thing could be a different issue, no? <civodul>apparently it's the call to 'fk' that triggers the miscompilation <janneke>(yeah, GOOPS is probably different -- it just reminded me of juggling with optimizations) <janneke>ah nice, you went into expanding pmatch ***rubdos_ is now known as rubdos
*janneke sends another bug report <jlicht>what is the goal/purpose of `procedure-source'? All of the procedures on which I called it give `#f', unless I specifically set the property using e.g. `(set-procedure-property myproc 'source ...)' <miha>hello, can I work directly with unsigned integers in Guile? Or is everything wrapped in SCM? <chrislck>ok annoying that there's no searchable answer: if I (load "srfi-180.scm") from srfi-180, it won't work. srfi-180 is written in r7rs which is not default guile. How on earth do I import srfi-180 if I'm using regular guile?? <chrislck>the idea is to integrate with gnucash. it uses libguile. <lispmacs[work]>hi, does Guile have any special facilities for working with POSIX shared memory (shm_open, mmap, etc.)? <lispmacs[work]>I was doing this project in C where I was opening a shared memory segment and then mapping it out with one big struct in a header file <lispmacs[work]>so multiple programs that are not parent/child could refer to the same "variables", i.e., fields in the struct in the shared memory <lispmacs[work]>I'm sure I could figure out on the C side of guile how to access shared memory but suppose then there might be some messy FFI work or something for accessing the fields of the struct <leoprikler>as long as you got the struct parsing right, shared memory should not be much of a problem in Guile <leoprikler>you will probably have to deal with the pointer type, though <leoprikler>but you *can* use wrapped pointers as well as define your own records on top (though the C world will not see them) <leoprikler>chrislck: have you tried using a small wrapper, that sets up r7rs and then loads the actual source file? <leoprikler>guile does similar things for other SRFIs and stuff too IIRC <rekado>so, the segfault unsurprisingly happens because Guile says it can’t access the memory at the specified address. <rekado>I do (let ((message (make-char*))) (the-c-proc (pointer-to message)) (char*->string message)) <rekado>I see that “message” is a bytestructure; when I use bytestructure-ref on it I get an integer that corresponds to the memory address that Guile says it can’t access. <mwette>rekado: the-c-proc arg type is char* or char** ? If char**, is it allocating memory? <rekado>the procedure signature is “int the-c-proc(char* message)” <rekado>do I need to do something to allocate the char buffer first? <mwette>rekado: It looks like that to me. There is nothing automatic for strings, IIRC. Maybe make-bytevector, bytevector->pointer, (make-char* <pointer>) <mwette>then just pass the output of (make-char* <pointer>) where <pointer> is what you get from bytevector->pointer ***sneek_ is now known as sneek
<davexunit>bytestructures or something similar should really be part of guile core. it's a real weak spot of the ffi right now. <davexunit>python and ruby both have a way of defining classes that encapsulate C structs. <davexunit>wrapped pointer types are nice for libraries that mostly give you "handles" to things, but if anything expects you to pass in a big struct or retrieve data from a big struct then good luck because you're going to be mining bytevectors. <civodul>davexunit: or you could use 'parse-struct' & co. but that's pretty inefficient <stis>python on guile impemetns ctypes <rekado>mwette: thank you very much! This helped a lot! <rekado>C feels so much like assembly with more complicated syntax <davexunit>civodul: I use that sometimes when I can get away with it. it works, but getting a list dumped out isn't particularly structured and yeah it also performs badly. <davexunit>I can use it in places where allocation isn't a big deal. <davexunit>I want a record type-like interface that does all the C struct building/parsing for me. <davexunit>so I don't have to think about padding (which I always mess up) and stuff <davexunit>I wrapped part of libfreetype recently and I wrote some horrible code to get offsets into bytevectors with struct data to pull out the bits I needed. <rekado>davexunit: wouldn’t (bytestructures guile) help with that? <davexunit>rekado: yes it would, but my needs haven't been enough to merit the dependency burden. <davexunit>I guess like that syscalls.scm file, but public. <davexunit>my game dev stack so far has wrappers for sdl2, freetype, openal, inotify, libvorbis, libvorbisfile, mpg123. <davexunit>most of the these don't require a lot of struct fiddling. <civodul>yeah struct fiddling is often for libc and old-style libs <civodul>newer libs often use opaque pointers