IRC channel logs
2023-07-03.log
back to list of logs
<wmedrano>Can someone confirm that this is bad? I used the C API (scm_to_utf8_stringn) to get a char*and then I passed that to a Rust String to handle the memory management. <wmedrano>I'm surprised that it didn't crash on my system. <rlb>wmedrano: if you're handing it to a rust handler that releases it via free(), that'll be exactly right. Otherwise, you might have an issue. <rlb>ACTION imagines rust probably has a "free when finished" wrapper, but if not, I suspect you could create one. <rlb>(imagine it might have one already for interactions with C, but don't know) <dokma>dalepsmith: in the end scm_c_call_with_current_module enabled me to stuff the C functions into my module. <_graywolf>I probably miss something major about how GC works and I am bit scared :D <cwebber>_graywolf: I'm not sure what you're asking for sure but <cwebber>"tracing" garbage collection can collect cycles just fine <cwebber>that's only gonna look good in fixed width but <cwebber>it basically starts at a root and walks a graph finding all the referenced objects <cwebber>anything not referenced gets thrown in the trash <cwebber>so once anything not "rooted" (typically: on an active stack) <cwebber>is no longer referred to by anything else not rooted <cwebber>reference counting matters for cycles, doesn't matter for tracing GC's <_graywolf>cwebber: But the command-pointer and param-array-pointer are referenced directly in the PQsendQuery(Params)?, so I do not understand why the GC would fail to find the references. I would somehow understand why it fails to find param-pointers, but even there, I would expect param-array-pointer to keep some kind of reference to it. <_graywolf>Especially since I assume everything binded by (let*) will be available for all subsequent params and the body. <_graywolf>So I do not understand why the (identity ...) calls are necessary. <_graywolf>"all subsequent params" -> this is confusing, let's ignore this part <rlb>...I wonder if something like scm_c_string_copy_utf8 (dest, src, &n) might be useful, i.e. to export strings without requiring a particular allocation method. <wmedrano>perhaps. The `&n` is useful but I imagine a lot of callers would get the length ahead of time to allocate memory. <rlb>Yeah, I was imagining that maybe (offhand) like libunistrings, i.e. you set it to the size of the dest buffer, and then the function changes it to the actual length, but depending on what you're doing and what you already know about the content, you might need an additional call in advance to get the utf-8 length. <rlb>(changes it to the actual length, *and* has a clear way to signal truncation cases :) ) <rlb>i.e. we'd need to make sure to provide that too. <rlb>Not saying that example is the best/preferred way to do that, but it should demonstrate the basic idea. (Hmm, I bet there's an example in the docs.) <wmedrano>The like titled "Putting Extensions into Modules" provides more details