IRC channel logs
2025-09-01.log
back to list of logs
<lechner>rlb / I wrote a syscall layer that sidesteps Glibc but requires an assembly stub per architecture. I already wrote them for x86_64, i686, Aarch64 and riscv64 and wonder how and where people actually run Guile <lechner>rlb / good idea, although I don't see arch in there <lechner>rlb / also, thanks for maintaining Guile in Debian! <apteryx>hi! is it possible to configure pretty-print to list multiple strings per line in a list of strings? <apteryx>currently it does one string per line <apteryx>I'd like it to fill the space until the default character width of 80 <ArneBab_>wingo: what’s involved in making a release? Can we (I) prepare something to reduce the load on release managers? <sneek>Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux <rlb>ArneBab: unless I'm mistaken, it looks NEWS entries might be missing for some of the things you added to 3.0.10 -- if you can and want to track some of those down, that'd help, e.g. 78e9e51065c23bc755e669295c46537a5e988791 (Also wondered what happened to the newlines in the commit messages.) <rlb>ACTION is also going to try to help with some of the release prep <rlb>I have a few entries for other things pending (was reviewing the commits). <ArneBab>I’ll add a news entry! The commit message seems to have been garbled in patch formatting :-/ <rlb>If you have time to scan all the commits you merged or wrote for missing entries, I'll skip them in my review, no worries if not. <rlb>old: wrt srfi-64, might want to check main, or see how things are in 3.0.11 once it's available since the implementation's been replaced. <ArneBab>rlb how should I send you the changes? With a PR on codeberg? (I have no merge permission there) <rlb>Whatever's easier for you should be fine. <ArneBab>rlb: easier would be to push to savannah, but I guess that’s not what release folks want. So I’ll create a PR. <ArneBab>(and looking at the log I’m surprised how much I merged) <rlb>I'd also be fine with pushing to some tmp branch on savannah if you like. <rlb>not pretty, but we have plenty of wip, etc. branches there already :) <ArneBab>(how) should I mention documentation improvements? <rlb>Hmm, I don't *really* know what I'm doing :) But I've been skipping some more minor things -- in part I've assumed that civodul has already done some of this. (The main thing I think he was waiting on was some entries for the notably complex changes wingo made to compilation, etc., but now looks like we're going to proceed anyway.) <rlb>If you're in emacs and you collapse all the content, you can see previous headers more easily, and I see some in there that are documentation related... <ttz>Is there a chance the hash bugs (both hashing permuted lists and bytevectors is wrong) be resolved in the v3.0.11? <rlb>ttz: don't know? I did fix something hash related in main a while back, but not sure it's related. <ttz>I raised two issues related to hashing bytevectors earlier this summer: #7900 and #79006 which is a duplicate, sorry for that. <ttz>I thought I raised another one for the lists but I can't find it back so I guess I didn't. <ttz>basically (equal-hash (list 1 2)) is the same as (equal-hash (list 2 1)) <rlb>lloda: also noticed you may have some commits in v3.0.10..main, or merged some, that might warrant NEWS, if so, and if you get time to take a look, that'd be great. <rlb>(A while back I noticed/fixed a hashing bug that was hashing iirc all symbols or keywords to the same value :/) <rlb>I forget the details. <ArneBab>thank you for taking this up and coordinating! <ttz>sorry a missing 0: #79000 <rlb>well, no promises :) I'm just going to do some doc/release.org related things as I get to them, and we'll see where that goes. <ttz>I just checked, hashing pairs does not work either (which could explain that it does not work for lists): (eq? (equal-hash (cons 1 2)) (equal-hash (cons 2 1))) => #t <rlb>Anyone else who's interested might want to take a look -- i.e. if nothing else, now's a good time for a "call for testing", i.e. if have some place you'd like 3.0.11 to work, nows a good time to try a "make check" there. <rlb>ttz: this is/isn't a regression with respect to 3.0.10? <ttz>I meant I checked on the v3.0.10 <rlb>OK, so it's the same on 9 and 10? <ttz>which branch is the release candidate for v3.0.11? <ttz>yes it's the same on .9 and .10 <rlb>OK, so offhand, I'd say we *want* to fix it for 11, but we could also fix it in 12. <rlb>...where is any formal (or as formal as we have) spec for our hashing? i.e. where are the semantics defined -- what are the hard requirements vs preferred behavior, etc. <ttz>RNR* specifies that two equal? object should equal-hash to different values <ttz>I guess this is hard behavior <rlb>...note to self - urls surrounded by angle brackets (and/or followed by a period) don't work right in say gitk <rlb>ttz: thanks -- though iirc our current hasher (at least the one I fixed before) intentionally doesn't do that, i.e. I believe for nested sexps, it only looks "so far" to generate the hash. <rlb>so if the two sides differ beyond that, we'll never know. <rlb>Assuming I remember that right (and even if not), I suspect we probably want "more discussion", likely including civodul and/or wingo... <ttz>This is wrong to make it the default hasher imho: if this behavior raises from a performance constraint, then a limited hash might be implemented but I would not expose it. And anyway, I think we need a conformant hash for equal-hash (which may be different from hash). <ttz>yes, more discussion would be great: I don't know of the history of the project so my input is very limited on the topic <rlb>Oh, I'm not arguing one way or the other -- just saying I don't feel like I'm position to decide atm :) <rlb>(It'd be nice to eventually have a standard set of immutable/persistent structures for which we could cache the hashes, computed either eagerly or lazily...) <ttz>why would you need to cache hashes? <rlb>well, I meant that depending on the hashing, I wondered if there might be cases where you didn't want to compute it until it was needed, and then, even if the structure was semantically immutable, the hash might be added on demand, atomically of course. <rlb>ttz: yeah, I think there are a number of potential contenders (hoot has some too, and wingo has his map and vector), etc. <rlb>and maybe one other I'm not thinking of someone mentioned? <rlb>iirc we only go until the depth limit is exhausted atm. <ttz>l.298: Also the hashes are currently associative, which ain't the right thing. <ttz>might be the cause of the list-related bug <rlb>Since that was intentional, and depending on the impact, I could also imagine this might be a change we'd decide requires a major release -- say we thought that the performance difference might disrupt enough uses to warrant that... <ttz>l.364/365 might be the cause of the bytevector-related bug, my guess that only the element of the underlying representation (possibly identical for bytevectors of the same kind) hashed <ttz>*was that/*the first element <ttz>nowadays hashing is so fast that I doubt speed might be an issue, but once again: all we need is one conformant equal-hash, having a non-conformant hash might be okay (even though its limitation should be documented) <rlb>well, if the sexp is 200M :) <rlb>Though caches are huge now too... <ttz>also, I ran into a huge performance issue while storing vectors into a hash-table the other day: performance was O(n) instead of O(1) <rlb>yep, that's likely a common problem (if all this is right) too <rlb>And regardless, I agree that if the standard says hashing has to match equal? then it does :) <rlb>...now I need to figure out where codeberg puts pull requests, refs-wise, so I can fetch them. <rlb>(I know where gh does.) <ttz>thank you for pointing me to the hash implementation! <rlb>Certainly, and iirc the bytevector structure is pretty straightforward too. <rlb>thanks -- for gh you can just add something like " fetch = +refs/pull/*/head:refs/remotes/github/pr/* <rlb>to the branch in .git/config -- trying to figure out whether there's something like that for codeberg too (testing...). <rlb>That fetch line will map all prs to pr/N locally. <ttz>Also rlb, would you know why R6RS libraries are not marked as declarative? <rlb>I haven't actually messed with rnrs libs much yet. <ArneBab>I’d guess because marking them declarative could break existing code (that relied on being able to module-set! bindings). <rlb>If we think that's something we might want to do -- we should put it on a 4.0 list "somewhere"... <ttz>But they are defined as immutable sets of bindings by the standard iirc <rlb>(if it's not something we can just change in 3) <ttz>Yes, sure this is a breaking change. <ttz>All explicitly exported variables are immutable in both the <ttz>exporting and importing libraries. It is thus a syntax vi- <ttz>olation if an explicitly exported variable appears on the <ttz>left-hand side of a set! expression, either in the exporting <ttz>or importing libraries. <ArneBab>were they also immutable in r6rs and r5rs? Our module system predates r7rs <ttz>(this is R6RS, I haven't looked elsewhere) <ttz>rlb: I have a configure error while running the guix shell command given in HACKING <ttz>configure: error: GNU MP 4.1 or greater not found; either install it, or pass '--enable-mini-gmp' to use included less-optimal arbitrary-precision integer support. <ttz>I guess there is something missing in guix.scm <rlb>Hmm, wouldn't know atm -- still haven't worked with guix myself. <rlb>mdj: does keyword formals need a NEWS entry? <rlb>mdj: s/keyword formals/keyword-formals/ <identity>R7RS: “In a program or library declaration, it is an error to import the same identifier more than once with different bindings, or to redefine or mutate an imported binding with a definition or with ‘set!’, or to refer to an identifier before it is imported. However, a REPL should permit these actions.”, “an error” meaning “implementations are not required to detect or report the error, though they are encouraged to do <rlb>...noticed/remembered riscv JIT support was added; I'll see about testing there on a porterbo in advance. <identity>so R^{6,7}RS disallow/discourage mutation of exported bindings; R^5RS does not take a stance on that, on account of not having a library system, though it has something to say on ‘scheme-report-environment’: “The effect of assigning (through the use of 'eval') a variable bound in a 'scheme-report-environment' (for example 'car') is unspecified. Thus the environments specified by 'scheme-report-environment' may be immutable.” <rlb>...that's going to take a while. <rlb>civodul: I added support for SRFI-64 tests to the test suite for SRFI-197; I'm wondering if/how we want to mention that in the NEWS, i.e. is that something we want to commit to as part of a "public api", or we could explicitly state that it's provisional/internal for now, or...? <rlb>c85825328826e2078fe0177e43185e4550d14282 <rlb>OK - made a full pass through the changes wrt the NEWS, and I'll likely commit something later -- other pending bits there are lloda's pr, mjd's changes, and NEWS for the PEG changes, if we want any. By default, I'll plan to decide about those, eventually, if others don't. <civodul>rlb: NEWS is for user-visible changes; IIUC this doesn’t fall into that category, does it? <rlb>sneek: later tell civodul -- hadn't understood them well enough yet to know if I knew :) Happy if we don't need them. <old>rlb: this still leave 3.0.10 broken. I need a define a workaround for guile 3.0.10 I think <old>or is 3.0.11 not meant to be used by distros and the jump will be from 3.0.9 to 3.0.11 directly <dpk>identity: R6RS and R7RS small both consider scheme-report-environment effectively deprecated; from an implementation p.o.v. i wouldn’t worry too much about whether they’re mutable <dpk>the R5RS committee added the original environment procedures because thought first-class environments were going to be the basis of the standard Scheme library system. this never happened