<spk121>I did, once, sorta. Haha. I sent a chapter to O'Reilly and they said no because Lisp-related books never sell. <spk121>OK, I've figured out how to call the Microsoft CL Compiler from WSL and LLVM Clang-CL on Windows 10, so my foolish quest to make a native (non-cygwin, non-mingw) Windows Guile can begin. But inauspiciously, it starts with trying to fix libtool and libltdl. <spk121>libtool, which has only accepted 10 patches in the last four years <spk121>I don't think so. I would never use it except that it is hooked into autoconf/automake <RhodiumToad>it's possible to use autoconf without using libtool... <spk121>I've assumed it would be. If there's a doc out there somewhere about it, I'd love to see it <RhodiumToad>my point of reference here is that postgresql, for example, has an architecture of dynamically loaded modules, but doesn't (and I think never has) used libtool <chrislck>Dear esteemed guilers... many warnings "warning: possibly unbound variable" have returned with guile-3.0.4 (and were not present in 3.0.2) -- any idea how to disable globally please? <spk121>chrislck: you need to avoid passing --warn=unbound-variable to guild compile <chrislck>spk121: it doesn't have --warn=unbound-variable anywhere <spk121>oh, apologies for not noticing that <leoprikler>GUILE_AUTO_COMPILE=0 guix environment --pure --ad-hoc guile -E GUILE_AUTO_COMPILE -- guild compile -Whelp | grep unbound <leoprikler> `unbound-variable' report possibly unbound variables <leoprikler>GUILE_AUTO_COMPILE=0 guix environment --pure --ad-hoc guile@2.0 -E GUILE_AUTO_COMPILE -- guild compile -Whelp | grep unbound <leoprikler> `unbound-variable' report possibly unbound variables <chrislck>leoprinkler: yes but something has changed guile-3.0.2 and 3.0.4 <chrislck>sneek: later tell civodul how to remove unbound-variable new between 3.0.2 and 3.0.4 <distopico>Hi, I'm starting ethics guile, I have a question, guile have something like hot reload for development, to recompile and reload ? <ArneBab>distopico: you develop in the REPL, then you can simply replace top-level functions during runtime <contrapunctus>So the Guile manual says that Guile supports the SRFI-64 unit test API, but I'm not sure I understand how one runs these tests once they're written. The SRFI mentions a test runner, and all I found was ggspec (~7 years old) and a SRFI-64 snowball (not sure if it actually is a test runner?) <euandreh>How to list files in a directory? I see srfi-170 has directory-files, but I don't see implementations of it yet <leoprikler>chrislck: perhaps have a look at %auto-compile-options? It's the same for both versions tho. <leoprikler>euandreh: you can do it low-level using readdir or high-level using (ice-9 ftw), Guix' find-files and some others <ane>contrapunctus: if you use autoconf, there's a test-driver.scm file that will then output automake compatible .trs files for `make check` <catonano>contrapunctus: if you set up your project with guile-hall, you have the unit testing set up for you <contrapunctus>catonano: I'd never imagined such a thing could exist for a Scheme 😀 <catonano>contrapunctus: it's a pity that nobody ever brings that up <catonano>euandreh: there's a paragraph in the manual named "File Tree Walk" <ane>I think guile hall is now guild hall <distopico>daviid: yes, I have geiser already setup, I'm Emacs, user, I tried guile-studio just curious but it not worked to me from guix ***rekado_ is now known as rekado
<rekado>distopico: oh, it’s broken? I’ll take a look later. <daviid>distopico: so, geiser offers all you need to reevaluate s-expr 'on the fly', from your source code emacs buffers of course ... don't you do that? ask here as i said, we almost all use it ... i am not a very good geiser user myself, but we have experts here .. <distopico>when it start require company, I have it installed in my .emacs.d, I tried installing from guix <distopico>daviid: I just started a few day ago, so I will try that, I think that is what I'm looking for <euandreh>leoprikler, catonano: I was expecting to find something more ready. <euandreh>ty for the manual reference, I'm reading it more closely <euandreh>hmm, but that would return a 0, and I would have to get the string and parse it <euandreh>I mean more ready as in: like scandir, but without the ".." "." parts <catonano>I suppose they were hoping for a procedure that used the machinery illustrated in File Tree Walk to simply list a directory <catonano>what I can say is that copying the example and adjusting it to adhere to your needs is not that hard but I undertsand you feeling <euandreh>how about this: (scandir path (lambda (p) (not (or (equal? "." p) (equal? ".." p))))) <rlb>I was looking at the module version docs and wondered if there were any provisions for multiple versions of a module. i.e. can you have (foo #:version (1)) and (foo #:version (2)) available at the same time so that other code can chose the one they want? <rlb>Of course I can go check the code, but I was also wondering about the broader standard, i.e. are there any requirements or existing conventions there. <rlb>weinholt: hah, thanks. Though I'm really wondering about even allowing their existence, i.e. can you have two versions *available* even if the program only picks one, as with libguile-2.2 and libguile-3.0. i.e. where would the (foo #:version (1)) and (foo #:version (2)) module files go in the filesystem, etc. <weinholt>rlb, plt-r6rs in Racket has a convention for mapping the combination of library name and version to a filename, but everyone else just ignores the version in the mapping, so two versions of a library would get the same file name, meaning only one version can be installed in a directory <weinholt>(speaking from my R6RS experience here, maybe there are others out there that do as Racket) <rlb>OK, so that leaves you with the boil-the-ocean upgrade problem for library upgrades. Or just don't break backward compat in your apis... <rlb>In any case, thanks -- definitely answers my question. <weinholt>i guess a workaround is to put the major version in the library name. i haven't seen anyone do that yet. <rlb>yep, I think that's likely often a good inclination <rlb>Just perhaps the potential to be a little nicer asthetically, to have the platform recognize that and provide a built-in mechanism. <rlb>civodul: odd behavior right now wrt gnutls28 and building against guile 3.0. If you build in a dev/shm tmpfs in exactly the right way (found via debian buildds), the reauth.scm test will hang forever. Re-running the test without "</dev/null" (which the debian tooling had specified) lets it finish. <rlb>I'll investigate, but I thought I'd mention it in case it rang any bells. *rlb is trying to herd the cats to get guile-2.2 removed from debian bullseye if we can... <RhodiumToad>actively removing guile 2.2 seems a bit hostile to things that depend on guile? <rlb>The alternative is to support if for 2+ years starting about a year from now. <rlb>i.e. this is just for the freeze, the actual debian release will likely be a bit less than a year from now (guessing). <rlb>And then be supported for 2+ years. <rlb>Debian may end up keeping it, but I'm trying to nudge away from where we ended up with guile-1.8, which was still in debian (jessie) and so technically supported via LTS until a few months ago. Even though it was last (I think) updated "upstream" 11 years ago. <RhodiumToad>I need to find a way to get 2.2 and 3.0 to coexist in the freebsd ports tree <RhodiumToad>main obstacle at the moment is that both ports want to own /usr/local/share/aclocal/guile.m4 <RhodiumToad>(there is no 3.0 port yet, I just have one I made locally) <rlb>Hmm, we just versioned that in Debian I think. <rlb>i.e. guile-3.0.m4, etc. *rlb checks to see if he also used update-alternatives <RhodiumToad>which presumably requires patching the callers to look for some specific version? <rlb>It's handled by "update-alternatives", so there's always a guile.m4, and it points to either the version with the highest "priority", or the one selected by the "admin" via update-alternatives. <rlb>and unsurprisingly guile-3.0-dev's priority is higher than guile-2.2's. <rlb>fwiw, in some cases where update-alternatives isn't sufficient, some debian packages provide their own helpers to switch things like that. <rlb>Though if there's any sensible approach, I'd prefer to see us handle competing m4 files upstream, i.e. as we do for all the other prefixed things. Though that might just mean to advise everyone to stop using unversioned names. <rlb>Of course that has it's own tedium, i.e. updating all the configure.ac's to refer to the new major release when it comes out. I suppose if guile were following strict semantic versioning, and we never made any mistakes, you'd just need guile-2.m4 and guile-3.m4 etc. :) <ane>I wonder if LilyPond has recently tried to get out of Guile 1.8 <rlb>civodul: when it hangs, I can see it crashing in the reauth.scm.log: <rlb> throw to `gnutls-error' with args (#<gnutls-error-enum The certificate and the given key do not match.> set-certificate-credentials-x509-keys!) <rlb>FAIL tests/reauth.scm (exit status: 1) <rlb>It also doesn't always hang after I enable debug logging -- sometimes it actually fails and umps the log to the terminal, so I imagine it's a race of some sort. <daviid>rlb: why in such a 'hurry', since both are in debian already, it doen't cost much to keep them, or does it? <rlb>Well, as mentioned, we may end up keeping 2.2, but doing so has potentially significant costs. As one example, unless we know we'll continue to produce bugfixes here (upstream), particularly for security bugs, for 2.2 for the next 3+ years, then keeping 2.2 in debian is shifting that potential work onto someone else. <rlb>i.e. me or the debian security team, or the lts team, or... <rlb>So it's (as often) a cost/benefit tradeoff. <rlb>And keeping any given older Y around longer decreases the resources available to package and maintain the next Y. Similar considerations of course apply upstream as well. <daviid>rlb: right, I understand - I can't answer for our mintainers of course, but my experience is, so far at least, they have been very good at offering support for older version - then of course guile has zero security bug :) <weinholt>rlb, in #969703, are you asking me to remove guile-2.2 support or to build for both 2.2 and 3.0? (i found a workaround for the miscompilation of md5.scm with 3.0) <weinholt>rlb, g-wrap is a reverse dependency, so i'm leaning towards building for both versions <daviid>weinholt: g-wrap? I thought only guile-gnome used it <daviid>guile-gnome will be removed from debian, i think g-wrap should be removed as well <weinholt>guile-gnome2-dev has reverse depends from theme-d-gnome, though <dustyweb>magit is listing the latest tag as v2.2.3 <dustyweb>I'm guessing tags just haven't been pushed up <daviid>weinholt: all I can tell you is they will be no maintaince upstream on guile-gnome, nor on g-wrap - thene-d-gnome should be removed as well, as anything that depends on guile-gnome and/or g-wrap <daviid>dustyweb: i have a proper v3.0.4 master tag in magit here, is it not a mater of 'git fetch --all' on your side maybe? <dustyweb>I forgot that the F operations only pull the necessary branch :) <daviid>yeah, i'm not very good at all this either, but what you wrote 'did ring a bell' here, so i looked in my notes ... :) <rlb>weinholt: so, not sure? My current concern is just to try to make it so that we have the option of removing guile-2.2 from bullseye, which means we have to get everything migrated to at least work with 3.0 before the freeze (in a month or two). <weinholt>rlb, alright, i'll go with support for both versions initially, and we can drop 2.2 when that seems ok, which might be tomorrow or in 11 years <rlb>Sounds good -- and thanks much. <daviid>weinholt: np! what debian packages are you working on? <daviid>weinholt: excellent goops tutorial by the way, I would like to suggest that the title 'Further remarks' become a clear 'Dynamically adding methods' or something like that ... <daviid>hum, it's been a little while I didn't compile guile-lib, let me try now, using master I mean <daviid>I know it works with 'early' 3.0, but i didn't try the very latest