Re: YAML and Makefile.PL (was various topics)

[Adam Kennedy]

A. Pagaltzis wrote:

* Adam Kennedy <[EMAIL PROTECTED]> [2006-01-31 07:50]:

There isn't really any very good way (that I can see at least)
to ensure that an end-user gets an update to EUMM/MB, just the
module packager.


So maybe that is the fundamental problem that should be
addressed?

Regards,


It comes down to dependencies being an "at least" rule.

As long as the CPAN installer can skip over already-met deps, you get 
the problem in one way or another.


And for sanity reasons, we WANT (nay HAVE) to have it that way.

Solutions that can be implement without either betting incredibly 
aggressive to users, putting MB or CPANPLUS into the core, or going down 
the bundled route, would be interesting to hear though.


Adam K

Re: YAML and Makefile.PL (was various topics)

[Adam Kennedy]

A. Pagaltzis wrote:

* chromatic <[EMAIL PROTECTED]> [2006-01-31 08:20]:

Perhaps CPAN/CPANPLUS should check for updates?


Maybe just add EUMM+MB to Bundle::CPAN? (Does CPANPLUS have an
equivalent?)

Regards,


But then how are you going to make Bundle::CPAN trigger when there's a 
critical failure, without requiring the user to be smart?


These things tend to cascade. The obvious solution results in a daisy 
chain of things you need to change.


Adam K

Re: testers.cpan.org out of sync with search.cpan.org?

[Tyler MacDonald]

Leon Brocard <[EMAIL PROTECTED]> wrote:
> > Usually this clears up in about a day, but in some cases it's been 3 or 4
> > days now and search.cpan.org is telling me that tests have run, but
> > testers.cpan.org doesn't seem to know anything about them.
> Sorry, I'll prod testers.cpan.org again. Give it a while to sync up.

Awesome, thanks! Is the code that drives testers.cpan.org open
source? I'd really like to learn more about it.

Cheers,
Tyler

[PATCH] A partial fix for Parrot::Configure::Data (RT #38260)

[Norman Nunley, Jr]

Parrot::Configure::Data->add had a bug in it which caused a reference to
itself to be included in the configuration hash.

This patch effects lib/Parrot/Configure/Data and t/configure/data.t

Please refer to rt ticket #38260 for further context.

Regards,

Norman Nunley




pcd.patch
Description: Binary data

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[David Cantrell]

brian d foy wrote:

<[EMAIL PROTECTED]> wrote:

Hopefully it will be something like:
$I::don't::bother::to::write::portable::code=1;
;-)

Seriously though, I would expect things in Win32::* to only work on
Windows, things in Linux::* only to work on linux, and so on for many
other sections (including Mac::* where I have some modules).  Portable
code isn't always the goal.


I want my code to be more like File::Spec, which provides a common 
interface to a load of platform-specific modules.  That has very good 
coverage of bizarro OSes, and I think we'd all agree that it's an 
excellent example of a nice portable module.


It doesn't work on RISC OS though.

--
David Cantrell

Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)

[avtanski]

Hello again,

If I use this:

use open ':encoding(UTF-8)';

