IRC channel logs
2026-05-10.log
back to list of logs
<rlb>I'm starting to suspect we don't test any escapes for (web http). I just changed one of the guards in collect-escaped-code to see, and all the tests still passed... <ArneBab>old: does the benchmarksgame benchmark help you? <ArneBab>old: or should I try and see whether I find another one? <old>ArneBab: I did not had time to check. Will try on monday I think <old>Oh wait. I just figured something <old>you are checking for real and inexact number -> flonum <old>would be interresting then to benchmark chickadee with flonum? as a primcal and use that predicate <JohnCowan>old: yes, the digits are contiguous in all encodings, and in Unicode all types of decimal digits are in mini-blocks of 0-9 <ArneBab>ACTION had actually forgotten that he had benchmarked that … <spk121>looks like old pulled the big gnulib update into main. I did my best to test it on as many systems as I could beforehand. I hope it is painless. <spk121>It built on Curiass, so, so far so good <spk121>Hmmm. The Gnulib change causes a build failure on musl on Alpine: conflicting types for off_t <old>ArneBab: is it on Guix? <old>ArneBab: well I just copied the code locally seems to work <old>Well the magnitude benchmark are not very good for what I want to do <old>it's doing too much GC allocation, too much noise <old>in pure comparison, the primcall to flonum? seems to give a speed-up of 1.30 <old>so I think the optimization is good to have. Now it would be to see how in CPS we can infer flonum? from hand written predicates <rlb>jcowan: just to be sure before I make it so, in srfi-152 the "must be newly allocated" specification does disallow copy on write, right? <rlb>(Asking, of course, since Guile is generally COW, and so I think most/all the existing srfi-13 functions are, which presumably means I'll need to have slight variants for srfi-152 rather than just republishing them as is.) <identity>i do not see why that would disallow COW;i believe «newly allocated» means the same thing as «The child process and the parent process run in separate memory spaces.» means for fork(2) <rlb>Well, it specifically mentions "shared strings there", so wanted to check. <rlb>"Except as noted, the results returned from the procedures of this SRFI must be newly allocated strings. This is a change from the definition of SRFIs 13 and 130, though most Schemes do not support sharable strings in any case." <identity>as in, not necessarily, but the differences are effectively impossible to observe <rlb>Unless you're specifically worried about memory consumption. <rlb>i.e. I have a 1G string and use string-break to grab the last byte or whatever. <probie>unambiguously to be srfi-152 compliant, they must be newly allocated strings <probie>it's fucking stupid, but if you want to be compliant with that srfi that's what you should provide; not just something which is equivalent under functional extensionality <identity>i still do not see how COW is going to make an implementation non-compliant in this case <rlb>It would if the whole intention was to make it so that you can write portable programs where you can know what the memory-related/sharing behavior will be, in cases where that matters. (i.e. I don't think it's stupid) <rlb>Without that, some algorithms would be untenable, portable, wrt memory consumption, i.e. with COW strings.. <rlb>s/portable/portably/ <rlb>So I just wanted to double-check the requirement. <jcowan>probie: SRFI 152 strings have to be indistinguishable from newly allocated strings by the as-if rule <jcowan>in particular, if they are read-only they can be shared. <jcowan>"A difference that makes no difference is no difference." --Spock <identity>maybe you should not rely on COW, sure, but that is orthogonal to implementation compliance. «newly allocated» does not necessarily mean that the object is a copy, just that the storage locations in the abstract memory store are ‹fresh›; operationally, if you successfully *set! the location, the only place where changes can be seen is through the location of the object you *set! <jcowan>And since RO strings cannot be string-set!, that's always safe. <rlb>And glad I double checked --- I'd thought maybe the "shareable strings" might be referring to structural sharing. <identity>hence «successfully *set!»; «It is an error to attempt to store a new value into a location that is denoted by an immutable object.» <rlb>jcowan: if the 152 test suite is updated, might be worth having a case where the string-map fn produces a string (just noticed that we're not yet compliant there because I just relied on our current srfi-13 string-map). <rlb>OK, I added it to my very long utf-8 todo list :) Though may well, since our srfi-152.sr64 is more or less the upstream one.