IRC channel logs
2025-12-23.log
back to list of logs
<mwette>I'm trying to generate a macro where I want to choose between a number of implementation modules for lower-level code. I don't want to reference modules for code I don't use. The following not working. Any ideas? https://paste.centos.org/view/0ceaee7fmb <mwette>The idea is to make something like cond-expand. <mwette>I see now cond-expand is implemented in scheme, in boot-9.scm. <mwette>but seems overkill for what I want <old>mwette: how do you select the implementation? <old>I mean, what is the criteria? <old>(I can't see the pastebin somedhow) <daviid>sneek: later tell tohoyn here is an updated version of your server test code - https://bpa.st/Q3QQ - lines 65, 77 and 86. And here is my last post to the introspection matrix room, but so far I have received very little (and totally useless) help - https://bpa.st/EZFA - I have very little hope anyone there help, if anyone here, d-bus knowledgeable, has any hint/iea, please ping me ... I'll switch back to other tasks, I have no more <daviid>mwette: your paste link is 'wrong', we can't browse it ... <mwette>old: front end compiler generates .scm file which includes a (define baseline xxx) form based on front end compiler flags. So 'guild compile-ffi -b cdata file.ffi' generates one .scm file but 'guild compile-ffi -b bytestructures file.ffi' generates a different .scm file. Aux code from file.ffi is included in both. <old>I'm not sure to fully understand, but you want to select an implementation of some module at compile time based on some properties is that right? <old>The way I do this in BLUE for example, is through a macro like you seems to be doing: <old>and for full-module selection well I guess you could put a `include' forms instead <mwette>old: yep. all like cond but evaluated at compile time I'll take a look. Thanks. <old>Okay well if you look at `cond-host' you could probably get away it something similar. Just iterate over the set of clause and the first one that match, return its expression <old>that ought to work well if you use the `eval-when' with expand and compile <sneek>Welcome back tohoyn, you have 1 message! <sneek>tohoyn, daviid says: here is an updated version of your server test code - https://bpa.st/Q3QQ - lines 65, 77 and 86. And here is my last post to the introspection matrix room, but so far I have received very little (and totally useless) help - https://bpa.st/EZFA - I have very little hope anyone there help, if anyone here, d-bus knowledgeable, has any hint/iea, please ping me ... I'll switch back to other tasks, I have no more <tohoyn>sneek: later tell daviid I may have found the cause of the bug <tohoyn>sneek: later tell daviid whereas in the Guile client the corresponding addresses are increasing <lechner>mmzero / dthompson is here sometimes <mmzero>lechner: Thanks! Do have a few questions for him regarding it and Chickadee's platform support <lechner>mmzero / you can try the sneek bot or hang out <mmzero>lechner That too! Though I think I'll try to send him a mail and see if he answers over there <mmzero>I will ask you this though. Do you happen to know if Guile runs on other platforms besides GNU/Linux? I am aware of Hoot and the Spritely Institute. But I am also talking about stuff like Android support or Windows and so on <identity>mmzero: probably not android, but windows and most unix systems should work <identity>no idea what Chickadee runs on, though. i assume anything that Guile and SDL2 run on? <mmzero>identity: Depends on SDL2, Guile-OpenGL, Vorbis, jpeg-turbo, so on <mmzero>identity: Just a guess. But since it depends on Guile and SDL2, Chickadee could run on both Unix and Windows? <lechner>mmzero / Yeah, just like identity wrote. Some folks use Guile on Windows; there are even some professional apps like LilyPond and GnuCash. About Chicadee I only know that drhompson once told me it was a lot faster than he had expected. <mmzero>lechner: That's great to know! I was planning to give it a try and all since is not everyday I see a game framework written on Guile, so that it performs well it's a boon! <mmzero>Reason I was asking about platform support is because I do run on an Unix system but I also wanted to see if it ran on Windows so I could either cross-compile or alternatively use Wine to generate a Guile Windows binary <mwette>sneek: later tell daviid, I don't know GDBus but worked with dbus years ago; looking at your example you are registering methods with x and s types, but decoding as variant; does GDBus put a variant layer on top? dbus does have a variant type `v'; maybe try that <lechner>mwette / thanks for guile-freezer. i'm doing some cool stuff with it and will share soon <lechner>Hi, anyone have an implementation of "rm -rf" in Guile, for example using file-system-walk? <lechner>ray1729 / thanks! does that follow symlinks? <ray1729>Hmm, it's using file-system-fold, I'll have to read the docs. <ray1729>Docs confirm: "The optional stat argument defaults to lstat, which means that symbolic links are not followed" <lilyp>yup, you can make it regular stat tho <lechner>ray1729 / thanks so much! you offer end-to-end customer service! <ray1729>lilyp: this is such a useful library, are there still plans to include it in guile? <lilyp>I haven't worked with upstream in a while and it has been three years since the last commit <lilyp>fwiw i have moved the repo to codeberg, like all repos i'd like to keep <ray1729>No recent commits might just mean it's finished :-) <ray1729>lilyp: thanks for the Codeberg pointer. I am doing the same thing and moving any active projects whenever I touch them. Most of my GitHub is incomplete experiments that never made it to a release. <lechner>lilyp / Hi, Guix still has the Gitlab repo. You haven't written to the Guix list lately. Will you fox the package definition? <lechner>lilyp / Also, do you like using Automake for that sort of thing? <lilyp>Automake is sadly the only build system with real Guile support <lilyp>I'd like to use Meson, but last time I checked it didn't support my usecase. <lilyp>As for the Guix package, I'm more busy on other parts of Guix (mostly gnome-team lately) <lechner>no docs yet, but it's conceptually like GNU Make and very simple <rlb>...also got me to wonder how that'll go wrt the utf8 changes --- there'll be some rebase conflicts of course, but could be some indirect effects I'll have to be careful not to miss (i.e. if I introduced other longs for hashes in the series; don't recall offhand). <ieure>Does Guile have something like if-let or when-let? <mwette>lechner: If you have time and are willing, could you try nyacc branch dev-3.02? It has some big changes, intended to support alternate backends to cdata. <lechner>mwette / sure! i'm about to go for a run. i'll report back here in a few hours (or on GitBlub if there are issues) <lechner>mwette / also, thanks for the powerpc changes. i am hoping to test those also <rlb>ArneBab: if y'all do decide to merge that branch, might consider rebasing it first (my tests were all with it rebased on current main) so that the history's a bit simpler --- suppose we could also consider keeping a merge commit (even if it could fast-forward) to keep them delineated as a group. <lechner>mwette / Unbound variable: sizeof-basetype <lechner>mwette make[1]: *** [Makefile:100: scripts/compile-ffi.go] Error 1 <lechner>mwette / my last commit was a bit behind b811921e5ee97a23871df38e0060f323bb893005 <mwette>OK: I will move the use-modules ; new commit 8db527886f97fd444fcdcafe911b05c6f9a2cd08 <mwette>prev should have been 4b572a31ace5541dd466e28d7937615bdfa801fa <mwette>sneek: later tell lechner, There is no longer a depencency on guile-bytestructures. NYACC v3.02 will allow bytestructure (or bstructs), but via different package guile-fhbe. <ArneBab>rlb: thank you for the checks! The rebase should happen on codeberg automatically when I use the "just hit the rebase+merge button" workflow. <ArneBab>rlb: I’m really glad we’re moving forward with this! <rlb>I imagine you saw, but at least that remaining "long" I happened to notice may need fixing. <sneek>lechner, you have 1 message! <sneek>lechner, mwette says: There is no longer a depencency on guile-bytestructures. NYACC v3.02 will allow bytestructure (or bstructs), but via different package guile-fhbe. <mwette>lechner: thanks; I had deprecated that and others because parse-c99 does not generate them. Do you provide unsigned-int in other code? <lechner>mwette / i know where it comes from. another, older library is getting pulled in. hang on <lechner>mwette / almost there. i had to figure something out on my side. rebuilding <lechner>mwette / i think it's working fine. used it on linux-kernel on x86_64, Linux-PAM and maybe some other things <mwette>OK. Sorry about that. I'm purging others but will keep "unsigned int" (unsigned-int) for the time being. Any other machine architectures missing? <lechner>mwette / please don't do it for me! i don't need unsigned-int anymore. it propagated from an old version of what you call an FFI module, because Guix does not allow me to use my own channel in system software, meaning i have to copy packages around---and didn't. now unsigned-int is gone <lechner>mwette / i only checked x86_64 for now <lechner>it's all working. nyacc simply crept into much of my work because it is so amazingly great and versatile! <ArneBab>rlb: I merged now, because while some remains to fix, this can happen in a next PR to reduce the disconnect between PRs (and as such the amount of merge/rebase conflicts). <ArneBab>rlb: And I think that with no ABI breakage visible, we don’t need to delay further.