[Aptitude-devel] aptitude-qt VCS usage and code review

[Piotr Galiszewski]

2010/7/9 Daniel Burrows <dburrows at google.com>:
> On Thu, Jul 8, 2010 at 5:25 PM, Piotr Galiszewski <piotr at galiszewski.pl>
> wrote:
>>
>> Great ;) . I have already learned a lot and I know that every
>> experiences are important. I was only little nervous about gsoc
>> timelines, cause I am far behind my original schedule :/
>
>   Well, from my (selfish) point of view, I'd rather have you focus on
> quality over quantity.  That's because if you write good code, even
> a small amount, I can use it.  If you churn out a ton of code that's
> not up to snuff, it'll probably just end up being dropped and the
> whole exercise will be a waste of time for both of us.
>

OK. I will do my best to merge this two things. With repository format
you suggested it will be much easier :)

>>
>> >   Is package_manager some sort of a global storage pool of Packages,
>> > then?  Could you maybe call it package_pool instead to avoid naming
>> > confusion?
>>
>> yes it is. I will call it that
>>
>> >   I don't really understand the whole purpose of the Package object.
>> > Is the goal here to save memory and CPU time by only copying package
>> > information into QStrings once per package?
>> >
>>
>> For model I need an array of packages. And as the number of packages
>> is really big I have decided that custom class with lazy loading could
>> be a good idea. And my tests show that it is true (especially in case
>> of showing description on the list)
>
>   The other frontends don't have to do this, or perhaps they just are
> slow and could benefit from your work here!  Either way, I'd like to dig
> into
> this a little more.
>   These are the ways of retrieving package information from a package
> that spring to mind immediately:
>   1) Fully eager: as soon as the Package is created, copy all the values
> from
>       the PkgIterator over into the Package object (I believe the GTK+ code
>       effectively does this).
>   2) Fully lazy: the first time a member of Package is accessed, copy all
> the
>       values from the PkgIterator into it (what the current Qt code does).
>   3) Memberwise lazy without caching: just store a PkgIterator; when a
>       component of the Package is requested, return the corresponding
>       member of the PkgIterator (what the curses frontend does).
>   4) Memberwise lazy with caching: when a component of the Package is
>       requested, copy the corresponding member of the PkgIterator into the
>       Package object and return it (I don't think any aptitude code does
> this).
>   Which of these did you try?  Do you have numbers showing how big an
> improvement you saw?  Could you try some of the others to compare?

I tried second and third points. Do not have any hard numbers. My
assumptions were only based on feeling and time of response from GUI.
I do not know how to provide numbers, but I will try. The speed was
the easiest to observe during sorting and searching packages. On the
other hand, I think that returning of the most members will be short.
Only description loading and maybe something more is time consuming. I
will experiment with this

>   Is there any way to lose the QFoo types in Package?  I'm not sure we
> want to reuse it directly, but there might be a way to solve this problem
> more generally, as long as it doesn't require the use of Qt-specific (or
> GTK-specific) types.

Yes. There are only QStrings and QStringLists. std::string and
std::list could also be used. Moreover, I think that this class
requires much more thinking. Maybe it will be better do extend
PackageInformation class (and rename this to package_information or
package ;) ) ? There is also one more problem I am not entirely sure
hot is should be solved. What should be done after cache updating?
Packages could be changed so the state of package class also should be
updated. Maybe package objects should be stored in map/hashtable in
packages_pool instead of simple list?

>   Daniel

-- 
Regards
Piotr Galiszewski