Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Leopold Toetsch]

On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:


I've spent too much time on this error, so I'm routing around it, but
I'd love to figure out what's causing it. In my local version of
Punie I get this error when I run 'make test':


[ ... ]


... Also, if I modify the Punie compiler to dump out generated PIR
to a file before it executes it, I get no errors even on the bytecode
version.


While this all smells like a GC bug, I don't see it with r11401 on 
darwin nor x86/linux. I've also run io_print_6 through valgrind on the 
latter, which also doesn't show any indication re string truncation.


Anyway, if it's a GC bug, the following should succeed:

  punie$ TEST_PROG_ARGS=-G make test

and

  $ ./parrot -G languages/punie/punie.pbc 
languages/punie/t/io_print_6.p1



Thanks,
Allison


leo

Re: pugs link error

[Beau E. Cox]

On Wednesday 01 February 2006 09:10 am, Audrey Tang wrote:
> Beau E. Cox wrote:
> > Compiled/intstalled parrot-0.4.1 revision 11397 (svn). OK.
> > Downloaded pugs 6.2.11 revision 8909 (svn).
>
> r8927 added a probe to Makefile.PL: According to Leo, you need to keep
> the original Parrot source tree around, and let Pugs find one of
> src/{null,parrot,install}_config.o for embedding to happen.
>
> Thanks for the prompt feedback. :)
>
> Audrey

And thank you, Audrey, for the help. I was trying to 'skate' by
just pointing PARROT_PATH to /usr/bin/parrot-config w/o any built source
tree. All OK now.

-- 
Aloha => Beau;

Re: [Module::Build] [RFC] author tests

[Tyler MacDonald]

Adam Kennedy <[EMAIL PROTECTED]> wrote:
> Write this up. Then exhaustively test it on every single Perl platform 
> (50ish?) and every Perl version back to 5.004, including a random 
> collection similarly weird combinations (5.004 VMS, "that" 5.6.0 from 
> RedHat 7, 5.6.1 on Windows 95).

I let testers.cpan.org and ppm.activestate.com take care of that.

> Then make sure the code is so clean and complete you'll never need add 
> another lines of code or tweak the docs.

That's difficult, which is why nearly every core perl module has a
newer version available on CPAN...

> Then lets think about adding a new compulsory near-core dependency.

Ok, so Chris and I were getting a bit too excited about the idea. :)

A new module doesn't need to be added to the core, so long as there
is a way that we can reliably detect when a person wishes to build and test
any given perl package for an objectively unselfish purpose such as
1:prepackaging, 2:automated testing, or 3:releasing. All three are viral so
it's best to make sure they do no harm, while still maintaining some level
of convenience for the "end user".

There's already AUTOMATED_TESTING for 2 and "make disttest" for #3
(just keep a file around in your repo that's not in your MANIFEST and test
for it's presence.)

Any good way to detect #1?

And now that I think about it, I'm not so convinced about that whole
"concenience for the end user" nonsense. If they're mucking about installing
perl modules from the CPAN packages by themself, they're probably developers
that need some extra time to sit there and think about what sort of madness
they're getting themselves into anyway.

- Tyler

Re: [perl #38405] [PATCH] cleanup Makefiles for cleaning/building, plus shared for darwin

[Joshua Hoblitt]

The the darwin hints and MANIFEST.generated changes look OK but the
root.in changes will review some more review.

As a side note it's pretty clear that MANIFEST.generated needs to be
machine generated itself.

-J

--
On Wed, Feb 01, 2006 at 04:53:46PM -0800, Joshua Isom wrote:
> # New Ticket Created by  Joshua Isom 
> # Please include the string:  [perl #38405]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38405 >
> 
> 
> I've made a patch that modifies config/gen/makefiles/root.in and a 
> couple others to simplify things and improve "archclean".  At the same 
> time, it changes several directory paths to use variables to help any 
> possible future restructuring.  But I did notice that some files listed 
> in the generated Makefile but not in root.in don't use the variables at 
> all(I haven't looked, but I'll assume they're in few locations in the 
> config pm's).
> 
> Another thing I added is support for a shared parrot on darwin.  I left 
> shared support off in the hints.  Things like make world and make test 
> would still work, but running parrot from the build directory(if the 
> shared library isn't installed, and the env variable isn't set) won't 
> work.  It would effect everything in languages/.
> 




pgpeftE2L8hTy.pgp
Description: PGP signature

Development version

[Beau E. Cox]

Hi -

Congrats on your 6.2.11 release!

Did the development (svn) version really jump to 6.28.0?

I am running some scripts to automate a refresh of parrot and
pugs weekly so I can stay in tune with the current effort.
To identify my svn downloads by version and revision I:

1) slurp ChangeLog and pull version from /(\d+.\d+\.\d+)/s.
2) get revision from the svn output:
revision=$(tail -n1 svn.log|perl -e ';$_=<>;$r=/rev.*?(\d+)/i ? $1 : "";print 
$r') \

Two questions:

1) Are version and revision available in the source tree in a
   format easier to use?
2) If not, would the group consider maintaining a VERSION or
   VERSION and REVISION files in the root of the tree that
   could simply be cat'ed?

-- 
Aloha => Beau;

Re: Supporting C static storage

[Leopold Toetsch]

Leopold Toetsch wrote:


But C statics can of course change. The problems is, where to
store the static variable, especially native integers.


Another idea:

We keep the call frame of subs with statics (or Perl6 INIT and FIRST 
blocks) after returning from the sub. Additionally, we can set a new 
entrypoint for the sub after running the INIT code (or static 
initializer). The entrypoint would be reset for cloning closures to 
achieve perl6 FIRST block semantics.


The draw backs are increased memory usage and it doesn't work together 
with recursive subroutines easily, albeit I don't know, if recursive 
subs with statics are really meaningful.


E.g.

.sub "gen_random"
.param float max
.static int last  # just an alias for .local maybe
last = 42
after_init gen_random_init_done   # move sub entry point
goto gen_rand_2   # after_init could branch too
gen_random_init_done: #   automatically
.param float max  # duplicated get_params
gen_rand_2

.end

Comments welcome,
leo

Re: [Module::Build] [RFC] author tests

[Yitzchak Scott-Thoennes]

On Thu, Feb 02, 2006 at 02:56:09AM -0800, Tyler MacDonald wrote:
>   A new module doesn't need to be added to the core, so long as there
> is a way that we can reliably detect when a person wishes to build and test
> any given perl package for an objectively unselfish purpose such as
> 1:prepackaging, 2:automated testing, or 3:releasing. All three are viral so
> it's best to make sure they do no harm, while still maintaining some level
> of convenience for the "end user".
> 
>   There's already AUTOMATED_TESTING for 2 and "make disttest" for #3
> (just keep a file around in your repo that's not in your MANIFEST and test
> for it's presence.)
> 
>   Any good way to detect #1?

An environment variable.  PERL_TEST_EXHAUSTIVE?  And make/Build
disttest can set it too.

In the perl core, the few tests that are normally not run are
requested by a -torture switch.  But I think despite this precedent
exhaustive sounds better.

But please, lets not have new ta/ or whatever directories or .ta
files; this is a problem that is well taken care of with skip_all.

If somebody really wants, they could go the Test::Exhaustive
route, which would automatically do the skip_all if the env vars
weren't set.  But putting a few stock lines at the start of your
.t file isn't really all that big a deal.

Re: [Module::Build] [RFC] author tests

[Steffen Mueller]

Hi,

Tyler MacDonald wrote:

And now that I think about it, I'm not so convinced about that whole
"concenience for the end user" nonsense. If they're mucking about installing
perl modules from the CPAN packages by themself, they're probably developers
that need some extra time to sit there and think about what sort of madness
they're getting themselves into anyway.


I strongly disagree! CPAN is the preferred source for any Perl modules 
and the associated tools like CPAN.pm or CPANPLUS are the preferred 
method of installing them. Why? Because since you are not going to see 
all modules in .deb or whatever packages and not in the most recent 
versions. Using both the system's package system and CPAN's for module 
installation is going to bite you on most systems some day.


Also, if you write applications that use CPAN modules, you might a) not 
have the license to include the modules or b) not want to be responsible 
for maintaining the bundled versions or c) not want to inflict 5 
gazillion installed versions of module Foo on every user and d) not want 
to create different distributions for different platforms.


