process on
>>> how to fix it. (Embed it to the manual.)
>>
>> The “Submitting Patches” section mentions closure size specifically. Is
>> there anything you think we should add there?
>
> It does not give much details, e.g. the ones that Julien mentioned.
> Also I don't think
an output, plus the
> closure size of all of its references (the definition is recursive).
Yes. So the Data Service could pick that info from narinfo files and
have per-package pages with a graph showing the closure/self size
evolution—IOW, ‘guix size’ over time.
Doable, but easier said than done!
Ludo’.
Hi,
Tobias Geerinckx-Rice skribis:
> Ludovic Courtès 写道：
>> Nope (‘inherit’ is purely syntactic, it doesn’t “live on” at run
>> time.)
>> What would it buy you, though?
>
> In addition to what Gábor mentioned, ‘guix refresh -l’ rebuild numbers
> can be dangerously misleading when inheritance is
Ludovic Courtès 写道：
Nope (‘inherit’ is purely syntactic, it doesn’t “live on” at run
time.)
What would it buy you, though?
In addition to what Gábor mentioned, ‘guix refresh -l’ rebuild
numbers can be dangerously misleading when inheritance is
involved.
Would this not be useful
Le 10 février 2020 03:09:57 GMT-05:00, Pierre Neidhardt a
écrit :
>zimoun writes:
>
>>> Say FOO has BAR in its closure, but not in the explicit inputs, how
>can
>>> I figure out which of the indirect inputs drags BAR in?
>>
>> I do not understand what you are looking for, but there is already:
On Mon, 10 Feb 2020 at 09:09, Pierre Neidhardt wrote:
>
> zimoun writes:
> > I do not understand what you are looking for, but there is already:
> >
> >guix graph -t reverse-package
> > guix graph -t reverse-bag
>
> Yes, but this produces way too big a graph, which was my point below.
Pierre Neidhardt writes:
> zimoun writes:
>
>> You could propose such feature to the Guix Data Service.
>> For example, on this webpage [1], the history of all the Git package
>> in Guix is shown. The closure size could be reported.
>>
>> [1]
zimoun writes:
>> Say FOO has BAR in its closure, but not in the explicit inputs, how can
>> I figure out which of the indirect inputs drags BAR in?
>
> I do not understand what you are looking for, but there is already:
>
>guix graph -t reverse-package
> guix graph -t reverse-bag
Yes,
nodes to hide them and all
> >> their children.
> >
> > ‘guix size’ is key here: it’s a profiler, exactly what we need IMO.
> > WDYT?
>
> Maybe I'm missing something, but in general I think that guix size only
> gives a birds eye view and does not
ing Patches” section mentions closure size specifically. Is
> there anything you think we should add there?
It does not give much details, e.g. the ones that Julien mentioned.
Also I don't think `guix size' is enough, see below.
>> - Improve the tooling. In my experience, guix graph i
Hi,
On Fri, 7 Feb 2020 at 23:31, Gábor Boskovits wrote:
> Ludovic Courtès ezt írta (időpont: 2020. febr. 7., Pén 22:36):
>> zimoun skribis:
>> >> The thing is, I think it’s something that requires constant care, every
>> >> time we add a package or modify an existing one. It’s very easy to
Hello Ludo,
Ludovic Courtès ezt írta (időpont: 2020. febr. 7., Pén
22:36):
> Hi,
>
> zimoun skribis:
>
> >> The thing is, I think it’s something that requires constant care, every
> >> time we add a package or modify an existing one. It’s very easy to lose
> >> benefits that had been
Hi,
zimoun skribis:
>> The thing is, I think it’s something that requires constant care, every
>> time we add a package or modify an existing one. It’s very easy to lose
>> benefits that had been previously obtained through hard work!
>
> I have never thought, neither tried but is it possible
hide them and all
> > their children.
>
> ‘guix size’ is key here: it’s a profiler, exactly what we need IMO.
> WDYT?
It is hard to examine the graph with "guix size".
Sometimes, I am doing: "guix graph foo | grep"; especially with 'bag'
and friends. (I do not want
anything you think we should add there?
> - Improve the tooling. In my experience, guix graph is quickly unusable
> with a high number of nodes. Maybe d3.js could be leveraged to add a
> filtering system, or a way to click on nodes to hide them and all
> their children.
‘guix
Le 4 février 2020 11:22:10 GMT-05:00, zimoun a écrit
:
>Hi Pierre,
>
>On Tue, 4 Feb 2020 at 16:57, Pierre Neidhardt
>wrote:
>
>> Shall we start a work group to fix the issue?
>
>One of the obvious bottleneck is the documentation. Some packages come
>with a full doc and sometimes with Pandoc
Hi Pierre,
On Tue, 4 Feb 2020 at 16:57, Pierre Neidhardt wrote:
> Shall we start a work group to fix the issue?
One of the obvious bottleneck is the documentation. Some packages come
with a full doc and sometimes with Pandoc and/or TeX stuff. In
general, it is required but when speaking about
Hi!
At FOSDEM 2020 Ludovic explained to the world why Guix is better than
other container formats (to put it mildly ;p).
Possibly the only counter-argument to "Guix > Snap / Flatpak" is
the size of the Guix containers.
I also talked to Mathieu who has been working relentlessly on
With commit a8f996c, a new --map-file=foo.png option can be used to
create a PNG like the one below, thanks to Andy’s Guile-Charting. Maybe
not the optimal way to visualize this, but still quite useful IMO.
Comments welcome!
Ludo’.
Federico Beffa be...@ieee.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
Nice!
Here the output shows 3 columns next to store items. The first
column, labeled “total”, shows the size in mebibytes (MiB) of the
typo: mebibytes
No that’s intended:
On Thu, Jun 18, 2015 at 2:24 PM, Ludovic Courtès l...@gnu.org wrote:
Federico Beffa be...@ieee.org skribis:
l...@gnu.org (Ludovic Courtès) writes:
Nice!
Here the output shows 3 columns next to store items. The first
column, labeled “total”, shows the size in mebibytes (MiB) of the
Hello!
Commit fcc58db adds a new ‘guix size’ command (I’ve copied the
documentation below.)
I encourage you to give it a try, it’s quite insightful. For instance:
--8---cut here---start-8---
$ ./pre-inst-env guix size ardour
substitute: updating list
l...@gnu.org (Ludovic Courtès) writes:
Nice!
Here the output shows 3 columns next to store items. The first
column, labeled “total”, shows the size in mebibytes (MiB) of the
typo: mebibytes
Regards,
Fede
Federico Beffa be...@ieee.org writes:
l...@gnu.org (Ludovic Courtès) writes:
Nice!
Here the output shows 3 columns next to store items. The first
column, labeled “total”, shows the size in mebibytes (MiB) of the
typo: mebibytes
Regards,
Fede
https://en.wikipedia.org/wiki/Mebibyte
24 matches
Mail list logo
