Re: [Bug-gnupod] artwork support apparently (but not really) broken on ubuntu
Hi Chris, On Thu, Jul 02, 2009 at 07:03:21AM +0200, chris.com wrote: > > Hello Henrik, > > The behaviour is not "intended" as you so nicely put it. > It is/was a bug and has been corrected in the 6.4.9-9 version. > From the ChangeLog: > > 2009-03-01 6.4.9-9 Cristy > * Convert returns MagickFalse for the -version option (reference > http://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=13230). Thats good news. So I'll let this pass and I'll not invest any time into working around it. > I think "conversion -version" is a correct way to check whether > ImageMagick is installed. > autoconf contains a macro AC_PATH_PROG that checks the existence of the > executable > But there is no predefined macro as far as I can see that checks whether > a particular version is installed Every program reports its version in a different format, so there is no standard way of checking for a version. At least no way that would work on different Linux distributions, let alone different Unix versions. > However I haven't been able to figure out what to do with the IMAGIC > variable. > It seems indeed unused elsewhere. > I'll try to figure that out next Don't bother.. it realy isn't used anywhere else. There's only the check and the output in "configure.ac" which is translated by "autoconf" into the "configure" script. But if we ever decide to improve the error handling or even decide to change the code according to autoconf's findings, it's good to know that we should be able to rely on "convert -version". Thank you very much for the research. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
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
> subroutines because it removes the confusion of which order the arguments need
> to go in. It also allows you to set and use defaults, for example:
I hadn't looked at it from the angle of providing defaults. But it looks
very intuitive and robust. Until now I had defaults assigned one by one
to "my" variables in sub routines and then optionally overwritten by the
arguments passed in the $args_ref. Assigning them in one go is way more
elegant.
> state %defaults = ( # 5.10+ only, else "my %defaults"
> foo => 'a', # or a closure
> bar => 'b',
> );
"state" seems more or less equivalent to "static" in C. Nice feature.
> $args_ref = { %defaults, %{$args_ref} };
I hadn't tought of that way to merge hashes. I wonder if it is usable for
subroutines that are called very often or if "unrolling" both hashes and
merging them this way is slower than conditionally assigning one by one.
my $foo = 'a';
my $bar = 'b';
$foo = $args_ref->{foo} if defined($args_ref->{foo});
My first guess would be that merging the hashes is faster for bigger numbers
of arguments but slower if you are dealing with only a couple of arguments.
Anyway, I'll try both when the occasion arises and see what the profiler
has to say.
> It's not discussed in perlstyle, and perlsub because the maintainers of those
> files haven't really decided on a one-true way, or because they've been too
> lazy
> to write it... Damian Conway wrote bunch of good ideas about good Perl style
> in
> his book called Perl Best Practices, which is what most people point to when
> they talk about Perl style now. These practices have been turned into
> requirements by the Perl::Critic system too, so you can get automated feedback
> on your code quality by using the Perl::Critic programs.
Thats a very good pointer. I'll try and see what Perl::Critic has to say about
the code in gnupod.
>
> Hope this helps.
>
A lot! Thank you very much.
cheers
-henrik
___
Bug-gnupod mailing list
Bug-gnupod@nongnu.org
http://lists.nongnu.org/mailman/listinfo/bug-gnupod
Re: [Bug-gnupod] mktunes.pl creates corrupt iTunesDB ?
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. Thanks for the explanation. > > > I'd suggest applying the patch with this tidied up as > > appropriate. Done. Could you check if it still does what it was is supposed to do? :-) I merged the low_ram branch into master yesterday evening but I wanted to sleep over it before commiting. Here are the changes that actually happend to master: git diff 94462eb 25a4d8b or http://git.savannah.gnu.org/cgit/gnupod.git/commit/?id=25a4d8ba6a080589577abc20db7587a18b1cade9 It was a bit tricky as the previous merges on low_ram made parts of the changes in master look outdated eventhough they were more current than than in low_ram. I hope I didn't mess it up completely. :-) It may be better to avoid merges among branches. rather -o---o---o---o---o---o---o master \ \ \ / / o o---o---o / topic a \ / o---o---o---o---o topic b than -o---o---o---o---o---o---o master \ \ \ / / o o---o---o / topic a \ \ / o---o---o---o---o topic b Also, if you need to merge several branches into one, I suggest the usage of octopus merges instead of merging step by step. But I'm no git guru. So don't take my word for it. cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
[Bug-gnupod] The docs are dead! Long live the docs! ;-)
Hi there, Some minutes ago the doc branch was merged. Man pages are gone. Now there's the pod style documentation within the perl files. Not all of them but if somebody writes up an "undocument" mock up, there's an include mechanism that will allow to add it with a single line to the script files that don't have their own documentation yet. Hopefully this will be easier to maintain. Apart from that, there is the info documentation that I don't really know how to maintain. Volunteers welcome :-) While working on the documentation, I took a look at the build system and decided that it should be more modular than just "make install". Currently you can't really test your changes unless you install the whole thing. Now there is a rudimentary "build" step where scripts, modules and documentation are rendered into a separate directory where you can run them before you decide to call "make install" as root. It is rudimentary in many regards but it's a start. I want to get the functions of tools/gnupod_install.pl step by step out of there and into the Makefile/configure script. "gnupod_install.pl" should only prepare the files, do some substitutions and leave the real installation to standard posix tools like "cp" and "chmod" or maybe "install". (BTW: Is "install" a posix tool?) Along the way I want to a) make it configurable if you keep the .pl extension on the installed perl scripts (and their man pages) or if you'd rather strip them. (I'd rather strip the .pl but that's a matter of taste and I will not fight about it.) b) make the target directory for the gnupod modules configurable via ./configure (I don't like the way gnupod messes around in /etc to install its modules.) c) Insert your wish here ;-) cheers -henrik ___ Bug-gnupod mailing list Bug-gnupod@nongnu.org http://lists.nongnu.org/mailman/listinfo/bug-gnupod
