date:20050617

Eric Wilhelm [EMAIL PROTECTED] writes:

 You wouldn't say

   --foo --no-foo

 if you just meant

   --no-foo

 Would you?

I think the basic question is, what do you expect from a certain
combination of options and arguments. For example,

  --foo arg1 --no-foo arg2

This can be interpreted as:

  process arg1 and arg2 with $foo == 0
  process arg1 and arg2 with $foo == 1
  process arg1 with $foo == 1, and arg2 with $foo == 0
  process arg1, --no-foo and arg2 with $foo == 1

Even more exotic possibilities:

  process something with $foo == arg1 and $no_foo == arg2
  process arg2 with @foo == qw(--no-foo arg2)
  process something with @foo == qw(arg1 --no-foo arg2)
  and so on

As I wrote in an earlier message, there's no real standard on what
interpretation is correct, hence they all have a reason for being
there. And Getopt::Long handles all of them (and more). Too much
flexibility? Maybe. But where does the flexibility get in the way?

Using configuration options, most of the flexibility can be
controlled.

-- Johan

Re: RFC: Getopt::Modern

Eric Wilhelm [EMAIL PROTECTED] writes:

 Do you mean to say that 99% of the time (when --foo and --no-foo are 
 both present) that it is because somebody has an alias with a --foo 
 flag written into it?

Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition of the semantics?

-- Johan

Re: Failing Reports due to 3rd Party Software (was Fw: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0)

2005-06-17 Thread Randy Kobes

On Fri, 17 Jun 2005, imacat wrote:

[ ... ]
 From my personal experience dealing with GNU autoconf
 and automake, I think the module author should be
 responsible to specify what external executables,
 libraries, versions are required.  Then
 ExtUtils::MakeMaker can produce a certain error checking
 them before generating the Makefile, and CPANPLUS can then
 capture that error and know some external prerequisites
 failures.

For the problem of checking an external library, one might
want to consider something like the have_library() function
used by, eg, XML::LibXML::Common:
 http://search.cpan.org/src/PHISH/XML-LibXML-Common-0.13/Makefile.PL
This compiles some sample xs glue, and links against the
specified library, to see if the library is useable.

-- 
best regards,
randy

Re: Failing Reports due to 3rd Party Software (was Fw: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0)

2005-06-17 Thread Jos I. Boumans



On Jun 17, 2005, at 4:43 AM, imacat wrote:
I'm forwarding this whole thread to Jos Boumans (author of 
CPANPLUS),
Michael G Schwern (author of ExtUtils::MakeMaker) and the 
module-authors'

list.


Sorry, with several pages worth of top quoting, i have no idea what 
this thread is about, or what is

expected of me.

If there's a bug in any software i've published, please file a bug 
report against it.


If there's an opinion or advice you'd like, please phrase a question.

Thanks,

--

Jos Boumans

Suicide is our way of saying to God:
You can't fire me! I quit!

CPANPLUShttp://cpanplus.sf.net

Re: RFC: Getopt::Modern

Eric Wilhelm [EMAIL PROTECTED] writes:

 Ok, and maybe I showing my age here, but is *this* where the 
 negated-options thing comes from?  I.E. is this the historic (and 
 entire) reason for having the 'foo!' syntax in Getopt::Long?

No, it's because of a) defaults. Sometimes a flag is enabled by
default, sometimes its disabled by default. Having both the --foo and
--no-foo options it is always possible to exactly define what you want
the current invokation of the command to do, regardless of any default
settings. It's user-friendly redundancy.

And b) mixing options and arguments, where --foo arg1 --no-foo arg2
means that arg1 is processed with --foo and arg2 with --no-foo.

-- Johan

Re: Failing Reports due to 3rd Party Software (was Fw: Re: FAIL Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0)

On Fri, 17 Jun 2005 01:14:51 -0700
Michael G Schwern [EMAIL PROTECTED] wrote:
 On Fri, Jun 17, 2005 at 10:43:14AM +0800, imacat wrote:
 This is all a bit of a ramble.  Could we have an executive summary as to
 the point particularly in relation to MakeMaker, CPANPLUS and module authors
 in general?

It's not my question, isn't it?  I'm not writing XS modules.  I'm
just a poor CPAN tester offering my CPU, my bandwidth, my time testing
new modules and being accused by modules author for sending FAIL reports.

Forwarded by imacat [EMAIL PROTECTED]
--- Original Message ---
From:imacat [EMAIL PROTECTED]
To:  Perl CPAN Testers cpan-testers@perl.org
Date:Fri, 17 Jun 2005 09:42:37 +0800
Subject: Re: Failing Reports due to 3rd Party Software (was Fw: Re: FAIL 
Convert-Binary-C-0.59 MSWin32-x86-multi-thread 4.0)


On Thu, 16 Jun 2005 22:12:50 +0100
Barbie [EMAIL PROTECTED] wrote:
 However, the conversation thread brings up another issue that has been
 floating
 around for some time. External libraries and apps that are pertinent to a
 successful test suite, may not be available or installed on the smoke box. I
 agree with Robert and Imacat that these should be flagged, so that anyone
 looking at the cpan-testers web pages will know that there isn't a
 straightforward install involved. In my opinion that report should be
 something
 other than FAIL, UNKNOWN or NA, as those have specific meanings. To be
 honest
 I'm not really sure the 'PERL_IS_TOO_LOW' check should be an NA report
 either.
 There needs to some other report type that indicates the build could not
 continue due to external factors. Any visitors would then at least know
 that
 they need to read the README, at the very least, to see what extra software
 they
 need. As to what to call this other report I don't know. I've been thinking
 about this for over a year and still haven't thought of anything suitable.
 The
 closest I got was UNGRADED.