in my script, it crashes and makes a big fat core dump.  :-(

I think it is up to me to figure out the problem now, but if you
have any suggestions, I'll be glad to hear them.  Unfortunately,
because this is not a high priority project I can work on it
only for half and hour daily - that's the reason I'm replying so
slow.

Thanks,

- Alex

[PATCH] Bug fix to Parrot::Configure::Data

[Norman Nunley, Jr]

Parrot::Configure::Data->add had a bug in it which caused a reference to
itself to be included in the configuration hash.

This patch effects lib/Parrot/Configure/Data and t/configure/data.t

Please refer to rt ticket #38260 for further context.


Norman Nunley



pcd.patch
Description: Binary data

[perl #38260] [BUG][PATCH] Parrot::Config contains invalid info

[Norman Nunley, Jr. via RT]

I have a partial solution.  There was a bug in Parrot::Configure::Data->add 
which
caused it to always include a stringified copy of self for every usage of add.  
This
leads to a large number of garbage hashref strings with even larger numbers of
delimiter seperated delimiter strings.

I'll attempt a deeper exploration as to the reason why variable expansion isn't
being done at some later point.

This effects lib/Parrot/Configure/Data and t/configure/data.t

> [EMAIL PROTECTED] - Tue Jan 17 12:44:55 2006]:
> 
> attached is my lib/Parrot/Config.pm file generated from r11223, on
> windows using msvc. inside you'll find a few things, like keys given
> unix file path values,
>  'bin_dir' => '/usr/local/bin',
> 
> an invalid key,
>  'Parrot::Configure::Data=HASH(0x193a650)' => '   ',
> 
> and unexpanded values,
>  'libparrot' => '$(LIBPARROT_STATIC)',
>  'libparrot_ldflags' => '$(LIBPARROT_STATIC)',
>  'libparrot_shared' => 'libparrot$(SHARE_EXT)',
> 
> 
> these should be fixed as appropriate.
> ~jerry
> 
> 



pcd.patch
Description: Binary data

Re: [perl #38371] [BUG] t/op/calling.t is failing (IREGs aren't being cleared)

[Leopold Toetsch]

jerry gay (via RT) wrote:


on platforms sensitive to IREGs with junk data, or on any platform
when running `TEST_PROG_ARGS=-D40 perl -Ilib t/op/calling.t`, test 78
is failing (as reported on #parrot by jisom)


Fixed - r11386

leo

Re: [perl #38348] [PATCH] Accept return values via a Continuation

[Leopold Toetsch]

Bob Rogers wrote:

   From: "Leopold Toetsch via RT" <[EMAIL PROTECTED]>



   Yep. At least as long we don't have better support for creating
   limited continuations that are able to return some results.

I'm afraid I don't follow.  What would you consider better?


Limiting the callframe range, where the continuation can go. Currently 
creating a continuation is rather expensive, as all RetContinuations up 
the call chain are converted into full continuations. This is necessary 
because there is no further information about the usage of the 
continuation. It could be passed to 'main' and then 'jump' back. Thus 
all the intermediate frames have to be kept alive, because normal 
function return goes through these frames.




   But, FWIW, I am coming around to the view that continuations
shouldn't ever be invoked like this.  Plain function calling is likely
to confuse optimizers, since they won't understand that you don't ever
expect to return.  I was about to propose a new op when I discovered
that tailcall works just fine for this purpose (see below).


I don't think that we can enforce this. Have a look at 
t/library/streams.t. I don't think that a compiler has the knowledge 
that it's compiling the invocation of a continuation instead of a plain 
subroutine.


The tailcall syntax works, because it's just ignored by the continuation.

leo

Re: [PATCH] Bug fix to Parrot::Configure::Data

[Leopold Toetsch]

Norman Nunley, Jr wrote:

Parrot::Configure::Data->add had a bug in it which caused a reference to
itself to be included in the configuration hash.

This patch effects lib/Parrot/Configure/Data and t/configure/data.t


Thanks, applied - r11387.
leo

Re: testers.cpan.org out of sync with search.cpan.org?

[Leon Brocard]

On 1/30/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:

> Awesome, thanks! Is the code that drives testers.cpan.org open
> source? I'd really like to learn more about it.

Of course! (include subtle dig at non-opensource CPAN websites here)

  http://search.cpan.org/dist/CPAN-WWW-Testers-Generator/
  http://search.cpan.org/dist/CPAN-WWW-Testers/

Leon

Re: PARROT_IN_EXTENSION

[Jonathan Worthington]

"Nicholas Clark" <[EMAIL PROTECTED]> wrote:
I think that I must be missing something. In ponie, src/pmc/perl5pmcs.h 
looks

like this:

--
/*
* !!!   DO NOT EDIT THIS FILE   !!!
*
* This file is generated automatically from 'various files'
* by /home/nick/Ponie/ponie00/parrot/tools/build/pmc2c.pl.
*
* Any changes made here will be lost!
*
*/

#define PARROT_IN_EXTENSION
PARROT_DYNEXT_EXPORT Parrot_PMC Parrot_lib_perl5pmcs_load(Parrot_INTERP 
interpreter);

--

To me, that PARROT_IN_EXTENSION is not helping.
Both the #define and use of PARROT_DYNEXT_EXPORT look useless here, as it is 
in the group's .c file that the symbol export stuff is needed in (and it is 
there too).  Just tested and ci'd a change that removes them.


Hope this helps,

Jonathan 

Re: YAML and Makefile.PL (was various topics)

[Chris Dolan]

On Jan 31, 2006, at 2:30 AM, Adam Kennedy wrote:

Solutions that can be implement without either betting incredibly  
aggressive to users, putting MB or CPANPLUS into the core, or going  
down the bundled route, would be interesting to hear though.


If I've read the perl5-porter summaries correctly, M::B just entered  
core in 5.9.3.  There has long been hope that M::B and CPANPLUS will  
be in core for 5.10.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: YAML and Makefile.PL (was various topics)

[Chris Dolan]

On Jan 31, 2006, at 2:32 AM, Adam Kennedy wrote:

But then how are you going to make Bundle::CPAN trigger when  
there's a critical failure, without requiring the user to be smart?


CPAN.pm and CPANPLUS.pm already check their own version against CPAN  
on every run.  All we'd need to do is have Andreas or Jos increment  
the CPAN.pm/CPANPLUS.pm version and just about everyone would be  
prompted to upgrade the next time they tried to install something.


Chris
--
Chris Dolan, Software Developer, Clotho Advanced Media Inc.
608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

TODO test paradox: better TODO test management?

[Mark Stosberg]

Here's my test-first TODO test management paradox:

If I write a failing test and share it through the central repo,
the smoke bot fails and keeps sending us e-mail until it is fixed,
which can be annoying when these are un-implemented features and not
bugs. The effect can be quit paying attention to the smoke bot. 

If I mark the test TODO, the smokebot succeeds and the test disappears
from the radar of tests that should be fixed soon. 

What's a good way to manage TODO tests so that they continue to be
noticed and worked on, but without being annoying? 

Partly I wish that the reporting tools provided more detail about TODO
tests. Rather than just telling me that X TODO tests passed, I'd like
to know exactly what they were and where they were located so I can go
work on them.

I also realize I have another class of TODO tests, it's the: 

Ill-get-to-it-eventually,-maybe-next-year class of TODO tests.

These are things that I've noted I'd like to have an automated test for, 
but the tests are long term because they are expensive, difficult to
setup, or well, I'm imperfect.

Maybe being able to add a "due date" to tests would help. :) 

The TODO tests would pass before the due date, but if they aren't 
addressed in flow of work, they start failing to bring attention to
themselves. 

And then there could be a "snooze" button too...

Mark

Re: TODO test paradox: better TODO test management?

[demerphq]

On 1/31/06, Mark Stosberg <[EMAIL PROTECTED]> wrote:
> Here's my test-first TODO test management paradox:
>
> If I write a failing test and share it through the central repo,
> the smoke bot fails and keeps sending us e-mail until it is fixed,
> which can be annoying when these are un-implemented features and not
> bugs. The effect can be quit paying attention to the smoke bot.
>
> If I mark the test TODO, the smokebot succeeds and the test disappears
> from the radar of tests that should be fixed soon.
>
> What's a good way to manage TODO tests so that they continue to be
> noticed and worked on, but without being annoying?
>
> Partly I wish that the reporting tools provided more detail about TODO
> tests. Rather than just telling me that X TODO tests passed, I'd like
> to know exactly what they were and where they were located so I can go
> work on them.
>
> I also realize I have another class of TODO tests, it's the:
>
> Ill-get-to-it-eventually,-maybe-next-year class of TODO tests.
>
> These are things that I've noted I'd like to have an automated test for,
> but the tests are long term because they are expensive, difficult to
> setup, or well, I'm imperfect.
>
> Maybe being able to add a "due date" to tests would help. :)
>
> The TODO tests would pass before the due date, but if they aren't
> addressed in flow of work, they start failing to bring attention to
> themselves.
>
> And then there could be a "snooze" button too...

While only indirectly related.

Lately when ive built blead I see stuff like "10 TODO tests
unexpectedly passed!"

So far ive not found a way to make harness tell me which they are...

So i too would like a report of TODO tests, both those passing and
those failing.

yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: TODO test paradox: better TODO test management?

[Chris Dolan]

On Jan 31, 2006, at 10:40 AM, demerphq wrote:


While only indirectly related.

Lately when ive built blead I see stuff like "10 TODO tests
unexpectedly passed!"

So far ive not found a way to make harness tell me which they are...

So i too would like a report of TODO tests, both those passing and
those failing.


You could try:

  make test verbose=1 > out

and then search the output for "TODO"

Chris
--  
Chris Dolan, Software Developer, Clotho Advanced Media Inc.

608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703
vCard: http://www.chrisdolan.net/ChrisDolan.vcf

Clotho Advanced Media, Inc. - Creators of MediaLandscape Software  
(http://www.media-landscape.com/) and partners in the revolutionary  
Croquet project (http://www.opencroquet.org/)

Re: TODO test paradox: better TODO test management?

[demerphq]

On 1/31/06, Chris Dolan <[EMAIL PROTECTED]> wrote:
> On Jan 31, 2006, at 10:40 AM, demerphq wrote:
>
> > While only indirectly related.
> >
> > Lately when ive built blead I see stuff like "10 TODO tests
> > unexpectedly passed!"
> >
> > So far ive not found a way to make harness tell me which they are...
> >
> > So i too would like a report of TODO tests, both those passing and
> > those failing.
>
> You could try:
>
>make test verbose=1 > out
>
> and then search the output for "TODO"

Harness should provide better info. Todo tests are important. If they
unexpectedly succeed IMO they should be treated as if a test failed.
Until the author agrees that a todo test should be passing it doing so
should be a bug. And the way the author should show her agreement is
to change it so it isn't a TODO anymore.

cheers,
yves




--
perl -Mre=debug -e "/just|another|perl|hacker/"

Re: What am I doing wrong? (Perl, UTF-8 and cyrillic)

[Tels]

Moin Alex,

On Tuesday 31 January 2006 02:56, [EMAIL PROTECTED] wrote:
> Hello again,
>
> If I use this:
>
> use open ':encoding(UTF-8)';
>
> in my script, it crashes and makes a big fat core dump.  :-(

Please trim this down to a minimal (!) example, and then send a bug report 
via perlbug. (You did not say what Perl version you were using, if in 
doubt, maybe you can upgrade it first. Coredumps are fixed often in minor 
Perl versions)

> I think it is up to me to figure out the problem now, but if you
> have any suggestions, I'll be glad to hear them.  Unfortunately,
> because this is not a high priority project I can work on it
> only for half and hour daily - that's the reason I'm replying so
> slow.

No problem we try to help, we will likely need more data from you.

Best wishes,

Tels

-- 
 Signed on Tue Jan 31 18:23:15 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Given enough time, all legal battles in the tech industry will invoke
 the DMCA. This generally means that all constructive arguments have
 ended." NialScorva's law



pgpD1Odr1vFXW.pgp
Description: PGP signature

Re: YAML and Makefile.PL (was various topics)

[Tels]

Moin,

On Tuesday 31 January 2006 06:50, chromatic wrote:
> On Monday 30 January 2006 20:40, Adam Kennedy wrote:
> > Incremental releasing is a toolchain problem.
[snip a good comparisation]

> I don't say this often, but that really doesn't seem scalable to me. 
> If I have to re-release a distribution because of a bug in the build
> system that users can't upgrade on their own, the build system sucks
> for my purposes.

And now you understand why I am angry that users updating their YAML to 
the newest version couldn't install my modules because YAML changed and I 
had to release new versions of all of them (or tell the users to 
downgrade their YAML, or wait for a new YAML and then upgrade it).

I can mitigate this by not using YAML. So I could use Module:Install 
instead and find myself in the very same boat - I have to hope that the 
bundled version of Module::Install will work on whatever system the user 
has. (I think it will, but so I though YAML will :-D

Now, I know Module::Install is an outstanding piece of work, and while it 
does have the "bundling" issue, it should also be noted that the other 
two options aren't much better as my YAML problem (and the Module::Build 
dependency) show.

You basically have to hope that the user's system has the tools to install 
your module.

At the end of the day, it comes down to who has the work, and the ability 
to fix this. If my users can fix things on their end, it removes the 
dependency on my (and my free time and energy). If I can fix things for 
them, it removes the dependency on their time and energy.

I see myself as a solution provider, and I want my modules as small, lean, 
correct and easy to use as possible. If I can save 5 minutes, but create 
a bigger download/workload/system requirements for all my users, well, I 
would not do that.

So, it comes down to find a compromise. If I spend all day long arguing 
install methodologies and fiddle with my Makefile.PLs, I am not writing 
code. So less talk and more code from me :)

Best wishes,

Tels

-- 
 Signed on Tue Jan 31 18:24:56 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Let's say there are a thousand. But there are 284 million people in
 this country. You can't have public policy that is aimed at 100,000
 people when the other multi-multi-millions are also involved. You can't
 do it that way." - Jack Valenty in http://tinyurl.com/2y65n



pgpuH3eqXJNds.pgp
Description: PGP signature

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Tels]

Moin,

On Tuesday 31 January 2006 00:37, demerphq wrote:
> On 1/30/06, David Cantrell <[EMAIL PROTECTED]> wrote:
> > demerphq wrote:
> > > On 1/30/06, David Cantrell <[EMAIL PROTECTED]> 
[snip]
> > > > Sorry, i guess my comment was in bad taste. I was just alluding to 
> observations made in the p5p lists and elsewhere that basing file
> system behaviour on the OS isnt entirely safe, and even expecting the
> same semantics in the a tree could be unsafe.

Like when part of it is an mounted CD-ROM (Hint: ROM :)

Best wishes,

Tels

-- 
 Signed on Tue Jan 31 18:19:52 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Nuclear powered vacuum cleaners will probably be ready within 10
 years." Alex Lewyt, of the Lewyt Corporation, a vacuum maker, predicted
 in The New York Times on June 10, 1955 -- A warning to all technophiles



pgpbKFMv5sEQG.pgp
Description: PGP signature

Re: TODO test paradox: better TODO test management?

[chromatic]

On Tuesday 31 January 2006 08:59, demerphq wrote:

> Harness should provide better info.

Write your own.  perldoc Test::Harness::Straps or see the examples in chapter 
3 of the Perl Testing book:

http://examples.oreilly.com/perltestingadn/

-- c

bug with Test::Exception? or imacat's autotest box?

[Tyler MacDonald]

Take a look at this output:

http://www.nntp.perl.org/group/perl.cpan.testers/285112

It looks like this particular system is not noticing that Test::Exception
requires Sub::Uplevel, then gets confused thinking it was *my* module that
needed Sub::Uplevel. What's even more concerning is the presence of line
noise right after the "make test FAILED"... Any idea what can be going on
here?

Thanks,
Tyler

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Barbie]

On Mon, Jan 30, 2006 at 08:59:58AM -0500, David Golden wrote:
> 
> Well, the more generalized problem is how to you signal to an automated 
> test that you're bailing out as N/A for whatever reason?  For Perl 
> itself, it's easy enough for the smoke test to check if the required 
> version of Perl is available -- and the smoke test is smart enough not 
> to try to install an updated version of Perl to satisfy the dependency. 
>  It bails out with N/A instead.
> 
> What's a clean, generic mechanism for a distribution to signal "please 
> check this dependency and abort if it's not satisfied"?  Something in 
> the META.yml (e.g. Alien::*)?  Send a specific string to STDERR?  Send a 
> specific exit codes?  Ugh.  Other ideas?

For CPANPLUS (and thus YACSmoke) the distribution author can check the
OS from a list of known compatible OSs, and if it doesn't find it, bail
out with a "OS unsupported" message. See this slide [1] for a simple
example.

[1] http://birmingham.pm.org/talks/barbie/cpan-ready/slide603.html

This has been in CPANPLUS for a while now. While the obvious
distributions of Win32:: and Linux:: may be OS specific, there are
others that are not so obvious from the name, which may support a number
of OSs, or might not support specific ones. 

The above exit mechanism provides an NA report to the CPAN testers. 

Barbie.

Re: TODO test paradox: better TODO test management?

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-01-31 19:40]:
>Write your own. perldoc Test::Harness::Straps or see the
>examples in chapter 3 of the Perl Testing book:

