FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Gentoo > Gentoo Development

 
 
LinkBack Thread Tools
 
Old 09-01-2012, 06:15 PM
Zac Medico
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On 09/01/2012 09:00 AM, Ciaran McCreesh wrote:
> On Fri, 31 Aug 2012 18:45:59 -0700
> Zac Medico <zmedico@gentoo.org> wrote:
>> On 08/31/2012 04:07 PM, Ciaran McCreesh wrote:
>>> On Fri, 31 Aug 2012 16:03:25 -0700
>>> Zac Medico <zmedico@gentoo.org> wrote:
>>>>> runtime-switchable USE flags for optional dependencies o.O? It
>>>>> sounds like using a spoon to eat spaghetti to me.
>>>>
>>>> All suggested deps are not equal, so USE flags give you the
>>>> ability to pick and choose the ones that you want.
>>>
>>> So does --take / --ignore with suggested dependencies, with the
>>> added advantage that suggested packages don't end up being brought
>>> in without user request just because a user has a particular use
>>> flag enabled globally.
>>
>> If the USE flags have ambiguous meanings doesn't that mean that
>> they've been poorly named?
>
> It's not like that. It's that in practice, suggestions are mostly for a
> particular specific feature (such as git-send-email support), not for a
> general concept (such as email in general).
>
> It also defeats the point of suggestions, if they're not made visible.
> For users, suggestions should look like suggestions, and they should
> be able to see them easily.

This sounds more like a user-interface issue than a problem with
runtime-switchable USE flags (GLEP 62). The nice thing about
runtime-switchable USE flags is that makes it possible to allow users to
unify all of their optional dependency choices in their USE flag settings.

You can still implement a --take / --ignore mechanism while allowing the
use of runtime-switchable USE conditionals in SDEPEND. It's simply a
matter of ignoring the USE conditionals and instead using your --take /
--ignore mechanism to select atoms.
--
Thanks,
Zac
 
Old 09-01-2012, 06:28 PM
Ciaran McCreesh
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Sat, 01 Sep 2012 11:15:16 -0700
Zac Medico <zmedico@gentoo.org> wrote:
> This sounds more like a user-interface issue than a problem with
> runtime-switchable USE flags (GLEP 62). The nice thing about
> runtime-switchable USE flags is that makes it possible to allow users
> to unify all of their optional dependency choices in their USE flag
> settings.

The nice thing about GLEP 62 is that no-one has implemented it and tried
it with lots of packages and a bunch of users, thus figuring out just
how much of a pain in the ass getting this right is... Right now we're
debating the merits of a tried and tested solution versus an entirely
hypothetical idea.

If you really think unification is an advantage, you could treat
exheres-style suggestion names as a special USE_EXPAND group. But
practical experience suggests that suggestions *shouldn't* be unified,
and that the way to make the feature useful to users is to get the user
to explicitly accept or reject suggestions, and to make suggestions look
like suggestions.

--
Ciaran McCreesh
 
Old 09-05-2012, 12:06 AM
"Jorge Manuel B. S. Vicetto"
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 31-08-2012 20:46, Ciaran McCreesh wrote:

<snip>

> Also, we're getting rather a lot of *DEPEND variables here... If
> we're making people make major changes to their deps, which for
> HDEPEND we definitely would be, then the "it's expensive since
> people would have to redo their deps" argument against a combined
> DEPENDENCIES variable goes out of the window, so we should rethink
> that too.

I have to agree with Ciaran, instead of multiplying DEPEND variables,
it's probably time we move to a single DEPENDENCIES variable.