Thus, user's need to be able to install Perl modules from CPAN.

Of course, that's just my understanding and my opinion. I have had to 
maintain such a cross-platform application that needed to bundle a lot 
of modules. It was hell.


We're extraordinarily lucky to have such a good toolchain and such a 
great repository of modules.


Steffen

Re: [Module::Build] [RFC] author tests

[Chris Dolan]

On Feb 1, 2006, at 10:35 PM, Tyler MacDonald wrote:


Chris Dolan <[EMAIL PROTECTED]> wrote:

There is a class of tests that module authors perform that end users
are not expected to run.  For example code coverage tests, spelling
tests, coding style tests, etc.  These tests are either prohibitively
expensive or complicated or unpredictable for end users to run.  I
call these "private tests" or author tests.


I really like this idea. But as you pointed out, it's not just
authors that need to worry about running these tests, it's packagers
(ppm/deb/etc), automated testers (cpants/testers.cpan.org/etc), and  
hackers.

I'd suggest we call these "exhaustive" tests.


No, I disagree.  I'm specifically talking about author tests, NOT  
packager tests.  Things like Test::Spelling are pointless and  
difficult for packagers to execute because Test::Spelling relies on  
an external aspell or ispell program *and* performs differently in  
the presence of an author's custom dictionary (mine has "Dolan"; does  
yours?)


These specifically are not exhaustive tests but spit-and-polish tests.

To make this less abstract, let me list the specific author tests  
that I employ for most of my CPAN modules, along with an explanation  
of why it wouldn't work for a packager


 * copyright.t - Ensures that there is a "Copyright ".([localtime]-> 
[5]+1900) somewhere in every .pm file.  Will break 11 months from now.
 * distribution.t - Relies on Test::Distribution, which is not in my  
prereq list
 * perlcritic.t - Runs Test::Perl::Critic on all .pm files.  Will  
fail without my specific $HOME/.perlcriticrc and will fail with  
future, more exhaustive versions of P::C
 * spelling.t - Runs Test::Spelling.  Will fail without my custom  
dictionary
 * versionsync.t - Checks that the $VERSION is the same in all bin/*  
and *.pm files.  This test is pointless after release, since it's  
already been tested before release
 * pod.t - Checks POD validity.  This test is pointless after  
release, since it's already been tested before release
 * pod-coverage.t - Checks POD completeness.  This test is pointless  
after release, since it's already been tested before release


and one I have not yet employed:
 * coverage.t - Ensures that Devel::Cover totals are higher than  
some threshold


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: Supporting C static storage

[Larry Wall]

On Thu, Feb 02, 2006 at 12:51:36PM +0100, Leopold Toetsch wrote:
: Another idea:
: 
: We keep the call frame of subs with statics (or Perl6 INIT and FIRST 
: blocks) after returning from the sub. Additionally, we can set a new 
: entrypoint for the sub after running the INIT code (or static 
: initializer). The entrypoint would be reset for cloning closures to 
: achieve perl6 FIRST block semantics.

Uh, maybe I'm pointing out something that's already blindingly obvious
to everyone else, but for "state" variables cloned closures can't
use the same static storage location.  (Or is that what you're meaning
already by "keep the call frame"?)

: The draw backs are increased memory usage and it doesn't work together 
: with recursive subroutines easily, albeit I don't know, if recursive 
: subs with statics are really meaningful.

Unlike the situation with clones, a "state" variable *is* shared
between recursive invocations.  As for whether that's meaningful,
I don't know either.  But you could, say, temporize such a variable
just like a global, and that might make some kind of sense.  Anyway,
the P6 model of "state" is more like a persistent lexical than like
C's static.  (Though of course Parrot will probably want C's static
semantics for various other languages...)

Anyway, I thought I'd clarify a bit--we just don't want people
confusing "state" with "static", given the similarity of the names.

Larry

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Larry Wall]

On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
: 
: On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
: 
: >I've spent too much time on this error, so I'm routing around it, but
: >I'd love to figure out what's causing it. In my local version of
: >Punie I get this error when I run 'make test':
: 
: [ ... ]
: 
: >... Also, if I modify the Punie compiler to dump out generated PIR
: >to a file before it executes it, I get no errors even on the bytecode
: >version.
: 
: While this all smells like a GC bug, I don't see it with r11401 on 
: darwin nor x86/linux. I've also run io_print_6 through valgrind on the 
: latter, which also doesn't show any indication re string truncation.
: 
: Anyway, if it's a GC bug, the following should succeed:
: 
:   punie$ TEST_PROG_ARGS=-G make test
: 
: and
: 
:   $ ./parrot -G languages/punie/punie.pbc 
: languages/punie/t/io_print_6.p1

As another datapoint on what *might* be the same bug, there are two
PGE failures I get regressing Pugs using embedded Parrot, saying
something like:

error:imcc:syntax error, unexpected ']'
in file 'EVAL_6' line 99

Which seems similar though not identical to Allison's error message.

Anyway, it still fails using TEST_PROG_ARGS=-G on the Pugs test, though
I don't know if the embedding interface examines TEST_PROG_ARGS.
And it could well be a Pugs bug, though the fact that that tests
pass with external rather than embedded Parrot seems to indicate not.

That's all FWIW.  No time to pursue it further, unfortunately...

Larry

Re: [Module::Build] [RFC] author tests

[Tyler MacDonald]

Steffen Mueller <[EMAIL PROTECTED]> wrote:
> > And now that I think about it, I'm not so convinced about that whole
> >"concenience for the end user" nonsense. If they're mucking about
> >installing perl modules from the CPAN packages by themself, they're
> >probably developers that need some extra time to sit there and think
> >about what sort of madness they're getting themselves into anyway.
> I strongly disagree! CPAN is the preferred source for any Perl modules 
> and the associated tools like CPAN.pm or CPANPLUS are the preferred 
> method of installing them. Why? Because since you are not going to see 
> all modules in .deb or whatever packages and not in the most recent 
> versions. Using both the system's package system and CPAN's for module 
> installation is going to bite you on most systems some day.

Steffen,

I more meant the madness they are getting themselves into by
programming in perl in the first place. :-)

- Tyler

Re: [Module::Build] [RFC] author tests

[A. Pagaltzis]

* Chris Dolan <[EMAIL PROTECTED]> [2006-02-02 16:55]:
>On Feb 1, 2006, at 10:35 PM, Tyler MacDonald wrote:
>>I really like this idea. But as you pointed out, it's not just
>>authors that need to worry about running these tests, it's
>>packagers (ppm/deb/etc), automated testers
>>(cpants/testers.cpan.org/etc), and  hackers.
>
>No, I disagree. I'm specifically talking about author tests, NOT
>packager tests. Things like Test::Spelling are pointless and
>difficult for packagers to execute because Test::Spelling relies
>on  an external aspell or ispell program *and* performs
>differently in  the presence of an author's custom dictionary
>(mine has "Dolan"; does  yours?)
>
>These specifically are not exhaustive tests but spit-and-polish
>tests.

I was just gonna say. It’s pointless for anyone but the author to
check POD or test coverage. Only under the assumption that the
author was negligent and shipped a distribution without running
the POD tests does it make any sense for a packager to run them.
And then it still doesn’t make sense for *every* packager to run
them. Similarly for Devel::Cover – what’s the packager to do,
write more tests to include with the platform-specific package?
That makes no sense.

These are tests that need to pass once on the author’s system
*before* release. If a release is cut without them passing, it’s
pointless of others to re-run them.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Supporting C static storage

[Leopold Toetsch]

Larry Wall wrote:

On Thu, Feb 02, 2006 at 12:51:36PM +0100, Leopold Toetsch wrote:
: Another idea:
: 
: We keep the call frame of subs with statics (or Perl6 INIT and FIRST 
: blocks) after returning from the sub. Additionally, we can set a new 
: entrypoint for the sub after running the INIT code (or static 
: initializer). The entrypoint would be reset for cloning closures to 
: achieve perl6 FIRST block semantics.


Uh, maybe I'm pointing out something that's already blindingly obvious
to everyone else, but for "state" variables cloned closures can't
use the same static storage location.  (Or is that what you're meaning
already by "keep the call frame"?)


Yep. With the scheme mentioned above a cloned closure would get a fresh 
'state' variable as it of course needs distinct registers (aka call 
frame) too.


: The draw backs are increased memory usage and it doesn't work together 
: with recursive subroutines easily, albeit I don't know, if recursive 
: subs with statics are really meaningful.


Unlike the situation with clones, a "state" variable *is* shared
between recursive invocations.  As for whether that's meaningful,
I don't know either.  


That's the same with a C static. Rescursion (not tail recursion) would 
need some extra copying of state vars and book-keeping of register frames.



...But you could, say, temporize such a variable
just like a global, and that might make some kind of sense. 


Yep.


... Anyway,
the P6 model of "state" is more like a persistent lexical than like
C's static.  


Sorry for my dumb question - what's the difference then? (Besides that C 
dosn't have closures ;)



... (Though of course Parrot will probably want C's static
semantics for various other languages...)




Anyway, I thought I'd clarify a bit--we just don't want people
confusing "state" with "static", given the similarity of the names.

Larry


leo

Re: [Module::Build] [RFC] author tests

[Tyler MacDonald]

Chris Dolan <[EMAIL PROTECTED]> wrote:
>  * copyright.t - Ensures that there is a "Copyright ".([localtime]-> 
> [5]+1900) somewhere in every .pm file.  Will break 11 months from now.
>  * distribution.t - Relies on Test::Distribution, which is not in my  
> prereq list
>  * perlcritic.t - Runs Test::Perl::Critic on all .pm files.  Will  
> fail without my specific $HOME/.perlcriticrc and will fail with  
> future, more exhaustive versions of P::C
>  * spelling.t - Runs Test::Spelling.  Will fail without my custom  
> dictionary
>  * versionsync.t - Checks that the $VERSION is the same in all bin/*  
> and *.pm files.  This test is pointless after release, since it's  
> already been tested before release
>  * pod.t - Checks POD validity.  This test is pointless after  
> release, since it's already been tested before release
>  * pod-coverage.t - Checks POD completeness.  This test is pointless  
> after release, since it's already been tested before release
> 
> and one I have not yet employed:
>  * coverage.t - Ensures that Devel::Cover totals are higher than  
> some threshold

Wow, you really *are* exhaustive. How do you find the time to write any
code? ;-)

Now that I understand exactly what you mean by "author" tests, here's what I
think: Whatever convention you're using, if these tests are only going to
work on your system, then they definately shouldn't be in "t". And since
there's absolutely no value in these types of tests for anybody else except
the module author, there's no real point in having a convention, just stick
'em anywhere that the make/buildfiles will ignore them.

- Tyler

Re: [Module::Build] [RFC] author tests

[Tyler MacDonald]

A. Pagaltzis <[EMAIL PROTECTED]> wrote:
> I was just gonna say. It???s pointless for anyone but the author to
> check POD or test coverage.

I agree about the POD coverage. But if I got a different level of
code coverage on somebody else's system than my own? I'd be very interested
in finding out why. I was actually considering playing with YACSmoke and
Devel::Cover to make a site that shows the code coverage metrics for all of
CPAN, but then I realised that I'm getting far too obsessed with this
testing stuff and I need to focus on writing real code if I ever want to
finish an application. :-)

- Tyler

Re: [Module::Build] [RFC] author tests

[Christopher H. Laco]

A. Pagaltzis wrote:
> * Chris Dolan <[EMAIL PROTECTED]> [2006-02-02 16:55]:
>> On Feb 1, 2006, at 10:35 PM, Tyler MacDonald wrote:
>>> I really like this idea. But as you pointed out, it's not just
>>> authors that need to worry about running these tests, it's
>>> packagers (ppm/deb/etc), automated testers
>>> (cpants/testers.cpan.org/etc), and  hackers.
>> No, I disagree. I'm specifically talking about author tests, NOT
>> packager tests. Things like Test::Spelling are pointless and
>> difficult for packagers to execute because Test::Spelling relies
>> on  an external aspell or ispell program *and* performs
>> differently in  the presence of an author's custom dictionary
>> (mine has "Dolan"; does  yours?)
>>
>> These specifically are not exhaustive tests but spit-and-polish
>> tests.
> 
> I was just gonna say. It’s pointless for anyone but the author to
> check POD or test coverage. Only under the assumption that the
> author was negligent and shipped a distribution without running
> the POD tests does it make any sense for a packager to run them.
> And then it still doesn’t make sense for *every* packager to run
> them. Similarly for Devel::Cover – what’s the packager to do,

Normally I'd agree, but that's not 100% set in stone. I work on
Linux/Win32 and run the usual pod syntax/coverage tests on those platforms.

I also have FreeBSD servers for which package could/would be created. On
more than one occasion, I've had pod2html/man (troff) errors under
FreeBSD that were only found by running the author tests there, even
though the pod syntax/coverage was perfectly fine on two other platforms.

It's these sorts of problems where the packager running those tests are
quite beneficial...Especially on platforms where the packagers/dists may
be adding patches to the core dist.

-=Chris



signature.asc
Description: OpenPGP digital signature

Re: [Module::Build] [RFC] author tests

[chromatic]

On Thursday 02 February 2006 10:04, Tyler MacDonald wrote:

> A. Pagaltzis <[EMAIL PROTECTED]> wrote:

> > I was just gonna say. It???s pointless for anyone but the author to
> > check POD or test coverage.

>   I agree about the POD coverage. But if I got a different level of
> code coverage on somebody else's system than my own? I'd be very interested
> in finding out why.

Perhaps this is something PITA could report.

-- c

Re: [Module::Build] [RFC] author tests

[chromatic]

On Thursday 02 February 2006 02:56, Tyler MacDonald wrote:

>   And now that I think about it, I'm not so convinced about that whole
> "concenience for the end user" nonsense. If they're mucking about
> installing perl modules from the CPAN packages by themself, they're
> probably developers that need some extra time to sit there and think about
> what sort of madness they're getting themselves into anyway.

Ahh, but what about all of those developers using Perl 5.004 who just *have* 
to be on the bleeding edge of new code?

(Yeah, I don't understand that argument either.)

-- c

Is S05 correct?

[Yiyi Hu]

Hmm,
There are sevral appears in S05 which use => instead of -> in a for loop.
So, Is this a typo?
eg:
for @{$} => $pair {
say "Key: $pair[0]";
say "Val: $pair[1]";
}

Thanks,
Xinming

Re: Is S05 correct?

[Larry Wall]

On Fri, Feb 03, 2006 at 03:02:12AM +0800, Yiyi Hu wrote:
: Hmm,
: There are sevral appears in S05 which use => instead of -> in a for loop.
: So, Is this a typo?
: eg:
: for @{$} => $pair {
: say "Key: $pair[0]";
: say "Val: $pair[1]";
: }

Yes, that's a typo.  Thanks.  It is now fixed on svn.perl.org, and
should propagate to dev.perl.org by tomorrow.

Larry

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Patrick R. Michaud]

On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
> On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
> 
> >I've spent too much time on this error, so I'm routing around it, but
> >I'd love to figure out what's causing it. In my local version of
> >Punie I get this error when I run 'make test':
> 
> While this all smells like a GC bug, I don't see it with r11401 on 
> darwin nor x86/linux. I've also run io_print_6 through valgrind on the 
> latter, which also doesn't show any indication re string truncation.
> 
> Anyway, if it's a GC bug, the following should succeed:
> 
>   punie$ TEST_PROG_ARGS=-G make test

This may or may not be related, but I'm getting a segfault for
building PGE itself (x86_64/linux), when trying to run mklib.pir
to generate the built-in rules.

This is one of the first times I've tried any of this under
64-bit linux, so it might be totally unrelated.  At any rate,
I've *finally* gotten many of my other tasks out of the way so
I'm back on the case.  :-)

Pm

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[jerry gay]

On 2/2/06, Patrick R. Michaud <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 02, 2006 at 11:33:25AM +0100, Leopold Toetsch wrote:
> > On Feb 2, 2006, at 2:33, Allison Randal (via RT) wrote:
> >
> > >I've spent too much time on this error, so I'm routing around it, but
> > >I'd love to figure out what's causing it. In my local version of
> > >Punie I get this error when I run 'make test':
> >
> > While this all smells like a GC bug, I don't see it with r11401 on
> > darwin nor x86/linux. I've also run io_print_6 through valgrind on the
> > latter, which also doesn't show any indication re string truncation.
> >
> > Anyway, if it's a GC bug, the following should succeed:
> >
> >   punie$ TEST_PROG_ARGS=-G make test
>
> This may or may not be related, but I'm getting a segfault for
> building PGE itself (x86_64/linux), when trying to run mklib.pir
> to generate the built-in rules.
>
i'm getting this, too, on win32. as are others, i think, on many platforms.

> This is one of the first times I've tried any of this under
> 64-bit linux, so it might be totally unrelated.  At any rate,
>
  cd compilers/pge && ../../parrot -t mklib.pir >PGE/Library.pir

near the end of it's output, reports:

[snip]
  3229 callmethodcc P0, "genfixedstr"   - P0=Object(PGE::Exp::Literal)=PMC(0x417
020),
  1973 get_params PMC_C[266] (7), P2, P0, S3, S2, S5, S4, S0- , P2=PMCNULL,
P0=PMCNULL, , , , ,
  1982 set_args PMC_C[24] (1), P2   - , P2=Object(PGE::Exp::Literal)=PMC(0x4
17020)
  1985 get_results PMC_C[236] (5), I3, I0, I4, I1, S-1  - , I3=0, I0=2,
I4=1, I1=0, S-1="(null)"
  1992 callmethodcc P2, "quant" - P2=Object(PGE::Exp::Literal)=PMC(0x417
020),
  1898 get_params PMC_C[24] (1), P0 - , P0=PMCNULL
[snip]

what the heck is register "S-1" in the get_results op??
when parrot got infinite registers, i don't think that meant they
could be negative, too :)

maybe that'll help track things down.


> I've *finally* gotten many of my other tasks out of the way so
> I'm back on the case.  :-)
>
yay! welcome back.
~jerry

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Leopold Toetsch]

Patrick R. Michaud wrote:


This may or may not be related, but I'm getting a segfault for
building PGE itself (x86_64/linux), when trying to run mklib.pir
to generate the built-in rules.


Yep. Working on that currently. I've simplied it to this testcase now:

.sub main :method
.local int a
(a,$S0) = self."foo"()
self."bar"()
.end

This isn't runnable per se it dies of course with method not found. But 
it's revealing that both 'a' and '$S0' aren't getting any register (# 
-1) assigned. Both symbols are missing from the symbol list;


$ parrot -dff -tf c.pir 2>&1 | less

This might be some reason for further PGE errors or not, I'm still 
investigating the real problem, which just got unhidden by r11402.



Pm


leo

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Patrick R. Michaud]

On Thu, Feb 02, 2006 at 01:32:49PM -0800, jerry gay wrote:
> > This may or may not be related, but I'm getting a segfault for
> > building PGE itself (x86_64/linux), when trying to run mklib.pir
> > to generate the built-in rules.
> >
> i'm getting this, too, on win32. as are others, i think, on many platforms.
> 
> > This is one of the first times I've tried any of this under
> > 64-bit linux, so it might be totally unrelated.  At any rate,
> >
>   cd compilers/pge && ../../parrot -t mklib.pir >PGE/Library.pir
> 
> near the end of it's output, reports:
> 
>   3229 callmethodcc P0, "genfixedstr"   - 
> P0=Object(PGE::Exp::Literal)=PMC(0x417
> 020),
>   1973 get_params PMC_C[266] (7), P2, P0, S3, S2, S5, S4, S0- , 
> P2=PMCNULL,
> P0=PMCNULL, , , , ,
>   1982 set_args PMC_C[24] (1), P2   - , 
> P2=Object(PGE::Exp::Literal)=PMC(0x4
> 17020)
>   1985 get_results PMC_C[236] (5), I3, I0, I4, I1, S-1  - , I3=0, 
> I0=2,
> I4=1, I1=0, S-1="(null)"
>   1992 callmethodcc P2, "quant" - 
> P2=Object(PGE::Exp::Literal)=PMC(0x417
> 020),
>   1898 get_params PMC_C[24] (1), P0 - , P0=PMCNULL
> [snip]
> 
> what the heck is register "S-1" in the get_results op??
> when parrot got infinite registers, i don't think that meant they
> could be negative, too :)

*Very* interesting -- I got the same problem.  The call
that generates the above is

(min, max, islazy, iscut, $S0) = self."quant"()

where the $S0 is a dummy register that isn't used anywhere
else in the subroutine.  If I convert this to a real
register, as in

(min, max, islazy, iscut, S8) = self."quant"()

then the segfault goes away.  (Through judicious print
statements I was also able to narrow the problem
down to this specific call.)

I see the "-1" registers appear elsewhere in the output,
for example, the following call has $I2 and $I3
which aren't used in the rest of the subroutine:

($I0, $I1, $I2, $I3, $S0) = self."quant"()

It produces:

  3165 set_args PMC_C[24] (1), P0   - , 
P0=Object(PGE::Exp::Literal)=PMC(0x906d10)
  3168 get_results PMC_C[236] (5), I1, I0, I-1, I-1, S0 - , I1=0, I0=0, 
I-1=17, I-1=17,
  3175 callmethodcc P0, "quant" - 
P0=Object(PGE::Exp::Literal)=PMC(0x906d10),

If I need to be doing something else for parameter placeholders,
let me know.  I haven't tried the absolute register version 
(that doesn't segfault for me) on Allison's code yet, I'll work 
on that next.

Pm

Re: Supporting C static storage

[Larry Wall]

On Thu, Feb 02, 2006 at 07:12:08PM +0100, Leopold Toetsch wrote:
: >... Anyway,
: >the P6 model of "state" is more like a persistent lexical than like
: >C's static.  
: 
: Sorry for my dumb question - what's the difference then? (Besides that C 
: dosn't have closures ;)

That *is* the difference.  But for those of us handicapped by coming
from a C background, the extension of "static" semantics into closure
space would tend to lead one toward thinking that all clones share a
particular state variable, because a C programmer doesn't really known
when he's confusing a particular storage mechanism with a particular
semantic model.  But then, all humans tend to confuse cultural truth
with universal truth--even when (some would say "especially when")
they come from a culture that aspires to learn universal truth.

Hmm, I'm not sure I've ever slammed fundamentalists and mathematicians
in the same sentence before...  :-)

Larry

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Leopold Toetsch]

Leopold Toetsch wrote:


.sub main :method
.local int a
(a,$S0) = self."foo"()
self."bar"()
.end


and

  > ... get_results PMC_C[236] (5), I3, I0, I4, I1, S-1

This is solved now with r11408 / r11409.

leo

Re: [Module::Build] [RFC] author tests

[A. Pagaltzis]

* Christopher H. Laco <[EMAIL PROTECTED]> [2006-02-02 18:50]:
>On more than one occasion, I've had pod2html/man (troff) errors
>under FreeBSD that were only found by running the author tests
>there, even though the pod syntax/coverage was perfectly fine on
>two other platforms.

Are you sure that’s not instead an argument from fixing the
corresponding pod2foo converter to behave on that platform?

Regards,
-- 
Aristotle Pagaltzis // 

Re: [perl #38406] [BUG] PGE - truncating PIR code generated by p6rule

[Patrick R. Michaud]

On Wed, Feb 01, 2006 at 05:33:29PM -0800, Allison Randal wrote:
> # New Ticket Created by  Allison Randal 
> # Please include the string:  [perl #38406]
> # in the subject line of all future correspondence about this issue. 
> # https://rt.perl.org/rt3/Ticket/Display.html?id=38406 >
> 
> 
> I've spent too much time on this error, so I'm routing around it, but  
> I'd love to figure out what's causing it. In my local version of  
> Punie I get this error when I run 'make test':

...as of r11409, I'm not seeing the 'make test' error for punie
(on my Linux/x86_64 box).

I don't know if this is because it's now working, or because you've
routed around the particular problem you were seeing, so let
me know if you're still getting the error and I'll look into it
right away.  I definitely would like to make sure it's not a PGE
issue.  :-)

Pm

Re: Macros?

[Larry Wall]

On Sun, Jan 29, 2006 at 08:13:44PM +, Luke Palmer wrote:
: On 1/29/06, Yuval Kogman <[EMAIL PROTECTED]> wrote:
: > Aside from that they are normal perl 6 subroutines, that simply get
: > invoked during compile time instead of during runtime.
: 
: With one extra "feature".  By default (my preference) or with a trait,
: parameters can get passed in as ASTs instead of real values:
: 
: macro debug ($var) {
: qq[print '$var.text() = ' ~ $var.text()]
: }
: debug($foo  );
: # expands to
: print '$foo   = ' ~ $var  ;
: 
: We would also like a quasiquoting mechanism, so don't have to rely on
: string concatenation, and we don't have to construct parse trees by
: hand.  It's sort of a happy medium.  But that is as yet unspecced.

S06 now sez:

+=head2 Macros

+Macros are functions or operators that are called by the compiler as
+soon as their arguments are parsed (if not sooner).  The syntactic
+effect of a macro declaration or importation is always lexically scoped,
+even if the name of the macro is visible elsewhere.  As with ordinary 
operators,
+macros may be classified by their grammatical category.  For a given 
grammatical
+category, a default parsing rule or set of rules is used, but those rules
+that have not yet been "used" by the time the macro keyword or token is seen
+can be replaced by use of "is parsed" trait.  (This means, for instance, that
+an infix operator can change the parse rules for its right operand but not its
+left operand.)
+
+A macro is called as if it were a method on the current match object returned
+from the grammar rule being reduced.
+
+Macros may return either a string to be reparsed, or a syntax tree
+that needs no further parsing.  The textual form is handy, but the
+syntax tree form is generally preferred because it allows the parser
+and debugger to give better error messages.  Textual substitution
+on the other hand tends to yield error messages that are opaque to
+the user.  Syntax trees are also better in general because they are
+reversible, so things like syntax highlighters can get back to the
+original language and know which parts of the derived program come
+from which parts of the user's view of the program.
+
+In aid of returning syntax tree, Perl provides a "quasiquoting" mechanism
+using the keyword "code", followed by a block intended to represent an AST:
+
+return code { say $a };
+
+[Conjecture: Other keywords are possible if we have more than one AST type.]
+
+Within a quasiquote, variable and function names resolve first of all
+according to the lexical scope of the macro definition, and if unrecognized in
+that scope, are assumed to be bound from the scope of the macro call
+each time it is called.  If they cannot be bound from the scope of
+the macro call, a compile-time exception is thrown.
+
+Variables that resolve from the lexical scope of the macro definition
+will be inserted appropriately depending on the type of the variable,
+which may be either a syntax tree or a string.  (Again, syntax tree
+is preferred.)  The case is similar to that of a macro called from
+within the quasiquote, insofar as reparsing only happens with the
+string version of interpolation, except that such a reparse happens at
+macro call time rather than macro definition time, so its result cannot
+change the parsers expections about what follows the interpolated variable.
+
+Hence, while the quasiquote itself is being parsed, the syntactic
+interpolation of a variable into the quasiquote always results in
+the expectation of an operator following the variable.  (You must
+use a call to a submacro if you want to expect something else.)
+Of course, the macro definition as a whole can expect whatever it
+likes afterwards, according to its syntactic category.  (Generally,
+a term expects a following postfix or infix operator, and an operator
+expects a following term or prefix operator.)
+
+In case of name ambiguity, prefix with C to indicate a name in
+the compiling scope, and C to indicate a name in the macro 
definition's
+scope.
+
+[Conjecture: Due to these dwimmy scoping rules, there is no need of
+a special "unquote" construct as in Scheme et al.]

Larry

embparrot still has two failures

[Larry Wall]

Failed Test   Stat Wstat Total Fail  Failed  List of Failed
---
t/rules/from_perl6_rules/array_ca   18  460845   10  22.22%  41-45
t/rules/from_perl6_rules/named_ca   18  460826   48 184.62%  3-26
1155 subtests skipped.
Failed 2/506 test scripts, 99.60% okay. 29/9078 subtests failed, 99.68% okay.

I narrowed the first one down to:

pugs> "GATTACA" ~~ m/ @bases:=[A|C|G|T]*/;
error:imcc:syntax error, unexpected ']'
in file 'EVAL_1' line 77

pugs -V:

This is Perl6 User's Golfing System, version 6.2.11, February 1, 2005 (r8945) 
built for i386-linux-thread-multi

Summary of pugs configuration:
archlib: /usr/lib/perl6/i386-linux-thread-multi
archname: i386-linux-thread-multi
bin: /usr/bin
exe_ext: 
file_sep: /
installarchlib: /usr/lib/perl6/i386-linux-thread-multi
installbin: /usr/bin
installman1dir: /usr/share/man/man1
installman3dir: /usr/share/man/man3
installprivlib: /usr/lib/perl6
installscript: /usr/bin
installsitearch: /usr/lib/perl6/site_perl/i386-linux-thread-multi
installsitebin: /usr/bin
installsitelib: /usr/lib/perl6/site_perl
installsiteman1dir: /usr/share/man/man1
installsiteman3dir: /usr/share/man/man3
osname: linux
pager: /usr/bin/less -isr
path_sep: :
perl5path: /usr/bin/perl
perl_revision: 6
perl_subversion: 0
perl_version: 0
prefix: /usr
privlib: /usr/lib/perl6
pugs_revision: 8945
pugs_version: Perl6 User's Golfing System, version 6.2.11, February 1, 
2005 (r8945)
pugs_versnum: 6.2.11
pugspath: /usr/bin/pugs
scriptdir: /usr/bin
sitearch: /usr/lib/perl6/site_perl/i386-linux-thread-multi
sitebin: /usr/bin
sitelib: /usr/lib/perl6/site_perl
siteprefix: /usr
sitescript: /usr/bin
sourcedir: /home/larry/pugs

