IRC channel logs
2024-06-03.log
back to list of logs
<lechner>the argc is no issue, but I can't get the argv right <janneke>ACTION just leaves make, bespoke, potato-make here too ;) <wingo>rapprochement with ESR is a terrible idea :) <dthompson>I saw this email when I was very much not awake and was baffled why I was seeing mail from esr <civodul>bah, and seriously, what’s up with the name <lechner>janneke / thanks for that pointer! first time i read about it. that work has great potential, although having spent some time with Guile I'm not sure any Makefile is human-friendly. "Autodafe's aim is to convert Autotools build recipes into a bare makefile that is human friendly." <lechner>civodul / the name refers to a gruesome step that resembled a public exorcism in the Spanish inquisition, which targeted Jews who converted to Christianity in order to avoid expulsion in 1492 but secretly practiced their old religion. https://en.wikipedia.org/wiki/Auto-da-f%C3%A9 <janneke>but what's interesting is that esr is very open to guile (personally, possibly not for the project), and also that i figured the parsing auto* and translating it is the hard bit; whether to spew out the recipes in make or guile might be "just add another backend" <lechner>you have to be, in order to work on Autotools. Plus, it's a relief compared to m4 <janneke>yeah, much respect to pick this up; and i guess python is a sane choice <janneke>ACTION rather means: there's a lovely pick of much worse choices than python ;) <civodul>lechner: yeah, i know what it means, and i don’t like to see this word here <old>so is the idea to convert autotools stuff to readable makefile for all packages? <lechner>hi, why do pointers from string->pointer look like 32-bits on my equipment? <old>lechner: what do you mean by look like 32-bits? <old>((@ (system foreign) string->pointer) "foo") => $1 = #<pointer 0x7aedc0> <old>so indeed the string is raw at this address (confirmed with GDB). So the printer simply omit to print leading 0 <old>the string is allocated in the heap <lechner>old / ok, thanks! what's a good way to get a pointer to that pointer, please? <old>I'm not sure to understand what you mean. You want a pointer that points to this string like (char **) but in Guile? <lechner>not quite. for use with a foreign library, i hope to pass a pointer to the C pointer that points to string <old>what's the signature of the foreign library call? <lechner>i think that's a wrapped pointer to the unwrapped pointer to the string <old>okay then I think you could do the following <mwette>lechner: you'll need to generate a bytevector of the pointer-address(es) and convert that to a pointer to pass <mwette>I assume you're still talking about passing char *argv[] <old>mwette: I'm trying that without much success <weary-traveler>what's the guile way to combine path components? something that handles file-name-separator-string appropriately. does such a convenience function exist? <old>weary-traveler: no. But I do have some WIP module that implement paths stuffs like racket <lechner>mwette / same project from two years ago. Guile-PAM is done, but this is the last piece <old>weary-traveler: You just do string-append. the OS usually ignore double // in path anyway <weary-traveler>old: sounds like your module will be helpful. thanks for the confirmation regd this situation <old>mwette: okay did it. You must not passed with pointer->bytevector <mwette>I think you need string->pointer, pointer-address, bytevector-u64-native-set!, bytevector->pointer <old>using a setter ought to be faster than ^ <old>I have not touched this for months. I don't recall if it supports Windows paths <weary-traveler>thanks for sharing. i am a little surprised something like this isn't in the standard libraries <lechner>thanks so much! now i have to pass more than one string, and perhaps be more conscious of other architectures <lechner>mwette / two years ago, you or perhaps daviid wrote I also have to keep the reference alive across the call. is that still true? it seems to wprk without <mwette>Yes, you want to do that. If GC executes during the call that could be bad. <lechner>mwette / thanks! i can't pass two strings. was the idea that i can write the second pointer using the index feature like this (bytevector-u64-native-set! bv 1 raw-address) <mwette>you need to size the bytevector = (* argc (sizeof '*)) and use (bytevector-u64-native-set! bv (* i 8) ith-raw-address), assuming your pointers are 8 bytes <lechner>wow, you are such a genius. i can only imaging the sweat and tears you went through writing ffi-helper! <lechner>wow, it's working. the last piece. calling legacy pam modules from Guile-PAM <lechner>mwette / should GC ever executing during a foreign function call? <mwette>guile is multi-threaded, so you have to assume it may <lechner>is a pointless, unassigned reference like (list argv) enough to keep the variable alive, or will it be optimized away? <old>lechner: to protect from GC, the object needs to be protected, not just the pointer. This can be difficult. Wingo talks about it in one of his blog post. I think the trivial solution is to return the reference. That way, the compile is forced to keep the reference in the entire procedure <janneke>mwette: do you know off-hand what nyacc 1.09.7 uses from (rnrs arithmetic bitwise) (in nyacc/lang/sx-util.scm) <janneke>mes does not have (rnrs arithmetic bitwise) yet <janneke>mwette: headsup, some tags seem to be mising (1.08.7, 1,09.3, 1.09.4) <janneke>oh, it seems (rnrs arithmetic bitwise) isn't needed for guile-3 or mes <janneke>hmm, guess i'll add an empty module to mes then <janneke>hmm, we already have that, just not a guile-style variant <janneke>oops, sorry for the noise, thanks for listening! :) <daviid>old, mwette and lechner: afaict, string->pointer makes a copy of the string, to produce a null terminated string, so cmiiw, but you don't need to keep a ref to the original string, just the result of the string->pointer call - and as in the char **argv argument, as you need to construct a bytevector, just olding a ref to the bv (or even just the bytevector->pointer (?)) should be enough to protect the bv and its content from being gc'ed <daviid>lechner: nearly 'out of the box', as you do not use g-golf, it needs a few adaptation, p-size as (sizeof '*), probably rename o-ptr to bv-ptr, renaming the procedure and not keeping intermediate ptr (nor return them) should be fine