That’s not a long-term answer though, is it?

I agree with Yves here, this is stuff that needs to be useful by
default.

Regards,
-- 
Aristotle Pagaltzis // 

Re: bug with Test::Exception? or imacat's autotest box?

[Tyler MacDonald]

Fergal Daly <[EMAIL PROTECTED]> wrote:
> I have a fail against a module for exactly the same reason. I
> initially blamed Module::Build but they convinced me it was Imacat's
> setup. Apparently the output looks like an old version of something or
> other.
> 
> http://rt.cpan.org/NoAuth/Bug.html?id=15034
> 
> has details.
> 
> Imacat didn't respond to my email at the time,

That sucks. :-( If imacat's box has gone AWOL, is there anything
cpan testers can do to flag it as such? At least until his/her attention is
grabbed and the problem is addressed?

Thanks,
Tyler

Re: TODO test paradox: better TODO test management?

[chromatic]

On Tuesday 31 January 2006 11:44, A. Pagaltzis wrote:

> * chromatic <[EMAIL PROTECTED]> [2006-01-31 19:40]:

> >Write your own. perldoc Test::Harness::Straps or see the
> >examples in chapter 3 of the Perl Testing book:
>
> That’s not a long-term answer though, is it?

Why not?  You know more about your application and your team and your 
requirements than Test::Harness does.  There's also always verbose mode and 
grep, if the default summary is too simple.

-- c

Re: TODO test paradox: better TODO test management?

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-01-31 20:55]:
>You know more about your application and your team and your
>requirements than Test::Harness does.

