IRC channel logs


back to list of logs

<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?
<wleslie>'(display (getcwd))'
<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>hmm, not a good day for Guile
<lloda>finding bugs is good
<janneke>lloda: yes, thanks for the heads-up
*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>civodul: ah, that's a nice trick!
<janneke>already pointing sharper
<janneke>civodul: somewhat reminds me of
<janneke>yay, /me got the hang'er reproduced with static input
<janneke>now to bisect
<civodul>janneke: further reduced:
<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??
<rekado>chrislck: --r7rs
<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]>was wondering if something similar could be done in Guile
<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.
<stis>hey guilers!
<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>this is fun!
<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?
<civodul> has code similar to bytestructures but less sophisticated, expansion-time only, and more compact
<davexunit>rekado: yes it would, but my needs haven't been enough to merit the dependency burden.
<davexunit>guile core should really have something.
<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