@*INC:
/usr/lib/perl6/i386-linux-thread-multi
/usr/lib/perl6
/usr/lib/perl6/site_perl/i386-linux-thread-multi
/usr/lib/perl6/site_perl
/usr/lib/perl6/auto/pugs/perl6/lib
/usr/lib/perl6/site_perl/auto/pugs/perl6/lib
.

Larry

Re: Macros?

[Larry Wall]

After a little more cleanup, S06 now reads:

=head2 Macros

Macros are functions or operators that are called by the compiler as
soon as their arguments are parsed (if not sooner).  The syntactic
effect of a macro declaration or importation is always lexically
scoped, even if the name of the macro is visible elsewhere.  As with
ordinary operators, macros may be classified by their grammatical
category.  For a given grammatical category, a default parsing rule or
set of rules is used, but those rules that have not yet been "used"
by the time the macro keyword or token is seen can be replaced by
use of "is parsed" trait.  (This means, for instance, that an infix
operator can change the parse rules for its right operand but not
its left operand.)

In the absence of a signature to the contrary, a macro is called as
if it were a method on the current match object returned from the
grammar rule being reduced; that is, all the current parse information
is available by treating C as if it were a C<$/> object.
[Conjecture: alternate representations may be available if arguments
are declared with particular AST types.]