I don’t see “unexpectedly successful TODO tests should be treated
like other failures” as particularly application-specific.

>There's also always verbose mode and grep, if the default
>summary is too simple.

I definitely want to be notified automatically of passing TODO
tests, and apparently at least three others care enough to post
about it on this list. Conversely, I’m pretty sure that of those
who don’t *want* it, most simply don’t care, and if this were a
default, very few would actually want to turn this behaviour off.

All things considered, this seems like a prime candidate for
default behaviour. That’s why I don’t think punting to let-
everyone-roll-their-own is a long-term solution for this one.

Regards,
-- 
Aristotle Pagaltzis // 

pre0 non-smoke

[Larry Wall]

Here's results of r8894 on up-to-date Fedora Core 4 with embparrot
r11392.  Other the usual embparrot rules breakage, is looking pretty
clean here even with bleadparrot.  All the failures below look like
rules coredumps to me, including the undef.t one.

Larry

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
t/builtins/undef.t   01172   26  36.11%  60-72
t/pugsbugs/rule_used_in_Str.t  254 65024 34 133.33%  2-3
t/pugsbugs/rules_with_embedded_pa  254 65024 12 200.00%  1
t/rules/from_perl6_rules/anchors.01119   38 200.00%  1-19
t/rules/from_perl6_rules/array_ca01145   90 200.00%  1-45
t/rules/from_perl6_rules/assert.t011 48 200.00%  1-4
t/rules/from_perl6_rules/capture.01165  130 200.00%  1-65
t/rules/from_perl6_rules/charset.0 422   44 200.00%  1-22
t/rules/from_perl6_rules/codevars01110   20 200.00%  1-10
t/rules/from_perl6_rules/combchar011 36 200.00%  1-3
t/rules/from_perl6_rules/der_gram01133   66 200.00%  1-33
t/rules/from_perl6_rules/grammar.01117   34 200.00%  1-17
t/rules/from_perl6_rules/inline.t011 24 200.00%  1-2
t/rules/from_perl6_rules/litvar.t01129   58 200.00%  1-29
t/rules/from_perl6_rules/named_ca01126   52 200.00%  1-26
t/rules/from_perl6_rules/null.t  0 4 36 200.00%  1-3
t/rules/from_perl6_rules/prior.t 01131   62 200.00%  1-31
t/rules/from_perl6_rules/repeat.t011 6   12 200.00%  1-6
t/rules/from_perl6_rules/rulecode011 48 200.00%  1-4
t/rules/from_perl6_rules/stdrules  254 65024   222  444 200.00%  1-222
t/rules/from_perl6_rules/subrule.01118   36 200.00%  1-18
t/rules/from_perl6_rules/subst.t 011 36 200.00%  1-3
t/rules/from_perl6_rules/word.t  011 7   14 200.00%  1-7
t/rules/named_rule_capture.t 011 48 200.00%  1-4
897 subtests skipped.
Failed 24/506 test scripts, 95.26% okay. 589/9076 subtests failed, 93.51% okay.

