IRC channel logs

<jcowan>You're home!

<benl>hello I'm trying to use the Chickadee library and I can't even get the hello world program to work correctly :/

<noe>benl, what’s the error?

<yarl>Hey old. Regarding R6RS opaque records (context https://codeberg.org/guile/guile/pulls/152 and our last irc discussion). The current implementation does already leak fields because a record type created with define-record-type uses (rnrs records procedural)'s make-record-type-descriptor which uses boot-9's make-record-type. This one sets the printer to default-record-printer, opaque or not. I didn't find R6RS papers

<yarl> very clear on what the external representation for opaque records should be. Even https://srfi.schemers.org/srfi-237/srfi-237.html that goes beyond is not completely clear on that matter, is it? To compare I looked at how racket and chez-scheme treat an opaque record of type foo. They both print #<foo>.

<yarl>All this to say that I think that the leaking problem should be resolved in boot-9, using a non-leaking printer for opaque records. WDYT?

<yarl>Do you want me to send a PR for this?

<yarl>And what should be the external representation? <type> ? #<type> ? what about when you (define-record-type <foo> ...) as often, this will print #<<foo>> which is ugly.

<czan>What's the absolute minimum structure I can get away with to distribute a Guile project? Everything I'm seeing is using autotools and seems pretty complex. Assuming I have no dependencies (beyond Guile), can I get away with just a Makefile or similar? Assuming the answer is yes: is there prior art anyone can point me to?

<ekaitz>czan: you don't need anything else than guile if you don't have extensions written in C or anything like that

<czan>I want to distribute it as a library, so presumably I would want some build process to precompile .go files and whatnot. I'm basically asking "how can I do that without using autotools?"

<ekaitz>`guild compile`

<ekaitz>czan: do you use guix?

<czan>I do use Guix, yeah. I'm not familiar with guild. I'll check it out.

<czan>I've never really had to compile Guile beyond "make" in existing projects and geiser-compile-current-buffer, so I'm deeply unfamiliar with this process. :)

<ekaitz>czan: in guix you have a guile build system

<ekaitz>if you are used to read guix code you can see what it does

<ekaitz>it's pretty simple

<ekaitz>guix/build/guile-build-system.scm <-- this is the description of the phases

<czan>I am very able to read Guix code. :) I'm just wary of writing software that can *only* run in Guix. I don't want to require that everyone who uses my library uses Guix.

<ekaitz>czan: what I mean is you can see how it builds and distributes and replicate it yourself

<ekaitz>it's just a bunch of calls to `guild compile`

<ekaitz>and then installs the lib by copying those to the correct path

<ekaitz>it should work perfectly for *any* distro

<czan>Yeah, fair call. I'll write myself a Makefile, then. Thanks!

<czan>Honestly, I hadn't considered that Guix's guile-build-system would do anything other than the (seemingly ubiquitous) autotools build process. Thanks for pointing that out to me.

<ekaitz>in guile-build-system it uses just guild compile i think, that's why many guile projects use gnu-build-system instead

<ekaitz>guile-build-system is very simple

<spk121>czan: if you wanted just a plain makefile it would look something like this: https://gist.github.com/spk121/baaae2ba1bd2754d1ed937d7883033bd

<spk121>well that's GNU make anyway

<czan>Cheers! That's pretty close to what I'm coming up with, but particularly the %site-dir and %site-ccache-dir bits would have taken me a while to come up with.

<czan>I don't suppose there's any way to get Guile to emit dependency information (i.e. which other files were loaded when compiling a given file)? I'd like to ensure that macros are recompiled correctly across files. Similarly to how I use -MMD with clang to emit dependencies in make target format which I can -include in my makefile.

<yarl>also old, get/set-object-property is legacy. where do I put (define custom-printer (make-object-property)) ?

<mwette>I thought there was something for packaging guile code.

<mwette>sneek: software?

<czan>The manual mentions Hall, but that generates autotools stuff, which I'm trying to avoid.

<mwette>Maybe that is what I was thinking of. I understand the need. I ended up making my own Makefile.in's and minimal configure.ac.

<tohoyn>sneek: botsnack

<sneek>:)

<daviid>sneek guilesoftware?

<daviid>sneek guile-software?

<sneek>guile-software is http://sph.mn/foreign/guile-software.html Send an email to tantalum, <sph at posteo dot eu> to make changes or post a new project.

<daviid>mwette: ^^

<mwette>daviid: ty

<mwette>czan: ^

<old>yarl: where does it say object-proprety to be legacy?

<yarl>old 6.9.2 Object Properties : Guile also implements a more traditional Lispy interface to

<yarl>properties, in which each object has an list of key-value pairs

<yarl>associated with it. Properties in that list are keyed by symbols. This

<yarl>is a legacy interface; you should use weak hash tables or object

<yarl>properties instead.

