IRC channel logs

<daviid>sneek: later tell bootchk I have fixed the gi-array->scm, could you either git pull (devel branch) or subtitue the entire (g-golf gi utils) file with this version - https://paste.debian.net/1405587/ - run the make/make install danse, then run your plugin ... let me know (I did test 'manually', here - https://paste.debian.net/1405588/ - you can see that the instances are properly being retreived ... I'll add this test to the test suite

<daviid>asap ...

<sneek>Will do.

<daviid>sneek: later tell bootchk if it still fails, we'd need to investigate if the gimp array of instances is somehow malformed, or if there is a problem in the typelib def for the returned value or a bug in gi-argument->scm procedure, for arrays (always possible, but I'd be very surpried, as it passes all g-golf implemented gimarshalling array tests, and this means that the pointer passed to gi-array->scm has properly been either

<daviid>dereferenced or not, depending on the information provided by insecting the typelib for the arg or returned value)

<sneek>Got it.

<ArneBab>sam113101: I’m using Guile because I think that Scheme is the best option to investigate the limits of programming and how simple a programming language can be without sacrificing power. But elisp is common lisp tailored to building an editor and it’s better for that than Scheme, I think (correct datastructures for that). And I see people do great stuff with sbcl.

<humm>Trying to compile Guile HEAD, it seems to eat CPU and stop moving at “BOOTSTRAP(stage0) GUILEC ice-9/eval.go” and trying to run libguile/guile and interrupting it after a few seconds gives me this neat looking backtrace; is there anything immediately obviously wrong with it? Or do I just have to go digging where there may be a loop in the startup code? https://okturing.com/src/15873/body

<dsmith>Guile takes a LONG time to build. Give it at least 30 minutes

<humm>oof, alright

<dsmith>Building from a tarball is quicker as there are pre-compiled bootstrap files.

<humm>I see

<dsmith>It does go quicker after the first two .go files are built, as they are then used for the rest.

<dsmith>Think of it this way, all the slowness of the run times is removed and pushed into the build time...

<identity>it is compiling the fast compiler with a slow interpreter

<dsmith>The price you pay for very optimized compiled code is a more complicated and slow to build compiler

<humm>if I think of it that way, I’ll also have to think C compilers push even more slowness into build time and yet build time is faster over there

<dsmith>What identity said is really the correct reason. What I said is just a mental game to put up with slow build times.

<humm>I understand

<identity>humm: we have only so much people working on the bootstrap interpreter compared to the amount of people working on GCC, and the bootstrap interpreter is only used for bootstrap, as the name suggests

<humm>the reason I started trying to build from Git was to test if this little commit indeed does work as intended before opening a PR: https://codeberg.org/humm/guile/commit/d6ff03efdf6879b22331ea9f86e173518dc31865

<identity>or maybe not, but the point of the interpreter is to run the damn code, not make it run fast (this is the job of the compiler, and the JIT)

<dsmith>Other language implementations often require a previous version to build. Guile builds from scratch.

<humm>it’s good that Guile does it that way

<humm>ice-9/eval.go built \o/

<rlb>humm: yeah, you'll normally only have the long wait for the first build in any given git work tree.

<rlb>After that, it'll generally be fairly fast.

<rlb>Also if you have more than one core, "make -jCORE_COUNT" can help quite a bit.

<dsmith>The -j doesn

<dsmith>t help with that first eval.go though

<rlb>right

<rlb>But the rest is pricey too in stage0.

<dsmith>humm, So, how long did that take?

<humm>I think eval.go alone took like 40 minutes now

<rlb>humm, at least you're not m68k (I assume) -- https://buildd.debian.org/status/logs.php?pkg=guile-3.0&arch=m68k

<dsmith>Building guile on my old cobalt cube took all day.

<humm>hah

<dsmith>And then bobot++ took another day.

<dsmith>Was like a 512MHz mips

<humm>I’m on a very modern Intel(R) Core(TM) i7 CPU M 620 @ 2.67GHz

<rlb>I'd guess that might take about an hour?

<rlb>(4 core 8th gen intel takes about 30m)

<rlb>iirc

<dsmith>./configure can take a long time, and can't be parallel (no -j )

<humm>configure did take longer than most configure scripts I run into

<dsmith>I wonder if there are some things in there that can be trimmed out

<humm>I’m almost certain there are a bunch

<rlb>Hah, I wonder if you could pre-seed a clone via an archive. Checkout the same tag, untar the archive on top, then checkout whatever you want.

<humm>checking for stdio.h... (cached) yes

<humm>at least my config.site has a bunch of things already, like this one, but still

<rlb>Offhand I think the cached checks should be pretty fast.

<rlb>It's the others...

<old>If Guile was bootstaping itself with an older version, it could be build with Blue :-)

<humm>rlb: stdio.h is only cached because OpenBSD has a neat config.site ready to use

<dsmith>Hmm. There is a GUILE_FOR_BUILD env var, IIRC.

<rlb>Oh, I thought it was from a redundant check in guile's configure.ac.

<dsmith>humm, Are you on obsd?

<humm>yes

<dsmith>Cool!

<dsmith>I recently submitted some changes to get fbsd working better and passing tests. Curious how obsd will fare

<dsmith>by-passing for the most part..

<humm>JIT doesn’t work out of the box because mmap(WRITE | EXEC) is prohibited and I don’t care enough to allow guile and the mounted file system to allow that or to figure out a patch

<humm>and all the libraries that use shared objects (including guile-readline) miss -avoid-version in their libtool options; that doesn’t work on OpenBSD; I’m slowly submitting a few patches for that

<dsmith>So with other things that do JIT, how do they handle that? First just WRITE and then later just EXEC ?

<humm>I think so, yes

<rlb>I'd still love to have a bsd tested in ci if we had some reasonable way to do it.

<dsmith>rlb, Is guile doing ci on codeberg?

<rlb>I don't think it is now, and don't know of plans.

<rlb>civodul: is that something we might want? ^

<lechner>old / thanks for posting this some time ago. it helped me a lot! https://lists.gnu.org/r/guile-devel/2022-09/msg00036.html

<rlb>Also, I don't know what codeberg's CI is like -- i.e. does it allow public access to the logs, etc.

<rlb>dsmith: though last time I looked, I think codeberg only supports one flavor (maybe an ubuntu?).

<mwette>btw, guile/README does not mention needed gperf

<humm>gmake: *** [Makefile:2065: all] Error 2

<humm> 260m25.93s real 424m48.66s user 11m13.53s system

<humm>(it’s a makeinfo error)

<humm>(was an old makeinfo version)

<humm>Guile built \o/

<dsmith>humm, Yey!

<dsmith>humm, Does it pass gmake check ?

<humm>let’s see

<dsmith>(new and improved, supports the -j option)

<rlb>ACTION guesses -j2 or -j3 for the tests for a two core machine...

<ieure>3 probably. Generally +20% concurrency per core, lets you do CPU work while other things are doing IO.

<dsmith>I usually do nice make -j$(nproc) ...

<dsmith>Keeps the system snapppy

<rlb>When I'm testing anything that fsyncs a lot, also "nice ionice eatmydata ..." :)

<rlb>(assuming you're not actually testing fsync...)

<rlb>cf. pg_ctl start -o -F ...

<rlb>*no not use outside testing* :)

IRC channel logs

2025-11-11.log