Macros may return either a string to be reparsed, or a syntax tree
that needs no further parsing.  The textual form is handy, but the
syntax tree form is generally preferred because it allows the parser
and debugger to give better error messages.  Textual substitution
on the other hand tends to yield error messages that are opaque to
the user.  Syntax trees are also better in general because they are
reversible, so things like syntax highlighters can get back to the
original language and know which parts of the derived program come
from which parts of the user's view of the program.

In aid of returning syntax tree, Perl provides a "quasiquoting"
mechanism using the keyword "CODE", followed by a block intended to
represent an AST:

return CODE { say $a };

[Conjecture: Other keywords are possible if we have more than one
AST type.]

Within a quasiquote, variable and function names resolve first of
all according to the lexical scope of the macro definition, and if
unrecognized in that scope, are assumed to be bound from the scope
of the macro call each time it is called.  If they cannot be bound
from the scope of the macro call, a compile-time exception is thrown.

Variables that resolve from the lexical scope of the macro definition
will be inserted appropriately depending on the type of the variable,
which may be either a syntax tree or a string.  (Again, syntax tree
is preferred.)  The case is similar to that of a macro called from
within the quasiquote, insofar as reparsing only happens with the
string version of interpolation, except that such a reparse happens
at macro call time rather than macro definition time, so its result
cannot change the parser's expectations about what follows the
interpolated variable.

Hence, while the quasiquote itself is being parsed, the syntactic
interpolation of a variable into the quasiquote always results in
the expectation of an operator following the variable.  (You must
use a call to a submacro if you want to expect something else.)
Of course, the macro definition as a whole can expect whatever it
likes afterwards, according to its syntactic category.  (Generally,
a term expects a following postfix or infix operator, and an operator
expects a following term or prefix operator.)

In case of name ambiguity, prefix with C to indicate a
name in the compiling scope, and anything else (such as C)
to indicate a name in the macro definition's scope, since that's the
default.  In particular, any variable declared within the quasiquote
block is assumed to scope to the quasiquote; to scope the declaration
to the macro call's scope, you must say

my COMPILING::<$foo> = 123;
env COMPILING::<@bar> = ();
our COMPILING::<%baz>;

or some such if you wish to force the compiler to install the variable
into the symbol table being constructed by the macro call.

[Conjecture: Due to these dwimmy scoping rules, there is no need of
a special "unquote" construct as in Scheme et al.]

Larry

Re: [Module::Build] [RFC] author tests

[Adam Kennedy]

 * copyright.t - Ensures that there is a "Copyright 
".([localtime]->[5]+1900) somewhere in every .pm file.  Will break 11 
months from now.
 * distribution.t - Relies on Test::Distribution, which is not in my 
prereq list