From my personal experience dealing with GNU autoconf and automake,
I think the module author should be responsible to specify what external
executables, libraries, versions are required.  Then ExtUtils::MakeMaker
can produce a certain error checking them before generating the Makefile,
and CPANPLUS can then capture that error and know some external
prerequisites failures.

I think I was wrong on this issue.  This is not only CPANPLUS's
responsibility.  ExtUtils::MakeMaker should return certain status or
message to notify CPANPLUS for that.  

- Original Message Ends 

--
Best regards,
imacat ^_*' [EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Woman's Voice News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug


pgprvuXFtPdJi.pgp
Description: PGP signature

Re: RFC: Getopt::Modern

Eric Wilhelm [EMAIL PROTECTED] writes:

 Please see this essay
 http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt

Nice piece of writing, but it contains several flaws. For example:

If your spouse tells you to get tuna and halibut, but not any
other fish, you would probably get in trouble if you returned
from the store with no fish, and yet this is what programmers seem
to expect from the following command-line:

  go_shop --fish tuna --fish halibut --no-fish

But the results should be the same as below:

  go_shop --no-fish --fish tuna --fish halibut

However, the equivalent of 

  go_shop --fish tuna --fish halibut --no-fish

is the spouse telling tuna and halibut, but no fish. Now, if my
spouse starts telling me things like that, I've got reasons to start
worrying about her mental health.

But the bottom line of your essay is that human logic is not computer
logic (which is true) and that programmers (and computer users) often
abide with computer logic instead of human logic. 

When my wife tells me to get tuna and halibut, but no fish, I'll ask
her what do you mean. As for the command line options, using

  go_shop --fish tuna --fish halibut --no-fish

should result in an error message like ambiguous use of conflicting
options or something. All other interpretations are, according to
human logic, wrong.

But then there's that nasty little fact that's called history: we've
done it according to computer logic for 50 years or so, and it is not
easy to break habits. I think for this reason the original GNU options
parser used a + prefix to indicate that this option was going to be
interpreted differently than ususal.

-- Johan

Re: RFC: Getopt::Modern

On Fri, 17 Jun 2005 10:57:26 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
 Eric Wilhelm [EMAIL PROTECTED] writes:
  Please see this essay
  http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt
 If your spouse tells you to get tuna and halibut, but not any
 other fish, you would probably get in trouble if you returned
 from the store with no fish, and yet this is what programmers seem
 to expect from the following command-line:
 
   go_shop --fish tuna --fish halibut --no-fish
 
 But the results should be the same as below:
 
   go_shop --no-fish --fish tuna --fish halibut

To Eric,

I did not notice the go_shop problem.  But I think it's trivial to
solve that with Getopt::Long:

my @conf_fishes = read_conf(fish);  # get qw(trout)
my @opt_fishes = qw();
my $opt_nofish = 0;
Getopt::Long::GetOptions(
  fish=s  = [EMAIL PROTECTED],
  no-fish = \$opt_nofish,
);
@conf_fishes = qw() if $opt_nofish;
my @fishes = (@conf_fishes, @opt_fishes);

Who said the variable to save the no-fish status has to be
revelant with the fish variable anyway?  If they are saved in
different variables, the order doesn't matter, does it?

--
Best regards,
imacat ^_*' [EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Woman's Voice News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug


pgpf9fwozK3Jp.pgp
Description: PGP signature

Re: RFC: Getopt::Modern

* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 01:35]:
 I dont understand. If there was no need to be able to say
 --foo --no-foo, then why do both exist?
 
 No, no, no.  Start over.
 
 1.  There is a need.
 2.  It doesn't matter what order the user gives the options in,
 the result should be the same.

Wait, why start over? Im asking what this need is. I want to
know which things we are trying to achieve. If we dont know
that, how will we know when we achieved them?

 Did you read the essay about why order doesn't matter?

I did now and I didnt see anything new that hasnt been
mentioned in this thread already.

First, to get the show stopper out of the way, your proposed
model is trivial to implement in terms of Getopt::Long.

my $verbosity = 5;

GetOptions(
'v|verbose'  = \( my $opt_verbinc = 0 ),
'no-verbose' = sub { $verbosity = 0 },
);

$verbosity += $opt_verbinc;
$verbosity = 10 if $verbosity  10;

Clear, self-documenting code.

Second, you are using a weird and unusual example to support your
arguments: a ranged variable option that is incremented using
binary switches.

The only case where Ive ever seen that model used is precisely
for the -v verbosity switch. The first I encountered it, I
thought it was strange. Of note that a program typically has only
one switch which behaves this way, and that Ive never seen
anyone write -vxyvjvkv rather than  -xyjk.

Thus, I posit that this model is wrong in most cases.

It seems that accumulative switches are all that you are really
talking about.

I therefore further posit that the switch you called
--no-verbose is a misnomer.