- --
Regards,

Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBAgAGBQJQRpeVAAoJEC8ZTXQF1qEP/UgQALd+7oqAODQA5bXdyqV+Qix+
mDN66c/6UO4VS2dyhfCEyA3osJzFS4u6mIuR7uFpXoKXGGs+MYdl7EG9C 0k48zUu
YLCDD56oyk6wACxBk7EHWVql1rvFoFemMUw5YUVq71w3FU9hrp Bi/DXKsoAlCRyw
4B2p6t8p6efll3vzbcz7M0LZseiox4GBTFCrtxR5zwgvx3b0gK vgU1Pv+AT3SBQK
J3IOxb09GSLCJKo56+iDHGuS5RwBBmdWP9l3+AdbjR2LoQ05f8 o8a7/geg1Qqg/Z
gVVSo4WDN2kIDJOvCBuXuo95a0KKFt/zUgfwjsqe02fRu2mDiWAju4L6vk2WE316
4yfMULI6HrVUk3ra+O4ZW7eoOuRvPVDpr4vyCVetFe4bx+zmlo/CmzOg/2teMyoc
rlMvOigR/4D+wxX7mbw/0fwZ5tVUbZ2pkdEhKetlpDe+xbWY0LhaczKdizwF7BrT
d+BeazPGWBP/muY0s3VDu3KV/3TRS0tME8GRsDevA9nCfA2plU0ZmmZnTB69tLc+
/dgdexHhc3IuA5eMObwOfSK6r9Jozlrv09TDvb6kHXm+0kqhV/W/aaS1qT4Bjlxd
psMjf9lSJHLcXuhtOz9OW4qmhp4BGCA8Rgeoq25Yw8E2eH0abv DbHR5U7u1hEpnQ
j6rJ0fZ27tfbMecd5i8b
=Zv/I
-----END PGP SIGNATURE-----
 
Old 09-05-2012, 07:19 AM
Fabio Erculiani
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, Sep 5, 2012 at 2:06 AM, Jorge Manuel B. S. Vicetto
<jmbsvicetto@gentoo.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 31-08-2012 20:46, Ciaran McCreesh wrote:
>
> <snip>
>
>> Also, we're getting rather a lot of *DEPEND variables here... If
>> we're making people make major changes to their deps, which for
>> HDEPEND we definitely would be, then the "it's expensive since
>> people would have to redo their deps" argument against a combined
>> DEPENDENCIES variable goes out of the window, so we should rethink
>> that too.
>
> I have to agree with Ciaran, instead of multiplying DEPEND variables,
> it's probably time we move to a single DEPENDENCIES variable.

So, let's say that I only want to apply a filter function against the
buildtime dependencies, in that case I'd need to parse *all* the
dependencies anyway?
The complexity would become:
O((b + r + p) * P)
b = amount of buildtime dependencies
r = amount of runtime dependencies
p = amount of post-dependencies
P = amount of packages i need to apply the filter to

Instead of just:
O(b * P)

It sounds like a good "dis-optimization". Some pkgs have really long
list of *DEPEND.

>
> - --
> Regards,
>
> Jorge Vicetto (jmbsvicetto) - jmbsvicetto at gentoo dot org
> Gentoo- forums / Userrel / Devrel / KDE / Elections / RelEng
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.19 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJQRpeVAAoJEC8ZTXQF1qEP/UgQALd+7oqAODQA5bXdyqV+Qix+
> mDN66c/6UO4VS2dyhfCEyA3osJzFS4u6mIuR7uFpXoKXGGs+MYdl7EG9C 0k48zUu
> YLCDD56oyk6wACxBk7EHWVql1rvFoFemMUw5YUVq71w3FU9hrp Bi/DXKsoAlCRyw
> 4B2p6t8p6efll3vzbcz7M0LZseiox4GBTFCrtxR5zwgvx3b0gK vgU1Pv+AT3SBQK
> J3IOxb09GSLCJKo56+iDHGuS5RwBBmdWP9l3+AdbjR2LoQ05f8 o8a7/geg1Qqg/Z
> gVVSo4WDN2kIDJOvCBuXuo95a0KKFt/zUgfwjsqe02fRu2mDiWAju4L6vk2WE316
> 4yfMULI6HrVUk3ra+O4ZW7eoOuRvPVDpr4vyCVetFe4bx+zmlo/CmzOg/2teMyoc
> rlMvOigR/4D+wxX7mbw/0fwZ5tVUbZ2pkdEhKetlpDe+xbWY0LhaczKdizwF7BrT
> d+BeazPGWBP/muY0s3VDu3KV/3TRS0tME8GRsDevA9nCfA2plU0ZmmZnTB69tLc+
> /dgdexHhc3IuA5eMObwOfSK6r9Jozlrv09TDvb6kHXm+0kqhV/W/aaS1qT4Bjlxd
> psMjf9lSJHLcXuhtOz9OW4qmhp4BGCA8Rgeoq25Yw8E2eH0abv DbHR5U7u1hEpnQ
> j6rJ0fZ27tfbMecd5i8b
> =Zv/I
> -----END PGP SIGNATURE-----
>



