<apteryx>RhodiumToad: serializer #f or empty-serializer (defined elsewhere) would be sufficient! <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>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>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>if you pm me your email I could simply give you authorship of the commit, which would be more accurate :-) *chrislck never thought define-syntax-rule could be inside a (define) environment... <flatwhatson>ah great, really happy my stubborn investigation of that unit test paid off! <civodul>i have patches regarding the finalizer pipe and thread "sleep pipes", not sure if that's what you were looking at <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>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>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 <civodul>flatwhatson: ah yes, that makes sense to me, thanks! <civodul>could you send the updated patch to 40525@debbugs.gnu.org? <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 41948@debbugs.gnu.org, as a follow-up to your patch? ***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/ ***andrea is now known as Guest72264