It should be called --start-verbose=0, which indeed should be
parsed in precedence order rather than command line order. --foo
--no-foo makes sense in mathematic terms, not in linguistic
ones. Certainly its not anywhere as obvious an expression of
your intent as something like --foo --start-foo=0 is.

This model is even easier to implement in terms of Getopt::Long.

GetOptions(
'v|verbose'   = \( my $opt_verbinc = 0 ),
'start-verbose=i' = \( my $opt_startverb = 5 ),
);

my $verbosity = $opt_startverb + $opt_verbinc;

And no, you cant tell what option comes from an alias and which
doesnt. Even if you could, that wouldnt cover cases like

my @cmd = qw( foo --bar --baz );
if( $something ) { system @cmd, qw( blah blah ) }
elsif( $other  ) { system @cmd, '--wibble', @wibble }
elsif( $whatev ) { system @cmd, '--wubble', @wibble }
else { system @cmd, qw( --no-bar blah blah ) }

What youre asking the --no-foo mechanism to do for you it
neither something its meant to do nor something its a good
literary choice for.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;

Re: Fw: Failing Reports due to 3rd Party Software...

2005-06-17 Thread Robert Rothenberg




On 17/06/2005 09:14 Michael G Schwern wrote:


This is all a bit of a ramble.  Could we have an executive summary as to
the point particularly in relation to MakeMaker, CPANPLUS and module authors
in general?


CPANPLUS issues FAIL reports when there is no C compiler, which irks
module authors who feel such reports make their module look bad.

Some feel that CPANPLUS should detect this and not send a report, others 
feel it should send a report, but with a different grade: NA or some new 
grade such as UNGRADED, since there are advantages to testing what a 
Build will do if there is no C compiler.


Another idea is to ExtUtils::MakeMaker or Module::Build to refuse to try 
and build a module if a C compiler is required (and update CPANPLUS to 
detect this).  This seems connected to the larger issue of NA reports 
when libraries or applications are missing.


I'm of the opinion that people who pay attention to test reports when 
deciding whether to use a module should be saavy enough to interpret 
them, but I'm probably wrong. Maybe a FAQ is needed for the testers web 
site that explains how to do this?


My own take is that these fails should be sent out anyway, but as NA 
reports.  Too many grade types can get confusing, but it should be 
feasible to analyze failure reports automatically to classify them:

 * Perl version too low
 * Unsupported operating system
 * Missing required libraries or applications
 * Missing compiler, linker or other utility needed for build
 * Other error during build

In other words, the meaning of NA should be it wasn't able to 
successfully build the software and get to the testing phase.


Rob

Re: RFC: Getopt::Modern



On Jun 16, 2005, at 10:33 PM, Ken Williams wrote:


For a counterexample, please see the -f and -i options to /bin/rm.  
Many people, myself included, have found it exceptionally useful that 
the final switch takes precedence, because then we can do things like 
alias ls ls -i and still be able to use the -f switch when we need 
to.


Er, not ls.  rm.  Gee, I thought I was writing such a clear 
message...


 -Ken

Re: RFC: Getopt::Modern



On Jun 16, 2005, at 11:04 PM, Eric Wilhelm wrote:



Ok, and maybe I showing my age here, but is *this* where the
negated-options thing comes from?  I.E. is this the historic (and
entire) reason for having the 'foo!' syntax in Getopt::Long?

If so, is that why there is so much resistance to evaluating in 
anything

besides command-line order?


I dunno.  Personally, I think you should just write your module. =)  
Don't call it ::Modern or ::User, because clearly there's a lot of 
disagreement among the users here, call it something like 
::NonExclusive.  But it seems like the worst that could happen is that 
people don't use it.


 -Ken

RE: RFC: Getopt::Modern

2005-06-17 Thread Orton, Yves

Title: RE: RFC: Getopt::Modern

[Quoting Eric Wilhelm, on June 16 2005, 15:14, in Re: RFC:
Getopt::Mo]
15 years * n requests/year = 15*n degrees of flexibility =
unpredictable

Hmm. I'd say

15 years * n requests/year * m happy users = reliability

which is as meaningless as your formula.

Its not just happyness with the reliability, its also the reliability of the author. I know for a fact that Johan responds to patches and bug fixes and feature requests quickly, and usually in a way that makes the user happy. (I think he turned down one patch of mine, but applied at least two or three so im happy with those odds.) OTOH, and no offence Eric, I don't know about you and your responsiveness. ID say its pretty hard to beat Johans.

True, but Getoptions() currently contains all of the expertness of
G::L, which means that other modules cannot learn anything about the
options (such as when Getopt::Helpful would like to know if these are
simple/float/list/hash, etc options without re-implementing G::L's
parsing.)

I can make this information available, if users would be interested.

Well, you already published the rules for parsing the options which was all I needed to write a wrapper around G::L to have it integrate INI file configuration and an a simplified interface for implementing defaults and options in a single hash.

If you tear it apart and put it back together in pieces,

How I do it, is my responsibility.

Agreed. So long as the parse rules don't change bizarrely IMO publishing them should be sufficient.

* multi-pass support
I think this is possibly the only real improvement to G::L.

And, (from my reading of G::L) one that requires a fundamental
restructuring of the code.

Unless I misunderstand what you mean by multipass here I think you are wrong:

