IRC channel logs
2023-08-24.log
back to list of logs
<haugh>Sometimes when I add a new module and it contains an error, my REPL gets into a state where I can't reload the module. Error: unknown file name for module #<directory (my-module) 7fcf6046c320> <haugh>Can I reset this state without restarting the process? I tried some of the undocumented module-* procedures but nothing worked <daviid>haugh: how about (reload-module (resolve-module '(you module here))) <haugh>that's how i get that error above <daviid>haugh: hum, are you sure the module name and file name match? <daviid>haugh: no sure i may help better then the above, just wanted to suggest .. but when you fix the bug, start a new session, does ,use (that module that was failing) works? <daviid>that should happen with any module then (?) - maybe a regression, not sure, it's been a long time i don't do this anymore, i use geiser to recompile one or a few procs, then quit and restart a new session ... <daviid>haugh: to convince yourself, try with one of your module you know is 'correct' ... i am gaone leave you with this now, good luck <haugh>Welp I can't seem to replicate it. Sorry for the distraction. <haugh>I identified the problem. When there's a typo in the define-module module-name, none of the interfaces that look up files according to symbolic module names know where to look. I assume. https://0x0.st/H9Tc.txt <haugh>So I suppose my question becomes "how do I forcefully load a file into a REPL" <haugh>deleting the .go file lets me ,use the correct module name without error, but I still get "unknown file name for module ..." on ,re <haugh>Even after the following it's telling me "unknown file name": (module-obarray-set! (module-obarray (resolve-module '(foo))) 'filename "foo.scm") <haugh>Oh, I misunderstood obarrays <haugh>Okay! I only needed (set-module-filename! (resolve-module '(foo)) "foo.scm") <haugh>Just learned more about modules than I ever wanted to know <haugh>This is actually an extremely cool interface <daviid>hum a bit ot but ... with this $(wildcard adw1-demo/icons/*) in my examples/adw-1//Makefile.am, make dist produces a tarball that has some but not all the icons/* files - any idea? <daviid>just as an example, it has adw1-demo/icons/hicolor/scalable/actions/widget-list-symbolic.svg, but not adw1-demo/icons/hicolor/scalable/actions/gesture-touchpad-swipe-back-symbolic-rtl.svg ... i just can't figure out why and how to solve this problem <daviid>hopefully not listing all 'by hand' <daviid>this is my last g-golf-0.8.0-a.5 release blocker - help/suggestion(s) welcome ... <wingo>aaaaaaaaaaaaaah i just got bit by the craziest thing <wingo>constructor args in different order than field definitions <wingo>well. i started adding (match graph (($ <reference-graph> defs refs) ...)) to code... <wingo>which is correct afaiu but then destructuring via match doesn't correspond to constructors... <wingo>took me a while to figure out what was going on :) <wingo>i want to fix the pretty-print bug today <civodul>since i use the "guile" channel, i always have the latest and greatest, including bugs :-) <wingo>oh i haven't done that :) i use a local build <wingo>in spritely we use guix to make a docker image that runs our ci, so i do use guix to update that package there <wingo>does the guile channel automatically pick up the latest guile ? <wingo>the spritely/hoot/wasm stuff is coming along btw, we are probably 2-3 weeks away from full r7rs <wingo>plus guile extensions like delimited continuations, dynamic states, etc <civodul>yeah the 'guile' channel gives you Guile built from current "main" <civodul>(the other approach is to do "guix install guile-next --with-branch=main" or similar, but you don't get provenance tracking thetn) <wingo>i think guix is probably not so good for me working on guile. i need faster iteration between change and running it <wingo>the lack of precompiled .go files and the serial build make that impossible <wingo>civodul: close :) should be (- n 8) instead of (- 8 n) <civodul>for development i use plain "guix shell -CP" in the Guile checkout <rrobin>hi, does anyone know of a nice example of using guile's texinfo to automatically generate documentation for a module? I have something working here, but keep running into silly issues like a missing top node in the generated file, or missing function names. <wingo>rrobin: have you tried (texinfo reflection) <rrobin>i am using it already, but running into a handful of pesky issues <wingo>i can imagine there are some issues, the code is verrrrrrrrry old <rrobin>it works but sometimes the output has some issues, for example module-stexi-documentation generates a good doc, but lacks a top node <wingo>could be that its output is meant to compose into something else... i don't recall :/ <rrobin>anyway just wondering, i'll figure something out, thanks <wingo>yeah sorry, nothing off the top of my head <rrobin>ah thanks i'll have a look janneke <rrobin>also having a look at make-texinfo.scm from guile-lib for inspiration <haugh>rrobin, I'm also very interested in procedurally generating documentation. I think I'm well behind you but if you learn anything game-changing please mention it in here. <haugh>jenneke, thanks for the lead <ulfvonbelow>Is there something like catch, but that accepts a third procedure to be called if the first one completes normally? <mwnaylor>A while ago I was grumbling about missing info nodes in Guile documentation. I found out today that they all actually had been installed. Turns out there is some weirdness in how the emacs info command accesses the indexes. Off to #emacs to discuss there.