Re: Performance of computing cross derivations
Ludovic Courtès writes: > Hi, > > Christopher Baines skribis: > >> When asked by the data service, it seems to take Guix around 3 minutes >> to compute cross derivations for all packages (to a single >> target). Here's a simple script that replicates this: ... > One idiom that defeats caching is: > > (define (make-me-a-package x y z) > (package > …)) > > Such a procedure returns a fresh package every time it’s called, > preventing caching from happening (because cache entries are compared > with ‘eq?’). That typically leads to lower hit rates. > > Anyway, lots of words to say that I don’t see anything immediately > obvious with cross-compilation, yet I wouldn’t be surprised if some of > these cache-defeating idioms were used because we’ve payed less > attention to this. I've got a feeling that performance has got worse since I looked at this originally, I've finally got around to having a further look. I spent some time looking at various metrics, but it was most useful to just write the cache keys of various types to files and have a read. The cross-base module was causing many issues, as all but one of the procedures there produced new package records each time. There is also make-rust-sysroot which showed up. I've sent some patches as #68266 to add memoization to avoid this, and that seems to speed things up. Looking at other things in the cache, I think there are some issues with file-append and local-file. The use of file-append in svn-fetch and local-file in the lower procedure in the python build system both bloat the cache for example, although I'm less sure about how to address these cases. One thing I am sure about though, is that these problems will come back. Maybe we could add some reporting in to Guix to look through the cache at the keys, lower them all and check for equivalence. That way it should be possible to automate saying that having [1] in the cache several thousand times is unhelpful. The data service could then run this reporting and store it. 1: # "/bin/svn"> signature.asc Description: PGP signature
Re: Suggestion for a guix shell feature.
Tried to use to antioxydant build system, I cannot seem to add it as a channel but was able to clone the repo and authenticate it manually.. then guix build -L . -f antioxidant-packages.scm fails to run with error, ice-9/eval.scm:223:20: In procedure proc: error: rust-sequoia-ipc-0.26: unbound variable hint: Did you forget a `use-modules' form? I think I am going to stick to adding libs to LD_LIBRARY_PATH manually as it works even though I know you said its wrong. -- Sent with Tuta; enjoy secure & ad-free emails: https://tuta.com Jan 3, 2024, 17:57 by maxim.courno...@gmail.com: > Hi, > > Apoorv writes: > >> OK, it was my bad I had an older copy of guix.scm file I was passing >> that, it didn't have cargo-build-system. But now I'm getting so many >> other errors related to cargo deps missing or version mismatch, I >> tried adding those deps spent like 1-2 hours but something dep was >> still missing or version mismatch, finally I gave up. I'm not sure how >> many deps I have to add like this.. this is getting way to complicated >> then it needs to be. >> > > cargo/rust is poorly integrated in Guix, as there's some impedance > mismatch between package handling by Guix and Cargo itself, which would > rather take care of it. > > I'd expect most Rust developpers using Guix only do so to provide > Rust/Cargo, and let Cargo take care of the rest. Otherwise you'd need > to replicate the pain the cargo-build-system goes through to make it > work. > > A more future-proof approach if you'd like to improve Rust integration > into Guix would be to continue integrating the 'antioxydant' build > system effort started by Maxime Devos [0], which doesn't rely on Cargo > to build Rust crates (and supports dynamic linking of Rust libraries, I > think?). > > [0] https://notabug.org/maximed/cargoless-rust-experiments > > -- > Thanks, > Maxim >
Re: Why is it acceptable to have digital-ocean-configuration in the Guix?
On 2024-01-04 14:22:48 -0500, Thompson, David wrote: > On Thu, Jan 4, 2024 at 5:34 AM Tomas Volf <~@wolfsden.cz> wrote: > > > > Greetings, > > > > I would like to inquire regarding digital-ocean-configuration type used for > > provisioning DigitalOcean Droplets. I do not understand why it is > > acceptable to > > have this type in the source code. Reading the Free GNU/Linux distributions > > criteria[0] I see this sentence (emphasis mine): > > > > > This means they will include, and *propose*, exclusively free software. > > > > As far as I know DigitalOcean Droplets are not free software (please > > correct me > > if I am wrong). I contemplated on this for a bit, and I do not understand > > why > > it is acceptable. > > > > Would someone be so kind to explain the reason to me? > > Perhaps this will help explain why you can't simply call a web service > nonfree: > https://www.gnu.org/philosophy/network-services-arent-free-or-nonfree.en.html Ah, thank you very much for the link. Interesting reading. One consequence I did not (until now) realize is that I could (in theory) implement a Free GNU/Linux distribution that would be tied into various APIs of (for example) AWS and require it to run. And, based on my reading, it would still qualify to be on the list. That is unexpected. > > To use a different example: Google doesn't publish the source code for > YouTube. Guix includes the free software yt-dlp program that can talk > to YouTube and download videos. Would you consider this a violation of > the FSDG? > > Guix also downloads a lot of source code from GitHub. Is this an issue? I did not consider these examples, because it did not even occur to me that it *could* be an issue. I guess the perceived difference came from the Droplets having their own dedicated place in the manual including their own type. My takeaway from this is that when I get around to implementing this for AWS and/or Azure, I can submit the patch. Thank you again and have a nice day, Tomas Volf -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors. signature.asc Description: PGP signature
