Re: getting round Test::More test formatting trickiness

[Smylers]

Dr Bean writes:

> I've gotten comfortable with Test::More conventions, but it's
> difficult in my editor to really quickly create lots of tests.

Which editor is that?

> is($o->index('You'), 1, 'objects index 1');
> isnt($o->index(1), 1, 'objects index 2');
> isnt($o->index(2), 2, 'objects index 2');
> is($o->index($t), 3, 'objects index 3');
> 
> Incrementing numbers and substituting words and letters takes
> time

If your editor happens to be Vim then be aware that Ctrl+A adds 1 to the
number currently under the cursor, or the next number on the current
line if the cursor isn't on a number.

That means that if you press Enter to move on to a line (so the cursor
is at the start of it) Ctrl+A will increment the first number (or if
you're already on the line, press 0 first to move to the start of it).

And if there's a second number you wish to increment on the same line
then simply press l to move to the right of the first number (which the
cursor will have moved to on pressing Ctrl+A the first time) and then
press Ctrl+A again.

If you're doing this a lot then you can use q to record a keyboard macro
for processing one line and moving on to the next, then it's just a case
of holding down the @ key to do as many lines as you want.

Smylers

Re: Activestate and Scalar-List-Utils

[demerphq]

On 3/14/06, Jan Dubois <[EMAIL PROTECTED]> wrote:
> On Tue, 14 Mar 2006, David Golden wrote:
> > Steve Peters wrote:
> > > The problem was that newer Scalar-List-Utils uses an internal Perl
> > > function that Windows does not see as an exported function. This was
> > > changed with Perl 5.8.8. Once ActiveState releases a Perl 5.8.8,
> > > they should be able to upgrade the version of Scalar-List-Utils that
> > > they distribute.
> >
> > I don't really understand that answer given what I see in the field.
>
> It is not that simple. The problem is that the same PPM repository is
> used by clients using older versions of ActivePerl, and none of those
> versions contain a PPM that could upgrade their bundled Scalar-List-
> Utils module.
>
> I think Gozer has some ideas about how to work around this in the near
> future, so I let him answer this... :)
>
> In the longer run we need to fix the whole PPM infrastructure to be
> able to upgrade core modules too.

While you do it maybe you could think about not throwing away the bulk
of the package when you build the ppd. I personally think its
disappointing that modules installed with ppm come without any testing
framework. At the bare minimum it makes doing on site quickie patches
much more frustrating.

Yves

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

Re: getting round Test::More test formatting trickiness

[A. Pagaltzis]

* Smylers <[EMAIL PROTECTED]> [2006-03-15 09:05]:
>If your editor happens to be Vim then be aware that Ctrl+A adds
>1 to the number currently under the cursor, or the next number
>on the current line if the cursor isn't on a number.

It also has “visual block mode,” which is initiated using Ctrl-v,
and lets you cargo rectangular areas of text around the place.
You can even indent such blocks to insert a block of whitespace
in the middle of the selected lines. You can also use virtual
edit mode to place the cursor beyond the end of a line. This can
be combined this with visual block mode, too. (You can draw ASCII
art tables that way very quickly.) And countless other things.

Regards,
-- 
Aristotle Pagaltzis // 

Re: Activestate and Scalar-List-Utils

[Adam Kennedy]

The main reason this is hapenning is that it's not currently possible to update
CORE packages in ActivePerl, so any module that depends on a CORE package can
be suffering from this. This problem will persist until it becomes possible to
update core packages in ActivePerl.

It's certainly not an ideal situation, but unless somebody can point out an
easier solution, this is where we are at.


I agree completely. There are some fairly entrenched problem here.

The tipping point for me is that as the author of PPI, I can't even 
install it using PPM onto my own Windows laptop so I can do demos of it 
at conferences.


I've mentioned it a number of times to a number of people over the 
course of almost a year, and with all due respect to Philippe's efforts 
to improve PPM I think we've reached the point where the problem is no 
longer a single distribution or technical problem, and it isn't 
something he can fix.


I think the underlying problem here is that ActiveState has become a 
gatekeeper for the entire platform, so whenever a problem like this 
comes up, it's necessarily their interests (by which I mean things like 
making sure they retain binary compatibility) which take priority over 
the community's more varied interest.


And I think it has become a limiting factor.

