[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-gnupod] new branches
From: |
H. Langos |
Subject: |
Re: [Bug-gnupod] new branches |
Date: |
Thu, 25 Jun 2009 11:45:28 +0200 |
User-agent: |
Mutt/1.5.18 (2008-05-17) |
On Wed, Jun 24, 2009 at 11:20:06PM +0200, Richard van den Berg wrote:
> On 6/24/09 10:58 PM, H. Langos wrote:
>> I guess the do_not_stretch_artwork feature is harmless. I'll merge
>> that into master.
>>
>
> Ok, cool. I still want to add a selectable color in gnupodrc for that
> when I have some time.
Sure. That would be nice. Just put that in your do_not_stretch_artwork
branch and I will merge it again into master later.
>> The decrement_plid feature would be nice to include into master
>
> The reason I keep it around is that it seemed to make a difference in
> RAM usage the first time I tried it out..
>
>> Instead of decrementing from MAXINT, I would suggest to make the sequence
>> counter jump to the next 2^n value before the playlists are added?
>> This would not rise the values too high and still in most cases it would
>> avoid the massive shifting of IDs.
>>
>
> Why not just always start it at 2^30 ? This get's rid of the
> signed/unsigned issue and still leaves room for 1 billion songs and
> playlists. (Or 2^20 with leaves room for 1 million songs.) And you have
> the added benefit of easily comparable iTunesDB that contain a different
> number of songs or playlists, even if you cross a 2^n boundary.
Do you know how iTunes handles those IDs? In the iTunesDB that I looked at
just now, It seems to interleave the IDs for mhit, mhia, and other elements
that need one. Still they are all pretty small values < 2^16.
Did anybody ever test itunes with more than 2^16 files? I mean for all we
know the ID field could be two bytes and those next two bytes could be just
plain zeros. ;-)
How about starting at 2^15 and jumping to the next 2^n in case we already
have more than 2^15 songs? Crossing of those 2^n boundaries gets really
rare from that point onwards.
I am a defensive driver on the road (i.e. I try to anticipate the mistakes
of others) and I'd like to say the same about my programming style. (Tough I
am still far from it.)
> Thanks for the help with git. I think I know enough of the basics now,
> but there's quite a few advanced features that still puzzle me. :-)
No worries. I also learn something new about git every day.
BTW: What do you think about the changes in hlangos/doc ? (Getting rid of the
separate man page files and integrating them as pod into the scripts.)
I am still not sure weather I should write a small preprocessor into
gnupod_install to merge the templates there (the same way as PERLBIN and
VERSION are merged there. Or rather create a separate make target that would
create the man pages before the install target.
I wonder whats easier to handle for package maintainers. I guess I'll
ask Raphael and Brian (the Debian package maintainers) about that.
cheers
-henrik