IRC channel logs

2020-10-05.log

back to list of logs

***apteryx is now known as Guest73071
***apteryx_ is now known as apteryx
<ManDay>I'm not sure whether it's a lack of understanding on my part, but I'm frustrated with Guile's CLI. There appears to be no way in the world to simply run a script and debug it (c.f. gdb on a C program)! If I run the script and it has an error, Guile prints a (more or less comprehensible) error to the terminal and then just quits. And there appears to be no way from debugging it UNLESS I *manually*
<ManDay>execute the command in an interactive session. I've tried everything from -c -s and -e switches to even crafting a temporary .guile, either things don't execute or I'm not getting the interactive debugger. Is this design on purpose? It just doesn't seem to be thought-trough for practical usage.... :-/
<ManDay>Judging from the title, I guess I should update before speaking... The newest in Gentoo is 2.2.6 and the titles mentions something 3.0.4. Though I suspect an update wont change that particular issue
<rekado>ManDay: for Guile applications I find it helpful to start a REPL server alongside the application
<lloda>tbh i just do (load ...) on the repl to get the debugging prompt, that hasn't bothered me. But yeah 3 behaves in the same way
<rekado>e.g. with (spawn-server (make-tcp-server-socket #:port repl-port))
<rekado>I also wrap the application in call-with-error-handling to enter a debugger when an error occurs in the thunk
<ManDay>ok, I'll take a look into that. lloda that's what I've been doing so far but I find it completely pointless, that should be a feature of the binary. I'll do a PR if I can figure out how to make it work (never looked into guile)
<rekado>these two options together make application development and debugging rather convenient
<ManDay>so using call-with-error-handling, how would I apply that *without* modifying my source code?
<ManDay>I don't even care if I have to write a shell wrapper around it, I just want to be able to type "guile-with-debug some-file.sh" on the command line and get a working debug
<ManDay>for god's sake guile seems to be throwing every rock it can find into my way
<ManDay>it can't be that difficult
*ManDay tries generating a script which encapsulates the file into call-with-error-handling on the fly
<ManDay>well that kind of works. not exactly the same prompt i get interactively but it will have to do
<ManDay>thanks
***ftknox_ is now known as ftknox
<roptat>mh... I'm trying to define this macro: https://paste.debian.net/1165971/ but I get source expression failed to match any pattern in form (modify-as-document d (remove id))
<roptat>the macro works well for set and remove*
<roptat>(initially, I named them set, delete and delete*, but though there could be a conflict with delete, but I had the same issue)
<mwette>embedded control character you don't see? -- retype the form maybe
<roptat>I tried moving remove and remove* around by only deleting * and adding it, but that didn't change anything
<roptat>also renaming remove to removee works, so I'm wondering if the * is interfering somehow?
<lloda>that's very strange, * is just a character
<lloda>is remove* defined before?
<roptat>the order doesn't seem to be important
<lloda>i mean defined in the environment, not by yourself
<roptat>neither set, remove nor remove* are defined
<mwette>try to retype the entire second form, from ((_ doc to spec ...))
<mwette>invisible (control) characters can get you sometimes
<dsmith>Does it matter if you move the "replace* before the "replace"?
<roptat>no, it doesn't
<roptat>ha! actually remove is defined in the context of the definition
*janneke stumbles over (ice-9 rdelim)s write-line and sends a patch
<mwette>How is remove defined in the context of the definition?
<mwette>It's a keyword, right?
<dsmith>I don't understand what that macro expands into. Looks recursive, but I don't see how it terminates. But my macro-fu is weak. Especially syntax-case.
<roptat>dsmith, it terminates in the first case
<roptat>(only doc, but no additional spec)
<roptat>at the definition point, I use (srfi srfi-1), which defines remove
<roptat>if I copy the macro to a point where remove is not defined (in a fresh repl for instance), I don't have that issue at all
<dsmith>Doh!
<dsmith>Now I see. In the base case, "doc" can be a whole expession.
<dsmith>roptat: So what version of Guile?
<dsmith>ISTR some changes in 3 about macros
<dsmith>Ahh nevermind
<dsmith>** Define top-level bindings for aux syntax: `else', `=>', `...', `_'
<dsmith>That's what I was attempting to remmeber
<roptat>3.0.2
<ManDay>The guile texinfo manual says the warning about replacing a core binding would be prevented by a define-module option #replace. I get warnings about (display) and associates being overriden by r6rs - apparently the r6rs module does NOT use #replace... Can these warnings be prevented?
<ManDay>(they print right into my output, messing everything up)
<ManDay>worked around it with (import (except (rnrs (6)) newline display))
<leoprikler>ManDay: you could register your own warn-core-override-no-rnrs, which works just like warn-core-override but does not do anything if one of the modules starts with rnrs
<ManDay>thanks, a bit an overkill but I get the idea
<leoprikler>does anyone know if guile has a string i/o port that can be both read and written to?
<leoprikler>pipes are probably close to what I'm looking fore
<leoprikler>hmm, output-strings could probably also do similar things, but they don't seem to handle #\delete well
<dsmith>leoprikler: Do you want #\delete to remove a character?
<leoprikler>either that or #\backspace
<leoprikler>but both just get appended to the string with put-char, which tbf one would expect
<dsmith>What you are probbaly needing is a pty or something else that has a line-discipline.
<dsmith>Or maybe readline?
<leoprikler>I get my inputs through keyboard events, though.
<leoprikler>See https://gitlab.com/leoprikler/tsukundere/-/blob/devel/tsukundere/script/utils.scm#L121-151
<dsmith>Hmm. Probably need to implement that by hand then..
<leoprikler>I could probably implement something similar based on bytevectors, but I'm not sure how much I'd gain from doing so
<stis>hej guilers!
<leoprikler>hi stis
<manumanumanu>tjena stis!
<manumanumanu>what kind of exciting saker are you up to today?
<stis>my long term goal is to test and test and test the python implementation, it's a huge task
<stis>not only the language. but actually getting the batteries to work as well.
<mwette>leoprikler: maybe something lurking in https://git.savannah.nongnu.org/cgit/emacsy.git/tree/emacsy text.scm
<manumanumanu>stis: do you feel motivating or just insurmountable?
<manumanumanu>does it*
<leoprikler>mwette: hmm, it seems like (ice-9 gap-buffer) is a good place to search
<leoprikler>perhaps that should be documented
<manumanumanu>I though tthat was deprecated...
<manumanumanu>the documentation was removed before 2.0 iirc.
<manumanumanu>leoprikler: https://www.gnuvola.org/software/guile/doc/Gap-Buffer.html
<manumanumanu>that is the old docs
<leoprikler>yeah, it seems to use soft ports, which IIRC is the "old" way of doing custom ports
<civodul>sneek: seen OrangeShark
<sneek>OrangeShark was in (here?) 7 months ago, saying: oni-on-ion: it is a package on guix https://guix.gnu.org/packages/guile-studio-0.0.2/.
<stis>manumanumanu: I've just want something to do and why not make the python implementation a little better. It is a daunting task though
<manumanumanu>I have a similar feeling. I spent a little time looking at foof-loop asking "why the eff did he do it like that?!". Now I am trying to write a similar thing, but with support for racket-like subloops. I have had to start over 2 times so far after going "oooh, that's why!"
<stis>yeah I know the feeling
<davexunit>leoprikler: yeah I looked at soft ports recently for a similar reason. prob not worth building something on something so old and crusty.
<davexunit>I haven't gone down the rabbit hole yet, but a custom binary port with a wrapper around it that does utf8->string could work.
<spk121>leoprikler: in (ice-9 readline), you can use the 'readline' function
<spk121>would that work?
***janneke_ is now known as janneke
<leoprikler>I'm not sure, but probably no.