IRC channel logs
2024-10-30.log
back to list of logs
<old>what is the canonical way of protecting objects from the GC when passed to C in pointer form? <old>For example, if I make a bytevector with a pointer to a string in it. I then pass a pointer to the bytevector to C. What's the "correct" way of protecting both the bytevector, the pointer to it, the pointer to the string and the string. <old>also it is still unclear to me if *->pointer copy the value or not? I always get a new pointer when doing so <old>not for the bytevector, but for the string I always get a new pointer <old>I think that the main problem here that I would need to tell the GC to scan specific location in bytevectors for pointers to Scheme object <dthompson>if you have a pointer to a bytevector that you send to c then you need to arrange that you are holding a reference on the scheme side so it doesn't get GC'd <dthompson>in the case of the string, you'll need to hang onto the scheme pointer object specifically if it needs to survive past the ffi call you're making <mwette>old: look at guardians for an option <mwette>off topic: what's the name of the std (parser?) engine that interfaces langages to different text editors? <old>right. Python seems to make it easier in that respect. It seems to understand when you are making compound types that fields are pointer that must be protected from GC <old>would be nice to have a simple API like so: (bytevector-hint-gc-pointer BV OFFSET) <old>I could simply add the embedded object in a global hashtable and remove them with a guardian on the bv <old>but that's pretty cumbersome when the runtime should provide this functionnalities <dthompson>old: I don't really understand that suggestion. I've been a heavy user of the ffi for years and haven't needed such a thing <old>Say I pass a structure to C. This structure has fields which are pointers to other structures. So I need to embedded the address of a pointer in a bytevector <old>The bytevector is not scanned by the GC for pointer to object. Resulting in undefined behavior <old>It is a common pattern. It should be supported imo <old>I should be able to tell the GC, by the way, this is a place in memory where you should scan for more objects <old>I understand that bytevector are allocated without adding scan in them for good reasons, but there are also good reason to explicitly tell the GC that some part of that bytevector contained reference to object <mwette>maybe there should be make-bytevector/not-pointerless <old>mwette: but some fields are not pointers! <old>struct { int x; /* don't scan */ char *string; /* scan! */ } <mwette>so what, the gc looks at everything and decides which are pointers <old>consertivatively yes <old>anyway, I can get around it with guardian. Just seems like adoc <old>and more bookeeping on my end in Scheme to project objects <dthompson>I think you may be overcomplicating/misunderstanding something but I can't say for sure <old>well actually weak key hash table seems to be the best solution here <old>any other way to protect string* ? <ineff>Hello everyone, I'm having trouble writing macros, can someone lend a hand? <ineff>Yeah I kinda trying to write a macro that basically reverse elements in a s-expression <ineff>Basically I'd like to write reverse just as a macro rather than a function <ineff>the goal would be to do right-handside application rather then traditional left-handside <ineff>dsmith, sneek thank you both I'll take a look <mwette>ineff: maybe start with simple example and write out by hand, look for the pattern <mwette>e.g., (rev a b c) => (cons a (cons b (cons c '()) <mwette>oops: (cons c (cons b (cons a '()) <mwette>(rev a b c) => (revx '() a b c) => (revx (cons a '()) b c) => ... <ineff>mwette: doing things with a fixed amount of arguments it's easy <ineff>problems start raising when you want to do things recursively <mwette>You should work on that. Sometimes you need to use another macro. I have done this: I created a macro xcons* that works like cons* but in reverse order. It's four lines long. Do you want to see it? <old>I was aiming at: (define-syntax compile-time-reverse (lambda (x) (syntax-case x () ((_ elements ...) (reverse #'(elements ...)))))) <old>Not sure how to not have a list at the end tho. ,expand (+ (compile-time-reverse 1 2 3)) => (+ (3 2 1)) <ineff>old: that's what I was trying, the problem is that it doesn't seem to be working <old>would like to have ,expand (+ (compile-time-reverse 1 2 3)) => (+ 3 2 1) <ineff>and I don't know why, shouldn't the macro system be able to run every function at "compile-time"? <mwette>(define-syntax-rule (rev elt ...) (xcons* '() elt ...)) <mwette>ineff: you can do some of that; I think you should get comfortable w/ vanilla syntax-rules programming before going on to more fancy stuff like compile time eval <ineff>mwette: it is that simpler than working with syntax-case? <dthompson>syntax-case was quite a bit harder to learn, for me. <ineff>I think that the problem is understanding what is exactly a transformer <ineff>from what I've read from the manual it should be just a one-argument function, that expects to get a syntax-value and should return a syntax value. <ineff>Though, it seems to me that's not the whole truth <ineff>I feel kinda there are some limitations to what these functions can actually do <ineff>dthompson: so any function returning syntax objects can be used as the third argument of a define-syntax form? <ineff>mwette: I think I'm getting somewhere. Looking at your example for xcons*, it seems you are doing tail recursion for the macro <ineff>do macros support full-recursion or are they restricted to be tail-recursive functions? <dthompson>ineff: yeah you could do (define (foo stx) 42) then (define-syntax bar foo) and then (foo 999) and it will expand to 42 <ineff>dthompson: shouldn't it be (define (foo stx) #'42) for being a transformer? <ineff>Shouldn't it return a syntax object? <dthompson>it won't have any source info without being wrapped in a syntax object <ineff>Ok, thank you all for the help. Have to go.