--
Fabio Erculiani
 
Old 09-05-2012, 07:27 AM
Ciaran McCreesh
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, 5 Sep 2012 09:19:45 +0200
Fabio Erculiani <lxnay@gentoo.org> wrote:
> So, let's say that I only want to apply a filter function against the
> buildtime dependencies, in that case I'd need to parse *all* the
> dependencies anyway?

Yes, and? If your dependency parser's time isn't "so tiny it makes
absolutely no difference compared to the filesystem access time needed
to get the metadata in the first place" then you're doing something
severely wrong.

And if we are going the "parser time" route, then given the heavy
intersection between build and run dependencies, the overall amount of
data to be processed in the common case that all dependencies are
required is smaller with unified DEPENDENCIES.

--
Ciaran McCreesh
 
Old 09-05-2012, 10:44 AM
Rich Freeman
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, Sep 5, 2012 at 3:19 AM, Fabio Erculiani <lxnay@gentoo.org> wrote:
> The complexity would become:
> O((b + r + p) * P)
> b = amount of buildtime dependencies
> r = amount of runtime dependencies
> p = amount of post-dependencies
> P = amount of packages i need to apply the filter to
>
> Instead of just:
> O(b * P)

Well, actually, in both cases the complexity is O(n), assuming you
only need to make a constant number of passes through the deps per
package.

The whole point of O notation is that it is about how it scales, not
how long it takes. An O(n) algorithm can actually be slower than an
O(n^n) algorithm even on a large dataset. However, the key is that at
some point if the dataset gets large enough the O(n) algorithm will
always become faster.

I tend to agree with Cirian though - the time for some code to run
through the dependencies array and do something isn't going to be very
high. If a piece of code has to do it many times there is nothing
that says the package manager can't index it.

Rich
 
Old 09-05-2012, 11:23 AM
Fabio Erculiani
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, Sep 5, 2012 at 12:44 PM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Sep 5, 2012 at 3:19 AM, Fabio Erculiani <lxnay@gentoo.org> wrote:
>> The complexity would become:
>> O((b + r + p) * P)
>> b = amount of buildtime dependencies
>> r = amount of runtime dependencies
>> p = amount of post-dependencies
>> P = amount of packages i need to apply the filter to
>>
>> Instead of just:
>> O(b * P)
>
> Well, actually, in both cases the complexity is O(n), assuming you
> only need to make a constant number of passes through the deps per
> package.
>
> The whole point of O notation is that it is about how it scales, not
> how long it takes. An O(n) algorithm can actually be slower than an
> O(n^n) algorithm even on a large dataset. However, the key is that at
> some point if the dataset gets large enough the O(n) algorithm will
> always become faster.
>
> I tend to agree with Cirian though - the time for some code to run
> through the dependencies array and do something isn't going to be very
> high. If a piece of code has to do it many times there is nothing
> that says the package manager can't index it.

I don't want to diverge (again) from the main topic, but I think that
you're just oversimplifying it.
If you consider parsing an ebuild something hidden behind a lot of
abstraction layers, O(n) vs O(n/2) is a big difference, even if both,
normalized, are still O(n). And I would never design an API which
assumes that O(n/2) equals to O(n), because you don't know how that is
going to be used in upper layers, today, tomorrow and in 5 years.

>
> Rich
>



--
Fabio Erculiani
 
Old 09-05-2012, 11:27 AM
Ciaran McCreesh
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, 5 Sep 2012 13:23:19 +0200
Fabio Erculiani <lxnay@gentoo.org> wrote:
> If you consider parsing an ebuild something hidden behind a lot of
> abstraction layers, O(n) vs O(n/2) is a big difference, even if both,
> normalized, are still O(n). And I would never design an API which
> assumes that O(n/2) equals to O(n), because you don't know how that is
> going to be used in upper layers, today, tomorrow and in 5 years.