{
local @[EMAIL PROTECTED];
Getoptions();
}
Getoptions();

Done. And that's exactly what I do in Getopt::Long::INI (which thanks to this thread I now remember I need to upload to CPAN.)

I currently have two projects that address this issue: Getopt::Toolkit
(which is based on Getopt::Long) and Getopt::Long version 3 (which is
a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
projects into a single new Getopt::Long version is somewhere on my
TODO list. HOWEVER, since I highly appreciate my happy users, whatever
comes out of the merge will be drop-in compatible with the current
Getopt::Long. If this implies that you will not use it because it is
too flexible, that's fine with me. One unhappy user against a zillion
happy users.

OOOH. Maybe I shouldn't upload Getopt::Long::INI after all...

Anychance of some previews?

Finally, I must say, your web site makes me sad.

I can see why. Just so you know many of us hold G::L and yourself in high regard.

Cheers,
Yves

Re: RFC: Getopt::Modern

# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 12:55 am:

 Do you mean to say that 99% of the time (when --foo and --no-foo are
 both present) that it is because somebody has an alias with a --foo
 flag written into it?

Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition of the semantics?

I never suggested that it should be disallowed.  Only that it should be 
equivalent to '--no-foo --foo'.

--Eric
-- 
Unthinking respect for authority is the greatest enemy of truth.
--Albert Einstein
-
http://scratchcomputing.com
-

Getopt::Long wishes (was: RFC: Getopt::Modern)

* Johan Vromans [EMAIL PROTECTED] [2005-06-17 17:20]:
 I can make this information available, if users would be
 interested.

Access to structured data is always nicer than implementing and
re-implemeting a parser for its serialized form.

So if it doesnt take too much effort, it would be nice to have.
I might even need this at some point (Im the current maintainer
of Getopt::Auto, though I must admit I have not done much to earn
the title yet).

 One unhappy user against a zillion happy users.

Since were at this: the one thing I still fall back to
Getopt::Std for is small scripts. I love Getopt::Long, but it
incurs a pretty high startup cost. Is there any chance you can
play some deferred compilation cards to make it go faster?

Of course, its kind of tricky for a module whose code all runs
exactly once, at program startup maybe you can isolate the code
that implements various features and compile only those which are
actually requested/used? Of course, I have no idea what Im
talking about, given that I havent taken even a cursory look at
the code.

I just thought Id throw these out here while were at the topic,
before I get distracted by some other shiny ball.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;

Re: RFC: Getopt::Modern

# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 02:51 am:

  I did not notice the go_shop problem. But I think it's trivial to
solve that with Getopt::Long:

my @conf_fishes = read_conf(fish); # get qw(trout)
my @opt_fishes = qw();
my $opt_nofish = 0;
Getopt::Long::GetOptions(
 fish=s = [EMAIL PROTECTED],
 no-fish = \$opt_nofish,
);
@conf_fishes = qw() if $opt_nofish;
my @fishes = (@conf_fishes, @opt_fishes);

Yes.  You can solve it.  It's not really trivial by the time you add 
meats, cheeses, breads, and mustard though.  All of these things come 
in many flavors and you might have a config file with your favorites 
listed in it so that running go_shop with no arguments gives you a 
routine trip, but you want to be able to change these things when you 
get bored of the same-old options.

These 4 extra lines multiply by 5 items so far.

  Who said the variable to save the no-fish status has to be
revelant with the fish variable anyway? If they are saved in
different variables, the order doesn't matter, does it?

What I'm trying to do with Getopt::Modern here is to establish some 
conventions which allow this to happen internally.  This saves the 
author some code and gives the user a guaranteed consistent experience 
with multiple programs.

The debate on the usefullness of '--no-' appears to say it's useful.

The debate on its behavior says that there are historical (and 
convenience) reasons to keep its evaluation in command-line order.

What I'll probably end-up with is something like '--un-' performing the 
above task of initializing internal values.

--Eric
-- 
Everything goes wrong all at once.
--Quantized Revision of Murphy's Law
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

On Fri, 17 Jun 2005 08:45:26 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
 Ok.  Then my previous argument stands.  If the --no- means unset any 
 hard-coded or config-file defaults, then it shouldn't be evaluated in 
 command-line order.

Well, as I said, if you would like unordered options, simply put
foo and no-foo in 2 different variables seperately.  It's just the
flexibility you accused on Getopt::Long that may solve your problem
in 2 lines, but not having to write a whole new module.

Getopt::Long::GetOptions(
  fish=s  = [EMAIL PROTECTED],
  no-fish = \$opt_nofish,
);
@conf_fishes = qw() if $opt_nofish;
@fishes = (@conf_fishes, @opt_fishes);

--
Best regards,
imacat ^_*' [EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Woman's Voice News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug


pgpN0cxhOyIAb.pgp
Description: PGP signature

Re: RFC: Getopt::Modern

# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 08:14 am:

 If it involves typing @main::ARGV, something is wrong.

This is another one of your statements that feel like a religious
issue. If typing @main::ARGV indicates that something is wrong, I
think you have to address the Perl design and maintenance team.

This is not about the look of the variable name.  It's about a package 
modifying a global variable deep inside the core of its functionality.

Here's how I addressed the issue.  There's only one instance of ARGV in 
the code.  get() doesn't care what you pass it, so it's easier to wrap.  
You could even use it for parsing hash values in API functions.

sub GetOptions {
my $self = Getopt::Modern-create(@_);
return($self-get([EMAIL PROTECTED]));
}

I was wrong about that being @main::ARGV.  It's just @ARGV.

Anyway, this GetOptions() function is not meant to be wrapped, and it 
serves as a dirt-simple example of what to do if you want to wrap 
Getopt::Modern.

--Eric
-- 
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
--Alan Kay
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:00]:
 In fact, as I mentioned I would be happy for G::L to have this
 functionality, but I doubt that program-order evaluation (one
 of the main design goals) is going to fit without some serious
 restructuring.  

