IRC channel logs


back to list of logs

<mwette>In the geiser REPL is there a command to close the connection to the server, to cause it to exit? I was using (exit) or (quit) but those result in response on the server side of "Wrong type to apply: ()", and it does not die, but the geiser repl closes. (And I can reconnect with C-c C-z.)
<jao>C-c C-q
<mwette>end goal is to run the repl-server in a fiber task.
<jao>(or ,exit)
<mwette>same result: geiser closes i/f but guile process is still running
<jao>it surely is not for me, so i don't really now
<jao>geiser just emits guile's ,exit repl command, nothing much more
<jao>you can try in an independent repl and see if that works
<jao>you're connecting to it via geiser-connect?
<jao>okay, then no, there is no command in geiser to kill the process
<jao>unless guile itself provides one, but i don't know about that
<mwette>thanks for the feedback, jao
<jao>no problem, it wasn't very useful :)
<mwette>Well, I found another guile-side one that doen't work on the server but does close geiser: (stop-server-and-clients!)
<ennoausberlin>Hello. Due to guix I want to dig a little deeper into guile. Is there a good article or video about debugging in guile?
<chrislck>what's this talk about Nickserv? isn't a/s/l not enough? <grumble>
<dsmith-work>Morning Greetings, Guilers
<old>ennoausberlin: To my knowledge, there's no such thing
<old>That would but a good thing to have though
<tohoyn>A script fails to compile: see snippet
<tohoyn>steps to reproduce: guild compile test1.scm
<tohoyn>The error message I get is in the file test1-error.txt
<tohoyn>Could you help me with this?
<tohoyn>It is
<tohoyn>^^^^^ extra characters
<ennoausberlin>old: I recently skimmed over some flux harmonics (system crafters) episodes to see how an experienced schemer handles errors, but it was more using display() than using more sophisticated means. I am still a guile newbie, but that just does not look right
<old>tbh I debug a lot with `pk` and the REPL
<tohoyn>It is as if the match expression got evaluated compile time
<old>ennoausberling: I'm very used to having a debugger like GDB can be able to single step every instruction. I dream of that day with Guile, but we're not there totally yet
<old>you can still use the debugger to get a backtrace. Things get more hard with multi-threading though
<ennoausberlin>old: I read the first time about pk.
<dsmith-work>One day I somehow was able to single-step through some elisp code. It was amazing! (I think I had to instrument the function?)
<dsmith-work>Would love to see that in Guile
<old>It's not documented I think. But it's really a good thing to have in your toolbox. Just `pk` any expression to see the result and it get return
<old>dsmith-work: Are you sure it was real :O
<old>ennoausberlin: `(pk (cons 1 2))`
<old>Try it
<old>Only problem with pk, it's is not thread safe
<dsmith-work>Yes! Stepping by expression. I did say is was elisp and not Scheme.
<old>So for debugging multi-threading .. I have this ad-hoc thing: `(define-syntax-rule (PK exp ...) (with-mutex some-global-mutex (pk exp ...)))`
<old>dsmith-work: I have never program in elisp expect configuring emacs. Is the experience smoother than Guile?
<dsmith-work>Different as teflon and sandpaper
<dsmith-work>But I don't remember what I did.
<old>Which one is the sandpaper :p
<dsmith-work>Now you got me curious and I have to find it again..
<ennoausberlin>old: I heard about putting racket in scheme lang mode and paste your guile code there. :)
<old>Hmm. I think that if you're ever in a very deep pit of bugs then that could be a solution
<old>But as a workflow .. that's beyond insanity
<old>might as well just use racket
<tohoyn>tohoyn: sorry, the address was wrong. The correct address is
<dsmith-work>old: Probably was just M-x debug-on-entry RET func-to-debug RET and then when calling func-to-debug lands you in the debugger, just keep pressing d
<tohoyn>it seems that the gnome pastebin links do not work. A gentoo pastebin link for the script is at and the error message at
<old>dsmith-work: Cool I just tested it and it seems very natural to use
<dsmith-work>cancel-debug-on-entry when done
<old>yes thanks
<old>I have the bad idea of debugging `message` lol
<dsmith-work>That'l larn ya
<spk121>I did once make a whole Guile debugging GUI. The GUI part came out okay, but, I got so frustrated trying to figure out how to extract the information I needed about source locations and stack, I gave up.
<spk121>So here it lies, unfinished.
<dsmith-work>tohoyn: I can't get to those either.
<dsmith-work>tohoyn: How about ?
<dsmith-work>Too bad was abused.
<haugh>Hello friends, I have some questions about reloading modules
<haugh>First, when I do `,reload` without a file change, does anything happen? How can I manually "unload" a module, to simulate its first load?
<haugh>Separately I'm really interested in getting some kind of file-watching autoreload going, which I can totally hack together editor-side, but I'd like to know if there's an "official" approach
<haugh>spk121, great project name
<dthompson>haugh: I never really reload modules when I work on them, I just re-eval the relevant code within them using Geiser in Emacs.
<dthompson>haugh: but to answer the more general question about file watching, there is no "official" approach, but I have a Linux-specific solution via inotify bindings:
<dsmith-work>(Re: re-eval in geiser)
<dthompson>there has been talk before about making a library that uses this code + bindings for file watching on other platforms to make a cross-platform API but that hasn't materialized.
<dthompson>I have been successfully using these inotify bindings to auto-reload non-scheme data in my programs for years now.
<tohoyn>dsmith-work: debian pastezone complained about spam when I tried to use it
<haugh>dthompson, thank you. That REPL evaluation approach is basically what I've been doing: just sending text objects to a Vim terminal w/ REPL, but now I'm starting to treat everything as a module and that's getting a little tedious.
<haugh>What percentage of productive users do you all estimate are using Geiser?
<tohoyn>dsmith-work: what does gentoo pastebin complain to you?
<haugh>This inotify lib is extremely hot, thanks much
<dsmith-work>"Unable to connect" for
<dthompson>haugh: I'd say that "most" (not sure what percentage) people that spend a lot of time developing guile programs are using geiser + emacs.
<tohoyn>dsmith-work: so you can't access the server?
<dsmith-work>That may be becuse of local filtering here.
<dthompson>haugh: the thing that's very nice about geiser is that it knows what module you are editing. you can just re-eval code within a module file and it does the right thing. that's the big convenience. surely something could be written for vim to do the same?
<haugh>Ahhhh that does sound game-changing.
<dsmith-work>tohoyn: Right. Can't connect at all.
<dsmith-work>* Recv failure: Connection reset by peer
<dsmith-work>* Closing connection 0
<dsmith-work>curl: (56) Recv failure: Connection reset by peer
<dsmith-work>Probably corporate firewall blocking
<old>+1 for inotify. It's the easiest way of having auto-reload on Linux
<tohoyn>dsmith-work: I can send the files to you by e-mail if you are interested
<old>However gotta be careful when you do the auto-reload to avoid corrupting any state for example
<old>In a video game typically you would do the auto-reload at the end of a frame loop
<nckx>sneek: botsnack
<sneek>I've been running for 13 days
<sneek>This system has been up 3 weeks, 6 days, 15 hours, 10 minutes
<dsmith-work>tohoyn: Sure
<tohoyn>dsmith-work: can you give me your email address?
<tohoyn>dsmith-work: Actually it is not needed
<haugh>so is geiser basically just running ,in(module)(exp) when you send it an expression? That shouldn't be impossible to emulate
<tohoyn>dsmith-work: I just sent you one of the files with hexchat. did you receive it to your chat application?
<dsmith-work>tohoyn: I probbaly don't have erc wired up for dcc
<dsmith-work>OR corporate firewalls..
<old>haugh: Typically yes. Evaluation and compilation is done within the module defined in the buffer
<old>so you don't have to do `,m (my module)` everything you want to re-evaluate something
<old>Also one thing that is very important is the usage of `define-once`. Very important for global variable that need to be initialized once. Otherwise it get redefined everytime you evaluate the buffer
<haugh>Okay very good, thanks much
<dthompson>maybe I should use define-once, but I've been live coding guile programs for 10 years and have never used it
<tohoyn>dsmith-work: did you receive my e-mail?
<dsmith-work>Yes thanks
<haugh>tohoyn: third party email mood
<tohoyn>haugh: I could not find a suitable pastebin
<daviid>tohoyn: when debian false positive smap your paste, try centos, or open suse, or sourcehut (sh i thin you need an acccount to post, not to visit) if you have an account, then try debian in the next few ours or the nextr day, debian 'does that' with all of us'
<daviid>but avoid pastin, it tracks, not tro-friendly ...
<daviid>*tor-friendly :)
<dsmith-work>tohoyn: The parent case is inside the item case
<daviid>*try debian the next few hours again ... too many tipos today :)
<haugh><tohoyn> "haugh: I could not find a..." <- if you've got $20/year lying around I recommend sourcehut
<dsmith-work>tohoyn: Add a ) after the (newline) and remove one at the very end.
<tohoyn>dsmith-work: yes, I just corrected the file and resent it to you.
<dsmith-work>tohoyn: If you are in emacs, it will match parens. Also can reformat it.
<tohoyn>dsmith-work: the result is still the same
<dsmith-work>I don't get the error with the corrected file.
<tohoyn>to be sure, did you compile it with guild (not ran it)?
<dsmith-work>No, I just evaled the buffer
<tohoyn>ok. you should try "guild compile test1.scm".
<dsmith-work>Ah, need (use-modules (ice-9 match))
<dsmith-work>(define-module (test1)
<dsmith-work> #:use-module (ice-9 match))
<old>dthompson: Global threads pool is a good example of resource you don't want to revaluate everytime!
<old>database handle also
<dthompson>yeah definitely. I rarely have modules with state in them.
<dthompson>I also rarely re-eval whole modules. usually I re-eval individual procedures.
<dthompson>interesting to learn about how other people work in this kind of an environment.
<tohoyn>dsmith-work: t
<dsmith-work>dthompson: Yes, I usually just re-eval the proc I'm messing with.
<dsmith-work>tohoyn: It's behaving now for you?
<tohoyn>dsmith-work: yes
<w0ll3q1uszxabiwo>ACTION sent a code block:
<w0ll3q1uszxabiwo>How do you read this to understand why is that exception raised?
<w0ll3q1uszxabiwo>afaik it's saying that the object 'match' has a syntax error, but the backtrace doesn't show it anywhere calling match?
<w0ll3q1uszxabiwo>(not guix-specific error rather me trying to understand how to read guile backtrace)
<old>You always read the backtrace bottom to top
<old>Starting from frame zero: 1685:16 0 (raise-exception _ #:continuable? _)
<old>Many frames are noise such as frame 3 with map1
<old>But from what I can understand, the pattern matching failed inside a lambda procedure passed to append-map
<old>Not true, it failed in packages->outputs which is called in the lambda passed to append-map
<w0ll3q1uszxabiwo><old> "Not true, it failed in packages-..." <- > 673:15 6 (append-map #<procedure 7fd5dbde8800 at guix/scripts/environment.scm:327:16 (expr)> ((gc-root . "/home//kreyren/.cache/guix/profiles/jiuevdxuwe6hvm7ovr7czqipyck4x4i55ucwyexfh2zfuoqjvn3q") (exec "godot") (load ad-hoc-package "./dist/guix/guix.scm") (ad-hoc? . #t) (system . "x86_64-linux") (substitutes? . #t) (symlinks) (offload? . #t) (graft? . #t) (print-build-trace? . #t)
<w0ll3q1uszxabiwo>(print-extended-build-trace? . #t) (multiplexed-build-output? . #t) (debug . 0) (verbosity . 1)))
<w0ll3q1uszxabiwo>There is no packages->outputs though?
<w0ll3q1uszxabiwo><old> "You always read the backtrace..." <- oh it evaluates from bottom up?
<w0ll3q1uszxabiwo>so frame 0 -> The first thing parsed to guile?
<w0ll3q1uszxabiwo>seemingly yes bcs of the ice-9
<w0ll3q1uszxabiwo>so that way it can be deduced that the frames 3-6 are the contents of packages->outputs?
<w0ll3q1uszxabiwo>yep seems to be
<w0ll3q1uszxabiwo>old: thanks you just made guile significantly more understandable to me
<old>w0ll3q1uszxabiwo: My pleasure. What's tricky is that the first frames are almost always noise in `ice-9 boot`
<old>Not always ofc
<old>you get more information in Guile I think
<old>Here for example a Python backtrace for a division by zero:
<old>Here's the same program but in Guile:
<old>Backtrace is much more verbose
<haugh>dthompson, just curious, why is %make-inotify marked up with the % but not the other instantiators?
<haugh>oh it's got a wrapper, I get it
<haugh>I've been doing this with a * suffix; is a % prefix more conventional?
<w0ll3q1uszxabiwo><old> "w0ll3q1uszxabiwo7vet7op4fhjk84wk..." <- i always read it from top to bottom bcs i was executing it from guix and the first thing there was primitive load followed by run-guix x.x
<w0ll3q1uszxabiwo>so like the logic was that guix is doing the processing and then sends that to ice-9
<w0ll3q1uszxabiwo>or whatever @_@
<dthompson>haugh: yup, you figured it out! % is the convention I saw in guix and maybe elsewhere, back when I was new to guile, so it's what I've used.
<dsmith-work>Those % are sharp and pointy. Need to handle thing like that very carefully..
<dsmith-work>Kind of like a scissors that is opened all the way
<dsmith-work>Don't *ever* run with one of those variables
<haugh>okay I'm converting to %instantiator but if I ever see instantiator* in the wild I'll come back here and complain
<haugh>dsmith-work, every single time I show Scheme to someone for the first time they have a conniption at the characters allowed in bindings, so yeah, approximately as dangerous as scissors
<dsmith-work>There are very few things not allowed.
<dsmith-work>Gahh. Took me forever to find it:
<rekado>I just checked the logs… my messages didn’t make it through :(
<rekado>catching up…
<rekado>w0ll3q1uszxabiwo: it says that your match expression has no clause for #<unspecified>
<rekado>I’m guessing that dist/guix/guix.scm is your file? And it evaluates to an unspecified value, perhaps because it ends with a definition.
<rekado>and guix/scripts/environment.scm calls packages->outputs, which assumes that what you give it is a package and not #<unspecified>
<rekado>old: re the ice-9 boot thing: this may be a regression.
<rekado>IIUC it has already been corrected with a patch by flatwhatson
<w0ll3q1uszxabiwo>rekado: ye i intentionally broke the package to show the output as i really just wanted to figure out how to read the backtrace O.o
<rekado>haugh: I use a trailing “*” to indicate a variant; I use a leading % to indicate a “raw” constructor, or a module-global variable.
<rekado>I use the #{ syntax}# for generated values that are accessed only in macros.
<haugh>rekado, by "module-global" you mean top level definitions that are not exported?
<rekado>and usually in my code these will be lookup tables or configuration
<old>%internal *global* variadic* variant/x
<old>That's my usage :)
<old>I also use this: `(eventually~ ~thunk)`
<haugh>Man I love this language. I was beginning to think I just wasn't meant to be a "real programmer" (whatever that means) but it turns out I'm just allergic to guardrails. Can you believe people write Golang full time
<old>Procedure that work with defered computation have the suffix `~` and parameters of that function which are defered are prefix with `~`
<haugh>old: Oh definitely stealing this
<old>haugh: I believe that many people suffer from writing Golan/Java/whathever full time
<spk121>I've used +someOtherTypeOfGlobal+
<old>I also have `&procedure-that-throw-an-exception!`
<old>Like `&ensure-user-connected!`
<haugh>do you mark "proc that might throw" different from "proc that always throws"
<rekado>oh, I only ever use & for condition values.
<rekado>never for procedures