IRC channel logs
2023-07-02.log
back to list of logs
<Zelphir>I just tried using geiser with `geiser-connect' to connect to a Guile REPL. This Guile REPL is launched in a Guix shell, so that it has all the dependencies, so that I can run the code in Geiser with the dependencies available. However, it took a long time to connect. I am guessing, that it was waiting for something specific in the prompt string, which it did not find and then had a timeout, working with what it got. The prompt in Geiser then looked <Zelphir>sort of scrambled, as if Geiser could not deal with the color codes or other formatting of the external Guile REPL. I will try to paste an example. <Zelphir>The prompt looks like this in Geiser: ^A^Bscheme^A^B^A^B@(^A^B^A^Bguile-user^A^B^A^B)^A^B^A^B^A^B^A^B> ^A^B <Zelphir>Does anyone know how to avoid that, when connecting to external process Guile REPL? Geiser seems to work as usual, except for that. <Zelphir>I also tried starting the external Guile REPL once inside vterm in Emacs and once in xfce4-terminal. No change. <Zelphir>The Guile REPL command that launches the REPL was: guile --listen=12345 -L . -L contracts -L commands -L test -l shell.scm -l commands.scm <flatwhatson>Zelphir: it might be guile-colorized causing problems, it's enabled by guix's default guile config <flatwhatson>one hack is to set INSIDE_EMACS=1 in the environment running guile, guix's default guile config won't activate guile-colorized if that's set <Zelphir>flatwhatson: Yep, that fixed it! I commented out (activate-colorized) from my ~/.guile and now it works and also connects immediately. <Zelphir>Using it like this, I don't need the colors, because I have them in Geiser. <mfiano>Interesting. I haven't seen this with a local connection and colorized. <mfiano>Also hi Zelphir. We talked on fedi about a year ago (I have too good of a memory) <mfiano>Is there a set of procedures (in Guile or provided by some SRFI) like SRFI-1's `every`/`any` that operate on bytevectors (or anything that guile treats as bytevectors, like SRFI-4 vectors and arrays)? <dokma>I seems to be misunderstanding something about modules. When I use scm_c_define_gsubr to define a procedure it seems to be available from guile only up to the point I use define-module. I thought scm_c_define_gsubr defines the procedure in the top level environ where it is always available? <dokma>dalepsmith: you any good with modules? <dokma>wingo: what happens to a procedure defined with scm_c_define_gsubr after a define-module call? Why is it not defined any more? <dokma>I literally did: scm_c_define_gsubr and then in scm_c_eval_string I invoked it with (daemon), then I did a define-module and immediately after that daemon is not defined any more. <dokma>Well, same thing happens directly from the repl: <dokma>(define (daemon a b) (display "proc")) <dokma>;;; <stdin>:10:1: warning: possibly unbound variable `daemon' <dokma>ice-9/boot-9.scm:1685:16: In procedure raise-exception: <dokma>So obviously define-module changes the environment or whatever the term is. <dalepsmith>dokma: Not really. I think at the core, a "module" is just a mapping between names and values. <dalepsmith>If you are writing C code, you can use the SCM_DEFINE snarfing macros that generate a .x file that has all the define gsubr stuff. You then include that into your module init fucntion. <dokma>dalepsmith: I've read the snarfing docs. My issue is that I don't understand why a defined symbol disappears after a define-module <rlb>dokma: yes, define module changes current-module. <rlb>scheme@(guile-user)> (current-module) <rlb>$1 = #<directory (guile-user) 7fe56e302c80> <rlb>scheme@(guile-user)> (define-module (foo)) <rlb>$2 = #<directory (foo) 7fe56abe0960> <rlb>scheme@(foo)> (current-module) <rlb>$3 = #<directory (foo) 7fe56abe0960> <rlb>And iirc some things don't change back at the end of the file (if you're loading a module, say via use-module). i.e. unfortunately for me at the time, reader state like srfi-88. <rlb>If you used srfi-88 then (haven't tried in a good while), it'd affect the reader from then on, i.e. it affect any modules/code read after that module too. I'd tended to think it shouldn't. <rlb>dokma: depending on what you're trying to do, you either need to set the current module before the define, or introduce the binding some other way, i.e. via module-define, etc. <mfiano>there is a procedural module api <dalepsmith>There is some C function that calls a user supplied function in the context of a module. Let me see if I can find it.. <dalepsmith>... and leaves you back in your original module context <rlb>Zelphir: I believe you likely want to define a given parameter once, and then import it into every module that needs it. If you were to (re)define it in each module, you'd be setting up per-module "parallel universes" wrt that parameter. <rlb>(unless that's what you want) <dokma>rlb, dalepsmith: yes, define-module changes the current module and that is my issue. <rlb>dokma: right I was just verifying your assumption. So you'll need to change the current module to the one you want to put the new definitions in before you define, or use something like module-define, or... <dokma>Trying to figure out how to reorganize that so that I am able to invoke the C functions after the define-module <dokma>Without the define-module all works well. <rlb>Whatever things you want to have happen in (sapod) have to happen when it's the current-module, and whatever things you want to happen in another module have to happen when it's not. Since the define-module changes to the new module, you'll need to move things before that that shouldn't happen in the module, *or* restore the module you want after the define module with (set-current-module (resolve-module '(some module)), or use <rlb>save-module-excursion, or... <rlb>I think the first question would be whether you intend for daemon and get-arguments to be defined in (sapod) or not. <rlb>So you could define the module in a separate step, and then populate it. evaluate code in it, etc.