Why do you keep claiming that? Both me and someone else already
posted working code that shows how you can trivially do what you
want with Getopt::Long if you just use two different variables.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;

Re: RFC: Getopt::Modern

* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:20]:
 In any case.  How does G::L evaluate in precedence order?
 That's why I'm writing G::?

By parsing into two separate variables, and allowing separate
module-client code evaluate how to react to the values in those
to variables. A working example of code that does this is in the
part of my message that you conveniently snipped.

 There are other useful situations for controlling the order.
 We just haven't covered them yet.

Which cant be addressed using quite the same approach as the one
that has already been shown to work for this case? I am doubtful,
but go ahead, convince me.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;

Re: RFC: Getopt::Modern

On Fri, 17 Jun 2005 09:08:51 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
 Yes.  You can solve it.  It's not really trivial by the time you add 
 meats, cheeses, breads, and mustard though.  All of these things come 
 in many flavors and you might have a config file with your favorites 
 listed in it so that running go_shop with no arguments gives you a 
 routine trip, but you want to be able to change these things when you 
 get bored of the same-old options.
 
 These 4 extra lines multiply by 5 items so far.

It's 2 lines, not 4.

Of course, you can request registering a new module to save 2 x 5 =
10 lines of code.  Or, as you said, saving 4 x 5 = 20 lines.  But mostly
when I get an argument of a file name, I have to check it's existence,
it's permission, its type, bla bla bla.  With proper comments, that
takes at least 9 lines for an argument (not an option).  In your example,
that is 9 lines x 2 arguments x 5 options = 90 lines.  This is only the
argument parsing.  The real code is far more complicated.  Last
application I wrote take 2442 lines.  In such a case, I don't care about
saving 10-20 lines or not.  To save 10-20 lines, I would rather try
another neat algorithm for the main code.  Enhancing algorithm of the
main code may save 200-300 lines at once.

Most applications as complicated as your example exceeds 1000 lines. 
Saving 10-20 lines for that is non-sense.  An application that has only
50 lines may matter, but I doubt its option complexity to have 10-20
lines to save.

A new module, with its accompany documentation, its test suite and
its future maintainance, takes at least 1500 lines.  The usefulness of
controlling the option order can be done in 2-20 lines with Getopt::Long,
and you are going to writing more than 1500 lines just to save them? Na~

I agree with others.  If you do think saving 2-20 lines is vital to
your application, I would suggest naming it something else than
Getopt::Modern.  The word Modern poses an attitude of superiority
towards its competitors.  But everyone here does not agree with that
superiority.  I think it's rather personal taste, not modernity.  I
would *not* suggest, say, Getopt::Save20Lines, by the way. :p

--
Best regards,
imacat ^_*' [EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Woman's Voice News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug


pgp6X2jG2ksI6.pgp
Description: PGP signature

Re: RFC: Getopt::Modern

* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:15]:
 It's not really trivial by the time you add meats, cheeses,
 breads, and mustard though. All of these things come in many
 flavors and you might have a config file with your favorites
 listed in it so that running go_shop with no arguments gives
 you a routine trip, but you want to be able to change these
 things when you get bored of the same-old options.

Thats not trivial, period. Any solution will have to be pretty
complex if its supposed to handle this  especially if you want
the user to be able to override only some defaults, but not
others. Im not sure that any form of command line will be
anything other than craptacular for a job like this.

This would all be much easier if we had actual examples to
discuss.

 What I'm trying to do with Getopt::Modern here is to establish
 some conventions which allow this to happen internally.  This
 saves the author some code and gives the user a guaranteed
 consistent experience with multiple programs.

Thats never going to happen for the users. There are way too
many other programs already out there. Most of them work
differently from yours.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;

Re: RFC: Getopt::Modern

2005-06-17 Thread Ovid

--- A. Pagaltzis [EMAIL PROTECTED] wrote:
 Why do you keep claiming that? Both me and someone else already
 posted working code that shows how you can trivially do what you
 want with Getopt::Long if you just use two different variables.

Which, to me, is the clincher.  Getopt::Long can easily support what
Eric wants.  There's been an awful lot of energy spent in this thread
over something which most don't see as an issue.  I'm still trying to
figure out why it's carried on this long.

Cheers,
Ovid

-- 
If this message is a response to a question on a mailing list, please send
follow up questions to the list.

Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/

Re: Fw: Failing Reports due to 3rd Party Software...

2005-06-17 Thread Michael G Schwern

