Hi,

Ludovic Courtès <ludo@gnu.org> skribis:
> Arne Babenhauserheide <arne_bab@web.de> skribis:
Offtopic: I love reading Esperanto here!
>> Ludovic Courtès <ludo@gnu.org> writes:

>>>   guix environment --ad-hoc jupyter python-ipython python-ipykernel -n

>> How exactly did you run the derivation?

> If you run the command above, it’ll list
> /gnu/store/…-manual-database.drv.  So you can just run:
>
>   guix build /gnu/store/…-manual-database.drv
>
> or:
>
>   guix build /gnu/store/…-manual-database.drv --check
>
> if it had already been built before.

Somehow I can’t get guix to actually run my changed code with this
command, so I’m not sure I tested the right thing.

What is the clean approach to run the profile.scm from git?

>>> On a SSD and with a hot cache, on my 4-core laptop, I get 74s with
>>> ‘master’, and 53s with this patch.
>>
>> I’m using a machine with 6 physical cores, hyperthreading, and an NVMe
>> M.2 disk, so it is likely that it would not be disk-bound for me at 4
>> threads.
>
> The result may be entirely different with a spinning disk.  :-)
>
> I’m not saying we should optimize for spinning disks, just that what you
> see is at one end of the spectrum.

That’s right, yes.

> But anyway, another issue is that we would need to honor
> ‘parallel-job-count’, which means using ‘n-par-map’, which doesn’t use
> futures.

Ouch, yes. That’s an issue … 

Thank you for bringing it up!

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken