IRC channel logs
2026-08-15.log
back to list of logs
<old>Not really happy with the usage of assert from (rnrs base) since the compiler currently only see throw error scm-error raise-exception as primitives <old>but I guess I could make it so that raise is also seen <old>ah jesus (rnrs base) define a bunch of proxies <old>that's such an optimization barrier. wow <old>so every assert is translate into a dynamic module lookup <rlb>I did some rearrangement wrt some string a ports-related bits in rnrs in utf8, but yeah, some of it was a bit confusing/surprising. <rlb>(much indirection, which I suppose makes sense given that we were probably trying to provide newer rnrs in terms of what we already had) <ArneBab>(I should really create an SRFI for define-typed for a simpler alternative) <ArneBab>Something that could be neat would be topological sort of dependencies by extracting import and use-modules via a code walker. <ArneBab>(though likely not for guile itself, because guile is needed for guile in in make, so guile can’t use the guile extensions to make, otherwise bootstrapping is dead) <dthompson>old: re: (rnrs base): in addition to being optimization barriers, those proxies are a blocking issue for r6rs support in hoot. I told wingo about it and he is in support of fixing this. <old>dthompson: so we all agree on changing this great <old>good reason for fixing that. Tho I need to check it deeply to see if that's a breaking change <ArneBab>mwette: could that be used in a makefile to order dependencies? <ArneBab>(I personally would benefit a lot from autogenerated dependencies which ensure that when I update a file with syntax-rules, all files importing them will get rebuilt, too) <mwette>Or maybe not. You may want the dependency graph itself for that. <mwette>Not just the topo sorted list of modules. <mwette>The procedure `probe-file' may give you what you want. <ArneBab>mwette: do I understand your probe-file correctly that it won’t find (import …)? <mwette>It does not. Also, it only checks top-level forms, IIRC. <ArneBab>Would you be open for a patch to also extract import? <ArneBab>may take a while but I’ll try (that’s a path forward to solving a problem ☺) <old>not makefile, the BLUE system already support module dependencies tracking and 2 stages build for guile <loon>what is the recommended way of doing ~user => /home/user expansion in guile? I'm not finding any mention of glob(3) or wordexp(3) in the docs <loon>I could bind them easily enough, but I'd love a built-in procedure if possible <rlb>loon: hmm, bit surprised we don't have glob() already. No promises, but I might poke at one or more of those. <loon>rlb: I'm surprised too! I may try my hand at it as well, idle weekend hacking is a good time for yak shaving :) <rlb>loon: I think the only "difficulty" might be figuring out where they should go. I don't think we should add them to (guile) --- we're trying to avoid adding any new bindings there. The most likely place would be (ice-9 posix), but iirc there's no likely way to have bindings there that don't end up in (guile) atm. <rlb>We *can* define it there (posix.c), and then steal the bindings somewhere else, though, so you could at least start there, or in filesys.c I suppose. <daviid>there is a glob implementation in guile-gnome (which I snarfed in my perso guile tool box), but both url gives a 502 ( i woner if savannah archives projects that are not being active for a while, maybe) - let me paste, i have a local copy <daviid>i am not sure it expands ~USER expression though, i mainly used it to expand foo* expressions <daviid>loon: maybe ask in guix, they also have such utils 'somewhere' ... ask in #guix <rlb>I don't know those functions well enough to know offhand, but I suppose another question might be whether we'd want the platform-specific/posix versions, instead of, or in addition to, some other scheme functions. <loon>I was planning on binding the C functions directly, like the rest of guile's POSIX support <rlb>Offhand, I'd imagine we might want the platform versions, whatever else we do. <loon>I checked in gnulib as specified in HACKING, but it doesn't have a replacement for wordexp(3) and notes that a few platforms (e.g. openbsd, cygwin) don't have those functions <loon>I just checked an openbsd system and indeed it doesn't have it <rlb>That RATIONALE for wordexp is ... "interesting". <rlb>e.g. "While wordexp() could be implemented entirely as a library routine, it is expected that most implementations run a shell in a subprocess to do the expansion."... <loon>where are you seeing a RATIONALE? <rlb>ACTION did not expect that :) <loon>Me neither, I only learned of wordexp/wordfree today while looking into this <rlb>And yeah, think it's good to look at gnulib (as you are) and the specs to make sure these aren't posix functions with "trouble". <loon>I'm beginning to see that there's some "interesting" particulars here: the feature of glob that I want, GLOB_TILDE, is an extension which seems to be de facto standard <rlb>btw, just as a general rule, I'd suggest now when we have a choice, to prefer str+len calls/operations over null terminated string operations because if we do adopt utf8, we'll be able to work with no allocation or copying at all whenever we're in a utf-8 compatible locale. With null termination, we'll sometimes have to copy, and much more rarely now, heap allocate. (Current guile has to effectively always heap allocate.) <rlb>(adopt the proposed utf8 changes) <loon>So for my potential glob binding, this would involve exposing a procedure that takes a string and a length, in C style? <rlb>Well, I mostly just meant that if you have two options wrt syscalls. <rlb>i.e. if you could call some_syscall(s) vs some_syscall(s, n), prefer the latter so that when I rework it for utf8 we can avoid the copy, though if I know about the call, and it's that easy, I'l just do it myself :) <rlb>Just a general suggestion, really. <rlb>(In some cases, we still won't need the copy because of some more recent "cleverness" in utf8, i.e. the guile string might be null terminated anyway.) <loon>got it, thank you. the functions I'm looking at are in libc, not syscalls, and I don't think they have a string + length variant <rlb>yeah, unfortunately not common, I don't think. <loon>yeah. lots of legacy there <rlb>...also might prefer scm_from_*stringn when you already know the length so we don't have to find it again (as I just notice that I should actually make that true when we can ;) ) <TheTaoOfSu>Anyone able to recommend a GUI framework with a Guile library that can handle mobile Linux UI? <TheTaoOfSu>I've heard GTK and Qt/KDE both have support, but I don't see a Qt/KDE bindings library <TheTaoOfSu>Possibly because their stuff uses a bunch of C++ <TheTaoOfSu>Ideally, something that can work well for both desktop and mobile both. I think the webdev term for that is a responsive UI? <mwette>I believe "swig" can generate guile wrappers for C++ declarations. (I'm not a swig user.) <daviid>TheTaoOfSu: libadwaita is the only lib, afaik, that will let you dev an app that adapts itself to the device, and it actually provies an adaptative preview functionality 'out of the box', see the awaita-1-demo - g-golf has a port of the demo as well - https://www.gnu.org/software/g-golf/ <loon>kde/plasma have kirigami and qt quick for apps that adapt to display sizes, but I don't know if they have bindings for guile <TheTaoOfSu>daviid: that sounds handy. I don't see a library straight for it, but sounds like it should be covered by G-Golf? <TheTaoOfSu>loon: I can't find Kirigami bindings for any implementation, but it's possible I've missed it <TheTaoOfSu>lol the G-Golf manual's section on mobile devices is just... Empty. Like there used to be something that got cleared out, and they forgot to put it back or something <daviid>TheTaoOfSu: if you use libadwaita, and ofc use the api that 'triggers' the adaptive mode when that aplies, your app will just work on any evice, including mobile, that is the all point ... <daviid>TheTaoOfSu: just install g-golf, and try the adwaita-1-demo - i am using g-golf myself, fwiw <daviid>TheTaoOfSu: "... I don't see a library straight for it, but sounds like it should be covered by G-Golf?" g-golf is a gobject-instropection binding for guile, the you may use it to import any GNOME namespace that is introspectable, and that includes a bunch of libs, including libadwaita (ofc) <ArneBab>old: I don’t really want a language-specific build system. I’ve seen that become ugly with Java and Python (dealing with ant, maven, gradle, pip, setuptools, distutils, waf, scons, and now likely uv), so I’d rather like to find the support that makes autoconf+automake work better. <daviid>TheTaoOfSu: ping me if you need any help ... <ArneBab>(also hacking the numpy build system to get scientific Python to work on an intel cluster … not fun at all. Those experiences are why I nowadays prefer autoconf+automake over all others: that has more warts, but on the long run it works better, especially when slightly outside the expected usage) <ArneBab>old: that said: if it were possible to call BLUE dependency calculation from $(guile …) in a Makefile, that would be pretty neat.