IRC channel logs

<ArneBab>old: you could write make in the minimal scheme supported by mes?

<old>ArneBab: what I mean is that I have a fully robust build system written in Guile

<old>and I wonder if it would be possible to use it to build guile itself

<old>or there is a chicken-egg problem

<dsmith>rlb, Well. I can't seem to get make check to stop early any more. It *always* shows the final summary now. Without me messing with guile-test exit codes.

<ArneBab>old: I think that’s a chicken egg problem, yes. You’d have to write the build system in mes scheme so you can bootstrap guile from mes. mes can already build tinycc which can build gcc 4.7, so you can bootstrap GNU make, and that bootstraps Guile.

<ArneBab>autoconf+automake have the advantage that they are supported in every distribution, so I don’t think it’s wise to replace them. Even more so after recently packaging maven-built libraries in Guix. That’s a horror. Python (pip) and Javascript (npm) are horrible, too.

<ArneBab>Java, Python, and Javascript all made their own build tool, and that creates major headaches when packaging.

<ArneBab>(java gradle is even more horrible - to the degree that for packaging that, I actually recovered the old ant buildsystem; which is also worse to package than Makefiles, but less horrible than gradle)

<ieure>Last job I had, we used Gradle. No Java build tool is actually good IMO, but Gradle was uniquely unpleasant.

<ieure>I made my peace with Maven, it's not good, but it's adequate in most regards, and I got mad enough to figure out how to make it do the things I wanted

<dthompson>be careful not to conflate build systems with package managers. every "modern" language has made this mistake.

<dthompson>lest we become successful enough to have stuff like this happen https://www.aikido.dev/blog/npm-debug-and-chalk-packages-compromised

<old>ArneBab: I don't intend to intergate any package managing

<elb>dthompson: oh that's awesome, I'm glad I asked!

<elb>dthompson: so it looks like flat pages take site metadata body, but blogs still take site title body; any thoughts on unifying them both to site metadata body?

<elb>also I have something similar to ugly-default-layout's title handling in all of my sites, but I do (title ,(if (string=? title site-title) title (string-append title " – " site-title))) to avoid stuttering

<elb>(which maybe is something to consider as a default)

<euouae>hey all two questions

<euouae>1) I have a C app that uses guile as an embedded language. I can evaluate expressions but if there's a lisp error I get a segfault

<euouae>I want to catch the guile exception (with scm_catch?) but I'm not entirely sure how to pass a thunk to scm_catch

<euouae>In my program I'm reading a proc of 1 argument and then I invoke it with a list