snipped ones that need your personal files, you are certainly right 
there. I wouldn't even include them at all. Put them in the MAKEFILE.SKIP.


 * versionsync.t - Checks that the $VERSION is the same in all bin/* and 
*.pm files.  This test is pointless after release, since it's already 
been tested before release


This one you are wrong on. It's important to have this enabled in the 
distribution. The reason is the following.


Imagine you add a new module, or remove a module. For various reasons 
(often involving things like Class::Autouse recursive loading or 
Module::Pluggable or similar things) you can in some cases accidentally 
load a module from an old version of the dist installed somewhere else 
in @INC.


versionsync.t (or various other implementations of it) is not only 
testing that the versions within the dist are synced, but that in 
loading your module you aren't ACCIDENTALLY loading something else you 
shouldn't be.


I've had it happen 2 or three times in real life now on things like PPI 
(which had a huge number of classes which moved a number of times) and 
the Email::Send problem that only got fixed a few days ado.


 * pod.t - Checks POD validity.  This test is pointless after release, 
since it's already been tested before release
 * pod-coverage.t - Checks POD completeness.  This test is pointless 
after release, since it's already been tested before release


and one I have not yet employed:
 * coverage.t - Ensures that Devel::Cover totals are higher than some 
threshold


There is some value in running these in some contexts.

If you look at the way the make/Build system works, you can see it's 
designed to encourage free software and distributed development.


Otherwise why would you have a Makefile for everyone that installs a 
module that is also capable of doing a new release.


Now personally, with the exception of pod.t I don't even include the 
files in my distribution. Those sorts of tests are done by my release tool.


But I'm starting to think that might be wrong...

TEST_AUTHOR or TEST_RELEASE seems like a good idea to me. It doesn't add 
anything to the CPAN release infrastructure, and it's easy to implement.


That said, you'd have to manually turn it on when you were releasing, 
and then turn if off when installing other people's modules... :/


But I don't know that I like disttest autodetection. I quite like being 
able to run the additional tests manually if needed, and not be limited 
to only during the disttest process.


Adam K

Re: [Module::Build] [RFC] author tests

[Adam Kennedy]

chromatic wrote:

On Thursday 02 February 2006 10:04, Tyler MacDonald wrote:


A. Pagaltzis <[EMAIL PROTECTED]> wrote:



I was just gonna say. It???s pointless for anyone but the author to
check POD or test coverage.



I agree about the POD coverage. But if I got a different level of
code coverage on somebody else's system than my own? I'd be very interested
in finding out why.


Perhaps this is something PITA could report.

-- c


Just as a datapoint on this topic, the PITA request objects (as of 5 
minutes ago) now  support the ability to explicitly set environment 
variables you want set when running the tests, on top of the 
default-but-overridable ones like AUTOMATED_TESTING (yes, you can turn 
it off if you really want to).


So any additional tests you want to allow to be enabled by an 
environment variable, we can help you out with the "on other systems" bit.


Also, if anyone has a good knowledge of Xen, and they let me know?

Adam K

Re: [Module::Build] [RFC] author tests

[chromatic]

On Thursday 02 February 2006 17:45, Adam Kennedy wrote:

> Just as a datapoint on this topic, the PITA request objects (as of 5
> minutes ago) now  support the ability to explicitly set environment
> variables you want set when running the tests, on top of the
> default-but-overridable ones like AUTOMATED_TESTING (yes, you can turn
> it off if you really want to).
>
> So any additional tests you want to allow to be enabled by an
> environment variable, we can help you out with the "on other systems" bit.

Fantastic!

I hope to release some Module::Build-based code in the next *mumble* to show 
one way of segregating tests without adding boilerplate to their headers.

-- c

Re: [Module::Build] [RFC] author tests

[A. Pagaltzis]

* Adam Kennedy <[EMAIL PROTECTED]> [2006-02-03 02:45]:
>But I don't know that I like disttest autodetection. I quite
>like being able to run the additional tests manually if needed,
>and not be limited to only during the disttest process.

Maybe do it the other way around? Define INSTALL_AUTOMATED and
INSTALL_INTERACTIVE environment variables that get set during
installation, so author tests run by default and can be skipped
when installing.

That does require touching more infrastructure, though. But it
should solve the problem long-term, because by doing it that way,
excluding tests not meant for end-user installation would not
require assinging names up front for every phase in the lifecycle
of a module and skipping each of them explicitly.

Regards,
-- 
Aristotle Pagaltzis // 

Re: [Module::Build] [RFC] author tests

[Yitzchak Scott-Thoennes]

On Thu, Feb 02, 2006 at 10:01:48AM -0800, Tyler MacDonald wrote:

I strongly feel that authors should keep everything necessary
for their distribution public; either in the CPAN distribution
itself, or via a "permanent" publicly available version control
system.

Who's to say you won't lose interest in maintaining the module or in
perl altogether at some point?  Or move to Antarctica and be unable to
maintain it?  Or have your home/business or wherever your files are
kept destroyed in a hurricane or other natural disaster?

And, of course, we all will die someday.  Some suddenly.

I do agree that many (all?) of these tests are irrelevant to someone
packaging your distribution.

> Chris Dolan <[EMAIL PROTECTED]> wrote:
> >  * copyright.t - Ensures that there is a "Copyright ".([localtime]-> 
> > [5]+1900) somewhere in every .pm file.  Will break 11 months from now.
> >  * distribution.t - Relies on Test::Distribution, which is not in my  
> > prereq list
> >  * perlcritic.t - Runs Test::Perl::Critic on all .pm files.  Will  
> > fail without my specific $HOME/.perlcriticrc

"Test::Perl::Critic allows you to configure Perl::Critic by passing the
path to a F file in the C pragma.  For example:

  use Test::Perl::Critic (-profile => 't/perlcriticrc');
  all_critic_ok();"

Probably you'd like this to keep in sync with any changes to your
.perlcriticrc, which may require some changes to your Makefile.PL/
Build.PL.

> > and will fail with future, more exhaustive versions of P::C

It would be nice if there was some way to indicate which version of
P::C was expected to pass, and TODO any newly looked for problems.

> >  * spelling.t - Runs Test::Spelling.  Will fail without my custom  
> > dictionary

There's Test::Spelling::add_stopwords and =for stopwords.  These
should be used as much as possible instead of adding to your custom
dictionary.  But at least your custom dictionary is recreatable
(because all the needed words are included in your pod :) should
someone else pick up maintenance of your distribution.

> >  * versionsync.t - Checks that the $VERSION is the same in all bin/*  
> > and *.pm files.  This test is pointless after release, since it's  
> > already been tested before release
> >  * pod.t - Checks POD validity.  This test is pointless after  
> > release, since it's already been tested before release
> >  * pod-coverage.t - Checks POD completeness.  This test is pointless  
> > after release, since it's already been tested before release
> > 
> > and one I have not yet employed:
> >  * coverage.t - Ensures that Devel::Cover totals are higher than  
> > some threshold
> 
> Wow, you really *are* exhaustive. How do you find the time to write any
> code? ;-)
> 
> Now that I understand exactly what you mean by "author" tests, here's what I
> think: Whatever convention you're using, if these tests are only going to
> work on your system, then they definately shouldn't be in "t". And since
> there's absolutely no value in these types of tests for anybody else except
> the module author, there's no real point in having a convention, just stick
> 'em anywhere that the make/buildfiles will ignore them.

I disagree; presumably anyone running disttest would want these tests run,
so they belong in t and named .t, with an appropriate skip_all at the top.

Does anyone have a problem with disttest setting PERL_TEST_EXHAUSTIVE?
Or a suggestion for a better name?

Chris, how are you currently set up to run these tests only when
preparing a release?

Re: embparrot still has two failures

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> pugs -V:

  LW> This is Perl6 User's Golfing System, version 6.2.11, February 1,
  LW> 2005 (r8945) built for i386-linux-thread-multi
  

not that this has anything to do with the bug(s) under question but i
see a y2k+5 bug right there. unless larry is working on a very old
version of pugs. and since it was first released about a year ago
according to audrey, i kinda doubt larry is working with v1.0.

:)

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

Re: embparrot still has two failures

[Larry Wall]

On Thu, Feb 02, 2006 at 10:58:39PM -0500, Uri Guttman wrote:
: > "LW" == Larry Wall <[EMAIL PROTECTED]> writes:
: 
:   LW> pugs -V:
: 
:   LW> This is Perl6 User's Golfing System, version 6.2.11, February 1,
:   LW> 2005 (r8945) built for i386-linux-thread-multi
:   
: 
: not that this has anything to do with the bug(s) under question but i
: see a y2k+5 bug right there. unless larry is working on a very old
: version of pugs. and since it was first released about a year ago
: according to audrey, i kinda doubt larry is working with v1.0.
: 
: :)

Would you like a committer bit?  :-)

Larry

Re: [Module::Build] [RFC] author tests

[Adam Kennedy]

That doesn't allow for what happens if both are missing.

I find the following a good general rule.

There are tests that test how the code actually works, that could 
convievably be different on different platforms.


These are always on.

There are tests for issues that are almost certainly (but not provably) 
going to pass everywhere, but add extra dependencies (and thus increase 
risks relating to failures, perl version deps, and platform 
compatibility). I include POD tests, because your pod might have issues 
with older POD parsers found in some places.


They get disabled BY _by_default_ unless the end user happens to have 
the module anyway, but they don't hold up the show for someone that 
doesn't. And they get run in automated testing, sometimes (really 
depends if the automated testing has testing the end-user case or 
testing the module itself as it's primary focus)


There are tests that are ONLY going to need to be run by the author 
before they can release.


They get disabled _by_default_ unless the person running the tests asks 
them to be run.


Note the by defaults. In the absense of any information to the contrary, 
everything but the primary functionality testing should always be off.


This keep dependencies and thus fallout to a minimum, and lets people do 
what they need to.


As for naming of things, I'd consider the tests for the author to be 
"release testing", and thus perhaps the name TEST_RELEASE for the 
environment variable to enable for release testing? It also has the nice 
property of being an imperative command when you say it. "Testing 
system, test release!"


Adam K

A. Pagaltzis wrote:

* Adam Kennedy <[EMAIL PROTECTED]> [2006-02-03 02:45]:

But I don't know that I like disttest autodetection. I quite
like being able to run the additional tests manually if needed,
and not be limited to only during the disttest process.


Maybe do it the other way around? Define INSTALL_AUTOMATED and
INSTALL_INTERACTIVE environment variables that get set during
installation, so author tests run by default and can be skipped
when installing.

That does require touching more infrastructure, though. But it
should solve the problem long-term, because by doing it that way,
excluding tests not meant for end-user installation would not
require assinging names up front for every phase in the lifecycle
of a module and skipping each of them explicitly.

Regards,

Re: [Module::Build] [RFC] author tests

[Chris Dolan]

On Feb 2, 2006, at 9:19 PM, Yitzchak Scott-Thoennes wrote:


Chris, how are you currently set up to run these tests only when
preparing a release?


I make no such distinction.  Instead, I see these tests as part of my  
day-to-day development and run all of them with every "./Build  
test".  Presently, I simply include them all in my MANIFEST.SKIP so  
they are not included in my uploaded package.


That's why I call these "author tests" and not "release tests" or  
"exhaustive tests".


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: embparrot still has two failures

[Uri Guttman]

> "LW" == Larry Wall <[EMAIL PROTECTED]> writes:

  LW> On Thu, Feb 02, 2006 at 10:58:39PM -0500, Uri Guttman wrote:
  LW> : 
  LW> :   LW> This is Perl6 User's Golfing System, version 6.2.11, February 1,
  LW> :   LW> 2005 (r8945) built for i386-linux-thread-multi
  LW> :   
  LW> : 
  LW> : not that this has anything to do with the bug(s) under question but i
  LW> : see a y2k+5 bug right there. unless larry is working on a very old
  LW> : version of pugs. and since it was first released about a year ago
  LW> : according to audrey, i kinda doubt larry is working with v1.0.
  LW> : 
  LW> : :)

  LW> Would you like a committer bit?  :-)

bits of myself need to be committed! :)

i will pass. i prefer to stay on the outside and fire silly potshots.
too much of me is committed already for me to focus on other critical
issues in pugs like that one.

to expand on what damian said, i see things no one else sees because i
am not bogged down by the reality of actually doing real work on
pugs. :)

btw, i have made this prediction in several minor places and i may as
well post it here. from what i see and follow, i predict p6 will be
bootstrapping itself by the end of 2006. not that i expect pugs to
slough off and fall away then, but it will be a major milestone. let's
see how good my tea leaves reading is with you all making the tea. :)
don't let this put any undue pressure on any of you!

and of course what i mean by bootstrapping is that p6 and its rules, the
tree munging stuff and code gen to parrot (or maybe something else) will
be working enough to compile and run itself. this assumes that the
working p6 for this will be a small subset of all of p6 anyhow.

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

something between "state" and "my"

[Dave Whipp]

(from p6i)

Larry Wall wrote:

On Thu, Feb 02, 2006 at 07:12:08PM +0100, Leopold Toetsch wrote:
: >... Anyway,
: >the P6 model of "state" is more like a persistent lexical than like
: >C's static.  
: 
: Sorry for my dumb question - what's the difference then? (Besides that C 
: dosn't have closures ;)


That *is* the difference. 

[...]

I was thinking about this discussion on p6i, and I started thinking that 
there's something between "my" and state: a "state" variable that is 
created/initialized on each invocation of a sub but only if it's not 
already in the dynamic scope (i.e. if its not a recursive call). A 
slightly silly example of its use (using "temp state" as the quantifier) 
would be:


  sub factorial(Int $x) {
  temp state Int $result = 1;
  $result *= $x;
  factorial $x-1 if $x > 2;
  return $result if want;
  }
  say factorial 6;

This code is essentially the same as any other recursive factorial 
function, except that it doesn't use call-stack semantics to maintain 
its state. (I know P6 will do tail recursion, but sometimes I find 
myself building complex args/return values to pass state from one 
iteration to the next.)


Equivalent code without this feature is:

  sub factorial(Int $x) {
  my Int $result = 1;
  my sub fact1(Int $x) {
 $result *= $x;
 fact1 $x-1 if $x > 2;
  }
  fact1 $x
  return $result;
  }

Dave.

use of parrot built source tree in pugs

[Beau E. Cox]

Hi -

When making pugs, I know that the following env must be
setup to imbed parrot:

...
export PUGS_EMBED="perl5 parrot"
export PARROT_PATH="/the/parrot/built/source/tree"
...

Is the parrot source tree only needed for the pugs make?
Can I get rid of it after pugs is sucessfully installed?
Is this question stupid?

-- 
Aloha => Beau;

Re: something between "state" and "my"

[Luke Palmer]

On 2/3/06, Dave Whipp <[EMAIL PROTECTED]> wrote:
>sub factorial(Int $x) {
>temp state Int $result = 1;
>$result *= $x;
>factorial $x-1 if $x > 2;
>return $result if want;
>}
>say factorial 6;

That's precisely what "env" variables are for.  The right way:

sub factorial(Int $x) {
env $result = 1;
my sub fact(Int $x) {
$+result *= $x;
fact($x - 1) if $x > 2;
return $result;
}
fact($x);
}

Of course, you can view env variables as implicit parameters.  Given
that, this function might be able to reduce to:

sub factorial(Int $x) {
env $+result = 1;   # expecting $+result
# param, default to 1
$+result *= $x;
fact($x - 1) if $x > 2;
return $result;
}

Luke

Re: Development version

[Beau E. Cox]

On Thursday 02 February 2006 05:55 pm, Kevin Puetz wrote:
> Beau E. Cox wrote:
> > Hi -
> >
> > Congrats on your 6.2.11 release!
> >
> > Did the development (svn) version really jump to 6.28.0?
>
> Yes. Major pugs releases are numbered by adding the next digit of 2*pi,
> rather than the more conventional x.y+1 :-)
>
> > I am running some scripts to automate a refresh of parrot and
> > pugs weekly so I can stay in tune with the current effort.
> > To identify my svn downloads by version and revision I:
> >
> > 1) slurp ChangeLog and pull version from /(\d+.\d+\.\d+)/s.
> > 2) get revision from the svn output:
> > revision=$(tail -n1 svn.log|perl -e ';$_=<>;$r=/rev.*?(\d+)/i ? $1 :
> > "";print $r') \
>
> clever, but ugh.

Yes ! That's why I posted ;)

>
> > Two questions:
> >
> > 1) Are version and revision available in the source tree in a
> >format easier to use?
>
> yes:
> VERSION can be parsed from META.yml with any handy YAML parser
> e.g. `perl -MYAML -e 'print YAML::LoadFile("META.yml")->{version}'`
> REVISION can be gotten with `svnversion .`

Ahem... META version is still 6.2.11... 

>
> > 2) If not, would the group consider maintaining a VERSION or
> >VERSION and REVISION files in the root of the tree that
> >could simply be cat'ed?
>
> META.yml

Many thanks for answering me; do you *ever* sleep? :)

-- 
Aloha => Beau;