So as soon as Schwern can be pulled out of Eve Online, and 
ExtUtils::Install is released and integrated, I hope to announce the 
first public beta of Vanilla Perl 5.8.8.


This gets rid of the idea of prebuilt binary packages as the default 
installation method entirely, and moves Win32 module installation to be 
the same as it is for every other Perl platform.


That is, you run a cpan client, and you install from CPAN directly.

The default installation method is via CPAN, and any platform-specific 
binary package system works in addition to it.


While it may not cover every scenario that ActivePerl currently does, 
and is far from a direct replacement, it does mean that the element of 
control can be returned, and every Win32 Perl problem doesn't have to be 
shoved into gozer's I'm-sure-already-overloaded inbox in order for it to 
be fixed.


My hope is it will democratise the Win32 Perl situation a bit more, and 
lead to a dramatic improvement in Perl module support on Win32, now that 
people can debug modules and generate patches to provide back to the 
original authors.


Adam K

Re: comment scope

[Mark Overmeer]

* Damian Conway ([EMAIL PROTECTED]) [060315 01:52]:
> That's why the general Perl 6 Pod syntax allows any block construct to be 
> labelled:
> 
> =begin comment (explanation)
> The devil made me write this code
> =end comment
> 
> =begin comment (future implementation)
> Add a :devil option
> =end comment
> 
> =begin comment (design)
> See www.dev.il/design/S25.pod
> =end comment
> 
> =begin comment (etc. etc.)
> >:-)
> =end comment

But are we still applying huffman encoding here?  I mean: do we really
write that little comments that long constructs are acceptable?

What about

  =comment explain
  The devil made me write this code
  
  =comment future
  Add a :devil option
  
  =comment design
  See www.dev.il/design/S25.pod
  
  =comment etc. etc.
  >:-)
  =cut

Much cleaner, and I don't like Pascal.
-- 
Regards,

   MarkOv


   Mark Overmeer MScMARKOV Solutions
   [EMAIL PROTECTED]  [EMAIL PROTECTED]
http://Mark.Overmeer.net   http://solutions.overmeer.net

Re: comment scope

[Larry Wall]

On Wed, Mar 15, 2006 at 04:42:53PM +0100, Mark Overmeer wrote:
: * Damian Conway ([EMAIL PROTECTED]) [060315 01:52]:
: > That's why the general Perl 6 Pod syntax allows any block construct to be 
: > labelled:
: > 
: > =begin comment (explanation)
: > The devil made me write this code
: > =end comment
: > 
: > =begin comment (future implementation)
: > Add a :devil option
: > =end comment
: > 
: > =begin comment (design)
: > See www.dev.il/design/S25.pod
: > =end comment
: > 
: > =begin comment (etc. etc.)
: > >:-)
: > =end comment
: 
: But are we still applying huffman encoding here?  I mean: do we really
: write that little comments that long constructs are acceptable?
: 
: What about
: 
:   =comment explain
:   The devil made me write this code
:   
:   =comment future
:   Add a :devil option
:   
:   =comment design
:   See www.dev.il/design/S25.pod
:   
:   =comment etc. etc.
:   >:-)
:   =cut


Hmm, for single paragraphs, we can huffmanize it further:

  =for explain
  The devil made me write this code
  
  =for future
  Add a :devil option
  
  =for design
  See www.dev.il/design/S25.pod
  
  =for etc. etc.
  >:-)

But of course that doesn't work if those are supposed to be =head-like
in front of bare paragraphs.  In which case the whole thing needs to
be wrapped in =begin/=end and then you really do use =head (or whatever
heading syntax we end up with).

  =cut

We're trying our best to get rid of =cut, which is why =end returns
to the parser state the =begin entered from.  If you put =begin into
code, the =end leaves back into code (unlike in Perl 5).  =cut was
a bad mistake on my part, and I'd like to forget my mistakes.

: Much cleaner, and I don't like Pascal.

You have to admit it helps it to stand out from the non-Pascal
code though...

All that being said, the final syntax hasn't been nailed down yet,
there are certainly differences of opinion among the designers that
you might successfully drive a wedge into.  :-)

But the most important thing we're going to introduce is

=use MyPodQuirks

so that syntactic and semantic differences are actually documented
somewhere rather than being implicit in the Postprocessor of the Day.
So it'll be easy to drive a cultural wedge between yourself and the
rest of humanity, as long as you describe it to the anthropologists...

That goes for Perl 6 in general too.

Larry

Re: getting round Test::More test formatting trickiness

[Tels]

Moin,

On Tuesday 14 March 2006 10:53, Smylers wrote:
> Dr Bean writes:
> > I've gotten comfortable with Test::More conventions, but it's
> > difficult in my editor to really quickly create lots of tests.
>
> Which editor is that?
>
> > is($o->index('You'), 1, 'objects index 1');
> > isnt($o->index(1), 1, 'objects index 2');
> > isnt($o->index(2), 2, 'objects index 2');
> > is($o->index($t), 3, 'objects index 3');
> >
> > Incrementing numbers and substituting words and letters takes
> > time
>
> If your editor happens to be Vim then be aware that Ctrl+A adds 1 to
> the number currently under the cursor, or the next number on the
> current line if the cursor isn't on a number.

Wow. Thanx! (And I have used vim for years...)

Best wishes,

Tels


-- 
 Signed on Wed Mar 15 17:33:10 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "I'm not a vegetarian, but I eat animals who are" -- Groucho Marx



pgpG4IHYBH6Tl.pgp
Description: PGP signature

Re: Activestate and Scalar-List-Utils

[Tels]

Moin,

On Tuesday 14 March 2006 23:24, Jan Dubois wrote:
> On Tue, 14 Mar 2006, David Golden wrote:
> > Steve Peters wrote:
> > > The problem was that newer Scalar-List-Utils uses an internal Perl
> > > function that Windows does not see as an exported function. This
> > > was changed with Perl 5.8.8. Once ActiveState releases a Perl
> > > 5.8.8, they should be able to upgrade the version of
> > > Scalar-List-Utils that they distribute.
> >
> > I don't really understand that answer given what I see in the field.
>
> It is not that simple. The problem is that the same PPM repository is
> used by clients using older versions of ActivePerl, and none of those
> versions contain a PPM that could upgrade their bundled Scalar-List-
> Utils module.

So, easy, use two repositories, or ditch that method entirely. I want 
people using my modules from this decade, not from last.

> In the longer run we need to fix the whole PPM infrastructure to be
> able to upgrade core modules too.

And I really hope this can be done, like, this year.

The whole situation is getting rather frustrating, because the problem we 
are trying to solve is something that shouldn't even be there.

Best wishes,

Tels

-- 
 Signed on Wed Mar 15 17:37:59 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Now, admittedly, it's critical software. This is the 'let's go kill
 people' software." -- Mark A. Welsh III



pgpwgPjVXqlFx.pgp
Description: PGP signature

Re: getting round Test::More test formatting trickiness

[Tels]

moin,

On Wednesday 15 March 2006 10:50, A. Pagaltzis wrote:
> * Smylers <[EMAIL PROTECTED]> [2006-03-15 09:05]:
> >If your editor happens to be Vim then be aware that Ctrl+A adds
> >1 to the number currently under the cursor, or the next number
> >on the current line if the cursor isn't on a number.
>
> It also has “visual block mode,” which is initiated using Ctrl-v,
> and lets you cargo rectangular areas of text around the place.
> You can even indent such blocks to insert a block of whitespace
> in the middle of the selected lines. You can also use virtual
> edit mode to place the cursor beyond the end of a line. This can
> be combined this with visual block mode, too. (You can draw ASCII
> art tables that way very quickly.) 

Dang, and I wrote a Perl module to do that...using all the time vim! :D

Best wishes,

Tels

-- 
 Signed on Wed Mar 15 17:39:55 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 Like my code? Want to hire me to write some code for you? Send email!



pgpFaMaVJg6HS.pgp
Description: PGP signature

Comments on namespace patch part 23 (wow, 23)

[Chip Salzenberg]

Neat work, Leo!  Couple of comments & requests:

On Wed, Mar 15, 2006 at 08:14:20AM -0800, [EMAIL PROTECTED] wrote:
> - initial/default HLL namespace is "parrot"

I didn't ask for a default, and I don't think there should be one, but I'm
interested in your reason for adding one.

   Rationale: the system as a whole *is* Parrot.  Looking at Parrot in
   context of a running computer system, there is a notional (not actual)
   "parrot::" before *Everything* in a running parrot system.  Adding an
   explicit "parrot::" seems to me like adding an explicit "perl::" to the
   beginning of every Perl package name.

