IRC channel logs
2025-12-03.log
back to list of logs
<old>3.0.11 still not avaible on Guix hmm <old>I was thinking it would be there after one day <mwette>I'm trying to build gnucash w/ 3.0.11 <mwette>maybe gnucash and lilypond should be checks for guile releases <rlb>We'd need rc releases unless someone knowledgeable enough is willing to do it from say main. <rlb>mwette: without having looked closely, I wondered if stale .go files might be involved somehow, and of course there's also the question of whether we might have broken backward-compat macro-wise somehow. <rlb>I'm not actually sure what we promise there? <rlb>i.e. are you required to rm all .go files when upgrading guile Z releases, or are we supposed to make sure that works (which is pretty restricting if you don't (and we don't) track dependencies introduced by macros). <rlb>Broadly speaking, another good reason to be pretty cautious/conservative with additions to a Z release. <rlb>s/additions/changes/ <mwette>The build went find. From the mail it seems it fails during a run. <mwette>i have to rebuild to install in a benign place to run <mwette>The build fails now. The guile code in there is a bit messy: e.g., use-module (tests ...) with no directory named tests. <rlb>Fails with the same (lambda ()) error? <old>rlb: well for bug fixes releases, is rc really necessary? <old>I would understand for minor version, but for patch version? <old>Althought, release cycle of Guile is now very high, even for patch release. So rc might be a good fit <mwette>no. something else. This will be an effort. Crashes loading(?) gnucash/report/test/test-commodity-utils.scm <rlb>I think we changed a number of macro-related things in the release... <mwette>I now have a script file to reproduce. <rlb>Hmm, then maybe you can git bisect the v3.0.10 to v3.0.11 range to find the problem. <rlb>assuming it's amenable to a simple, repeated "make install" or "rm -rf INSTALLDIR && make -j5 install" or something similar... <mwette>more of a brute-force approach, but seems to be srfi-64.scm <rlb>...wonder (with no evidence) if there's an expansion/body that's now just empty, and could be fixed with a (lambda () *unspecified* ,@body) or alternate macro base cases. <mwette>I found a bug in gnucash. I sent an email. In test-commodity-utils.scm, (teardown)))) -> ) (teardown))) should fix I think. <mwette>The -with-cleanup macro is expecting a cleanup-clause but it was not provided in a couple tests. <rlb>Maybe we got stricter or something? <mwette>srfi-64 should probably catch the syntax error and report. <mwette>srfi-64.scm seems to be a major rewrite <rlb>yes, it was overhauled <mwette>I wonder if syntax-rules is parsing correctly there. <rlb>There were also some psyntax changes, and maybe also some other macros that changed. <rlb>Are you supposed to be allowed to have a test-group-with-cleanup that has no body? <rlb>If not, then that formulation should probably be rewritten with two arities, or something else. <rlb>i.e. for (test-group name x) is x supposed to be a cleanup form? <rlb>I'd guess not offhand. <mwette>the lambda needs to be something like `(lambda () #t decl-or-expr ...)' <rlb>That's also going to crash (what you're saying) if there are no body forms. <rlb>Oh, right, you are saying that. <rlb>Right either #t or *unspecified*, depending, if it matters either way. <mwette>the with-cleanup form seems ok, the other one needs fix <rlb>But the other one also seems maybe off, i.e. unless x is supposed to be a cleanup in (test-group name x). <mwette>the syntax-rules is working correctly; (a b ... c) w/ two args shojuld result in b empty list <rlb>(test-group-with-cleanup name x) <rlb>That'll have no body, and run x as cleanup, right? <mwette>if that is illegal then the syntax0rules should catch it <rlb>Oh, do you mean that's not reachable because it's private and never called that way? <rlb>Or is it supposed to work that way? <mwette>I tested by copying that code and adding a ` in front of (dynamic-wind <mwette>no. If test-group-with-cleanup is illegal wth three args then there should be a ((_ a b) (syntax-error "more args expected")) <rlb>oops, left the ... in the first expansion, <mwette>I'd make that an error, since for that use one should just use (test-group suite-name decl-or-expr) <mwette>opportunity to catch unintended use <rlb>Sure, that'd work too. <rlb>No idea what the srfi says if anything. <rlb>If the second form should never be cleanup, then what we have now probably needs one of those fixes. <mwette>I'd throw back to the author to fix, if it can be turned around quick. <rlb>Were you planning to pursue it? Or could just file a bug or issue for now. <rlb>*If* the srfi doc syntax is supposed to mirror syntax-rules, i.e. if ... means the same thing, then it's probably not supposed to be an error. <rlb>i.e. they write it the same way <rlb>Of course that would also apply the more suprising semantics, so I'm not sure it's intentional. <rlb>Also they write exactly the same, gnucash-crashing expansion in the test-group description, i.e. (lambda () decl-or-expr ...) <rlb>again depends on whether those elipses are "formal" or informal. <dsmith>rlb, /topic should be updated for 3.0.11 Andy usually does it. <rlb>mwette: depending on which bit you weren't sure about, I just meant that I don't know if the syntax in the srfi-64 doc, i.e. the "..." usage there is intended to have full syntax-rules semantics, or if it's just an "informal" use of the elipsis. <rlb>dsmith: oh, right --- no idea if I can change it, but if not, we'll have to find someone who can. <rlb>ACTION remembers how to try... <rlb>Nope -- bot says no :) <rlb>wingo: if you see this, could you update the channel topic for 3.0.11 when you have time? <dsmith>rlb, Need ops. Then (I think) just "/topic new topic here" <rlb>Yeah, I remembered -- asked the chanserv and it said "no ops" :) <rlb>Of course we can also badger civodul when he's back. <sneek>Welcome back tohoyn, you have 1 message! <sneek>tohoyn, daviid says: I'll try to look at why your GClosure args seems wrong, but as I told you , I currently have (quite) limited free time - your last paste still uses a main that does not check nor sets the -d --debugg paramemter .. please update and re-paste, tx <tohoyn>daviid: could you paste a correct version of main <tohoyn>daviid: actually, argument on-my-signal to gd-bus-connection-signal-subscribe is a callback, not a GClosure <tohoyn>daviid: no I found the correct version of main <ieure>Does Guile have dynamic variables? <ieure>Okay, found them, "Parameters." <tohoyn>daviid: or is the callback implemented as GClosure? <ArneBab>rlb: Since our ccache is only prefixed by the major.minor version (3.0), we cannot require rebuilding of *.go files on a patch update, because our auto-compilation won’t do it. I’d prefer somethingdifferent, but that’s what our ccache does. <ArneBab>⇒ lib/guile/3.0/site-ccache -- if we want to guarantee that macros are updated, we must release 3.2 or change the cache to use 3.0.11 as namespace. <rlb>right, that's what I thought I remembered wrt versioning of the cache (which is the same as the .go install tree) <rlb>dpk: would have bene nice if noncharacters were smaller in utf-8 --- so each unencodable byte was (including the esc) less than 9 bytes, but I suspect noncharacters were considered "later" once unicode was fairly populated, if nothing else. <rlb>(I suppose if you thought that runs of unencodable bytes were going to be common, you might want some "bracketed" escape syntax, to save on the escaping cost.) <rlb>(And if you had 258 noncharacters you were willing to use for this, you could do even better.) <rlb>But of course the need for them should be rare and become increasingly so as utf-8 becomes even more pervasive. <dpk>how do you get to 9 bytes? <dpk>there are two cases: an individual bad byte would be six bytes, three for the high nybble and three for the low nybble <dpk>a literal noncharacter would be the quoting character (three bytes) plus the original noncharacter (three bytes) <rlb>Oh, I read things backward then -- I thought "real" noncharaters in the source string came through as-is, and undecodable bytes were escaped so that the original string won't be altered when there are no decodable bytes. <rlb>So if you have $'\xb5' in a utf-8 locale, it would decode to three 9 utf8 bytes. <rlb>the esc char, the b and the 5. <rlb>But sure, if you don't care about altering the unicode string during the translation when there are no undecodable bytes, then you can flip that around. <rlb>But then of course things like string-length would change for strings on ingest even if there were no undecodable bytes, etc. <mwette>rlb: Did you receive the email I sent yesterday re: the gnucash issue? <rlb>ekaitz: I noticed that the recent lightening changes don't include copyrights in the files, and i also didn't see any kind of blanket default via say a libguile/lightening/LICENSE (if that's even acceptable). Ludovic reminded me of https://lists.gnu.org/archive/html/guile-devel/2022-10/msg00008.html and so I wondered if you knew what should be in those files, and/or wanted to fix things up. <rlb>mwette: hmm, not sure --- which one (and also, can be a little slow wrt email sometimes). <rlb>Files I (well debian lintian) noticed were libguile/lightening/.woodpecker.yml <rlb> libguile/lightening/lightening/riscv-fpu.c <rlb> libguile/lightening/tests/call_10_2.c <rlb> libguile/lightening/tests/callr_10.c <rlb> libguile/lightening/tests/movr_dl.c <rlb> libguile/lightening/tests/movr_fi.c <rlb> libguile/lightening/tests/regarrays.inc <rlb>oops, that was supposed to be a paste url :) <rlb>mwette: if you mean the one in the guile-devel announcement thread about the gnucash teardown fix, I did see that... <mwette>rlb: the one where I point out the fix; the email lists no longer accept my emails <mwette>Oh. I didn't realize that. Then behavior of thunderbird has changed. <ekaitz>rlb: I could add the license headers if you ask me to, but if what you are asking is if we *need* them the answer is I've never understood why we should add the very same text in every single file of the repositories <rlb>ekaitz: Ludovic asked me to ask when I asked ;) I think for now, the plan is to keep doing what we've been doing (I'm guessing that's been informed by "lawyers" at some point.), but I asked about SPDX, and it sounds like that may be an eventual possibility (which is also nice for packagers/tooling). <rlb>The other main thing was that mail which says that we should still have copyright line(s) too, but they can just be the original author if they don't assign to the fsf. <ekaitz>ACTION is a rara avis in the free software, he doesn't like copyright headers <rlb>From the packagers perspective, I'd prefer SPDX (assuming there are no other concerns) so that, for example, it's easier to generate/validate/maintain debian/copyright, etc. (and easier on the debian incoming package reviewers). <rlb>mwette: oh, and were you intending to investigate further, or thinking of filing a bug or issue (presumably your preference) wrt the (two I think?) srfi-64 questions? No worries if not, just checking. <mwette>I was not. I was hoping gnucash would proceed to fix their end and relieve the pressure on 3.0.11, which is not urgent, I think. <old>License + File-copyright in two lines <mwette>Is there a FSF legal opinion on this? <mwette>rlb: If you think I should generate an issue for srfi-64 I will. <rlb>Oh, yeah, don't think it's urgent. And maybe first we/I should badger someone about the srfi-64 spec, i.e. what's actually intended in those two cases (or is it undefined, etc.), and go from there. <mwette>I agree. In any case the result there should be one of accept none or emit sensible error message, IMO. <rlb>mwette: actually, regardless, at least for the (lambda () ...) case, for backward compat, perhaps *we* should change it to (lambda () true-or-undefined decl...) for now? <rlb>now that I think about it <rlb>i.e. doesn't hurt, and prevents breakage wrt earlier verisions <mwette>I would just add a #f to the front. <mwette>Then, I guess, the form (test-group "name") would always fail, causing author to go check why, in case he made a mistake. <rlb>Oh, *of course* -- I wasn't thinking about the broader context. <rlb>Needs to be false or an error. <rlb>dpk: OK, I understand now -- from the sample implementation; thanks for the help. <dsmith>civodul, Thanks for the topic update <mwette>Was there a discussion about renaming .go files to use some other extension? <dthompson>none that I recall. on the mailing list or here? <rlb>thx, glad we made it <mwette>Can't remember. Must have been somewhere else. Context was conflict w/ Go files. <mwette>If .go has to go, then I was going to suggest .wo, and call them wingo files. <rlb>I think I'm likely to be a fan... <rlb>I might even be fine with the stricter variant (when appropriate) that doesn't allow excess length (at the expense of one more & in the call). <rlb>Wonder where/if that applies to the utf8 string changes -- have to poke at that later. <mwette>I don't like .so because that's been aound for decades to denote 'shared object'. It would be confusing, I think.