On Fri, Jun 17, 2005 at 10:53:44AM +0100, Robert Rothenberg wrote:
 CPANPLUS issues FAIL reports when there is no C compiler, which irks
 module authors who feel such reports make their module look bad.
 
 Some feel that CPANPLUS should detect this and not send a report, others 
 feel it should send a report, but with a different grade: NA or some new 
 grade such as UNGRADED, since there are advantages to testing what a 
 Build will do if there is no C compiler.
 
 Another idea is to ExtUtils::MakeMaker or Module::Build to refuse to try 
 and build a module if a C compiler is required (and update CPANPLUS to 
 detect this).  This seems connected to the larger issue of NA reports 
 when libraries or applications are missing.

Yes, this seems to be the way to go.  Module::Build improves its external
dependency detection and reporting (it already has a lot of the 
intrastructure to declare and detect external deps).  The only change to
CPANPLUS is to better detect these new dep failures and act appropriately.
This both puts the responsibility onto the build system, which is better
set up to handle it, and improves error messages when you're installing a
module without CPANPLUS.

Right now the reporting seems a bit ad hoc so some discussion will have to
happen between the CPANPLUS folks and the MB folks.

The same work should be done on MakeMaker but it would be too broad (MakeMaker
has none of the existing detection and reporting tools) and introduce far 
too much instability (because its make and shell, not Perl) too late in the 
game.  That part gets a resounding no.


 My own take is that these fails should be sent out anyway, but as NA 
 reports.  Too many grade types can get confusing, but it should be 
 feasible to analyze failure reports automatically to classify them:
  * Perl version too low
  * Unsupported operating system
  * Missing required libraries or applications
  * Missing compiler, linker or other utility needed for build
  * Other error during build
 
 In other words, the meaning of NA should be it wasn't able to 
 successfully build the software and get to the testing phase.

No, that's not the meaning of NA.  NA means Not Applicable which basically
means Not the author's problem.  Its for problems related to the user's
environment.  This includes all of the above EXCEPT other errors during
build.  If the build craps out for an *unexpected* reason then it is now
the author's problem.  Things such as:

* Syntax error
* Undeclared incompatibility
* Missing dependency
* Anything else the author didn't expect to fail

Take, for example, the recent problems PathTools was having on Windows which
caused a lot of build failures.
http://www.nntp.perl.org/group/perl.cpan.testers/180174

Those are legit failures during the build phase and should be reported.


-- 
Michael G Schwern [EMAIL PROTECTED] http://www.pobox.com/~schwern
You are wicked and wrong to have broken inside and peeked at the
implementation and then relied upon it.
-- tchrist in [EMAIL PROTECTED]

Re: RFC: Getopt::Modern



On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:


* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:

I'm still trying to figure out why it's carried on this long.


Calling the new module ::Modern and claiming that ::Long is
crufty, too flexible, and unpredictable probably set the mood.


Amen.  Eric, that was really obnoxious.  You might have had more luck 
convincing people that your approach had some merit if you were less 
haughty about it.


 -Ken

Re: RFC: Getopt::Modern

2005-06-17 Thread Austin Schutz

On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote:
 
 On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
 
 * Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
 I'm still trying to figure out why it's carried on this long.
 
 Calling the new module ::Modern and claiming that ::Long is
 crufty, too flexible, and unpredictable probably set the mood.
 
 Amen.  Eric, that was really obnoxious.  You might have had more luck 
 convincing people that your approach had some merit if you were less 
 haughty about it.
 

Imagine this is Eric's first try at publishing a module. While perhaps
his approach could use honing, perhaps we could make it a little less of
a smackdown? It would be nice to encourage contribution to the community.

Austin

Re: RFC: Getopt::Modern

# The following was supposedly scribed by
# Ken Williams
# on Friday 17 June 2005 01:07 pm:

 Calling the new module ::Modern and claiming that ::Long is
 crufty, too flexible, and unpredictable probably set the mood.

Amen. Eric, that was really obnoxious. You might have had more luck
convincing people that your approach had some merit if you were less
haughty about it.

Ouch!

Please note the RFC in the subject.  That's not Requests For 
Congratulations and Clamoring new users.