> - store_global, find_global w/o namespace are now relative to
>   current namespace

Excellent.

> - intermediate workaround for 'newclass / .namespace': try current and HLL
>   namespace to find class namespace

Good workaround, thanks.

> - getnamespace is absolute to namespace root

I don't think that's a good idea.  Once we start making exceptions to the
relativity rule, users will have to memorize those exceptions, and then some
opcodes will become less useful.  By my intention, the only way to get to
the namespace root should be via introspection (interpinfo).

On the other hand, I think we should consider get_namespace and find_global
opcodes that accept a namespace PMC as the "root" for the search.  Linux
just added a whole raft of analogous system calls.  For example, in recent
Linux you can open /etc/motd in two ways, either:

int fd = open("/etc/motd", O_RDONLY);

or:

int etc_fd = open("/etc", O_RDONLY | O_DIRECTORY)

int fd = openat(etc_fd, "motd", O_RDONLY);

I think Parrot opcodes like "get_namespace_at" or "find_global_at" (not
necessarily with those names), modeled on the Linux openat() family, will
address the usability problem that you seem to be addressing with your
getnamespace root exception, while also being useful in other circumstances.
-- 
Chip Salzenberg <[EMAIL PROTECTED]>

Re: comment scope

[Damian Conway]

Mark wrote:


: What about
: 
:   =comment explain

:   The devil made me write this code
:   
:   =comment future

:   Add a :devil option
:   
:   =comment design

:   See www.dev.il/design/S25.pod
:   
:   =comment etc. etc.

:   >:-)


In Perl 6 Pod, those are exactly equivalent to:

  =begin comment
  explain
  The devil made me write this code
  =end comment

  =begin comment
  future
  Add a :devil option
  =end comment

  =begin comment
  design
  See www.dev.il/design/S25.pod
  =end comment

  =begin comment
  etc. etc.
  >:-)
  =end comment

So...yes, you certainly *can* have them. ;-)


Then Larry wrote:


Hmm, for single paragraphs, we can huffmanize it further:

  =for explain
  The devil made me write this code
  
  =for future

  Add a :devil option
  
  =for design

  See www.dev.il/design/S25.pod
  
  =for etc. etc.

  >:-)


Yes. C<=for whatever> is the intermediate form between the abbreviated 
C<=whatever> and the explicitly delimited C<=begin whatever/=end whatever>.


So Larry's examples above are exactly equivalent to:

=begin explain
The devil made me write this code
=end explain

=begin future
Add a :devil option
=end future

=begin design
See www.dev.il/design/S25.pod
=end design

=begin etc.
etc.
>:-)
=end etc.

which a pod processor would treat as "external" (i.e. unknown) blocks..at 
least, until the Pod specification was extended to make those standard types. 
Of course, lowercase block typenames are reserved for future standard blocks, 
so it would be totally future-proof to write:


=for Explain
The devil made me write this code

=for Future
Add a :devil option

=for Design
See www.dev.il/design/S25.pod

=for Etc. etc.
>:-)



We're trying our best to get rid of =cut, which is why =end returns
to the parser state the =begin entered from.


Indeed. As does a C<=for> after the first blank line. And, indeed, a 
C<=whatever> after the first blank line.


In Perl 6 Pod, C<=cut> is only ever required if you're inside an extended Pod 
region (which you initiated with a C<=pod> directive).




: Much cleaner, and I don't like Pascal.

You have to admit it helps it to stand out from the non-Pascal
code though...


Yep. And besides: "There's more than one way to document it". ;-)



All that being said, the final syntax hasn't been nailed down yet,
there are certainly differences of opinion among the designers that
you might successfully drive a wedge into.  :-)


But *please* give us a week or two for Ingy and I to release our proposal and 
for %Larry{none 'Damian'} to drive nails into it first. ;-)




But the most important thing we're going to introduce is

=use MyPodQuirks

so that syntactic and semantic differences are actually documented
somewhere rather than being implicit in the Postprocessor of the Day.


[Damian scurries off to update S26 to "make it so"...]

Re: Best Practice for testing compilation of scripts

[chromatic]

On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:

