Hi Ludo,
On Sun, 12 Jan 2020 at 00:29, Ludovic Courtès wrote:
> zimoun skribis:
>
> > So knowing where the cycles are could help to transform the DaG (not
> > fully acyclic yet) to a DAG. :-)
>
> Unfortunately, the module graph necessarily contains cycles. The only
> way to avoid them would
Hi!
Christopher Baines skribis:
> Ludovic Courtès writes:
[...]
>> Another less elegant option would be to resort to a service (Data
>> Service or Cuirass) that would map a Guix commit to its .drv, and then
>> fetch that .drv from substitute servers and build it.
>
> I haven't got around to
Ludovic Courtès writes:
> BTW, there’s also the “Compute Guix derivation” phase that could be sped
> up, and that’s mostly independent of Guile.
>
> Things that could help include: “recursive Nix”¹ (the Guix derivation
> would itself be the result of a derivation, thus subject to
>
Hello,
zimoun skribis:
> So knowing where the cycles are could help to transform the DaG (not
> fully acyclic yet) to a DAG. :-)
Unfortunately, the module graph necessarily contains cycles. The only
way to avoid them would be to have exactly one module per package, given
that the package
zimoun writes:
> On Wed, 8 Jan 2020 at 22:50, Ludovic Courtès wrote:
>> Ricardo Wurmus skribis:
>
>> > On the other hand: this would need to be an ongoing effort. Newly
>> > introduced packages or even new features might create complex module
>> > cycles. It sounds tedious to keep track of
Hi Gábor,
On Fri, 10 Jan 2020 at 13:42, Gábor Boskovits wrote:
> > The modules graph (DAG) is already available. :-)
>
> The main problem here is that the modules do not form a DAG.
> There are circular dependencies between the modules.
> If those were not, then modular build would be possible,
Hello zimoun,
zimoun ezt írta (időpont: 2020. jan. 10., P, 13:10):
>
> Hi Gábor,
>
> Thank you for the explanations.
>
> Below, I am thinking loudly. :-)
>
> On Tue, 7 Jan 2020 at 21:14, Gábor Boskovits wrote:
>
> > > > Gábor once suggested an iterative approach of identifying the most
> > > >
Hi Ludo,
On Wed, 8 Jan 2020 at 22:50, Ludovic Courtès wrote:
> Ricardo Wurmus skribis:
> > On the other hand: this would need to be an ongoing effort. Newly
> > introduced packages or even new features might create complex module
> > cycles. It sounds tedious to keep track of this and to
Hi Gábor,
Thank you for the explanations.
Below, I am thinking loudly. :-)
On Tue, 7 Jan 2020 at 21:14, Gábor Boskovits wrote:
> > > Gábor once suggested an iterative approach of identifying the most
> > > important nodes in the package graph that should be moved to their own
> > > modules,
BTW, there’s also the “Compute Guix derivation” phase that could be sped
up, and that’s mostly independent of Guile.
Things that could help include: “recursive Nix”¹ (the Guix derivation
would itself be the result of a derivation, thus subject to
substitutes), or something equivalent without
Hello!
Ricardo Wurmus skribis:
> On the other hand: this would need to be an ongoing effort. Newly
> introduced packages or even new features might create complex module
> cycles. It sounds tedious to keep track of this and to enforce
> boundaries.
Yes, I think this is a dead end: glibc
Hello,
zimoun ezt írta (időpont: 2020. jan. 7., K, 19:38):
>
> Hi Ricardo,
>
> On Sun, 5 Jan 2020 at 21:38, Ricardo Wurmus wrote:
>
> > Gábor once suggested an iterative approach of identifying the most
> > important nodes in the package graph that should be moved to their own
> > modules, so
Hi Ricardo,
On Sun, 5 Jan 2020 at 21:38, Ricardo Wurmus wrote:
> Gábor once suggested an iterative approach of identifying the most
> important nodes in the package graph that should be moved to their own
> modules, so that we would end up with a package graph that looks less
> like a hair
Hi,
Just a couple notes here regarding the concrete questions. I'm sure
there are good solutions but I don't know what they are yet!
On Sun 05 Jan 2020 21:37, Ricardo Wurmus writes:
> Or could we improve compilation
> times by disabling optimizations?
I think Guix does this already; see
Hi Guix,
thanks to Ludo’s excellent work on “guix pull”, updating Guix has become
a lot faster than in the old days. With build farm support one usually
only needs to wait a little while to be able to download all parts of
an up-to-date Guix.
Unfortunately, changes to the repository invalidate
15 matches
Mail list logo
