IRC channel logs
2023-08-12.log
back to list of logs
<wklew>I'm getting behavior that makes me think it's happening to me <rlb>wklew: in your case is the pointer->procedure result bound somewhere (e.g. let bound) throughout the use of the procedure->pointer value? <rlb>Hmm, or wait, maybe I misread that... <wklew>This is for passing scheme functions as callbacks to a C library, so it's about procedure->pointer <rlb>Offhand, I'd think that as long as the "ptr" result there outlives all C side calls, it should be OK. <rlb>(i.e. as long as ptr is reachable somewhere on the scheme side the entire time) <wklew>Well I'm writing the pointer to a bytevector that sticks around, so that should be reachable? The bytevector is passed to C as a struct that has a collection of callbacks. <wklew>Or rather I'm writing the address of the pointer to the bytevector, not the actual pointer <rlb>Ahh, that won't work, if I understand you (and guile) correctly. i.e. guile doesn't know anything about the integer as the contents of a bytevector -- assume it doesn't even scan those. <rlb>you'll need to keep the actual return value around somewhere. <wklew>That's probably the problem then! Thank you. <rlb>i.e. once the integer is in the bytevector, it's just data <wklew>For some reason I assumed I needed to keep the procedure around, not the pointer <rlb>Nope, from a cursory glance at scm_procedure_to_pointer, I assume it stashes that somewhere safe for you. <wklew>That explains why the qsort example works <rlb>i.e. as long as you hold on to the return value. <wklew>Now where to keep the pointer... <rlb>...worst case, if acceptable, there's always a weak reference (to attach it to the "real" reference indirectly), but of course, then you need a place to put the weak hash table :) <wklew>I'm just going to wrap the callback struct in a record type along with a vector of cached pointers <wklew>No more crashes! I think you solved it rlb. <rlb>nice - glad to hear it. <rlb>...just finished a difficult/complicated rebase of the utf-8 work (pushed some of the important changes much further back so reviewers won't have to deal with the interim code, etc.). Not really sure exactly when it'll be yet, but should be much closer to something worth pushing for an initial look. Really hoping to have that in the next week or two, but we'll see. <mwette>rlb: looking forward to it --- Are you going to write it up? <rlb>mwette: "write it up"? <mwette>rlb: texinfo to put into guile ref manual, for example <mwette>any plan? I'm interested in understanding the implementation <rlb>Oh, certainly - I intend for the documentation to be fairly comprehensive, i.e. wrt stuff you'd want to know as a user in the info pages, and more implementation details in the commit messages and detailed code comments (like we have now in strings.[hc]). I've started on some of that, but plan to wait until I see what changes people want before I really fill it out. <rlb>Also have one possible further notable change we'll need to decide on wrt the implementation, but I'll likely hold off on badgering people too much about that until after the current arrangement is available for review. <rlb>i.e. it's a further "enhancement" (performance-wise I think), *if* we really do want to favor immutability (and more particularly read-only strings).