<euouae>e.g. I can read both `reverse' and `(lambda (x) (map 1+ x))` and both work fine -- but if I do a typo like `revrssss` then I get a segfault. I'd rather recover from it. But how can I create a "thunk" C-side that captures the procedure & list I'm passing?

<euouae>2) I notied in libguile/throw.h there's functions like SCM_API SCM scm_handle_by_proc (void *, SCM, SCM); but I don't see them listed in my Guile manual. Are they just missing or are they not public API? Looks public.

<euouae>ah for 1) maybe scm_c_make_gsubr is what I need

<euouae>hm... actually no. I have no idea

<rlb>euouae: depending on what you're doing, and if it's feasible, you may find it easier to do a s much on the scheme side as possible, e.g. if you can have c call a scheme function containing the relevant dynamic-wind, with-exception-handler, or similar, instead of having to do that part on the C side.

<rlb>dsmith: that past appears to be gone.

<rlb>"paste"

<euouae>rlb: It's an example application. On the C side I have a char pin[6]; a 6-digit PIN

<euouae>I convert it into a Scheme list of 6 elements and I do pin = scm_call_1(proc, pin);

<euouae>So I can evaluate some Scheme like `(lambda (pin) (map 1+ pin))` and it'll turn 123456 to 234567

<euouae>So with this setup, how can I catch an error in Guile?

<rlb>right, and assuming you're concerned about proc throwing, you could just have proc include a (with-exception-handler ...), if it's feasible.

<euouae>okay but what if proc is nonvalid syntaX?

<rlb>Where's the (lambda ...) coming from in the first place, a user string?

<euouae>yes, I can show you the entire app

<rlb>i.e. if you're not using eval, then the code would be in a .scm file and compiled.

<rlb>Or if loaded, then you'd need a wrapper around the load.

<euouae>I'm using scm_c_eval_string

<rlb>I'm not sure what'd be best -- just suggesting in general that one strategy is to just avoid as much work as possible on the C side.

<rlb>push the work the scheme code.

<rlb>"to the scheme code"

<rlb>You *can* do most anything on the C side, but it's very often harder.

<euouae>But how do I push a syntax error to the scheme side? turn it into (with-exception-handler ... (eval user-string))?

<rlb>sure

<rlb>that's one way

<rlb>but you'd probably want a function so you can pass the user-string as an arg

<rlb>in that case

<euouae>I mean yeah, the whole thing

<rlb>i.e. scm_...call a pre-defined (define (handle-user-string s) (with-execption... )) or something

<rlb>But you can also handle exception on the C side.

<euouae>yeah but thunks require global state

<euouae>it just occurred to me that I might have to do scm_with_guile(entry); and inside entry I do scm_catch(SCM_BOOL_T, entry2, handler);

<rlb>You can see many examples of that in libguile.

<euouae>so the 'real' entry is entry2

<rlb>git grep sym_dynwind_begin, etc.

<euouae>isn't scm_catch() the way to go with handling errors?

<rlb>well, that's for dynamic-wind

<rlb>i.e. if you need to guard a resource release.

<rlb>etc.

<euouae>there's no resources in that C example but yeah

<rlb>you certainly can't use guile from a thread that's not in "guile mode".

<rlb>"bad things will happen"

<euouae>not trying to do that

<euouae>I'm just saying that the thunk interface is very awkward on the C side

<euouae>because it's hard to capture/pass data to thunks

<euouae>I don't see how at least

<euouae>In Guile you can capture stuff from the lexical environment in a thnk

<rlb>no (built in) closures in c

<rlb>right

<rlb>It's just generally easier if you can move things to scheme.

<euouae>well it could have scm_catch_1(tag, proc, data, handler)

<euouae>but it doesn't

<rlb>By default, I'd generally write a program with scheme as the top-level, and call out to C, if it's feasible.

<euouae>instead of SCM proc(void); it'd be SCM proc(void *); what am I missing?

<rlb>i.e. the load-extension bits you were messing with earlier.

<euouae>That's a different project

<euouae>Well I'm sure you know there's projects that are like what I'm describing, e.g. gdb

<euouae>gdb is not written in Guile with C bits, it's in C with Guile embedded language

<euouae>(also python) so it's a valid use-case

<rlb>sure

<rlb>make too

<euouae>Yeah make

<euouae>so what is the reason scm_catch_1() does not exist? Also, scm_catch() does not have any use inside guile source, I checked

<euouae>one annoyance with documentation: scm_c_catch() says

<euouae>"There are some specific versions of Guile’s original ‘catch’ and ‘with-throw-handler’ exception-handling primitives that are still widely used in C code."

<euouae>This sounds like it's out of fashion, but in fact scm_catch() calls scm_c_catch() directly, it's just a specialization.

<euouae>yeah so what I was looking for is scm_c_catch() and it does what I need. Alright then... moving on.

<euouae>I think I might send a patch to fix the docs there, since scm_c_catch() is not "out of fashion" or anything of the sort despite what that doc passage above suggests

<rlb>I don't really know the history there.

<euouae>It's not a matter of history, the docs are not as precise as they should be

<euouae>They conflate how Guile's exceptions evolved with the C API (which did not evolve)

<rlb>In terms of closures, you could also have a scheme side function to do the capturing, if it's "regular" enough, i.e. scm_call... a function defined in scheme like (define (make-handler (...) (lambda (ex) ...))), returning a handler that can refer to all the args.

<rlb>call that to get the handler you want to pass to scm_catch (if I recall how scm_catch works correctly)

<euouae>what about my second question?

<euouae>is C stuff marked with SCM_API public or not?

<rlb>In general I think SCM_API should mean public, so perhaps just missing from the docs, though I'm not the authority.

<euouae>okay; good to know

<euouae>What happens if I need to call scm_* functions inside my scm_c_catch() handler?

<euouae>e.g. I have SCM str = scm_symbol_to_string(key); size_t len = 0; char *p = scm_to_stringn(str, &len, "ascii", SCM_FAILED_CONVERSION_QUESTION_MARK);

<euouae>I use that to find the description of the error that occurred

<euouae>(it's the KEY argument to `throw')

<euouae>I'm wondering if it's no-go and instead I need to communicate the error with the `void *data` parameter which can then attempt to print the error with another scm_c_catch()...

<euouae>I did it that way. Seems to be the right approach.

<ArneBab>ieure: In Hyphanet we use Gradle, because it can do integrity checks on dependencies. Maven only gained that capability two years ago. But I can’t say I enjoy gradle. At work I used Maven, and it’s OK, but I prefer makefiles ☺

<ArneBab>(OK is not good, but when people know it well, the details matter less, and for work I also made my peace with it. It’s just annoying for packaging in Guix)

<dsmith>rlb, Yeah, I removed the paste. As far as I can tell, it's not needed.

<dsmith>Was just an experiment

<dsmith>euouae, It's complicated, but check out guile-sqlite again. Scheme calling C calling Scheme which might throw an error, and bubbling that back up through catch handlers.

<dsmith>And yes there is some history in how exception handling has changed over the years

<humm>ACTION notices guile-sqlite missing -avoid-version for libtool

<humm>O all ye Guile people: if your shared objects have as consumer only their own package and if the exact file name of the sharee object is important, shared object versioning is unhelpful

<euouae>dsmith: I sent some doc patches that fix some issues I uncovered

<euouae>in particular <https://codeberg.org/guile/guile/pulls/14> IMHO makes it much clearer what the role of scm_c_catch() in the C API is -- it's central rather than deprecated as the text currently implies

<dsmith>Bah. Debian Trixie doesn't have sqlite v2