Re: TODO test paradox: better TODO test management?

[chromatic]

On Tuesday 31 January 2006 12:22, A. Pagaltzis wrote:

> I definitely want to be notified automatically of passing TODO
> tests, and apparently at least three others care enough to post
> about it on this list. Conversely, I’m pretty sure that of those
> who don’t *want* it, most simply don’t care, and if this were a
> default, very few would actually want to turn this behaviour off.
>
> All things considered, this seems like a prime candidate for
> default behaviour. That’s why I don’t think punting to let-
> everyone-roll-their-own is a long-term solution for this one.

Whose default behavior though?

Improving prove to show more diagnostics makes a lot of sense to me.  It's a 
developer tool.  I've long wanted better failure reporting.

Adding more information to the default Test::Harness summary doesn't make 
sense to me.  It's a user tool.  It's important to list failures there, as 
the code might not work right, but unexpected successes?  I don't want to 
have to explain those or the implications; I'm not sure it's useful 
information for most users.

I still think not enough people write their own harnesses, by the way.

-- c

Re: TODO test paradox: better TODO test management?

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-01-31 21:40]:
>Improving prove to show more diagnostics makes a lot of sense to
>me. It's a developer tool. I've long wanted better failure
>reporting.
>
>Adding more information to the default Test::Harness summary
>doesn't make sense to me. It's a user tool.