> I'm sure I could clean this up by opening a pipe
> instead of using backticks and output redirection.
> But even that doesn't smell very good.  I've looked
> around on CPAN, but I have not yet found a Test::
> module that seems appropriate.  I also wondered if
> fiddling with $^C would do the trick somehow.  Any
> suggestions?  Thanks.

I've long intended to take t/test.pl from the Perl core distribution and wrap 
up at least its runperl() in a Test:: module.  Perhaps that would work for 
you?

-- c

Best Practice for testing compilation of scripts

[Jeffrey Thalhammer]

Putting aside the argument that most logic should be
in libraries and not scripts, what is the best
practice for writing test cases to verify that your
Perl scripts compile?  My quick and dirty solution is
something like:

 use Test::More tests => 1;
 chomp (my $output = `perl -c $script 2>&1`);
 is($output, "$script syntax OK", "$script compiles");

I'm sure I could clean this up by opening a pipe
instead of using backticks and output redirection. 
But even that doesn't smell very good.  I've looked
around on CPAN, but I have not yet found a Test::
module that seems appropriate.  I also wondered if
fiddling with $^C would do the trick somehow.  Any
suggestions?  Thanks.  

-Jeff  


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: Best Practice for testing compilation of scripts

[Geoffrey Young]

chromatic wrote:
> On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:
> 
> 
>>I'm sure I could clean this up by opening a pipe
>>instead of using backticks and output redirection.
>>But even that doesn't smell very good.  I've looked
>>around on CPAN, but I have not yet found a Test::
>>module that seems appropriate.  I also wondered if
>>fiddling with $^C would do the trick somehow.  Any
>>suggestions?  Thanks.
> 
> 
> I've long intended to take t/test.pl from the Perl core distribution and wrap 
> up at least its runperl() in a Test:: module.  Perhaps that would work for 
> you?

compile_ok() ?

--Geoff

