Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Nicolò Balzarotti
Pierre Neidhardt writes: > Another option is plzip (parallel Lzip, an official part of Lzip). Wouldn't that mean that this will become a problem when we'll have parallel downloads (and sometimes parallel decompression will happen)?

Re: guix pack file enumerator?

2020-12-15 Thread Nicolò Balzarotti
> This reminds me of the much-loved "agentless" model of software > deployment as practiced by Ansible. > If Guix could deploy to any machine with Guile + sshd that would be a > pretty compelling story. Nice! This reminds me of nixos-infect [1]. But I think we don't even need guile, as we can gui

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Nicolò Balzarotti
Pierre Neidhardt writes: > > What do you mean? > If you download multiple files at a time, you might end up decompressing them simultaneously. Plzip won't help then on a dual core machine, where you might end up being cpu bound again then. Is this right? If it is, reducing the overall cpu usage

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Pierre Neidhardt
Nicolò Balzarotti writes: > If you download multiple files at a time, you might end up decompressing > them simultaneously. Plzip won't help then on a dual core machine, > where you might end up being cpu bound again then. Is this right? > > If it is, reducing the overall cpu usage seems to be a

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Pierre Neidhardt
Here the "pipeline" could be a CSP channel. Not sure what the term is in Guile. -- Pierre Neidhardt https://ambrevar.xyz/ signature.asc Description: PGP signature

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Jonathan Brielmaier
Super interesting findings! On 14.12.20 23:20, Ludovic Courtès wrote: 2. Use Zstd like all the cool kids since it seems to have a much higher decompression speed: . 630 MB/s on ungoogled-chromium on my laptop. Woow. Not only decompression speed

Word order in Guix l10n

2020-12-15 Thread Zhu Zihao
Hi, Guix users! Currently I'm putting my energy into Guix l10n(zh_CN). However, there's a serious flaw in current implementation of l10n. AFAFIK, Guix use format in (ice-9 format) to format the the template string return by `G_`. The template string of (ice-9 format) looks similar to the format

Re: Finding versions of packages

2020-12-15 Thread Ludovic Courtès
Hi, zimoun skribis: > On Mon, 14 Dec 2020 at 11:38, Ludovic Courtès wrote: > >> However, it might give the false idea that users can pick >> package versions independently (as in: I want esbuild X, GCC Y, and Go >> Z), which is not really the case: packages are interrelated. > > Someone tried t

Re: Specifying dependencies in manifest

2020-12-15 Thread Ludovic Courtès
zimoun skribis: > Maybe this function could go to the module imported by manifest. WDYT? Yes, that could be a utility procedure in (guix packages). (bag-direct-inputs (package->bag p)) may not be far from it… Ludo’.

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Ludovic Courtès
Hi, Nicolò Balzarotti skribis: > I guess this benchmark follows the distri talk, doesn't it? :) Yes, that and my own quest for optimization opportunities. :-) > File size with zstd vs zstd -9 vs current lzip: > - 71M uc.nar.lz > - 87M uc.nar.zst-9 > - 97M uc.nar.zst-default > >> Where to go f

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Ludovic Courtès
Hi, Pierre Neidhardt skribis: > Another option is plzip (parallel Lzip, an official part of Lzip). > >> decompression of ungoogled-chromium from the LAN completes in 2.4s for >> gzip vs. 7.1s for lzip. On a low-end ARMv7 device, also on the LAN, I >> get 32s (gzip) vs. 53s (lzip). > > With four

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Nicolò Balzarotti
Ludovic Courtès writes: > A lot in what sense? In terms of bandwidth usage, right? Yep, I think most of mobile data plans are still limited. Even if here in Italy is easy to get 50Gb+/monthly, I think it's not the same worldwide.

Re: Word order in Guix l10n

2020-12-15 Thread Julien Lepiller
Even when translating to French, I sometimes feel the need to change word order, but I end up finding a slightly unnatural way to preserve the order of arguments. I don't have an example at hand though. I don't know enough about guile to know how best to implement that (or if that exists alread

Re: Finding versions of packages

2020-12-15 Thread zimoun
Hi, On Tue, 15 Dec 2020 at 12:16, Ludovic Courtès wrote: > However, doing such composition on a per-package basis and as the > default way of composing packages is inefficient and, more importantly, > the resulting compositions may not work. A package written for Python 2 > may not work with Py

Re: Word order in Guix l10n

2020-12-15 Thread Arun Isaac
Hi Zhu Zihao, I faced the same problem while working on the Tamil localization. I used the ~* argument jumping supported by (ice-9 format) to work around this. So, for the message "could not find bootstrap binary '~a' for system '~a'", you could do something like "无法找到用于引导 ~1@* 系统的二进制文件 ~0@*" ~

Re: Word order in Guix l10n

2020-12-15 Thread Zhu Zihao
Arun Isaac writes: > Hi Zhu Zihao, > > I faced the same problem while working on the Tamil localization. I used > the ~* argument jumping supported by (ice-9 format) to work around > this. So, for the message "could not find bootstrap binary '~a' for > system '~a'", you could do something like >

Re: [outreachy] Walk through the Git history (guix git {authenticate,log})

2020-12-15 Thread Magali
Hello, I've been tweaking this piece of code below, trying to adapt it so that it could get the latest commit into the commit list too, but I haven't had success. On 12/12/2020 09:24, zimoun wrote: > --8<---cut here---start->8--- > $ guix repl > GNU Guile 3.0.4

Re: When substitute download + decompression is CPU-bound

2020-12-15 Thread Joshua Branson
Looking on the Zstandard website (https://facebook.github.io/zstd/), it mentions google's snappy compression library (https://github.com/google/snappy). Snappy has some fairly good benchmarks too: Compressor Ratio Compression Decompress. zstd2.884 500 MB/s1660 M