<flatwhatson>speaking of the patch queue... i've sent a patch to improve the "all errors lead to boot-9" situation <rekado>flatwhatson: I’m looking forward to seeing this fixed. I’d love to see better error reporting in Guile. <rekado>relatedly, I see “<unknown-location>: warning: non-literal format string” (or any other error/warning message) when compiling a Guile project <rekado>I only know where the problem is because I see what file it compiles <rekado>but it really shouldn’t be <unknown-location> <civodul>rekado: i think there's a regression in 3.0.8 here <civodul>would be interesting to try and bisect since v3.0.7 <flatwhatson>there's already a patch for unknown-location in guile-next <flatwhatson>the problem there was that the lazy inflation of location vector to alist is done by exporting tree-il-src/ensure-alist as tree-il-src <flatwhatson>but the analyzers use match record destructuring to get the src, which bypasses this and uses record-accessor instead <civodul>flatwhatson: so is this fixed on the "main" branch? <civodul>actually can you think of a unit test we could add to check that? <flatwhatson>well, it's fixed by adding support for printing source location vectors <flatwhatson>so we don't *need* to inflate them. so it shouldn't be that easy to regress <flatwhatson>could add a trivial test for location-string that checks it works with both vector and alist? <flatwhatson>i wonder if this could be considered a bug in match. like should match use an overridden field getter if it's in the lexical environment? <tohoyn>I have published Theme-D version 5.0.0 in SourceForge, see https://sourceforge.net/projects/theme-d/. I can't publish it in Debian archives right now because of some problems with upload rights. This version includes bootstrapped Theme-D compiler and linker, see subdirectory theme-d-bootstrap. <tohoyn>Unfortunately the bootstrapped compiler and linker are slower than the original ones. That's why the bootstrapped versions are not used as the default compiler and linker. <rekado>tohoyn: would it be possible to add a second pass (building the final compiler with the bootstrapped compiler) to make the result more performant? <tohoyn>rekado: the original and bootstrapped compiler and linker produce bit-by-bit equal output <flatwhatson>re: testing for warning/error regressions, maybe we need some higher-level tests which run guild compile over buggy examples and check for appropriate warnings & location info <civodul>flatwhatson: yes, i guess that calls for higher-level tests <civodul>we have that somewhat in tree-il.test IIRC <civodul>a couple of them explicitly check for source location at the beginning of the message <civodul>so if you know how to reproduce the initial bug, we can add it there <flatwhatson>it was any warning from the use-before-definition analysis, eg. unbound-variable-analysis <tohoyn>daviid: it would be nice of g-action-map-add-action worked with <g-settings-action> <tohoyn>daviid: g-action-map-add-action does not work with <gtk-callback-action>, either <tohoyn>daviid: I'm using the current G-Golf devel branch ***Furor is now known as Colere
***Server sets mode: +ntz
<lloda>is this a bug (format #f "~5,1,,,'0f" -9) => "0-9.0" ? <wingo>is it a change relative to guile 1.6 or whatever, or is it "does not conform to documentation" <lloda>i can see padding is padding so if it was space prefixing the sign would be wrong <wingo>it certainly doesn't look sensible to me :) <wingo>i feel like this is one of those fortran-era things, where you would pad with * or something <wingo>i hadn't seen it but yes i am pretty sure whippet will fix that. <wingo>i am currently working on conservative gc for whippet, close to done. surprisingly tricky <civodul>ooh, conservative GC, that must be a fun hack :-) <wingo>there are many flavors :) with conservative data segments or no, with conservative stacks or no, if pointers might be interior (i think i will do this just for stack roots, like bdw-gc does), whether heap edges are also conservative (we should be able to be precise on the heap and whippet does that, but maybe we need to support conservative edges) <wingo>how to handle displacement (like the struct -> vtable edges) <civodul>bdw-gc has a switch for interior pointers (i think we turn it off) ***maximed is now known as antipode
***NullPointerErro1 is now known as NullPointerError
<spk121>Hello Guile. I made patchset to remove the cruftiest part of our autotools that I'd like to pull into main. <spk121>We're still checking for a few headers and funcs defined in C89. <spk121>How should I do patches these days? I could post them all on guile-devel@gnu if that's what we're doing <daviid>tohoyn: not sure if you are refering to a missing feature, or a bug - I was kept afk nearly 7weeks, but back and working on VFunc proper support, which is quite complex, and I am not going to do anything else till it's done, unless a bug ... <tohoyn>daviid: g-action-map-add-action should accept an arbitrary object implementing the GAction interface. <tohoyn>daviid: are arguments with an interface type a missing feature or is this a bug? <tohoyn>daviid: OTOH g-action-map-add-action works with <g-simple-action> <daviid>tohoyn: didn't you already asled that question (i do't remember well, but something ring a bell and tells me this isrelated to GVariant, currently only one rudimentary GVariant case is supported ... <tohoyn>daviid: creating <gtk-callback-action> requires a GVariant <tohoyn>daviid: but the system accepts #f as the gvariant argument with <gtk-callback-action> <tohoyn>daviid: i.e. gtk-callback-action-new <tohoyn>daviid: I'll go offline now. I'll read the log. <daviid>sneek: later tell tohoyn, i won't spend time on anything else then proper support for VFunc, unless bug(s) while using implemented feature(s), GVariant are not supported 'proper' (and very far from) in g-golf current (as you know already ...) ***Noisytoot_ is now known as Noisytoot
***maximed is now known as antipode