Hmm. That’s a good point. Maybe the way to approach this would be
to include a default harness for use by developer tools, which
would include more chattiness about passing TODO tests.

Regards,
-- 
Aristotle Pagaltzis // 

Re: TODO test paradox: better TODO test management?

[chromatic]

On Tuesday 31 January 2006 13:31, A. Pagaltzis wrote:

> Hmm. That’s a good point. Maybe the way to approach this would be
> to include a default harness for use by developer tools, which
> would include more chattiness about passing TODO tests.

My perfect developer tool would complain noisily about failing tests (and give 
all of the diagnostic information for me to debug them), highlight bonus 
tests (and give the diagnostic information for me to promote them), and 
summarize everything else.  If it passes, increment the counter but don't 
tell me.

How would that work for you?

-- c

Re: bug with Test::Exception? or imacat's autotest box?

[Fergal Daly]

I have a fail against a module for exactly the same reason. I
initially blamed Module::Build but they convinced me it was Imacat's
setup. Apparently the output looks like an old version of something or
other.

http://rt.cpan.org/NoAuth/Bug.html?id=15034

has details.

Imacat didn't respond to my email at the time,

F

On 1/31/06, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> Take a look at this output:
>
> http://www.nntp.perl.org/group/perl.cpan.testers/285112
>
> It looks like this particular system is not noticing that Test::Exception
> requires Sub::Uplevel, then gets confused thinking it was *my* module that
> needed Sub::Uplevel. What's even more concerning is the presence of line
> noise right after the "make test FAILED"... Any idea what can be going on
> here?
>
> Thanks,
> Tyler
>
>

Re: YAML and Makefile.PL (was various topics)

[brian d foy]

In article <[EMAIL PROTECTED]>, Adam
Kennedy <[EMAIL PROTECTED]> wrote:

> The big advantage I see here is it's not you doing the work, it's 
> everybody else.
> 
> I generally don't have too much of a problem doing incrementals...
> 
> cd trunk/Module-Name
> ppichangeversion 0.14 0.15
> perl ../../tools/build_cpan.pl --install --commit --upload Module-Name

> Incremental releasing is a toolchain problem. You can automate the thing 
> down to a single command if you care enough. (even if it's a bit at a time)
> 
> And aren't you writing Module::Release or something to do exactly that?

Module::Release does do all of that, but that doesn't mean I let it
blindly do its thing or that I want to upload 50 new dists to CPAN when
none of them change anything in the real code.

Re: Kwalitee in your dependencies (was CPAN Upload: etc etc)

[Tyler MacDonald]

OK, speaking of "Kwalitee", I saw cpants for the first time today.
And saw that it claims to update every sunday, but there hasn't been an
update since december 5th. I also saw this interesting .pm file that
appeared to have an anonymous hash of every tarball in CPAN in it, all on
one line. That nearly crashed my browser. :-) What's up with CPANTS? Is it a
defunct project?

- Tyler

Re: bug with Test::Exception? or imacat's autotest box?

[Sébastien Aperghis-Tramoni]

Tyler MacDonald wrote:


Take a look at this output:

http://www.nntp.perl.org/group/perl.cpan.testers/285112

It looks like this particular system is not noticing that 
Test::Exception
requires Sub::Uplevel, then gets confused thinking it was *my* module 
that
needed Sub::Uplevel. What's even more concerning is the presence of 
line
noise right after the "make test FAILED"... Any idea what can be going 
on

here?


CPANPLUS sent the report to your module because its tests failed, 
because it uses Test::Exception which uses Sub::Uplevel which wasn't 
available during the test phase. The reason why Sub::Uplevel is missing 
may come from a problem in IMACAT's box, or maybe not. Details are 
missing because of the still present interaction problem between 
CPANPLUS and Module::Build. What you call "line noise" is most probably 
"File not found" in Chinese or Taiwanese.


The best thing is to ask IMACAT to send you a more detailed report.


Sébastien Aperghis-Tramoni
 -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]
Close the world, txEn eht nepO

Re: bug with Test::Exception? or imacat's autotest box?

[Tyler MacDonald]

imacat <[EMAIL PROTECTED]> wrote:
> > That sucks. :-( If imacat's box has gone AWOL, is there anything
> > cpan testers can do to flag it as such? At least until his/her attention is
> > grabbed and the problem is addressed?
> 
> I'll look into it and return ASAP.  It's Chinese New Year here, so
> give me a break and allow some delay, OK?  You could write to me again
> if I do not return for some certain period.

I wouldn't have suggested that unless fergal had indicated that it
was a long-standing issue. Now that I know you're aware of the problem and
looking into it, I thank you and will patiently await your reply. :)

Happy year of the dog!

- Tyler

Re: TODO test paradox: better TODO test management?

[A. Pagaltzis]

* chromatic <[EMAIL PROTECTED]> [2006-01-31 22:50]:
>How would that work for you?

Sounds exactly like things should be.

Regards,
-- 
Aristotle Pagaltzis // 

goto

[Larry Wall]

Just added the following to S04:

=head1 The goto statement

In addition to C, C, and C, Perl 6 also supports
C.  As with ordinary loop controls, the label is searched for
first lexically within the current subroutine, then dynamically outside
of it.  Unlike with loop controls, however, scanning a scope includes
a scan of any lexical scopes included within the current candidate
scope.  As in Perl 5, it is possible to C into a lexical scope,
but only for lexical scopes that require no special initialization
of parameters.  (Initialization of ordinary variables does not
count--presumably the presence of a label will prevent code-movement
optimizations past the label.)  So, for instance, it's always possible
to goto into the next case of a C or into either the "then"
or "else" branch of a conditional.  You may not go into a C
or a C, though, because that would bypass a formal parameter
binding (not to mention list generation in the case of C).
(Note: the implicit default binding of an outer $_ to an inner $_
can be emulated for a bare block, so that doesn't fall under the
prohibition on bypassing formal binding.)

Larry

Re: bug with Test::Exception? or imacat's autotest box?

[James E Keenan]

Sébastien Aperghis-Tramoni wrote:



CPANPLUS sent the report to your module because its tests failed, 
because it uses Test::Exception which uses Sub::Uplevel which wasn't 
available during the test phase. The reason why Sub::Uplevel is missing 
may come from a problem in IMACAT's box, or maybe not. Details are 
missing because of the still present interaction problem between 
CPANPLUS and Module::Build. 


1.  I suspect that it reflects the bug in CPANPLUS referenced by Fergal 
in his posting.


