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

# 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 g

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

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 g

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

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 Su

A GraphViz eye view of Parrot

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

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. > >

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

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 n

goto

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,

Re: TODO test paradox: better TODO test management?

* chromatic <[EMAIL PROTECTED]> [2006-01-31 22:50]: >How would that work for you? Sounds exactly like things should be. Regards, -- Aristotle Pagaltzis //

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

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 her

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

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 mor

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

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.

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

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 ../..

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

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 em

Re: TODO test paradox: better TODO test management?

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 abo

Re: TODO test paradox: better TODO test management?

* 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.

Re: TODO test paradox: better TODO test management?

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,

pre0 non-smoke

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 Sta

Re: TODO test paradox: better TODO test management?

* 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

Re: TODO test paradox: better TODO test management?

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 abou

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

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=

Re: TODO test paradox: better TODO test management?

* 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, -- Arist

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

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

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

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

Re: TODO test paradox: better TODO test management?

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

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

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 p5

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

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 distrib

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

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. (Y

Re: TODO test paradox: better TODO test management?

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

Re: TODO test paradox: better TODO test management?

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 passin

Re: TODO test paradox: better TODO test management?

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 f

TODO test paradox: better TODO test management?

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

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

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 A

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

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 correct

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

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-Ge

Re: PARROT_IN_EXTENSION

"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 automatic

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

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: [perl #38348] [PATCH] Accept return values via a Continuation

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,

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

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

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

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 attemp

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

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 dat

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

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

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

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 (includ

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

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:

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

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. Giv

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

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 failu

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

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,