IRC channel logs
2023-01-12.log
back to list of logs
<flatwhatson>re: bytevector-slice, nice to have something less hacky than (pointer->bytevector (bytevector->pointer bv offset) size) <daviid>guilers, let me shorten the quiz: i'd like to create a ffi-make-cif proc that calls the libguile/foreign.c make_cif function, how/what the shortest and best way? <akirakyle>daviid: I just got Warning: Unimplemented (prepare args-in) type - array;: (c -1 #f 1 interface) <daviid>akirakyle: ok, can you paste a snipset to reproduce, then i can add support for that type ... <daviid>akirakyle: i'll fix it, but i'd apreciate a smalest possible full/complete/executable scheme snipset to reproduce it - i am heads down to solve the snapshot and draw-glyph(s) bug (there are 'the same bug') <flatwhatson>daviid: make_cif is a helper for pointer->procedure and procedure->pointer <akirakyle>daviid: Is what I just send ok? I can try to make it more minimal if possible? <flatwhatson>it returns a pointer to a C struct, so wrapping it directly would involve creating a scheme type to represent the values of that struct <daviid>akirakyle: that doesn't look like the smalest reproducible but i'll look at it asap - a small snipset would just call that proc that fails (ans et-up what it needs) ... <akirakyle>daviid: Also not quite sure what you mean by "i am heads down" <daviid>flatwhatson: i need to call make_cif, fro scheme <daviid>flatwhatson: and receive the pointer to the ffi_cif pointer it returns <daviid>flatwhatson: i did think about that, but it doesn't seem pointer->procedure would let me access make_cif from libguile <flatwhatson>daviid: what would you then do with a scheme-wrapped ffi_cif*? presumably you really want a scheme representation of a C function prototype? <daviid>flatwhatson: i would pass that pointer to GI, let's concenrtrate on how may i call make_cif, from scheme <flatwhatson>you write a pretty straightforward C wrapper using the SCM_DEFINE macro from libguile, and pack the *ffi_cif into an SCM with scm_to_pointer <daviid>i need a C function that i can then call using the ffi <daviid>akirakyle: perfect! i'll look into it as soon as i will have fixed the ffi make-cif related bug ... <akirakyle>daviid: Also I'm still confused by your "i am heads down" comment? <daviid>akirakyle: tx! it's nice you are playing with all those snapshot pango ... libs, i have very limited knowledge of those ... and they sinply trigger bugs :):) <daviid>akirakyle: 'heads-down' is an expression to say i am concentrating full time, 1000%, no sleep, no rest ... :):) on somehting ... <akirakyle>daviid: Yes :) I think if g-golf can handle this stuff, it should really be able to handle anything! <daviid>an expresion to say 'nothing will grab you 'out of' until solved ... <daviid>i need a guiler to help me to call make_cif ... it's not so easy apparently, or they are all 'heads-down' to something :):) <flatwhatson>daviid: if you want to use the ffi (instead of writing a C extension for guile), you can probably call make_cif directly from scheme already <akirakyle>daviid: Thanks! I think fixing this unimplemented bug will then make this pango renderer and text render node bug more clear since it should then (mis)handle multi-line text <daviid>flatwhatson: i am all hears, i can' t call make_cif until someone helps me, can you paste an example, tx <daviid>make_cif isn't callbale from scheme afaict <akirakyle>daviid: Maybe I can help with this make_cif, but I'm still not sure what the context is for needing to call make_cif which might help me? <daviid>no context, i need to call make_cif <daviid>(make-cif 'double (list int '* double ...)) <daviid>(make-cif void (list int '* double ...)) ... <flatwhatson>daviid: the problem is that make_cif is an internal helper in libguile, not exposed in the public API <daviid>and it gives me the libguile ffi_cif pointer fantastically built by our belved maintainers :) <daviid>and i need a way to call it :(:):):)::) <flatwhatson>daviid: so whichever way you go, you can't! not without patching libguile to make it a public API <akirakyle>daviid: and then GI has functions which accept ffi_cif structs? <daviid>flatwhatson: how about patching an external C program that uses libguile? <daviid>akirakyle: i won't answer thos equix are taking my time, sorry <flatwhatson>daviid: in the libguile.so, there's no information on where to find make_cif to call it <daviid>flatwhatson: hum - that is a problem <flatwhatson>linker (either gcc or dynamic-link/dynamic-func) simply can't find that function <flatwhatson>IF it was in the public API, you could call it directly from scheme with dynamic-link/dynamic-func <daviid>flatwhatson: but if we write a CV program <daviid>a C program, that include libguile? <adhoc>flatwhatson: so it would have to be recompiled and that function put in the export list ? <adhoc>daviid: which makes one wonder, if it is internal, other function call it ? <flatwhatson>i mentioned them above, pointer->procedure and procedure->pointer <daviid>flatwhatson: and i answered, i do not know how to get a pointer to an ffi-cif using pointer->procedure <flatwhatson>daviid: no, because make_cif is not described in libguile/foreign.h, it's completely internal to libguile/foreign.c as a "static" (ie. hidden) function <daviid>so why did you offer to use those then :) - i need a make_cif function <flatwhatson>at the point i mentioned those, i didn't understand your use-case... <flatwhatson>also i expected make_cif to be exported, but on closer look, this is basically not possible without seriously naughty hackery <adhoc>does make_cif mess with global/internal state ? <daviid>flatwhatson: hum, that is terrible <flatwhatson>so your options would be to either: a) petition for make_cif to be made public, and depend on the next guile release as a minimum version, or b) clone make_cif directly <daviid>flatwhatson: ok, then clone make_cif _but_, it uses libguile all over the place, i only (barely) can write 'nornal' C code ... <flatwhatson>daviid: ok i'll make a patch, should i base from that devel branch or last release? <daviid>flatwhatson: yes, that would be awsome! <adhoc>what does the make_cif function do ? <daviid>adhoc: see libguile/foreign.c, where it is defined <adhoc>I can see why you did not want to re-write that ... <daviid>flatwhatson: can we agree on the interface, like <daviid> make_cif (ffi_type return_type, ffi_type arg_types, char *caller) [do we need a caller?) <daviid>make_cif (ffi_type return_type, ffi_type *arg_types, char *caller) <daviid>ffi_cif *\n make_cif (ffi_type return_type, ffi_type *arg_types, char *caller); <mwette>On the ffi thing, the older dynamic-link allowed usage that does not specify library, namely already linked into the code; the newer foreign-library-function seems to require a library; is there something to use for "lib" equivalent to no argument for dynamic-link? <daviid>mwette: i don't know, i always call passing the library <a12l>What procedure should I use to compare chars? I want to sort a list of chars (used `string->list` to create it). <a12l>I begin to really appreaciate polymorfism after all these type-specific function names.... <a12l>And I've to learn where I should look in the ref manual <flatwhatson>daviid: i'll just copy make_cif as-is from guile into gg-ffi.c and exposed from gg-ffi.h <flatwhatson>once that is done, changes can be made to the interface in following commits <daviid>ok - the 1st step is to make it so it compiles ... but it uses SCM things <flatwhatson>interesting that g-golf doesn't already use libguile.h at all? <daviid>flatwhatson: at all indeed, there are only a few C lines, and nothing that libgule would help with anyway ... <daviid>flatwhatson: which is why i'd like to then get this patch not usig libguile if possible ... <flatwhatson>instead of stripping out libguile to clone make_cif, why not add libguile properly so it can be used in future easily? <flatwhatson>i think it makes sense for g-golf to use libguile internally <daviid>flatwhatson: i don't pan to ever use it <daviid>flatwhatson: only some patches here and there - this make_cif is a very rare exception <daviid>and i don't know t, i only know the ffi and write 'basic' C code whe i rarely need some <flatwhatson>it is not simple to just strip out libguile usage in this case, that ffi_cif struct needs to be allocated <daviid>flatwhatson: but is that not in libffi itself? <flatwhatson>libffi defines the struct and functions which use it, but it is up to the application to allocate memory as needed <daviid>/* the memory: with space for the cif itself */ <flatwhatson>and then later: mem = scm_gc_malloc_pointerless (cif_len, "foreign"); <flatwhatson>memory is allocated via guile's gc, so it will be treated properly <daviid>ah, how about i allocate it from g-golf then? <daviid>so we change the interface, i pass a pointer to a bytevector for a ffi_cif <daviid>like i do in guile-cv, i never use C to allocate ... <daviid>flatwhatson: let's do that, wdt? <flatwhatson>daviid: what inputs are you expecting to call with? a big chunk of make_cif occurs in the fill_ffi_type function, which converts from guile's foreign types into libffi types <flatwhatson>you proposed an API taking ffi_type*, so you already have built up these type structures? <daviid>flatwhatson: i am working on it now <daviid>cause i'd like to remove the need for libguile 'all' <daviid>ffi_make_cif (ffi_cif *cif, ffi_type return_type, ffi_type *arg_types, const char *caller); <daviid>it return 1 if tha call succeeded (?) <flatwhatson>make_cif converts from guile's foreign types into ffi_type structures (which might be allocated on-the-fly if the type is a struct), then packs everything into an ffi_cif structure, then calls ffi_prep_cif(...) <flatwhatson>and you are proposing to remove the "converting from guile's foreign types" part, leaving very little <flatwhatson>if you can already pack an ffi_type structure, you can probably already pack an ffi_cif structure and call ffi_prep_cif directly <daviid>flatwhatson: ok, let's not do that then, 1st things 1st ... <daviid>i can effectively give you ffi_type_pointers, actually i already have tehm, i need tem in my previous 'naive' implementation <daviid>i have those, if that simplefies <flatwhatson>can you point me at the GI calls you're using to get them? <daviid>flatwhatson: basically, GI gives a argument type-info, i call g-type-info-get-ffi-type and i get the ffi_type pointer <daviid>so, in the api i propose, i would give you an array of those pointers ... <daviid>trying to find the GI doc online .. <daviid>can't find the online gi manual :):) <flatwhatson>it seems like almost the entire reason for using C here is to pack a struct <flatwhatson>you have code for packing an array in scheme (using bytevectors), but packing a struct is a step too far, so dropping to C <flatwhatson>this is a pure scheme library which can build C structures with a nice macro getter/setter API <flatwhatson>heh, documentation for these functions is TODO TODO TODO TODO -> TODO <daviid>flatwhatson: right, but they work :) - i use them ... <daviid>just wanted to confirm that i canpass you an array of ffi_types <daviid>it is just a mistery why they did not add a make_cif <flatwhatson>daviid: the API I propose is: void gg_make_cif (ffi_cif *cif, ffi_type *return_type, ffi_type **arg_types) <flatwhatson>or maybe returning int instead of void, to pass on the error code from ffi_prep_cif <flatwhatson>you proposed to name it "ffi_make_cif", but this is a bad idea, in case libffi decide to create that function in future <flatwhatson>i noticed elsewhere in g-golf C code, you follow the naming convention of upstream libraries (eg. g_ prefix), but this is ill-advised <flatwhatson>C has just a single global namespace, so stick to your own prefix for all functions (even if they logically are extending someone else's API) <daviid>flatwhatson: right, i'd need C review indeed, i think those are macros upstream ... but nonetheless <daviid>gg_ffi_make_cif (ffi_cif *cif, ffi_type *return_type, ffi_type **arg_types); <daviid>ah ok - then i know it's in my gg_ffi file ... <flatwhatson>daviid: actually... it looks like ffi_prep_cif is already the function you want <flatwhatson>it's confusing that guile's make_cif seems to build up the ffi_cif structure, then pass it to this function which does the same <daviid>very confusing, it seems it does extra wor though (?) <daviid>do you recommend i use that one then? <flatwhatson>all the extra work is building those ffi_type arrays from scheme representations <daviid>i am sorry it did not occur to me, precisely because guile seemed to do 'more' ... <flatwhatson>yes, i think you can just call ffi_prep_cif directly! <daviid>ok then, i am sorry i lost your precious time! <flatwhatson>not at all, i'm glad there's a "no patch required" solution ;) <flatwhatson>daviid: hmm, ffi_abi comes from ffitarget.h, seems to be platform-specific <daviid>i can copy what guile does i guess <flatwhatson>guile uses FFI_DEFAULT_ABI, which is also defined in that header, platform-specific <flatwhatson>the best option might be a simple helper function in C to return that value <pottsy>Hi folks. The manual mentions that SMOBs are deprecated, apart from "applicable" SMOBs. This makes sense because there is currently no replacement for such SMOBs (i.e. stateful thunks). Is there any sort of plan to replace these? (seeing as all other SMOBs are dreprecated) <daviid>flatwhatson: i updated but it fails, nothing pushed of course, but here is a paste with my changes, if you would like to look at, if you have time ofc, and see if you spot any 'big mistake' ... - https://paste.centos.org/view/bc27cd58 - i'll walk you through if you wish ... it's easier then it seems 'at first glance' but it fails :) <daviid>flatwhatson: so, callback-ffi-cif prepares the call, which occurs line 25 <flatwhatson>daviid: it might be worth checking the return code, it might give a clue <daviid>ok can i printf it, is it an int ? <daviid>i was looking for its type, i didn't find it <flatwhatson>it's in ffi.h, it's an enum, so yes treating it as an int is fine <flatwhatson>to clarify, i mean the ffi_status returned from ffi_prep_cif <flatwhatson>daviid: a-types should be an array of pointers to ffi_type, so its size is just (* n-arg (sizeof '*)) <flatwhatson>also i think you need to write (pointer-address ffi-type-ptr) in there <daviid>unbelievable - i made these changes, and it works now (but the double values mare stilltotally incorrect - let me paste my changes <flatwhatson>never mind that last one, i see bv-ptr-set! -> bytevector-pointer-set! which already uses pointer-address to unwrap the object <daviid>and now it 'pass', the peg-solitare game opens and still displays totyall wrong double values, here is an example <daviid>david@aicha:~/gnu/g-golf/git/examples/gtk-4 49 $ ./peg-solitaire.scm <daviid>; peg-solitaire snapshot-vfunc #<<gtk-snapshot> 7fed61f54cb0> width 6.95274231442705e-310 height 6.95274231442784e-310 <daviid>the width and height should both be 32 <flatwhatson>wolfram tells me this number is "zero point zero" :D <daviid>flatwhatson: i didn't get your suggetion above <flatwhatson>well i guess the problem is a mismatch between the actual type of the callback, and the type described in the ffi-cif that's been built <daviid>(gg-ffi-type-size) returns 8 - it calls sizeof(ffi_type *); <flatwhatson>ok, that is confusing naming, i'd expect gg-ffi-type-size -> sizeof(ffi_type) <daviid>i did all this because tje gi team would suspect my previous ffi-cif 'makig' might have been the problem <flatwhatson>i think you need to do some inspection of these values to ensure they look sane <daviid>flatwhatson: sorry i am confused, what values are you refering to? <flatwhatson>adding some simple code in the C wrapper to print out r_type and each of a_types <daviid>this is the problem, how do i verify an ffi-type? <daviid>(g-type-info-get-ffi-type type-info) returns a ffi_type * - how do i ask for a string of the type? <daviid>one thing is sure, actually 2: 1. the ffi-prep works, and 2. any pointers work, because in the peek i do, ;; peg-solitaire snapshot-vfunc #<<gtk-snapshot> 7fed61f54cb0> ... the #<<gtk-snapshot> 7fed61f54cb0> is obtained as a result of the ffi call, and it returns a pointer, and g-golf finds the goops instance ... <daviid>all vfunc numbers a re wrong though, this snapshot expects double, in this case the value should be 32.0 <flatwhatson>daviid: yes, i mean to verify from C that you're getting sensible values <daviid>i was hoping an api to print all args ... very bizarre it does not ewxists in libffi itself ... <daviid>i1'll try the r-type anyway, let's see <flatwhatson>if there is some mismatch, eg. pointer to wrong thing, it should be easy to verify with a sanity check <flatwhatson>also i made a mistake, printf("type: %d\n", r_type->type) should do fine <flatwhatson>you might as well write a function which takes a ffi_type* and dumps it out with printf <daviid>for 3 of the vfunc and type 0 for the last one <daviid>it seems correct, i have 4 vfunc, one return an enum, two integers, and the snapshot is void <flatwhatson>ok, you should also check arg types, as those are more complicated & more likely source of the problem <daviid>flatwhatson: in gg_ffi_prep_cif, i could for i=0 -> n_args ... <flatwhatson>daviid: yes, something like: for (unsigned i = 0; i < n_args; i++) { printf("arg %d type: %d\n", i, a_types[i]->type); } <daviid>flatwhatson: perfect, here is what i get <flatwhatson>yes, that seems to be: void (void*, void*, double, double) <flatwhatson>we'd need to dig deeper into the ffi_type structure to identify pointer type <daviid>flatwhatson: yes, but pointers work fine, as the peek shows ... <flatwhatson>but these really seem like sane values. so it seems the ffi_type packing stuff and ffi_prep_cif call are all working correctly <daviid>so, let me explain what happens 'next', when excuting a callback, maybe you spot a problem <daviid>the callback is executed by a closure marshal, the same code for any callback in g-golf, not just vfunc, any callback ... and it is entirely writen in scheme, easy to read ... here <daviid>(gi-type-info-extract-ffi-return-value type-info ffi-arg gi-argument) <daviid>that girffi interface extract the value from the ffi-arg, and fills the gi-argument <daviid>the gi-argument signatures a re correct, let me show you <daviid>flatwhatson: here, again tldr, the important thing is the type-tag of the last argument, used by my giargument->scm ... - https://paste.centos.org/view/52559826 - tha paste lists the vfunc names and cache entry, then the full description of the snapshot callback, the type-tag of the width and height args are line 11, extract field line 129, for the height line 141 extract gi argument field 159 <daviid>it's been two days i am on this, and the only reason, to me so far, is a bug in gi-type-info-extract-ffi-return-value, which is a girffi interface, i merely call it .. <flatwhatson>does (gi-type-info-extract-ffi-return-value ffi-arg gi-arg) modify its argument? you aren't using its return value <daviid>a bug in my progress in the ffi-args ptr <daviid>flatwhatson: no, it fills its last argument <daviid>it fills the gi-argument with the value ... <daviid>and again, if that would not work, none of the 'object type would work ither <daviid>i was refering to my progress in the ffi-args, but if that was the problem, it wold also fail to find the snapshot second arg, which is the gtk snapshot instance (the 'st is the widget) <daviid>looking at g-golf-callback-closure-marshal, just to make sure, all its args it receives them from the gobject 'engine', the ffi-cif is the one we just worked on to build using the ffi-prep ... so the ffi-args can't be wrong, and i progress to extract by increasng the original ffi-args pointer <flatwhatson>well, you know it's working for pointer types, but it appears to not be working for these doubles <daviid>and with 'all the above' said, and our work to make sure the ffi-prep works fine, it only remains a possible bug in gi-type-info-extract-ffi-return-value - unless i did miss something (too close to our own code someitmes blinds ...) <daviid>flatwhatson: right, it also fails with another vfunc that has args that should be integers <flatwhatson>and really, are you *sure* the unpacking of pointers is working? any old garbage could look like a valid pointer <daviid>it only works for ponters actually <flatwhatson>i think it might be worth doing some similar printf debugging on this side <daviid>i am pretty sure it's working, the peg-solitaire game makes a lot of snapshots, and you can drag them ... playing the game, it would crash immediately if those would return 'wrong' pointers <daviid>what i'd like to do is to look at the gi-type-info-extract-ffi-return-value code and copy, then make some printf as well <flatwhatson>you could make a simple C wrapper for it, which can printf the arguments & return values <daviid>but flatwhatson i am exhausted actually, i want to thank you to have particpated so well, i have to rest and try again tomorow ... <flatwhatson>daviid: no worries, you are much closer to having it working, sleep well :) <daviid>i'll ask where their source code is <daviid>so for double it calls gi_type_tag_extract_ffi_return_value, line 492 <daviid>for double, it runs te code at 530, and for pointers, as you wanted to check, it switches at 538 and execute the extract at 537 <pottsy>Is there any plan to replace boehm GC for guile? <flatwhatson>pottsy: yes it seems so, there is a new gc being developed <pottsy>and another/alternative question: if I manage my C memory perfectly, will I still leak memory from scm values? <pottsy>flatwhatson: do you know any information about the new gc? <pottsy>some discussion or forum post etc. (sorry not particularly familiar with the dev community of guile) <flatwhatson>pottsy: re: leaking memory from scm values, i don't really understand <flatwhatson>of course it's possible to program correctly without leaking :) (modulo bugs) <pottsy>flatwhatson: the current gc (boehm) is conservative which means it will likely leak memory. It works by scanning memory to find pointers to allocated memory, but can never be 100% sure whether something is garbage or not <pottsy>the manual says: "the Scheme stack is maintained apart from the C stack, and is scanned precisely (as opposed to conservatively)" <pottsy>I suppose there are probably some C functions to mark scm objects for collection <flatwhatson>yes there's a C API for interacting with the garbage collector <mfiano>hey flatwhatson. doing anything in guile lately? <mfiano>I've actually been taking a few days break because there's some sysadmin stuff I've been putting off for about 6 months I gotta take care of on my network, which will probably take me the rest of the week. <flatwhatson>i've been digging through email archives lately, resulting in a couple of patches for guile-email <flatwhatson>it's a pretty neat library, using (ice-9 peg) to implement RFC 5322 pretty closely <flatwhatson>still found some edge-cases running it over gmane archives going back to 1996... <mfiano>I'm actually not very familiar with modern parsers at all. It's something I want to learn about. I haven't even used a parser generator before...usually just write my own recursive descent parser the way I learned years ago. <festerdam>After compiling guile, how do I run the excutable? Running libguile/guile directly results in Pre-boot error; key: misc-error, args: ("primitive-load-path" "Unable to find file ~S in load path" ("ice-9/boot-9") #f)Aborted <a12l>Is there a standard function that returns a lowercase version of a given string, or do I need to write one myself? Can't find one when I look through the ref manual <a12l>Thanks! I zeroed in on "lower" <lloda>yeah that's something that could be added to the index <festerdam>Ok, I figured it out. Had to set Guile load path to guile/module. But now when compiling the modules it yells at me that there is no such language scheme or tree-il. <festerdam>I'm pretty sure it should know about those languages. <lloda>checking that page, it would seem that one of string-titlecase[!] or string-capitalize[!] is redundant <festerdam>This happens despite check-guile doing fine. <flatwhatson>festerdam: the normal way to run guile from build tree is the meta/guile wrapper script <festerdam>flatwhatson: Both meta/guile and libguile/guile are shell scripts, the actual executable being libguile/.libs/guile. How can I run it in gdb? <festerdam>With the proper setup that meta/guile and libguile/guile do. <apteryx>can I get the symbol corresponding to a procedure name? <lloda>apteryx: there's procedure-name <festerdam>flatwhatson: Huh. The script fails with: ice-9/read.scm:126:4: In procedure next-non-whitespace: /path/to/guile/libtool:11955:1: unterminated `#! ... !#' comment <flatwhatson>festerdam: are you building from a git clone, or a tarball? are you on an unusual (ie. non-linux or non-x86_64) system? <festerdam>flatwhatson: From a git clone because I wanted to see if a certain bug was also occuring on master. <flatwhatson>development now occurs on main branch, master is a bit old <flatwhatson>but are you on a regular linux system, or macos or windows or something else? <festerdam>I guess I should do a pull just in case, since this commmit seems to be from november so already a bit old. <flatwhatson>when you say "the script fails", do you mean one of those scripts in meta? <festerdam>flatwhatson: I mean meta/gdb-uninstalled-guile (meta/guile works, though). <flatwhatson>festerdam: those scripts are generated, it might be worth re-running ./autogen.sh && ./configure <festerdam>flatwhatson: Ok, on the latest commit it works now. I'm very sorry for bothering you. <flatwhatson>i doubt my unit test patch fixed it :P more likely it needed re-generation for some reason <old>What's the "official" way of auto documenting btw? <old>I know that there's the ;;; Commentary for the module. There's also docstring for procedure. But is there generation of documentation for comments before a procedure? <dsmith-work>There are actually two systems. One in in C and uses preprocessor macro magic and ends up in the guile-procedures.txt file at build time. The other is all in Scheme and uses the "docstring" in a procedure and the ;;; comments in a module. <dsmith-work>See guile_filter_doc_snarfage stuff in libguile/Makefile.am and the SCM_DEFINE* macros in libguile/gsubr.h <old>But for example, `guild doc-snarf' does not snarf any docstring <old>It does however snarf comments starting with `;;` not `;;;` and only lines that touches the begining of the procedure <old>For someone who want to document their code and generate a texinfo manual, perhaps there's some missing pieces here <old>maybe a blog post should be made or a recipe to help :) <lilyp>Actually, there is another way: You can run the texinfo module on your docstrings. <old>What do you mean by running the module? <lilyp>Note that it needs some of the ice-9 filesystem stuff to work because I wrote it that way, but you can do the same without. <old>does that work for comments also? <lilyp>That one's strictly for non-comment docstrings <lilyp>i.e. the one's you'd write in (define (my-function arg1 arg2) "Here I am documenting things" ...) <old>Well then, what's the use for procedure comment's? <old>Are they only for developers? If so, why having a doc-snarf for guild? <lilyp>doc-snarf works too (FSVO works), but imho it's a rather quirky thing to deal with <dsmith-work>The C pre-proc stuff is not installed. Only exists in the source dirs. <haugh>I'm aware of module docs and procedure docstrings. Are there any other "procedural documentation" or "literate programming" facilities in Guile? Are there any tools for generating docs from code? (Guessing texinfo is involved based on some of the docstrings I've seen.) <haugh>Also is there anything like a docstring for define-syntax? <lilyp>syntax is harder to grab, but you could give it doc strings/doc comments <lilyp>For the doc-snarf solution, you only need to update the regexp that matches function starts and you ought to be good to go <lilyp>it may or may not produce correct arguments <lilyp>I haven't played around with the docstring things, but note that syntax-case uses lambdas <count3rmeasure>is there a way to name regex pattern groups, ala pythons named regexs? I'm trying to represent linux paths that terminate in a shared object file that will variable numbers of directories in the path, and also represent the objectfile at the end? <count3rmeasure>I'm using the ice-9 regex module at the moment, if there's another one <lilyp>well, at least not with ice-9 regex, idk about funky other regexp libs out there <lilyp>you can however try using pegs <count3rmeasure>haven't used that before, I think this time I'll stick with what I've got experience, albeit in a different language, but thank you for future reference! <rekado>count3rmeasure: irregex can do it, I think <count3rmeasure>and for the record I may have been too hasty lilyp, it may end up being peg parsing if this doesn't work out, we'll see. <civodul>jpoiret: wip-posix-spawn ready to go for me; waiting for your green light :-)