IRC channel logs
2023-07-09.log
back to list of logs
<rlb>Hmm, I suspect it's likely we're either going to choose to switch to utf-8 and everything is going to have to adapt as needed to the fact that set! can no longer be O(1), or we're not. And so far, I've been given the impression that we have decided to migrate. <rlb>In that world, lilypond would just have to rework the relevant code. <rlb>spk121: wonder if there's any chance the "lightly mangled" could be typical corruption, whether via gc (missing remember_upto or similar), or other more typical mechanisms. <ArneBab>Are you aware that lilypond scripts are part of actual musical scores? That the lilypond people cannot just say “let’s rewrite that part of our code and it’s fixed”? <ArneBab>It depends on details whether the relevant code is “a few files to adapt” or “a significant fraction of all the user documents out there”. <rlb>I don't know that much about lilypond, but and I wasn't the one making the decision to try switching to utf-8. I've just done a *lot* of work on that front once I thought the decision had been made. <ArneBab>⇒ please do performance testing with lilypond: compile lilypond with your version of Guile, ask in the #lilypond channel for example documents, and work with them to see whether any needed adjustments can be made easily. <daviid>i don't think it is reasonable to ask rlb to compile and test lilypond <daviid>nor is it to ask to 'hold-on gile not usong utf8 because of lilypond, fwiw <rlb>I suppose atm, I'd say I'm far enough along, that *if* I do get something plausible finished up, we'll want to test it, and sounds like lilypond might be a good candidate to add to the set. <rlb>Whether I'm the one testing it specifically, or it's just in our broader analysis. <ArneBab>daviid: I think it’s unreasonable to do changes that break lilypond. Every other project that considers using Guile for something mission-critical would remember that — and shy away. <ArneBab>rlb: AFAIK lilypond has a test-suite where you’d see the effect directly. <rlb>Offhand, no idea what the effect's likely to be -- will depend very heavily on how much it relies on fine-grain string mutation. On the plus side, the new arrangement is likely to be more compact for western alphabets wrt cache, bandwidth, etc. <rlb>Once we're there, as long as lilypond's compatible with 3, and doesn't use internal apis, shouldn't be too hard to test, fwiw. <ArneBab>I don’t know whether this will cause problems or whether those problems would be easy to fix or whether it will just work, but it’s the most important test-case. <daviid>ArneBab: why don't you do it then ... totally unreasonable to ask rlb to do this, imo - and not even sure it is a good test anyway <ArneBab>daviid: it is a test whether it breaks lilypond. <daviid>we a re not gona write/maintain guile 'eternally' so 'it does not break lilypond', that's heresy to me - but i am off this conversation now, i made my point <daviid>and i think it is far too much to ask our wizard contributors 'to compile and test lilypond' - even lilypond maintainers have a hard time to compile lilypond ... <ArneBab>Since lilypond is not dead software but actually maintained software, this means to check with them. To care about those who use Guile and work with them. <ArneBab>rlb: I only noticed your work and its potential implications today, otherwise I’d have said something much earlier. <rlb>For what it's worth, on my end, the next step (assuming I get there) will be a public branch that anyone can try. So we'll have plenty of opportunity to test it out. <ArneBab>rlb: that sounds like a good way forward. <ArneBab>rlb: once you’re there, please also drop a line in #lilypond and ask them whether they could test if this causes any regressions for them. <daviid>they follow and post on guile-user, guile-devej ... they just seent a bug report goops related ... no need to ping them 'specifically', just announce on our ml should be sufficiant <ArneBab>I disagree: this is not just a technical matter but also a social one: pinging them specifically on a change that may affect them is a matter of courtesy which is very much needed after the problems the Guile 2 transition caused them. <rlb>One thing I've been wondering about today is whether we might want to change the existing behavior around copies, i.e. right now we explicitly say that you carry around the entire original (possibly large) string content via substring and other operations, unless you substring/copy, but with utf-8 that might be a bad trade since the O(N) mutation cost is going to be proportional to the original string content size, not the substring <rlb>size. But if operations like string-set! were to trim the content to just that string's characters when it was having to make a new copy anyway, that'd be a "free" improvement? <rlb>Assuming I'm thinking about it right. But the one catch is that if we want to / need to maintain the atomicity of the swap, and think we probably do, then we'd have to change the way the string refers to the string buffer. For example, we could make it point to a "pair" containing the string's buffer offset *and* buffer pointer. Then you can atomically swap that. Otherwise you'd risk a narrow window when trying to change the <rlb>string's in-line offset, and buffer pointer where they didn't align (leading to potential chaos). <rlb>But the disadvantage of that is that we'd have one extra (tiny) heap allocation and indirection, and I'd been trying to improve cache-locality, etc. rather than the reverse. In any case, I'm not finished thinking about it -- but I'm wondering if that realization might lead to some other possibilities (need to ponder). <ArneBab>I’m not deep enough in the string part of the code to judge that, but it sounds like interesting avenues to try. <spk121>dalepsmith: Samra wrote "In spite of LilyPond being compatible with Guile 3 for more than a year, we are still on Guile 2.2 solely because of lack of Windows support in Guile 3. LilyPond is not primarily targeted at programmers but musicians, so a large part of our user base is on Windows and it is absolutely unthinkable for us to drop our Windows binaries" <rlb>I wanted to check because it's enough work (notwithstanding the fact that I already have almost all the pieces) that I don't want to "just try it", even if I end up leaning that way :) <rlb>Oh, and that 'read only "base string"' representation actually is exactly what my current utf-8 stringbufs look like, hence "promotion". <chrislck>gnucash likely has a broader appeal than lilypond and very much requires windows too, and is therefore on guile-2.2 <rlb>...I guess it would have to if we don't work right there yet. <wmedrano>How essential is Guix for using Guile dependencies (like Chickadee)? <chrislck>Rhodium: are you sure? jralls has tried a few times (when I prompt him) and hasn't succeeded so far <chrislck>gnucash on linux easily uses guile-3 yes <chrislck>Rhodium: are you sure? jralls has tried a few times *on windows* (when I prompt him) and hasn't succeeded so far <chrislck>gnucash-on-WSL2 does successfully use guile-3.0 (obviously duh) <RhodiumToad>my problem with building it on freebsd is that it'll use guile 3.0 if present and there's no way to tell it not to <chrislck>it works on BSD? nice... if there are bugs/warnings please let us know <RhodiumToad>this seems to be an issue with most of the guile client s/w I've seen that uses cmake or meson to build <RhodiumToad>well, it compiled and runs, and someone is maintaining the port <RhodiumToad>my involvement is in trying to get the various dependent ports working without conflict if 2.2 and 3.0 are both installed <RhodiumToad>it's quite a nuisance when software just blindly goes for the latest version without providing some kind of configure override <RhodiumToad>it doesn't interfere with package building, because that's done in a clean environment with only the specified dependencies present, but it messes up attempts to build the port manually <chrislck>ok i'm not sure of the use case, however it probably would be better to move this discussion to #gnucash where the devs are <chrislck>ACTION is not a packaging expert at all -- i've mainly been maintaining and upgrading the reports and doing general cleanup <rlb>(and of course the sparse indexes are aligned after the content) <spk121>chrislck: well if gnucash and lilypond are both stalled on this Guile 3.0 on windows stuff, I've got a Guile 3.0 on Windows basically working, but w/o threads and w/o JIT. Is that good enough? If that's of value, I could clean up a branch and work on getting consensus to push it to main <spk121>I wanted to wait until threads and JIT worked. But honestly both GC and JIT are not in my normal skill set. <chrislck>spk121: this would be great. guile on windows has threads disabled[1], and all .scm are compiled to .go on packaging[2]. <chrislck>[2] however live gnucash can still run .scm files from the user, will it mean recompile every time? if that's the only side effect then no probs <tohoyn>daviid: I debianized g-golf version 0.8.0-a.4. See www.iki.fi/tohoyn/g-golf-debian/. <daviid>sneek: later tell tohoyn nice, thanks <daviid>dalepsmith: hello, so now you may even try g-golf effortless, a little extra effort is needed only if you wana play with cairo, then as said here (and in the doc), you'll have to clone guile-cairo, apply my patches, run the make danse ...