Sergio Pastor Pérez

@Mehrad@fosstodon.org @futurile@mastodon.social that doesn't sound right. You may have some problem there, it should be very fast

@Mehrad@fosstodon.org @futurile@mastodon.social There is not much you can do with that regard. You should definitely pin the commits of your channels, that way you won't be rebuilding things every time a channel updates. Once the things are cached everything should load immediately.

If you are using Emacs I recommend you check out this fork I made of envrc.el it allows you to load per-buffer environments asynchronously. My use case is precisely not blocking the editor with guix time-machine ....

https://codeberg.org/pastor/ben.el

@Mehrad@fosstodon.org To be clear, setting the cores flag -c is for limiting the resources, not for granting more, each derivation is built with the cores set to all the available ones.

It's for situations where you may want to spread the load between a few derivations. For example, if you are building gcc@12 and gcc@13, you may want to do guix build -c 25 -M 2 ..., given you have enough cores available.

I'm assuming that GCC caps the builds at 24 cores (I don't recall if that's true).

@Mehrad@fosstodon.org That's right.

@Mehrad@fosstodon.org By default Guix tries to feed the guix build systems with the number of cores available. Generally, most derivations will be built using all your available cores. The thing is that the underlying build systems will or will not make an efficient use of those cores. For example, the `gnu-build-system` will take all your cores and pass them to `make`. If `make` does not make an efficient use of those cores, you can use the `-M ` flag to build multiple derivations in parallel.

@baleine@piaille.fr I liked that you used your space to denounce the bitter side of today's society.

@gnu_slash_gabber@social.tchncs.de @cwebber@social.coop no no, I'm just saying that that is an option, if you require that use case. But we expect most people to use BLUE as a package.

@wingo@mastodon.social @cwebber@social.coop The talk focuses more on introducing the BLUE framework. And there is only a small mention of the backtraces improvements. But we are very interested in collaborating with the Guile community to help improve the developer experience of Guile.

@wingo@mastodon.social @cwebber@social.coop Yes! You can check it out here: https://fosdem.org/2026/schedule/event/3A7VGM-blue

@cwebber@social.coop @wingo@mastodon.social For those outside of the loop. This is how Guile backtraces look when using BLUE's enhancements.

All the credit should goes to my friend and wizard Olivier who implemented this backtraces enhancements!

@cwebber@social.coop this is some of the goodies I was saying Spritely would appreciate! What do you think, would Goblins benefit from the backtraces improvements? If there is enough interest we can get this into core Guile, so everyone benefits from the improvements. It's unfortunate that @wingo@mastodon.social didn't get to see the presentation, so I think he missed the backtraces improvements BLUE made.

@cwebber@social.coop Also, we didn't have time to cover this in the presentation. But BLUE supports embedding itself into any project, this is why we decided to license it under LGPL. The best example of a project which uses BLUE embedded, is BLUE itself. You just need to set the `BLUE_EMBEDDED` environment variable to point to the BLUE sources and add the `/blue` directory to your `PATH`. You can see an example on how this is done in the `.envrc` file under the BLUE sources.

@cwebber@social.coop As you can imagine upstreaming the BLUE package is cake, as the only dependency is Guile. I can arrange that if there are already interested users.

What I think you will find even more impressive, is that you don't need any of that time-machine to see how easy it is to bootstrap BLUE.

Try the following in the BLUE sources, you only need Guile: mkdir build && cd build && ../bootstrap && ./pre-inst-env blue configure --prefix=/tmp/blue-install -- build -- install -- installcheck

@leeg@fosstodon.org @cwebber@social.coop we are very happy with the amount of excitement the community is showing. We plan to have extensive manuals and examples. We just need to find more free time to write them down!

@zimoun@social.sciences.re @janneke@todon.nl @cwebber@social.coop hello Simon! Thanks for the paper recommendation, I actually heard about that paper before but I didn't get the time to read it.