<yarl>oops sorry about that.

<yarl>Did you see my comment about R6RS opaque records above?

<sneek>Yey! tohoyn is back :)

<meaty>hi guile, has anyone gotten hoot to work on guix recently?

<meaty>'hoot repl' fails saying that .../repl.js is missing, and indeed there is only repl.wasm in that dir

<meaty>also, 'guild compile-wasm' says unknown script

<ekaitz>meaty: guix shell guile-hoot guile -- guild compile-wasm ?

<meaty>oh, adding guile to the profile fixes the compile-wasm script. 'hoot repl' still gives the same error though

<meaty>i thought i might not have needed to specify guile cos it was already in my system profile

<ekaitz>meaty: you need to add guile because that tells the `guix shell` to add the env variables properly

<ekaitz>about the hoot repl idk, that maybe dthompson could solve

<rlb>...in our tests, it seems preferable to *avoid* a test description in a lot of cases with the current reporter, i.e. (with-test-prefix foo (pass-if-equal x y)) is notably better than (pass-if-equal foo x y)) because the former will actually show you the values on failure. The latter just shows you foo.

<rlb>Also (pass-if-equal x y) seems preferable to a lot of our (pass-if (string=? x y)) style tests i.e. rely pass-if-equal's equal when you can because then we have more information if/when we want to adjust/improve the reporting...

<rlb>"rely on"

<rlb>suppose the real answer to the first issue is to just improve the default test-lib reporter.

<rlb>hmm, pass-if-equal does print the expected/actual, even when there's a name, so just preferring that to pass-if when you can should be sufficient.

<meaty>im so sorry, can anyone help me troubleshoot why hoot isn't "working"? i have tried both the manual tutorial and the start of the interactive webpages blogpost and neither seem to do anything

<meaty>the HTML pages load, as do the js and wasm files (according to the inspector), but no console message, no node added to the DOM

<meaty>disclosure, i know almost nothing of javascript/interactive web dev stuff

<rlb>meaty: there are likely people here who may be able to help, but it could take a while, i.e. could be away for the weekend, etc.

<meaty>np

<rlb>...something's off wrt whitespace --- we currently optimize (string-trim-right s) by special casing and shunting to C-level uc_is_c_whitespace() tests, but uc_is_c_whitespace(0x2003) (em space) is 0, while (char-whitespace? (string-ref "\u2003" 0)) is #t.

<rlb>...expanding-test-coverage++

<rlb>ACTION reads up on char-whitespace?

<rlb>umm...

<rlb>scheme@(guile-user)> (string-ref "\u2003" 0)

<rlb>$1 = #\20003

<rlb>scheme@(guile-user)> (string-ref "\U00002003" 0)

<rlb>$2 = #\space

<rlb>3.0.11

<dsmith>Ur?

<dsmith>20003 instead of 2003 ?

<rlb>That part's fine --- I forgot #\... is octal by default...

<rlb>But the mismatch between uc_is_c_whitespace and char-whitespace? looks like a potential problem.

<rlb>ACTION is checking more carefully.

<rlb>i.e. perhaps that optimization is wrong.

<rlb>(if I'm "doing it right")

<rlb>I tried a trivial C printf for libunicode uc_is_c_whitespace (0x2003) and that returns 0.

<rlb>Optimizations like this one are what I'm wondering about: https://codeberg.org/guile/guile/src/branch/main/libguile/srfi-13.c#L808-L816 I'd preserved them in the utf8 branch, and saw the issue when expanding test coverage a bit.

<rlb>might even just be that the libunistring "c" whitespace spec doesn't match char-set:whitespace (which I believe is "unicode").

<rlb>Sounds plausible unless "c" there just means unicode...

<rlb>haha --- yeah, it does what it says on the tin (it's in gnulib sy_c_whitespace.c)

<rlb> return (uc == ' ' || (uc <= 0x000D && uc >= 0x0009));

<rlb>oops

<rlb>ACTION will fix it

<rlb>i.e. remove that optimization from main

<jcowan>C whitespace is smaller than Unicode White_Space

<rlb>exactly

<rlb>was referring to https://en.wikipedia.org/wiki/Whitespace_character#Unicode when adding some coverage :)

<rlb>hence the \u2003

<rlb>fixed

<jab>hey fellow guilers!

<jab>I've been writing the Hurd Qoths for a while now. I'm thinking that it would be cool to do the same thing for GNU Guile. Do ya'll suppose there would be interest in that?

<ekaitz>jab: your are supposing we know what a Hurd Qoth is

<jab>A Qoth is a quarterly update of the Hurd. It's just a blog post that I write 4 times a year. Here's what happened the last 4 months.

<jab>You can read them on hurd.gnu.org

<jab>I would like to do something to the official guile site, because I think a lot of the news on guile-user@gnu.org gets missed.

IRC channel logs

2026-04-11.log