[perl #38733] [TODO] Support utf8 as an input IO filter

[via RT]

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


In an effort to get APL working, I first have to be able to read an  
APL program into memory, which means unicode operators.

As I'm modifying ponie, I end up with something like:

.sub _slurp_file
 .param string filename
 .local pmc filehandle
 filehandle = open filename, "<"
 push filehandle, 'utf8'
 unless filehandle goto err_no_file
 $S1 = read filehandle, 65535
 close filehandle
 $I99 = charset $S1
 $S99 = charsetname $I99
 print "source is "
 print $S1
 print "\n"
 print "charset of source is: "
 print $S99
 print "\n"
 .return ($S1)
.end

This compiles, prints out what looks like the right source code  
(which at the moment is neither punie nor APL: "print 2²10;")

But the charset that's listed is ascii. I need to be able to read in  
the utf8 encoded file and have it recognized as such by parrot.

It would also be helpful to have badly-specified IO filters generate  
an exception. (utf8 doesn't appear to since it's supported for  
*output*. using "monkeys" as the filter generates the slightly more  
helpful: 'Layer not found').

Re: Best Practice for testing compilation of scripts

[Tels]

Moin,

On Wednesday 15 March 2006 21:29, chromatic wrote:
> On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:
> > I'm sure I could clean this up by opening a pipe
> > instead of using backticks and output redirection.
> > But even that doesn't smell very good.  I've looked
> > around on CPAN, but I have not yet found a Test::
> > module that seems appropriate.  I also wondered if
> > fiddling with $^C would do the trick somehow.  Any
> > suggestions?  Thanks.
>
> I've long intended to take t/test.pl from the Perl core distribution
> and wrap up at least its runperl() in a Test:: module.  Perhaps that
> would work for you?

Please drop me a note when it's done, since I also test quite a few 
scripts and their options with homegrown solutions.

Best wishes,

Tels

-- 
 Signed on Wed Mar 15 21:57:24 2006 with key 0x93B84C15.
 Visit my photo gallery at http://bloodgate.com/photos/
 PGP key on http://bloodgate.com/tels.asc or per email.

 "Five exclamation marks, the sure sign of an insane mind." -- Terry
 Pratchett



pgp2skpIFqVU1.pgp
Description: PGP signature

Re: [perl #38733] [TODO] Support utf8 as an input IO filter

[Will Coleda]

On Mar 15, 2006, at 3:56 PM, Will Coleda (via RT) wrote:


This compiles, prints out what looks like the right source code
(which at the moment is neither punie nor APL: "print 2²10;")



I hate unicode. That is 'print 2  10;'

Re: Best Practice for testing compilation of scripts

[Chris Dolan]

On Mar 15, 2006, at 2:47 PM, Geoffrey Young wrote:

chromatic wrote:

On Wednesday 15 March 2006 12:25, Jeffrey Thalhammer wrote:



I'm sure I could clean this up by opening a pipe
instead of using backticks and output redirection.
But even that doesn't smell very good.  I've looked
around on CPAN, but I have not yet found a Test::
module that seems appropriate.  I also wondered if
fiddling with $^C would do the trick somehow.  Any
suggestions?  Thanks.



I've long intended to take t/test.pl from the Perl core  
distribution and wrap
up at least its runperl() in a Test:: module.  Perhaps that would  
work for

you?


compile_ok() ?

--Geoff



It is unclear from Geoff's message above whether he is asserting that  
function exists, or if he is merely proposing it, so I googled.  It  
doesn't appear to exist in any Test:: package (corrections VERY  
welcome).  However, Adam Kennedy wrote one:


  http://search.cpan.org/src/ADAMK/ThreatNet-Bot-AmmoBot-0.10/t/ 
01_compile.t


That function should probably be changed to use FindBin instead of  
updir() calls.


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

[FWD: Re: FAIL threads-1.09 MSWin32-x86-multi-thread 4.0]

[Jerry D. Hedden]

> Subject: Re: FAIL threads-1.09 MSWin32-x86-multi-thread 4.0
> From: Max Maischein <[EMAIL PROTECTED]>
> Date: Wed, March 15, 2006 4:43 pm
> To: "Jerry D. Hedden" <[EMAIL PROTECTED]>
>
> Jerry D. Hedden wrote:
> > Would you mind running this again?  I tested this against ActivePerl
> > 5.8.0/1/2/3/4/6/7/8, and they all passed.  (ActiveState didn't make a
> > 5.8.5.  Go figure.)  If it fails again, would you please send me the
> > output of 'perl -Mblib t/basic.t'.   Thanks much.
>
> This time, run manually, it tests perfectly. I also wiped the directory
> and did a completely clean rebuild and it still tests good. So it must
> have been yet another screw-up between CPANPLUS / CPAN::YACSMoke and my
> machine/setup :-(

Here is yet another example of an erroneous failed test report that will
remain visible in the CPAN Testers database.  Clearly, both the
developer and the tester agree that the reported failure was in error.

The general concensus on this topic seemed to favor overwriting/masking
older reports with updated (i.e., corrected) reports.  If that is the
case, what needs to be done to move forward to correct this problem?

Re: Comments on namespace patch part 23 (wow, 23)

[Leopold Toetsch]

On Mar 15, 2006, at 20:21, Chip Salzenberg wrote:


Neat work, Leo!  Couple of comments & requests:


Thanks, yet unfinished though ...


On Wed, Mar 15, 2006 at 08:14:20AM -0800, [EMAIL PROTECTED] wrote:

- initial/default HLL namespace is "parrot"


I didn't ask for a default, and I don't think there should be one, but 
I'm

interested in your reason for adding one.

   Rationale: the system as a whole *is* Parrot.  Looking at Parrot in
   context of a running computer system, there is a notional (not 
actual)
   "parrot::" before *Everything* in a running parrot system.  Adding 
an
   explicit "parrot::" seems to me like adding an explicit "perl::" to 
the

   beginning of every Perl package name.


The rational for a default "parrot" namespace is simple. Parrot PMC are 
bootstrapping themselves by first registering PMC vtables and PMC types 
and then methods and MMDs[1]. The methods and MMDs need some kind of 
namespace. We were discussing this on IRC a bit. Before all the PMCs 
were occupying toplevel namespace names. Now it's "::parrot::Integer" 
and so on.


We have already a default HLL named 'parrot' - the initial one in the 
absence of any .HLL directive. Therefore it was just straightforward to 
use the default ``HLL namespace'' "parrot" as the default one.


I'm of course fine with any other name.




- store_global, find_global w/o namespace are now relative to
  current namespace


Excellent.

- intermediate workaround for 'newclass / .namespace': try current 
and HLL

  namespace to find class namespace


Good workaround, thanks.


Need more specs though. The plan as also described in the roundup mail 
is:


  .namespace "Foo"
  .sub some
  cl = newclass "Foo" #  namespace "Foo::Foo"
   ...

or in other words, it's breaking a lot of code. The correct sequence 
would need:


   # implicit .namespace [""] at top of file, actually all below HLL 
namespace


  .sub some
  cl = newclass "Foo" #  namespace "Foo"
  .end

  .namespace "Foo"

  .sub some_other
  cl = newclass "Bar" #  namespace "Foo::Bar"
  .end

Alternatively, we'd need some other means to create nested classes 
along with their namespaces.





- getnamespace is absolute to namespace root


I don't think that's a good idea.  Once we start making exceptions to 
the
relativity rule, users will have to memorize those exceptions, and 
then some
opcodes will become less useful.  By my intention, the only way to get 
to

the namespace root should be via introspection (interpinfo).


Well, I've asked that already and see pdd21:

   $P1 = get_namespace ["perl6"; "Foo"]


On the other hand, I think we should consider get_namespace and 
find_global

opcodes that accept a namespace PMC as the "root" for the search.


[ ... ]

Whatever might be best. It's not hard to change it now, but we should 
have a decision towards final.


BTW could you please add a note to pdd21, how the "add_namespace" 
opcode is supposed to work exactly (which namespace name does it create 
where)


[1] see the generated file: src/core_pmcs.c:175 and following

leo

Re: Best Practice for testing compilation of scripts

[Adam Kennedy]

http://search.cpan.org/src/ADAMK/ThreatNet-Bot-AmmoBot-0.10/t/01_compile.t

That function should probably be changed to use FindBin instead of 
updir() calls.


Actually, by modern standards I'd consider that a pretty half-assed.

Mostly for the fact it's a highly unix usage.

If it was doing it again, I'd be using IPC::Run3 or something more portable.

But the same principle applied. Ditch the output, give it a -c flag, and 
look at the return code.


Adam K

Re: getting round Test::More test formatting trickiness

[A. Pagaltzis]

* Tels <[EMAIL PROTECTED]> [2006-03-15 17:45]:
>Wow. Thanx! (And I have used vim for years...)

I hope the fabled “Vim for vimmers” tutorial gets written one
day. (It was supposed to be a guide to vim’s advanced features
for people who have been using vim for years but have stuck with
the basics.)

(Not least for myself, as I’m certain I’ll be able to take a few
slices out of it – I know vim has much more advanced navigation
stuff than I’ve been using, f.ex., and I only use the most basic
windowing features. There’s more stuff in this editor that’s
worth knowing than you can learn in a lifetime.)

Regards,
-- 
Aristotle Pagaltzis // 

Re: Best Practice for testing compilation of scripts

[Geoffrey Young]

>>> I've long intended to take t/test.pl from the Perl core  distribution
>>> and wrap
>>> up at least its runperl() in a Test:: module.  Perhaps that would 
>>> work for
>>> you?
>>
>>
>> compile_ok() ?
>>
>> --Geoff
>>
> 
> It is unclear from Geoff's message above whether he is asserting that 
> function exists, or if he is merely proposing it

yeah, sorry, it's been a long couple of days...

I was suggesting the functionality be added to Test::More as compile_ok(),
rather than runperl() in some separate CPAN module, as it seems to closely
parallel use_ok() for modules and would be rather useful on a larger scale.

fwiw

--Geoff

Re: Best Practice for testing compilation of scripts

[Tyler MacDonald]

Geoffrey Young <[EMAIL PROTECTED]> wrote:
> I was suggesting the functionality be added to Test::More as compile_ok(),
> rather than runperl() in some separate CPAN module, as it seems to closely
> parallel use_ok() for modules and would be rather useful on a larger scale.

I agree, a well written version of that would be awesome in
Test::More.

Cheers,
Tyler

Re: Best Practice for testing compilation of scripts

[chromatic]

On Wednesday 15 March 2006 18:43, Geoffrey Young wrote:

> I was suggesting the functionality be added to Test::More as compile_ok(),
> rather than runperl() in some separate CPAN module, as it seems to closely
> parallel use_ok() for modules and would be rather useful on a larger scale.

That would require prying Schwern out from having fun to do actual work!  I 
feel a shaming coming on.

SHAME
SHAME

-- c