On 7/2/09 3:43 PM, H. Langos wrote:
Could you check if it still does what it was is supposed to do? :-)
It looks fine, and my iPod still works, and didn't even have to reboot
it for it to show my 30640 files. :-)
I merged the low_ram branch into master yesterday evening but I wanted
to
G'day J,
Thank you very much for the examples and the insights.
It's good to know that I'm not completely off with my
novice's views of code style.
On Thu, Jul 02, 2009 at 10:30:04AM +1000, Jacinta Richardson wrote:
This practice is called named arguments and is a great way of calling
Hi Richard,
On Wed, Jul 01, 2009 at 04:57:14PM +0200, Richard van den Berg wrote:
On Wed, July 1, 2009 16:13, Jacinta Richardson wrote:
I suspect it's a matter of laziness.
I claim ignorance. I didn't know there was a fundamental difference
between the two ways of calling a subroutine.
Hi Richard,
On Fri, Jun 19, 2009 at 08:26:30PM +0200, Richard van den Berg wrote:
On 6/19/09 11:07 AM, H. Langos wrote:
Maybe the merge code should only be active if your memory saving feature is
active?
Here is the new patch that does just that. I love git, it's super fast. :-)
One
H. Langos wrote:
One more question:
Why did you use
resetxml;
instead of
resetxml();
?
I know the former doesn't pass an empty @_ array for the called sub but
passes the existing argument list. But you don't do anything with @_ in
resetxml(). So why bother passing the current arguments
On Wed, July 1, 2009 16:13, Jacinta Richardson wrote:
I imagine that the author didn't intend that effect of calling the
subroutine that way.
Absolutely right.
I suspect it's a matter of laziness.
I claim ignorance. I didn't know there was a fundamental difference
between the two ways of
H. Langos wrote:
Speaking of readability and code style. Is there a consensus among the
experienced and community-minded folks in regard to the passing of
parameters to subs? Especially when writing subs in modules?
I nowadays prefer to pass parameters as one hashref
subname({foo = x,
On Fri, June 19, 2009 10:27, H. Langos wrote:
Good thing you mention tunes2pod. Please try to make your changes
optional.
Something like a --merge option to express that you are going to merge
iTunesDB and GNUtunesDB.xml
I thought about this myself, but we would have to make this a parameter
On Fri, June 19, 2009 11:07, H. Langos wrote:
Maybe the merge code should only be active if your memory saving feature
is active?
That makes a lot of sense, and it easy to implement. :-) I'll post another
patch tonight.
Cheers,
Richard
___
On 6/19/09 11:07 AM, H. Langos wrote:
Maybe the merge code should only be active if your memory saving feature is
active?
Here is the new patch that does just that. I love git, it's super fast. :-)
Cheers,
Richard
diff --git a/doc/gnupodrc.example b/doc/gnupodrc.example
index
Hi Richard,
On Wed, Jun 17, 2009 at 10:00:16PM +0200, Richard van den Berg wrote:
On 6/17/09 10:41 AM, H. Langos wrote:
- $mktunes-WriteItunesDB;
+ $mktunes-WriteItunesDB(Keep=$opts{'keepattr'});
Shouldn't that be :
$mktunes-WriteItunesDB( {Keep = $opts{'keepattr'}} );
It
On Thu, June 18, 2009 08:22, H. Langos wrote:
Did I mention before that I hate perl? :-)
In about every other post to this list. ;-) To me, the things about perl
that I sometimes hate let me very quickly write code that does what I want
at other times. When I started with the tunes2pod code I
Hi Richard,
On Tue, Jun 16, 2009 at 10:05:16PM +0200, Richard van den Berg wrote:
On 6/16/09 12:44 AM, H. Langos wrote:
My first idea now is to
strip the iTunesDB of the stuff that is optional.
Thanks again for the suggestion, that worked really well. I can now see
all my 30415 songs!
On Wed, June 17, 2009 10:41, H. Langos wrote:
The code and the naming of variables should express
that this is a workaround, not the default. I.e the keepattr would
better be named low_ram_attr or shrink_itunes_db or minimal_attr.
I'll fix that. I was already thinkign you wouldn't like the
On Wed, Jun 17, 2009 at 12:11:06PM +0200, Richard van den Berg wrote:
On Wed, June 17, 2009 10:41, H. Langos wrote:
Your mhod skipping code should only be active if that option is set in
your .gnupodrc or given as command line switch.
That is the case now. If keppattr is not set, @keep is
On 6/17/09 10:41 AM, H. Langos wrote:
- $mktunes-WriteItunesDB;
+ $mktunes-WriteItunesDB(Keep=$opts{'keepattr'});
Shouldn't that be :
$mktunes-WriteItunesDB( {Keep = $opts{'keepattr'}} );
It turns out it depends on your usage. The form I chose you can used as:
Patch 2 bound the iTunesDB and GNUtunes.xml on id. Since gnupod
regenerates the id field on every mktunes run, other software might do
the same. So I figured binding them on the path attribute would be a
better idea.
Cheers,
Richard
? .gnupod_version
? Makefile
? autom4te.cache
? config.log
Hi Richard,
On Tue, Jun 16, 2009 at 11:46:47AM +0200, Richard van den Berg wrote:
On Tue, June 16, 2009 00:44, H. Langos wrote:
My first idea now is to
strip the iTunesDB of the stuff that is optional.
Absolutely. I was thinking the same thing. More along the lines of setting
all titles,
On 6/16/09 12:44 AM, H. Langos wrote:
My first idea now is to
strip the iTunesDB of the stuff that is optional.
Thanks again for the suggestion, that worked really well. I can now see
all my 30415 songs! Whoohoo. :-)
These are the mhods that gnupod supports:
my %mhod_id = ( title=1,
On Fri, Jun 12, 2009 at 04:33:43PM +0200, Richard van den Berg wrote:
On Fri, June 12, 2009 15:21, Heinrich Langos wrote:
I'd like to have a chain like this: ok - ok - broken
Here is such a chain:
http://richard.vdberg.org/gnupod/ok/11181/iTunesDB
The results I got today were not consistent with yesterday (ok iTunesDBs
would now be not ok). I learned a lot about the binary format, and
figured out that by messing with the ArtworkDB (for the performance
tests) the dbid_1 numbers were now out of whack. However, restoring the
whole
Hi Richard,
On Thu, Jun 11, 2009 at 11:15:38PM +0200, Richard van den Berg wrote:
On 11-6-2009 22:46, Richard van den Berg wrote:
Maybe it doesn't have to do with the iTunesDB size but a limit of the
internal structures?
I do think it is a limitation somewhere in iTunesDB. I tried to
22 matches
Mail list logo