<dsmith>humm, Thanks for the -avoid-version tip

<euouae>never upgrade debian until 3-6 months late

<dsmith>euouae, Trixie is 13. It's not even in 11 (yeah, it's been a while since I touched it)

<euouae>:/

<dsmith>The bot is running on Debian 9

<dsmith>!uname

<sneek>Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l GNU/Linux

<dsmith>!version

<dsmith>sneek, version

<sneek>Sneeky bot running on Guile version 3.0.3 using bobot++ release.2.3.1-6-a463-dirty

<rlb>dsmith: I recently learned there are debian containers for "all" versions of debian now, e.g. "podman run -it docker.io/debian/trixie" or more surprisingly "podman run -it docker.io/debian/eol:bo". I've not used containers much yet, but with that and podman, I might start, for some testing, etc.

<euouae>Here it is, my magnum opus <https://codeberg.org/annoyingusername/guile-project-skeletons-autotools>

<euouae>ping ArneBab ^ in case you are interested

<euouae>It's 6 example Guile projects, all the scenaria I could come up with, in both flat and recursive autoconf/automake

<euouae>Hopefully this can help people get their projects going and not having to deal with autopain anymore

<rlb>dsmith: where did you end up with respect to the test harness?

<dsmith>rlb, At this point, no changes!

<rlb>you mean it started "working right" for you as is?

<dsmith>rlb, It doesn't "short circuit" anymore. Was I just imagining it? Did the changes you pushed made it different?

<rlb>I imagine it still short circuits for say an (exit 2) at the top-level in foo.test?

<dsmith>rlb, yes. I always get a summary at the end. Made some fake tests that report all the different results.

<rlb>right, but with an explicit (exit 2) you don't, or you do get the summary?

<rlb>I'd have assumed the former.

<rlb>The changes we figured out should avoid some short-circuits, i.e. the ones due to broken reporter invocations.

<rlb>(since those should be fixed)

<dsmith>Now the make *does* stop with an error 2 after reporting the summary, if unexpected things happen

<rlb>here, an (exit 2) just after the define module in posix.test short-circuits and prints no summary with "make -j5 check".

<dsmith>Hmm. Let me try an explicit (exit 2) in a .test

<dsmith>AH. ok

<rlb>That's what I'd expect -- to avoid that, we'd need some additional fanciness (e.g. maybe a modal guile-test, etc.).

<rlb>I think.

<dsmith>So here is that looking-at-MFLAGS thing: https://bpa.st/FBTQ

<rlb>But you could also argue that errors like that are truly exceptional, and that we should just make sure our tests and/or test lib functions only allow exceptions to make it to the top level for actually broken/unexpected cases, where a short-circut is fine.

<dsmith>Not sure if that works at the moment.

<dsmith>Right

<rlb>what are the semantics there -- does the parallel test harness use -S or something?

<dsmith>An unexpected failure, or an unexpected pass should not short-circuit, IMO

<rlb>ACTION looks up -S

<dsmith>-S canccles a -K

<dsmith>-k

<rlb>Do you mean all unexpected failures, including that top-level (exit 2), or are you using "unexpected failure" in the test-harness xfail sense?

<euouae>what harnesses?

<ArneBab>euouae: nice! Thank you!

<rlb> https://www.gnu.org/software/automake/manual/html_node/Parallel-Test-Harness.html

<dsmith>rlb, I would think a broken testing infrastructure should halt the make. But individual tests that pass,fail,skip, etc. should not.

<euouae>rlb: I think in the link I gave above the harness is parallel, no?

<euouae>I used this test driver too <https://codeberg.org/annoyingusername/guile-project-skeletons-autotools/src/branch/main/recursive/blueberry/build-aux/test-driver.scm> that I snagged from some other GPL project

<euouae>I haven't yet demystified it, but I'm happy it shows me colors on `make check` and I get test reports

<rlb>euouae: dunno, but from the --trs-file arg, looks like an automake driver.

<euouae>oh that's definitely what it is

<euouae>I know that much

<rlb>dsmith: OK, sure, then it could be we just eventually want further enhancements to the test-suite lib and/or srfi-64 functions to recast some additional exceptions as errors.

<rlb>But for now, hopefully we've fixed your original, definitely broken test infrastructure issue.

<rlb>old: regarding https://debbugs.gnu.org/79415 -- the argument is that if tmpfile() does the typical thing, creating the file and then unlinking it, and if cloexec isn't set, then it won't actually be "gone" until all the children exit too if the original process doesn't explicitly close the port?

<old>yes

<old>the file descriptor are kept opened under the childs

<rlb>OK, well seems right to me.

<rlb>after looking at posix, etc.

<rlb>If/when I merge it, would you mind if I condense the comments a bit?

<rlb>(Can always find the elaborated rationale via git blame -> commit message, etc.)

<rlb>perhaps something like "/* F_DUPFD_CLOEXEC, not dup(2), so we still delete at process exit */"

<dsmith>I'm wondering if that dup/cloexec fix will make some other mysterious bugs go away...

IRC channel logs

2025-09-10.log