IRC channel logs


back to list of logs

<civodul>sneek: later tell wingo hi! WDYT of this 'sleep_pipe' issue when forking and of the proposed patch? ?
<sneek>Got it.
<apteryx>RhodiumToad: serializer #f or empty-serializer (defined elsewhere) would be sufficient!
<RhodiumToad>apteryx: does that code work as is?
<RhodiumToad>oh, I see the problem I'm having
<RhodiumToad>try it like this:
<RhodiumToad>(all I've checked is that it produces something that looks vaguely sane when rendered from tree-il back to scheme
<RhodiumToad>the (%location -location) thing looks wrong but as far as I can tell it's not changed
<apteryx>RhodiumToad: oh, that makes sense! Thanks for showing me how to propagate the needed information to the helper.
<apteryx>about the %location -location, yeah, that looks like a bug; I've seen warnings when compiling modules making use of define-configuration.
<RhodiumToad>looks like a missing arg to me
<RhodiumToad>first arg to that "id" macro is the syntactic context, not one of the elements of the name
<RhodiumToad>that's probably not the only way to address the problem, but it was the most obvious to me
<apteryx>ah, indeed!
<apteryx>RhodiumToad: I had thought about doing something like this, but had failed to see that I could use exact patterns such as #t to convey the needed information
<apteryx>so to me it looked like I'd go in circles, eh.
<RhodiumToad>well in this case the #t / #f passed to the helper is a normal datum
<RhodiumToad>the only hard part was figuring out how to make the helper generate the right syntax in the no-serialization case
<apteryx>hm, yes, that's what I meant with my broken jargon 'exact pattern' ;-)
<apteryx>It seems to work perfectly! Thanks for having guided me through it! Who should I credit in the commit message (if you don't mind!) ?
<RhodiumToad>me :-) you can credit me as RhodiumToad or as Andrew Gierth (or both)
<apteryx>OK! Thanks.
<apteryx>if you pm me your email I could simply give you authorship of the commit, which would be more accurate :-)
<RhodiumToad>I'd prefer not, just credit me in the message
*chrislck never thought define-syntax-rule could be inside a (define) environment...
<civodul>flatwhatson: i followed up on the libgc/munmap issue at <>
<flatwhatson>ah great, really happy my stubborn investigation of that unit test paid off!
<civodul>it did! much appreciated
<civodul>i have patches regarding the finalizer pipe and thread "sleep pipes", not sure if that's what you were looking at
<civodul>lemme know you think!
<flatwhatson>ooh, nasty
<flatwhatson>(the bug, not your patch... :)
<flatwhatson>civodul: lgtm, except i think GC_set_finalizer_notifier should only happen if thread is created successfully
<flatwhatson>do we need to worry about unlocking the mutex when throwing scm_syserror?
<flatwhatson>the full patch to finalizers.c:
<flatwhatson>guile: finalizers.c:258: start_finalization_thread: Assertion `finalization_pipe[0] == -1' failed.
<flatwhatson>oh, right, if creating the pipe succeeds but creating the thread fails, it's left inconsistent
<flatwhatson>this one is *tested*:
<flatwhatson>running test-out-of-memory gives multiple "error creating finalization thread", which means it's properly retrying thread creation and properly cleaning up if/when that fails
<tohoyn>sneek: botsnack
<civodul>flatwhatson: ah yes, that makes sense to me, thanks!
<civodul>could you send the updated patch to
<civodul>i'll give it another look later today and apply it if everything goes well
<civodul>i'd also like to have a test for the sleep_pipe problem
***jonsger1 is now known as jonsger
<flatwhatson>civodul: should that be, as a follow-up to your patch?
<flatwhatson>sneek: later tell civodul
***jonsger1 is now known as jonsger
<civodul>flatwhatson: thanks for the revised patch, i've pushed it!
<civodul>i also pushed the 'sleep_pipe' patch i posted earlier
<civodul>it fixes the problems we were observing before \o/
<civodul>maybe wingo can comment later
***andrea is now known as Guest72264