This is a work in progress, and I was requesting (primarily) feedback on 
the name (which I *know* is a dumb name (no.  Really.  The dumbest name 
I've ever thought of.))

Had I used Getopt::WorkingTitle, would this discussion have been rosier?

My slides contain some notes about what I was trying to fix in G::L.

There were some scathing objections to my take on how the option 
processing should behave.  So, I was trying to get to the bottom of the 
logic (past the religious fervor, etc, etc.)

What I've learned about this is that:

1.  Historically, --no- was intended to reset hard-coded and 
config-file options.

2.  Since then, lots of people have been using it to override aliased 
options (and as a fancy backspace key) (taking advantage of the 
coincidental command-order  of implementation detail.)


Where I'm going from here:

1.  History wins the '--no-'.  Fine.  That doesn't mean we can't move 
forward.

2.  More examples on the program-order evaluation, which appears to be 
largely misunderstood.

3.  A clearly written set of design objectives, for my sake and the sake 
of discussion.  Hell.  Maybe we'll even manage to hammer it into a 
standard.


The trouble with open-source is that instead of cursing a black-box, I'm 
able to dig through the code that's not doing what  I want and find 
what needs to change.  So, I curse what needs fixing (of course this is 
only what *I* see as needing fixing by definition I'm incapable of 
seeing anything else) in there without stopping to say:

Wow!  This module really does some great stuff!  Isn't perl beautiful 
and I'm really impressed at what Getopt::Long is so far.  Pats on the 
back for everybody and smiles all around.  Now.  Let's get to work 
because we can do better.

I am grateful to everyone who participated in the discussion.  Without 
you, there wouldn't have been one.  And it was a good discussion.  
Maybe I'll see a few of you at OSCON.  Send me an e-mail off-list and 
I'll buy you a beer.

I do have strong opinions.  I also don't surrender them easily.  Of 
course I think I'm great, but I never said I was better than anybody 
else :-)

I'm not posting to seek approval.  Tell me this is the dumbest idea 
you've ever heard and I'll be happy as long as you tell me why because 
I will have learned something and my code (or at least someone's code) 
will improve because of it.

Thanks,
Eric
-- 
We who cut mere stones must always be envisioning cathedrals.
--Quarry worker's creed
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

* Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
 Imagine this is Eric's first try at publishing a module.

Then what is http://search.cpan.org/~ewilhelm/? :-)

You could take at least a cursory look before making such
assumptions

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;

Re: RFC: Getopt::Modern

2005-06-17 Thread Austin Schutz

On Fri, Jun 17, 2005 at 11:22:58PM +0200, A. Pagaltzis wrote:
 * Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
  Imagine this is Eric's first try at publishing a module.
 
 Then what is http://search.cpan.org/~ewilhelm/? :-)
 
 You could take at least a cursory look before making such
 assumptions???
 

Was I assuming, or was I imagining? The point is that the
community can be unnecessarily combative and ugly, a point which to
my eyes you have helped illustrate.

Austin

Re: Failing Reports due to 3rd Party Software...

2005-06-17 Thread Rob Janes

so basically the executive summary is that cpanplus does not report 
adequately system dependency failures, like a missing c compiler or a 
missing library.  i guess the issue is one of prioritizing an 
appropriate response from maintainers who care about these reports.  
specifically, maintainers of perl xs modules will likely not want to be 
bothered with failure reports when the failure is due to a lack of a c 
compiler.


here's my suggestions on what to do about it:

i like barbie's abstraction, so i'd add that to my outline of 
CPAN/PLUS-yaml-ExtUtils::MakeMaker-Module::Build changes.


The idea is that perl xs modules have prereqs that are external to perl, 
be they compilers, utilities, file naming conventions (to backslash or 
not to backslash), libraries, etc.  Failure in this regard is 
essentially a prereq failure.  ExtUtils::MakeMaker and M::B would be 
changed to understand the concept of an external prereq.  This external 
prereq would be tested by a piece of custom code which the module author 
would have to write, as I did with Compress::Bzip2 to test for the bzlib 
library.  Likely E::M and M::B would have a list of names of external 
prereqs that would be understood, and reported on by the custom piece of 
code.  The yaml file generated by E::M and M::B would list these 
external prereqs, by name and description.  CPANPLUS understands perl 
prereqs.  external prereqs would be more difficult, but if we had a 
naming convention some basic external prereqs could be preprepared since 
they are everywhere, like for example system_cc=a c compiler,  
system_libbz2=bzlib devel library.  maybe something user_xxx=my 
custom ext. prereq for external prereqs requiring helper subroutines.


with perl xs, i just made CPANPLUS's check for prereqs more 
complicated.  E::M and M::B would have to assist in this.  i think 
currently cpanplus uses the yaml to check the prereqs and bails before 
it even runs the .PL file, correct me if i'm wrong.  ok then, both 
scenarios.  cpanplus runs .PL file and picks up prereq failures from the 
logfile.  this one is easy, the .PL file just has to report on the 
external prereq failures.  cpanplus reads the yaml and checks for 
prereqs, and schedules perl prereqs for loading.  for cpanplus to check 
for external prereqs, with a naming convention there would be some 
prereqs it could check for itself, but more generally it will have to 
call the .PL file with some special options to make the .PL check the 
prereqs. when invoked with those options, the .PL should not configure 
the module. CPANPLUS would only call the .PL file with those options 
(check external prereq) if the yaml indicated there were external 
prereqs (backward compatibility).


external prereq failure of a critical component should cause cpanplus to 
bail out of the build.  unlike with perl prereqs, there is no recovery 
action available to cpanplus.  or, the .PL could supply a helper 
function for recovery action.  for example, in Compress::Bzip2 if there 
is no bzlib installed, the recovery action is to activate the static 
build of the internal bzlib tagalong.  you could go crazy with this 
one.  like if a c compiler is missing you could fire up some p2p action 
and download a c compiler and install it.


-rob

r w j a n e sa tr o g e r s . c o m

Robert Rothenberg wrote:




On 17/06/2005 09:14 Michael G Schwern wrote:


This is all a bit of a ramble.  Could we have an executive summary as to
the point particularly in relation to MakeMaker, CPANPLUS and module 
authors

in general?



CPANPLUS issues FAIL reports when there is no C compiler, which irks
module authors who feel such reports make their module look bad.

Some feel that CPANPLUS should detect this and not send a report, 
others feel it should send a report, but with a different grade: NA or 
some new grade such as UNGRADED, since there are advantages to testing 
what a Build will do if there is no C compiler.


Another idea is to ExtUtils::MakeMaker or Module::Build to refuse to 
try and build a module if a C compiler is required (and update 
CPANPLUS to detect this).  This seems connected to the larger issue of 
NA reports when libraries or applications are missing.


I'm of the opinion that people who pay attention to test reports when 
deciding whether to use a module should be saavy enough to interpret 
them, but I'm probably wrong. Maybe a FAQ is needed for the testers 
web site that explains how to do this?


My own take is that these fails should be sent out anyway, but as NA 
reports.  Too many grade types can get confusing, but it should be 
feasible to analyze failure reports automatically to classify them:

 * Perl version too low
 * Unsupported operating system
 * Missing required libraries or applications
 * Missing compiler, linker or other utility needed for build
 * Other error during build

In other words, the meaning of NA should be it wasn't able to 
successfully build the software and get to the testing

Re: RFC: Getopt::Modern



On Jun 17, 2005, at 3:37 PM, Austin Schutz wrote:


On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote:


On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:


* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:

I'm still trying to figure out why it's carried on this long.


Calling the new module ::Modern and claiming that ::Long is
crufty, too flexible, and unpredictable probably set the mood.


Amen.  Eric, that was really obnoxious.  You might have had more luck
convincing people that your approach had some merit if you were less
haughty about it.



Imagine this is Eric's first try at publishing a module. While perhaps
his approach could use honing, perhaps we could make it a little less 
of
a smackdown? It would be nice to encourage contribution to the 
community.


True, I guess my message was at least as obnoxious.  Eric isn't a 
newbie author, though, he's pretty experienced and has a few good 
modules under his belt.  And as I said in my other message, I do 
encourage him to go ahead and write the module.  It doesn't really 
matter how many of us disagree with his design proposal - if it 
scratches his itch, it may well scratch others' itches.


 -Ken

Re: RFC: Getopt::Modern

On Fri, 17 Jun 2005 14:34:59 -0700
Austin Schutz [EMAIL PROTECTED] wrote:
   Was I assuming, or was I imagining? The point is that the
 community can be unnecessarily combative and ugly, a point which to
 my eyes you have helped illustrate.

Well, I suppose, I am one of those you mentioned.  Yes, I said
something like Getopt::Save20Lines.  Though I'm not the one started
that (I started to laugh at Johan's Getopt::Personal::EWilhelm), but
if that's not appropriate, I apologize.  But, then, is this whole thread
that meaningless?  We people here all took time to try to read, ask and
understand what Eric thinks, provide our feedback, explaining this and
that.  Aristotle and I even figured out a simple solution to Eric's
problem.  We have proved that Getopt::Long is not unpredictable.  It
is flexable to solve Eric's major problem.  Or maybe everybody here was
doing wrong.  Should we just say, go ahead, make your day, without
even bother to watch his slides and figure out the problem?

If a blind yes is all is needed here, it's OK.  Then Eric should
not address this issue at all.  Module registration is not required, too.

But, to be honest, I think the response Eric got is a lot more
friendly than what I got about a question regarding to CGI.pm.  Surely a
simple patch that shouldn't make any problem should not address any
discussion, but should it not address any attention to the author?  Of
course, it's the author's decision to pay attention to me or not.  I
shouldn't complain about that.

--
Best regards,
imacat ^_*' [EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

Woman's Voice News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug


pgpgCl8dwzmtc.pgp
Description: PGP signature

Re: Getopt::Crazy

# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 06:46 pm:

 (I started to laugh at Johan's Getopt::Personal::EWilhelm), 

Me too!

 Aristotle and I even figured out a simple
 solution to Eric's problem. We have proved that Getopt::Long is not
 unpredictable. It is flexable to solve Eric's major problem.

Yes and No.  We'll see.

 Or maybe everybody here was doing wrong. Should we just say, 
 go ahead, make your day, without even ...

No, this was (and is) a good discussion.  I've definitely learned that I 
need to work on the problem more, and write my ideas more clearly 
before I try to seek advice.  I just thought I could ask for a wee 
suggestion about the name before it was done, but now it's clear to me 
that I need to discover more about the problem that I'm trying to 
solve.

I'm sure there's a lot of misunderstanding of what I'm after.  I don't 
quite know myself, which is the main reason that I've not discussed the 
module much until now.  Maybe I'm crazy.  I dunno.  I had decided to 
take a step backward and look at option processing, why it is the way 
it is, etc.  Part of this process involves reading Getopt::Long.  
Anyway, did you ever look at a thing and think you've seen something 
that's either completely new or completely crazy?

Of course, if it is really new, people will call you crazy.  But, then 
again they'll do that even if your crazy!  Oh well.  I'll call it crazy 
from now until I come up with something better or it goes away.  
Writing code sure beats hanging out in a straightjacket, so I guess 
I'll be writing code.

In any case, if anybody wants to comment or suggest while I'm working on 
it, I'll be posting to this page as things progress:
  http://scratchcomputing.com/developers/Getopt-Crazy/

I'll probably go back to working on Getopt::Helpful for a few days to 
try to figure out why this is better than what I was doing (I'm 
guessing it mostly has to do with loading a config file.)  Don't worry, 
I'm not planning to put Getopt::Helpful (or Getopt::Crazy) on CPAN for 
a while yet.  They're both still sort of experiments.

Thanks,
Eric
-- 
It works better if you plug it in!
--Sattinger's Law
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern