IRC channel logs


back to list of logs

<old>Hmm #{foo bar}# should work
<old>but it does not here
<mfiano>scheme@(guile-user)> (symbol->string '#{foo bar}#)
<mfiano>$5 = "foo bar"
<festerdam>I'm having trouble figuring out how to use modules, I'm also seeing some weird behaviour that at least to me seems a bit inconsistent. I have a file called «common.scm» in a directory «alp(ttis)» containing the lines «(define-module (alp-tti common) #:export (a))» and «(define a 3)». Then in a REPL, whose %load-path contains the «alp(ttis)» directory, I do (use-modules (alp-ttis common)), which
<festerdam>fails with error «While compiling expression:\nno code for module (alp-ttis common)», however the when I try to do (use-modules (common)), it actually displays the compile message (ie. «;;; note: auto-compilation is enable, set GUILE_AUTO_COMPILE=0\n;;;or pass [bla bla...]», «;;; compiling /bla/bla/common.scm», «;;; compiled /bla/bla/common.scm.go»), but then that is immediately followed by the
<festerdam>previous error message («While compilling expression:\nnode code for module (common)». What I find weird is that if I then do (use-modules (alp-ttis common)), there is no error, but I still cannot access the variable «a». What am I doing wrong?
<festerdam>*, however then when I try to do
<festerdam>Ah, wait, it seems I do have access to the variable «a» in the end. But what I said before still stands. (use-modules (alp-ttis common)) → fails (use-modules (common)) → fails (use-modules (alp-ttis common)) → succeeds
<festerdam>Why is that?
<daviid>festerdam: %load-path must list the path 'above' the module, so, if the file is in /a/b/c/all-tis/common.scm, %load-path must contain "/a/b/c"
<daviid>and the module be defined as (define-module (apl-ttis common) ...)
<daviid>festerdam: try to look at GUILE_LOAD_PATH in 4.2.2 Environment Variables, and also look at a few modules def in the guile source tree itself, just 'to get it' ..
<daviid>festerdam: also, 6.18 Modules - 6.18.4 Modules and the File System
<festerdam>daviid: Thanks! But is the behaviour I described expected (the same use-modules expression having different outcomes)?
<daviid>festerdam: i didn't read the entire msg, as it is common 'newbie' problem to understand how the module system works, i first wanted topoint you to read and understand, then reproduce with your own modules ... ofc, once you've done that, you'll answer your own questions, but just to make sure, all this is deterministic, no black magic, no identical use-modules expression having different outcomes ...
<mfiano>daviid: He has a directory containing a parenthesized word in its name. His example is strange and I cannot tell as a newbie if this is a defect by the bad input resulting in non-determinism.
<festerdam>daviid: I got it working. Thanks!
<festerdam>mfiano: I tried renaming the directory to something different without parentheses («alp-ttis»). The same thing happens.
<mfiano>I am very familiar with the module system, but I have never given it such a strange directory name before, so the non-determinism had me confused.
<mfiano>That is why I just waited for an answer. I was curious what I had missed in all the modules I wrote to figure out how to structure complex programs.
<festerdam>Sorry, I should have been more careful with what I'm saying. With "the same thing happens", I meant, it continues to result in two different outcomes. :D
<mfiano>Unfortunately, how files are looked up is not specified in Scheme, but Guile's module system is one of the major reasons I chose it a couple months ago. It's just wonderful to work with (once you learn it fully)
<mfiano>So, don't give up, and ask us questions when you are stuck. The module system did give me a few problems with my complicated development environment that took me a week or two to figure out myself...
<old>mfiano: Oh right I forgot the quote
<old>I thought that the reader did not need the quote with the #{}#
<pottsy>hi all. my SMOBs are displayed awfully funny
<pottsy>e.g. `(window-width)` => 1024, but `window-width` => `#<?'?r?U 7f232d6037a0>`
<pottsy>is this the intended way for smobs to be formatted?
<mwette>pottsy: I'm guessing you did not a constant or static string when calling scm_make_smob_type.
<mwette>s/did not a/did not use a/
<mwette>scm_make_smob_type(buf, 10) vs scm_make_smob_type("mytype", 10)
<pottsy>mwette: ahh good idea
<pottsy>great, that was indeed the problem!
<pottsy>In general, should I assume that c-strings will not be copied by libguile?
<old>I think that the intent is to pass a string literal, which is by default read-only
<janneke>sneek: aren't you glad to see civodul?
<civodul>sneek: botsnack
<civodul>janneke: i've been toying with Cuirass for Guile as discussed the other day
<civodul>it's starting to do things
<civodul>i'll email guile-devel
<janneke>civodul: oh, thats nice!
<civodul>very much a déjà vu for me :-)
<janneke>yeah :)
<civodul>i feel like i've been hacking in circles of increasing radius over the last 15y or so
<civodul>something like that
<janneke>hehe, well luckily guix is more than a fancy ci
<civodul>the funny thing is that we can use Guile as a channel
<civodul>totally weird, but at the same time probably a useful kinda of tool
<janneke>civodul: nice writeup!
<old>Yay. Can do some timeout in Guile with libev: (run! (loop (timeout 1.0 (lambda (loop . rest) (pk "timeout after 1 second!") (break! loop)))))
<oenone>is it normal that I dislike the ...-set! functions, because it feels so imperative?
<old>Is there anything useful for `export-syntax' vs `export' ?
<old>If not now maybe in the future?
<civodul>janneke: thanks :-)
<civodul>so this is similar to what you were doing too, right?
<old>Is this a bug? (let-keywords '(#:foo bar) #t () (list)) => misc-error
<civodul>looks like it
<civodul>it should be okay to have zero bindings i guess?
<old>Although not very useful on its own, I have a syntax that could expand with empty bindings
<old>I'm using a dummy binding that's never used in the hope of it been optimized
<janneke>civodul: yes, we didn't have channels back then, but yeah, building a package for every git committ
<civodul>old: that could be a useful improvement
<old>I'll make a patch then
<mfiano>The collaboration between guilers is wonderful :)
<dadinn>hi all
<dadinn>I am experiencing a weird problem which seems to be quite complicated. I am trying to run multiple KVM/Qemu virtual-machines in parallel with ice-9:open-pipe* OPEN_BOTH, and then communicate them via serial connection over the pipe port. The problem is that the VMs run extremely slow, and the CPU utilization is very low.
<dadinn>I am not sure if this is a Qemu/KVM problem (it doesn't seem that the resources are exhausted, it is running on a damn-fucking powerful server machine with 200Gb RAM... I am actually using the RAM as tmpfs for storing the disk images (it's all for running temporary E2E tests)
<dadinn>I am using ice-9 expect macro to communicate via the port. I am thinking it might have something to do with the way the port is configured:
<dadinn>have these options applied on the port before starting the expect processing: (setvbuf port 'none), (set-port-encoding! port "UTF-8"), (set-port-conversion-strategy" port 'substitute).
<dadinn>not sure if the ports are somehow holding back the VMs processing power!? Any suggestions what might be going wrong here, or how to investigate this further? :/
<mfiano>I recall there being some performance improvements in this area in 3.0.9. Other than making sure you're up to date, this is above my head.
<old>If hardware acceleration enabled in the BIOS?
<old>You migh want to try with either Tcl except or Python pexcept to see if it's Guile the problem
<dadinn>old: hardware acceleration is enabled. The Tcl/Python expect is a great idea, though I would struggle rewriting my massive E2E test codebase! :(
<old>what about just making a small testing program
<old>just to see if it's guile related