Uhm. O(n) == O(n/2). Anything assuming they're different is just wrong.

--
Ciaran McCreesh
 
Old 09-05-2012, 12:46 PM
Rich Freeman
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, Sep 5, 2012 at 7:27 AM, Ciaran McCreesh
<ciaran.mccreesh@googlemail.com> wrote:
> Uhm. O(n) == O(n/2). Anything assuming they're different is just wrong.

We're basically debating definitions. O notation is used to indicate
how algorithms scale and nobody uses O(n/2) and such as a result.

An algorithm that is twice as slow is still twice as slow. That might
or might not matter. However, this isn't the domain where O notation
is used. You use O notation when your algorithm takes 30 seconds to
run and you want to know what happens with the dataset doubles 3000
times. It generally doesn't matter if the result is that it will take
1 trillion years to operate or 2 trillion years. You care more about
whether it will take minutes, hours, weeks, years, or whatever.

I can't really think of any practical examples where multiplying the
time to parse a list of maybe 50 items vs 5 lists of 10 items is going
to make that big of a difference. They're just lines in a text file -
your CPU can compare a few billions characters per second. Sure, if
you add 75 layers of abstraction you might be able to find just the
right point where a factor of 5 is going to make it intolerable but a
factor of 1 is almost acceptable, but go ahead and add/remove a few
layers and suddenly it is all fine or all horrible anyway. That is a
bit contrived. That's why everybody ignores constant factors in O
notation anyway.

Rich
 
Old 09-05-2012, 01:28 PM
Alexis Ballier
 
Default HDEPEND (host dependencies for cross-compilation) for EAPI 5?

On Wed, 5 Sep 2012 08:46:13 -0400
Rich Freeman <rich0@gentoo.org> wrote:

> On Wed, Sep 5, 2012 at 7:27 AM, Ciaran McCreesh
> <ciaran.mccreesh@googlemail.com> wrote:
> > Uhm. O(n) == O(n/2). Anything assuming they're different is just
> > wrong.
>
> We're basically debating definitions. O notation is used to indicate
> how algorithms scale and nobody uses O(n/2) and such as a result.
>
> An algorithm that is twice as slow is still twice as slow. That might
> or might not matter. However, this isn't the domain where O notation
> is used. You use O notation when your algorithm takes 30 seconds to
> run and you want to know what happens with the dataset doubles 3000
> times. It generally doesn't matter if the result is that it will take
> 1 trillion years to operate or 2 trillion years. You care more about
> whether it will take minutes, hours, weeks, years, or whatever.
>
> I can't really think of any practical examples where multiplying the
> time to parse a list of maybe 50 items vs 5 lists of 10 items is going
> to make that big of a difference. They're just lines in a text file -
> your CPU can compare a few billions characters per second. Sure, if
> you add 75 layers of abstraction you might be able to find just the
> right point where a factor of 5 is going to make it intolerable but a
> factor of 1 is almost acceptable, but go ahead and add/remove a few
> layers and suddenly it is all fine or all horrible anyway. That is a
> bit contrived. That's why everybody ignores constant factors in O
> notation anyway.

ewww, t_n=O(n) means 'there exists a constant C such that t_n <= C n';
it is just nonsensical to talk about O(n) vs O(n/2): take 2C instead
of C. If you care about the constant C then dont talk about O(). Measure
it in terms of CPU cycles for example, but then it becomes dependent on
a lot of things (compiler, hardware, etc.). However, it can be proved
that (with a sane implementation) all these differences scale only by a
constant factor between two implementations; this is why, when you talk
about algorithms and not execution time on a given hardware, the O()
asymptotic estimations are the ones that make sense. O() does not say
anything about execution time, but give a good idea of how your
algorithm will scale in the future: a O(n) algorithm will be able to
process twice as much data in the same time when your hardware will be
twice as fast, a O(2^n) one will be able to process only one more.

A.
 

Thread Tools




All times are GMT. The time now is 03:55 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org