Re: getting round Test::More test formatting trickiness

2006-03-15 Thread 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

2006-03-15 Thread 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

2006-03-15 Thread 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 // http://plasmasturm.org/


Re: Activestate and Scalar-List-Utils

2006-03-15 Thread 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: getting round Test::More test formatting trickiness

2006-03-15 Thread 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



pgpFZg672ctdB.pgp
Description: PGP signature


Re: Activestate and Scalar-List-Utils

2006-03-15 Thread 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



pgpost5naq4cV.pgp
Description: PGP signature


Re: getting round Test::More test formatting trickiness

2006-03-15 Thread 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!



pgpTv1X84PvQ7.pgp
Description: PGP signature


Best Practice for testing compilation of scripts

2006-03-15 Thread 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 21`);
 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

2006-03-15 Thread 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


Re: Best Practice for testing compilation of scripts

2006-03-15 Thread 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


Re: Best Practice for testing compilation of scripts

2006-03-15 Thread 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



pgpFx2tVgiIGm.pgp
Description: PGP signature


Re: Best Practice for testing compilation of scripts

2006-03-15 Thread 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]

2006-03-15 Thread 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: Best Practice for testing compilation of scripts

2006-03-15 Thread 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

2006-03-15 Thread 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 // http://plasmasturm.org/


Re: Best Practice for testing compilation of scripts

2006-03-15 Thread 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

2006-03-15 Thread 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


Re: Best Practice for testing compilation of scripts

2006-03-15 Thread 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