IRC channel logs
2025-01-10.log
back to list of logs
<dodoyada>I do hard things for fun, so guile has been great lol. recently I tried creating a logging module that includes module and line numbers in messages. I knew it didn't work for things ran through the repl but it does work for files executed against a repl. however, I found that it does not work in prod because the process is started with an expression (-c, maybe it works if you start guile with -s?), it just always lists the modu <dodoyada>`(guile-user)`. I'm thinking I just write logs with log level and call it a day <dodoyada>I spent a lot of effort figuring out how to get a list of modules (based on my project file tree), then reload those modules with a keybind. Once I figured it out I found I didn't need to do it at all due to auto compile, I just needed to call the function my app needs to refresh routes <dodoyada>I like learning the hard way because it really sticks <dodoyada>hmm I wonder why I never found it, I did go looking <lechner>sneek / later ask mwette / Hi, where may I read up on what's new in v2 of Nyacc, please? <lechner>sneek / later ask mwette / Also, do I need to include (nyacc foreign data) and use 'make-cdata' now in order to "make" a struct* type? The explicit constructor (in my case, make-pam_handle_t*) disappeared from the generated interface. <chrislck>dear guilers: I understand (string->number "1e4") => 1000.0 <chrislck>but why is (string->number "1d4") also 10000 <mange>r3rs only has e, but r4rs has e, s, f, d, l. Presumably there's some justification for that change somewhere. <mange>interpreted them essentially as Common Lisp does. ..." <chrislck>mange: thanks and the followon email from the wizard himself suggests it comes from fortran <mange>Yep, so it's got a pretty long history. :) <lloda>how do you put a newline in a docstring? @\ or @* show up in the output and @itemize produces extra blank lines i don't want <sneek>mwette, you have 2 messages! <sneek>mwette, lechner says: / Hi, where may I read up on what's new in v2 of Nyacc, please? <sneek>mwette, lechner says: / Also, do I need to include (nyacc foreign data) and use 'make-cdata' now in order to "make" a struct* type? The explicit constructor (in my case, make-pam_handle_t*) disappeared from the generated interface. <lechner>fremont up north but my cousin lives in santa monica <mwette>still on watch; in my group of 15 at work 2 lost homes <lechner>a friend's uncle completed his dream home two weeks ago, including a tennis court. gone <lechner>plus the psychological stress for you <lechner>anyway, i'd like to convert guile-pam to Nyacc 2.x. i really liked what I saw but am not sure my technical abilities are up to par. How may I create a particular wrapped type, please (pam_handle_t*, in my case) or wrap a raw pointer, rather than unwrap, which is more common in FFI? <mwette>lechner: go throught the examples in examples/nyacc/lang/ffi-help <mwette>cdata to raw pointer via cdata-arg->pointer <mwette>the function pointers to a lot more conversion in nyacc2 <lechner>mwette / so off the bat, the one thing that's a bit different is that the constructor is no longer exported by the generated file, correct? <lechner>i.e. make-cdata is in (nyacc foreign cdata) which i now have to load <mwette>there is no constructor anymore just the type object are exported. (make_foo_t) => (make-cdata foo_t) <mwette>a bit lower level now, but smaller generated files and fewer symbols exported <lechner>mwette / great! what was wrong with -bytestructures? <mwette>in scm/pam.scm I put (handle-address (pointer-address (cdata-arg->pointer handle))) <mwette>bytestructes required another layer (fh -types) on top to handle function types AND bytestructures is native only, cdata supports working cross-platform <mwette>I think I have a much better way to deal with function types now. <lechner>mwette / ffi-help-rt is gone, right? <mwette>yes, but you need `(nyacc foreign cdata)' (which uses `(nyacc foreign arch-info)' <lechner>yeah, but much better module location <lechner>looks great! i guess i wish i hadn't invested so much time into bytestructures <mwette>haha, I've been thinking generating something new for a while; your pains working with functions led me to have a good look and just do it. You have yourself to thank for the new system, in a way. <mwette>dthompson, and wingo also I've heard, are working on same type of capabilities; cdata handles all the things I wanted: cross-target arch's, bitfields, anonymous unions, function types and short-enums. <mwette>Oh, and still needs work: type equivalence. cdata has `ctype-equal?'. It will needs a way to deal with possibly-circular pointer chasing. <mwette>It also has procedures to pre-compute field offsets (with pointer dereferences in the middle!). <lechner>so fh-wrap is now a make-cdata #:from-pointer, right? <mwette>what file? I remember seeing that. <mwette>It is probably (make-cdata (cpointer (cbase '*))) <mwette>which is shortcut for (make-cdata (cpointer (cbase 'char))) <mwette>not sure about fh-wrap, lemme look <mwette>I should make a doc to help convert. I didn't think of that. <mwette>dthompson: there is a typo under `;; Pointer' I think near <item> <lechner>mwette / and (char*->string X) is now (make-cdata (cpointer 'char) #:from-pointer X) ? <mwette>lechner: there is also ccast which converts one type cdata object to another type <mwette>I'd need to look at all those utilities again. (I've been working on the nyacc C preprocessor which has a bug.) <lechner>mwette / so it's (ccast (cpointer 'char) X) ? <mwette>X has to be a cdata object there. What are you trying to convert? A cdata char* to a guile string? <mwette>I didn't take care of that. I think (pointer->string (cdata-arg->pointer X)) <mwette>Or (pointer->string (cdata-ref X)) is probably better. <lechner>also, just as an initial impression, i may be a little confused by the varying argument order. sometimes it's (prc result input) and sometimes (proc input result) isn't it? <mwette>You mean the cdata-set! arg order? It's different than bytestructure-set! but consitent w/ Guile's array-set! <mwette>I was trying to be consistent with Guile conventions. I wonder how bstructs does it ... <mwette>looks like bstruct does this: (bstruct-set! <type> <obj> (<key> <val>)) <mwette>versus cdat: (cdata-set! <obj> <val> <key> ...) <lechner>personally, i think that's more intuitive, but I'm new here <mwette>versus bs: (bytestructure-set! <obj> <key> ... <val>) <lechner>also, i am a little bit confused by your branch names. which one should i follow, please? <mwette>main has the latest release; dev-X.Y are in development and rel-X.Y are released ; don't use dev-X.Y; E.g., if I have to fix 1.09, that'll be on rel-1.09 <lechner>mwette / you use rel-X.Y for rebases, or do you provide long-term support? <lechner>mwette / and 'pointer-to' is now 'cdata&-ref' ? <lechner>mwette / where is cdata-arg->pointer please? <lloda>wish match would warn if you have extra clauses after a catch-all <mwette>oops: it's called unwrap-pointer in 2.01 ; moving to cdata-arg->pointer in 2.02 (not released) <mwette>lechner: be aware that the FH generated callbacks include conversions now <dthompson>mwette: catching up... I don't see the typo. maybe you weren't expecting to see 2 types defined in one define-bstruct form? <lechner>mwette / could you please rephrase that callback comment? <lechner>also is cdata-arg->pointer the same as cdata-ref? <mwette>In this case (if i understand) they are equivalent. <mwette>callbacks: this should work: (cdata-set! obj (lambda (foo) xxx) 'callback) and when called foo could be a ctype <mwette>cdata-ref will generate guile pointer for pointer ctypes; cdata-arg->pointer can handle ctypes, guile pointers and strings <mwette>the arguments can be cdata types <mwette>for Gtk, which uses a lot of casting I have to use ccast to convert from one cpointer to another. <mwette>lecher: CZTQ says you passed a procedure where it was expecting a pointer. If the type signature is not in the header it won't work. You can use instead the procedure using (unwrap-pointer (lambda (foo) ...) some_ftn_t*) if some_ftn_t* is defined as a function pointer type <mwette>lechner: Please make a list of things that don't work and I can work it. I am on another issue now.