IRC channel logs
2025-12-09.log
back to list of logs
<rlb>So let's say we end up deciding noncharacters is what we want, and I manage to get it implemented (I do have some preliminary bits working), presumably we'd be likely to eventually make it the default for "system data" (paths, user/group names, env vars, etc.), but what about ports? Offhand, my inclination is to think not, which might mean that it needs its own, independent %default-sysdata-encoding and <rlb>%default-sysdata-conversion-strategy. Any thoughts? <ArneBab>rlb: my main question to that is: can we preserve backwards compatibility? <ArneBab>ports are used in interprocess communication that’s traditionally hard to debug, so introducing breakage there would hurt quite a bit. <old>rlb: are we talking about locale here? <basicnpc>Does guile have a specification (no, not a manual)? Also, does the guile VM interpret, compile, or both the guile VM bytecodes? <dsmith>Both. (there is a JIT compiler). Specs are prob R{5,6,7}RS to varying degrees <basicnpc>That's scheme spec, I think. But thanks anyways, just comfirming :-) <basicnpc>guile-elisp - does it work if I provide an emacs-buffer related function? <basicnpc>Or does it just implement a small subset of elisp? <dsmith>An intersting question. Where does elisp the language end and emacs the application begin? IIRC buffers are NOT in the guile elisp. <basicnpc>I just checked the src of guile/elisp.. it seems pretty minimal <Arsen>string operations alone pull in half of emacs' quirks <dsmith>Say you wanted to create a completely different kind of application with elisp. Perhaps a CAD Scematic Capture app. Would that need buffers? Specifically, all the capabilties of emacs buffers? <Arsen>I mean, you could implement a superficially similar language <basicnpc>no, but then why would one want to write in elisp? <Arsen>... but at that point, I'd just opt for common lisp <Arsen>(or, well, scheme, of course) <basicnpc>elisp itself isnt a well designed lang; it's still relevant because the last emacs user is still alive. <dsmith>I learned elisp before Scheme. (and don't know CL) <basicnpc>so i have no idea why one'd like to reimplement elisp in guile <Arsen>basicnpc: so that they can reimplement emacs to use guile ;) <basicnpc>they would implement something else that's not emacs -_- <Arsen>why? in this hypothetical there's a fully compatible guile language implementation for elisp <basicnpc>because emacs doesn't have a spec, and by definition the only thing that would be an emacs is the result from the official emacs repo <basicnpc>they would implement something similar, but i fail to see the point in it <Arsen>that's not really a useful distinction.. <basicnpc>No.. I kinda see the point; it's some exercise an academically minded person may want to exercise. <Arsen>well, the point is to be able to use the GNU Unified Intelligent Language for Extension in all GNU programs <dsmith>Because elisp is crufty and funky while scheme is clean an elegant. "But so much elisp already exists!" So have Guile also understand elisp... <identity>i think that reimplementing elisp is a fool's errand, re-implementing something Emacs-like in Guile is a far better idea <Arsen>it is a fools errand since upstream doesn't want to accept guile lol <identity>i mean yeah if Emacs did not want to support MS-DOS it would be easier to integrate upstream <Arsen>ridiculous.. wasting developer time on such garbage <dsmith>Arsen, No need to be so concerned. Not much effort is going into it I think. <identity>i mean, if they drop the MS-DOS code, all the people who use latest Emacs on MS-DOS will be disappointed <ieure>I have run Emacs on MS-DOS, but it's not a critical part of my life. <identity>if Emacs running on MS-DOS is a critical part of your life then you need a text editor with better MS-DOS support <identity>ls: cannot open directory '#guile': Permission denied <rlb>With 'noncharacters (rather than 'subsitute), we'd be doing a reversible conversions, which is what you'd want for paths/groups/... as long as the process is reversed by default on the way out, e.g. getenv/setenv. <rlb>Personally, I feel like the default should have been 'error. <rlb>(at least for file contents) <rlb>I'd like to know when I'm discarding data. <rlb>(error rather than substitute) <rlb>But for paths, env vars, user and group names, etc. I think it may make sense for 'noncharacters to be the default, so that most programs "just work", even if you don't know anything about all the related encoding/decoding/unicode complexity. <rlb>ArneBab: ^ and there's no way to make it completely transparent, but in many/most cases where the change might be noticed, the program was already "corrupting" data... <rlb>(in the cases where it'd make a difference) <rlb>We could also make it "forever opt in", but that'd leave, I suspect, a much larger number of existing and future programs "just broken" when they don't. <rlb>i.e. what's the point of taking the bytes of a command line argument and losing them (replacing them with "?") if you don't have to? <mwette>Maybe there should be a guile wiki for discussion of major issues that could be worked for v4. <dsmith>mwette, Those kinds of discussions are usually on guile-devel <rlb>I suspect the main constraint (whether wiki, or list, or ...) is likely to be Ludovic and Andy's time, i.e. for any discussions. As far as I know the gc overhaul and maybe utf8 are the main current candidates. <rlb>At least that's what Andy suggested a bit back. <rlb>I'm mostly asking about noncharacters here while I'm trying to figure out what's sensible/feasible (and what's involved), and I'm not even sure it'll eventually work out --- even if we can decide exactly what we want, I suspect it may be notable, careful work. <rlb>There's also the question of whether it should go before/after utf8, which also depends on how invasive whatever we end up needing is, and or what we end up deciding about utf8. <rlb>Does anyone know if you can easily/sensibly change the "origin branch" of a codeberg pr? <rlb>i.e. so you can retarget it without losing all the history. <ieure>rlb, You can change the merge target, but not the source branch. <ieure>ex. if I made branch update-foo in ieure/guix, open a PR into the core-updates branch of guix/guix, I can change the target so it'll merge into master. But you can't change the update-foo branch in ieure/guix, you have to close the PR and open a new one. <rlb>ieure: hmm, I was mostly thinking about it for a case where say I opened a utf8 pr against main, but then we branch for 3.2 or 4.0 --- can I change it from main to the new branch. Sounds like maybe you're saying yes? <ieure>rlb, Yes, that's the target branch, which you can change. You can change the branch the changes will go into, but not the one they come from. Since that would change the entire PR. <rlb>(I also didn't see (but may have missed) anything like guile's LICENSE in libguile/lightening, just duplicate COPYING and COPYING.LESSER files.) <ekaitz>rlb: I consider them part of guile, a little present to the project <rlb>Though perhaps guile's LICENSE is meant to apply implicitly to that dir too... <rlb>Ahh, OK, so you wrote them. <ekaitz>if they are lightening changes, the license lightening has <ekaitz>if the changes are the woodpecker.yml and such yes, i wrote them <old>Is FSF still keeping copyright over Guile source? <rlb>No, the RISV changes that you merged. <mwette>I had started looking at guile's init sequence, wondering if that might benefit from some work. e.g., you can't make a guile-code binary because the code to init needed ftns load scms is in the same C funtion that loads boot-9.scm. <rlb>Not sure I follow that yet, i.e. "needed ftns load scms". <mwette>rlb: sorry; to elaborate: "code calling init c-functions to provide capability to load .scm files." <mwette>in one function: init_aaa(), ..., init_zzz(), load('boot-9.scm') <rlb>you're just saying you'd need to load boot-9.scm separately? <rlb>Hmm, and I also just wondered (wrt some init_foo() dep ordering sensitivity I noticed) whether we could make the deps more concreate by just having each init_foo() function be required to call any other init_bar() functions it needs, and make the init_THING() functions idempotent via a C static "loaded" boolean int (properly atomic one way or another). <rlb>e.g. cheap "module-ish" behavior instead of just having the only inter-init-dep info be implied by the current ordering of the init calls in that one list. <rlb>(half baked idea at best) <mwette>To solve the single binary guile app, I think the program would have to load boot-9 from memory. At least that's the solution I was working. (It seems the old practice of core dump followed by undump is not feasible. Right?) <rlb>So you'd want either some way to tell the init function how to load boot-9, or just factor that out into a separate call (think maybe I get it). <mwette>In the old days, when dinasaurs still walked the earth, you could write a perl script, then make it core dump, then run a program called 'undump' to make a monolithic binary to run the program from the point you core-dumped. <dsmith>Yeah, guile used to have unexec(). <rlb>Oh, sure -- I know *of* it (cf. emacs), just never been involved with it in any detail. <Arsen> 18:12:40 <dsmith> Arsen, No need to be so concerned. Not much effort is going into it I think. <Arsen>no, there's reason to be concerned <Arsen>eliz has repeatedly demonstrated that he's willing to waste other peoples' time by making them either adjust patches or test on obsolete microsoft systems <rlb>rscheme iirc has a similar trick -- can run "persistently" with all pointers being faulted back in on restart via page fault trap, etc. <dsmith>Back then, guile was just one library. No deps on gc and gmp. Was unexec only good the staticly liunked apps? <Arsen>hell, a bystander might think it's sabotage <dsmith>Arsen, I was speaking about the current state of elisp support in Guile. <dsmith>Not much has happened there in a while. <Deltafire>is it possible to build or run guile without libgc? <rlb>Deltafire: not at the moment --- longer term, Andy may replace the gc. <identity>you can build guile with libgc if you run «sleep 12096000; git pull» first <Deltafire>i was considering a version with no gc at all, for short-running programs that could probably manage without it <identity>without, i mean. you can build guile with libgc if you «sleep 1» first, though <mwette>Not sure what you want that for. You can run (gc-disable). And IIRC guile starts w/o ~6 MiB of memory for scheme. <dsmith>mwette, Hmm. That's not documented in the manual (that I can see), though there is a docstring for it. <Deltafire>i was thinking of ways to stop the guix segfault on boot, caused by libgc probing the heap/stack boundary. (gc-disable) wouldn't work because the segfault occurs before any guile code is executed <mwette>You could make a dummy gc, maybe, and link against that. <mwette>maybe not "dummy" but minimal fixed size memory. <mwette>But you get possible security risks that go with it, I guess. <rlb>also, sometimes tricks you can play with LD_PRELOAD -- no idea if that'd be feasible here. <identity>i would guess the early boot guile is statically linked