2.  In Imacat's defense:  When I was working on revisions to 
ExtUtils::ModuleMaker last summer, I had frequent FAILS on Imacat's 
boxes for versions that PASSed on other people's boxes.  I corresponded 
with her, and ultimately concluded that the fault was with my code, not 
with her testing box.  While I don't know the specific details, she 
appears to keep a more pristine testing box than the other CPAN testers, 
so if you fail to include prerequisites or do something else that's not 
kosher, she (her box, actually) is more likely to give you a FAIL than 
other testers.


So my own rule of thumb is:  If my distro has passed all its tests on 
imacat's boxes, then it has *really* passed!


jimk

A GraphViz eye view of Parrot

[Allison Randal]

This'll likely be out-of-date tomorrow, but I found it useful as a  
quick snapshot/overview of the Parrot repository.


  http://www.lohutok.net/parrot.pdf (200k)

Allison

Re: PARROT_IN_EXTENSION

[Nicholas Clark]

On Tue, Jan 31, 2006 at 01:46:30PM -, Jonathan Worthington wrote:

> Both the #define and use of PARROT_DYNEXT_EXPORT look useless here, as it 
> is in the group's .c file that the symbol export stuff is needed in (and it 
> is there too).  Just tested and ci'd a change that removes them.
> 
> Hope this helps,

Thanks, yes it did. It let me remove the hack to define PARROT_IN_EXTENSION
in ponie's Configure.pl

Nicholas Clark

Re: bug with Test::Exception? or imacat's autotest box?

[Greg Matheson]

On Tue, 31 Jan 2006, Tyler MacDonald wrote:

> Take a look at this output:

> http://www.nntp.perl.org/group/perl.cpan.testers/285112

> It looks like this particular system is not noticing that Test::Exception
> requires Sub::Uplevel, then gets confused thinking it was *my* module that
> needed Sub::Uplevel. What's even more concerning is the presence of line
> noise right after the "make test FAILED"... Any idea what can be going on
> here?

It's a NLS error message. In Big 5, it says. 'This file or
directory does not exist.'

-- 
Greg MathesonVent the Pent.
 --Samuel Beckett

Re: bug with Test::Exception? or imacat's autotest box?

[Tyler MacDonald]

Greg Matheson <[EMAIL PROTECTED]> wrote:
> On Tue, 31 Jan 2006, Tyler MacDonald wrote:
> 
> > Take a look at this output:
> 
> > http://www.nntp.perl.org/group/perl.cpan.testers/285112
> 
> > It looks like this particular system is not noticing that Test::Exception
> > requires Sub::Uplevel, then gets confused thinking it was *my* module that
> > needed Sub::Uplevel. What's even more concerning is the presence of line
> > noise right after the "make test FAILED"... Any idea what can be going on
> > here?
> 
> It's a NLS error message. In Big 5, it says. 'This file or
> directory does not exist.'

Ahh, in my firefox it looked like a bunch of copyright symbols and
squiggly lines. Guess I've got a few fonts to install. :)

The weird thing is, on most chinese language webpages, I get little
squares with the 2-byte hex code for the appropriate character written
inside...

- Tyler

[perl #38392] [BUG] FreeBSD bugs with JIT on t/op/trans.t

[via RT]

# New Ticket Created by  Joshua Isom 
# Please include the string:  [perl #38392]
# in the subject line of all future correspondence about this issue. 
# https://rt.perl.org/rt3/Ticket/Display.html?id=38392 >


When using JIT on FreeBSD 6.0, there are multiple failures in 
t/op/trans.t.  Most are geometric, sinh, tanh, and atan2, so these 
might be covered by a previous report.  But in particular are bugs in 
pow.  I've tried to track it down more specifically but I don't seen to 
be succeeding, and only getting more confused.

Of test 18(pow) of t/op/trans.t, tests 1, 2, 3, 4, 5, 6, 11, and 15 
fail.  Generally either 0.0 is returned or nan.  In trying to track it 
down, I ran into something more confusing.  Here's a program to 
demonstrate it and it's return.

---
.sub main :main
 $N1 = 3.0
 $N2 = 5.0
 $N3 = pow $N1, $N2
 print $N3
 print "\n"
 $N3 = pow $N1, $N2
 print $N3
 print "\n"
.end
---
0.00
243.00
---

I've also noticed that pow_n_nc_nc optimizes away to just set, and 
trying -O0 doesn't disable optimization.  With -O1 -j, it persists...  
With -O2 -j, it disappears.

Running `./parrot -O2 -j t/op/trans_18.pasm`, only tests 2, 3, 4, 6, 
11, and 15 fail, meaning 1 and 5 succeed with the optimization enabled. 
  Many of the tests in t/op/trans.t fail entirely with -O2, opcodes not 
found, mainly because of using integer registers.