On Thu, Aug 07, 2008 at 11:43:00AM -0700, Eric Wilhelm wrote:
# from David Cantrell
Please don't take focus away from the window I'm working in. Please
don't cover up any of the many windows I've carefully arranged so that
I can see everything I need.
I would say it only appears if the
# from David Cantrell
# on Monday 18 August 2008 04:07:
get remote GUIs to work
That's not what I said ;-) See, the remote X session is a protocol
You were talking about doing GUI stuff. You mentioned running tests
on another machines. So yes, it is what you said.
No, I didn't say
--- On Mon, 18/8/08, Ovid [EMAIL PROTECTED] wrote:
out who's to blame? Moving forward is so much more
satisfying did not/did too discussions.
more satisfying THAN did not/did too discussions.
And learning how to write is more satisfying still.
Cheers,
Ov ...
--
Buy the book -
# from Ovid
# on Monday 18 August 2008 09:14:
Moving forward is so much more satisfying than did not/did too
discussions.
Now if only there were somewhere to move forward to. My thought was
that a more sophisticated presentation of complicated have/want could
be accomplished using a pair
On Wed, Aug 06, 2008 at 08:17:09PM -0700, Eric Wilhelm wrote:
I bet that would be prettier in a GUI. We all develop on teletypes, eh?
Perhaps something involving TAP and diagnostics could be used to cause a
graphical program to run (egads! a graphical program!) on your shiny
widescreen LCD
# from David Cantrell
# on Thursday 07 August 2008 05:57:
Please don't take focus away from the window I'm working in. Please
don't cover up any of the many windows I've carefully arranged so that
I can see everything I need.
I would say it only appears if the tests failed. I would prefer
On 7 Aug 2008, at 22:34, Eric Wilhelm wrote:
I would say it only appears if the tests failed. I would prefer
that to
take focus rather than needing to go activate it. Would you rather
scrollback to read the diagnostics in your terminal?
Is that so odd? Emphatically YES - I would rather
# from Michael G Schwern
# on Wednesday 06 August 2008 19:49:
Maybe line them up and space them out?
# ++--+--+
# | Elt|Got |Expected |
# ++--+--+
# | 0|id, name |id, name |
# * 1|1, Bob |2, Bob *
# ++--+--+
I dunno
On Wed 02 Oct 2002 13:50, H.Merijn Brand [EMAIL PROTECTED] wrote:
As a start for a `normal' interface to the interperters internals, this time
no open hack, but a neat interface.
Very open to additions.
Useful?
Feedback please
Thank you Dan!
Devel::Size from Dan Sugalski is what we
At 4:45 PM +0200 10/11/02, Tels wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 11-Oct-02 H.Merijn Brand carved into stone:
On Wed 02 Oct 2002 13:50, H.Merijn Brand [EMAIL PROTECTED] wrote:
As a start for a `normal' interface to the interperters internals, this
time
no open hack, but a
On Wed 02 Oct 2002 13:50, H.Merijn Brand [EMAIL PROTECTED] wrote:
As a start for a `normal' interface to the interperters internals, this time
no open hack, but a neat interface.
Very open to additions.
Useful?
Feedback please
Thank you Dan!
Devel::Size from Dan Sugalski is what we
At 4:45 PM +0200 10/11/02, Tels wrote:
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 11-Oct-02 H.Merijn Brand carved into stone:
On Wed 02 Oct 2002 13:50, H.Merijn Brand [EMAIL PROTECTED] wrote:
As a start for a `normal' interface to the interperters internals, this
time
no open hack, but a
Michael G Schwern [EMAIL PROTECTED] writes:
But you're not. You're just exposing sbrk(), which is a gory detail. My
sbrk man page describes sbrk as being used to find the current location of
the program break which means nothing to me. Nor does returns the current
memory top.
It'll be even
H.Merijn Brand [EMAIL PROTECTED] writes:
Ahh, someone on /my/ side.
I guess most of the discussion boils down to
- sbrk () being unknown to people not familiar with unix
- Devel::Internals being to wide. [ Gimme another namespace proposal ]
- MemUsed interface to polymorphistic
So far, all I
Michael G Schwern [EMAIL PROTECTED] writes:
But you're not. You're just exposing sbrk(), which is a gory detail. My
sbrk man page describes sbrk as being used to find the current location of
the program break which means nothing to me. Nor does returns the current
memory top.
It'll be even
H.Merijn Brand [EMAIL PROTECTED] writes:
Ahh, someone on /my/ side.
I guess most of the discussion boils down to
- sbrk () being unknown to people not familiar with unix
- Devel::Internals being to wide. [ Gimme another namespace proposal ]
- MemUsed interface to polymorphistic
So far, all I
On Sat 05 Oct 2002 01:45, [EMAIL PROTECTED] wrote:
On Fri, Oct 04, 2002 at 08:24:12PM +0200, Slaven Rezic wrote:
Not a module, but a function which should work on FreeBSD and Linux:
Why not package this up and stick it on CPAN? Proc::Memory or
Wait a while. Ann Barcomb is working on this
Merijn wrote:
Wait a while. Ann Barcomb is working on this too. Let's collect all this into
one module and not release twenty or so that try to do the same.
I'm not actually working on it...I just had need of such a module
Thursday, mentioned to Jos what I had been trying to work on, and he
En op 5 oktober 2002 sprak Ann Barcomb:
I hadn't looked in to how I could solve my question, and because
it was given to me as a low priority task, I wasn't sure I was going
to have a chance to either. But you can count me as someone who will
be very happy about the module :)
I noticed CPAN
Nicholas Clark [EMAIL PROTECTED] writes:
On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote:
If what it does is merely return the value of the C sbrk() function,
then IMHO, sbrk() is a perfectly good name.
However, as to other possible names -- how about ProcessSize()
Tels [EMAIL PROTECTED] writes:
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
En op 5 oktober 2002 sprak Ann Barcomb:
I hadn't looked in to how I could solve my question, and because
it was given to me as a low priority task, I wasn't sure
is in my
private perl function repository, and I thought about creating a
public function repository on CPAN...
Regards,
Slaven
It's a good start nitpickthough you'll probably want
to do it File::Spec style with Proc::Memory::FreeBSD, etc.../nitpick
=item currmem([$pid
in the heap, which might or might not be related.
With usage of a perl structure, do you mean the size of an SV, plus
the size of an XPV, plus the malloced area for the string, etc.? I
Yes, that is what I thought.
think the heap usage is more important, because these is the memory
taken from
, it just
reports a change in the heap, which might or might not be related.
With usage of a perl structure, do you mean the size of an SV, plus
the size of an XPV, plus the malloced area for the string, etc.? I
Yes, that is what I thought.
think the heap usage is more important, because
optimising perl code at YAPC in Munich. I'm going to
use this as an opportunity to blatantly plug the fact that I've put it
online:
http://www.ccl4.org/~nick/P/Fast_Enough/
because it might contain one or two ideas that people haven't thought of.
People who saw it at YAPC may not want to read it *yet
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 Slaven Rezic carved into stone:
Tels [EMAIL PROTECTED] writes:
But shouldn't that be just the same, or slightly more (if the memory is
used in chunks of, let's say 16 bytes, it might alloc up to 15 more).?
The malloc system will
On Sat 05 Oct 2002 01:45, [EMAIL PROTECTED] wrote:
On Fri, Oct 04, 2002 at 08:24:12PM +0200, Slaven Rezic wrote:
Not a module, but a function which should work on FreeBSD and Linux:
Why not package this up and stick it on CPAN? Proc::Memory or
Wait a while. Ann Barcomb is working on this
On Fri, Oct 04, 2002 at 08:24:12PM +0200, Slaven Rezic wrote:
Not a module, but a function which should work on FreeBSD and Linux:
Why not package this up and stick it on CPAN? Proc::Memory or
something. It's a good start nitpickthough you'll probably want
to do it File::Spec style with
Merijn wrote:
Wait a while. Ann Barcomb is working on this too. Let's collect all this into
one module and not release twenty or so that try to do the same.
I'm not actually working on it...I just had need of such a module
Thursday, mentioned to Jos what I had been trying to work on, and he
En op 5 oktober 2002 sprak Ann Barcomb:
I hadn't looked in to how I could solve my question, and because
it was given to me as a low priority task, I wasn't sure I was going
to have a chance to either. But you can count me as someone who will
be very happy about the module :)
I noticed CPAN
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
En op 5 oktober 2002 sprak Ann Barcomb:
I hadn't looked in to how I could solve my question, and because
it was given to me as a low priority task, I wasn't sure I was going
to have a chance to
Nicholas Clark [EMAIL PROTECTED] writes:
On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote:
If what it does is merely return the value of the C sbrk() function,
then IMHO, sbrk() is a perfectly good name.
However, as to other possible names -- how about ProcessSize()
Tels [EMAIL PROTECTED] writes:
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 05-Oct-02 [EMAIL PROTECTED] carved into stone:
En op 5 oktober 2002 sprak Ann Barcomb:
I hadn't looked in to how I could solve my question, and because
it was given to me as a low priority task, I wasn't sure
is in my
private perl function repository, and I thought about creating a
public function repository on CPAN...
Regards,
Slaven
It's a good start nitpickthough you'll probably want
to do it File::Spec style with Proc::Memory::FreeBSD, etc.../nitpick
=item currmem([$pid
in the heap, which might or might not be related.
With usage of a perl structure, do you mean the size of an SV, plus
the size of an XPV, plus the malloced area for the string, etc.? I
Yes, that is what I thought.
think the heap usage is more important, because these is the memory
taken from
, it just
reports a change in the heap, which might or might not be related.
With usage of a perl structure, do you mean the size of an SV, plus
the size of an XPV, plus the malloced area for the string, etc.? I
Yes, that is what I thought.
think the heap usage is more important, because
optimising perl code at YAPC in Munich. I'm going to
use this as an opportunity to blatantly plug the fact that I've put it
online:
http://www.ccl4.org/~nick/P/Fast_Enough/
because it might contain one or two ideas that people haven't thought of.
People who saw it at YAPC may not want to read it *yet
On Thu, Oct 03, 2002 at 02:35:14PM -0400, Benjamin Goldberg wrote:
If what it does is merely return the value of the C sbrk() function,
then IMHO, sbrk() is a perfectly good name.
However, as to other possible names -- how about ProcessSize() ? I'm
not sure if this is really a valid
[EMAIL PROTECTED] wrote:
For a more fine-grained view, you
need hooks into Perl internals (such as the Perl malloc).
This sounds like Devel::Peek::mstat(). But I never looked at this before.
sbrk is very Unixish. It isn't in POSIX at all. Our system is highly POSIX
compliant but doesn't have a function that directly maps to sbrk. We do
have a way of determining heap max size and heap current usage, but it is a
functional (subroutine) interface. If you had a function that just
--8---
use Inline C = '
long MemUsed ()
{
return ((long)sbrk (0));
}'
--8---
Then I thought it was very likely that I would use this more than once, so I
turned it into a module, but before I installed it, well, you all saw it
It isn't in POSIX at all. Our system
At 01:01 PM 10/3/02 +0200, H.Merijn Brand wrote:
So far, all I got was criticism. I asked for it. But no-one said it was
useful.
(Or I didn't read between the lines enough).
Well, since I probably have been the person that set this off, I think I
should say something here.
Ideally, I think
En op 4 oktober 2002 sprak Michael G Schwern:
The problem is when you put those two next to each other, one
promising a friendly interface, one a bare-metal interface,
it confuses the intent of the module. Is it for Joe End User
or is it for Joe Core Hacker?
A module to report memory usage
H.Merijn Brand [mailto:[EMAIL PROTECTED]] writes:
So far, all I got was criticism. I asked for it. But no-one said it was
useful.
(Or I didn't read between the lines enough).
In my experience, the phrase I really liked your idea and I hope you won't
mind if I share a few ideas for improving
On Thu, Oct 03, 2002 at 10:43:43AM +0100, Nicholas Clark wrote:
The reason I'm saying it might not be much use to people unfamiliar with
the internals of unix is precisely because it does return a precisely defined
but not directly useful value - the highest address on the heap.
If you read
Michael G Schwern wrote:
On Wed, Oct 02, 2002 at 01:50:56PM +0200, H.Merijn Brand wrote:
SYNOPSIS
use Devel::Internals;
A little broad. Perhaps Devel::Memory?
my $end = sbrk ();
my array = (1..1);
print The creation of this array used ,
On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote:
On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
I realize that sbrk() is a familiar concept to deep C programmers on
BSD-style systems, but in order for this to be useful to Perl programmers,
or even
On Thu 03 Oct 2002 11:43, Nicholas Clark [EMAIL PROTECTED] wrote:
On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote:
On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
I realize that sbrk() is a familiar concept to deep C programmers on
BSD-style systems,
On Thu, 03 Oct 2002 13:01:52 +0200, H.Merijn Brand [EMAIL PROTECTED] said:
If it only returns the value from sbrk(), damn well call it sbrk.
Ahh, someone on /my/ side.
Mee too.
So far, all I got was criticism. I asked for it. But no-one said it was useful.
(Or I didn't read
Michael G Schwern wrote:
On Wed, Oct 02, 2002 at 01:50:56PM +0200, H.Merijn Brand wrote:
SYNOPSIS
use Devel::Internals;
A little broad. Perhaps Devel::Memory?
my $end = sbrk ();
my array = (1..1);
print The creation of this array used ,
On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote:
On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
I realize that sbrk() is a familiar concept to deep C programmers on
BSD-style systems, but in order for this to be useful to Perl programmers,
or even
On Thu 03 Oct 2002 11:43, Nicholas Clark [EMAIL PROTECTED] wrote:
On Wed, Oct 02, 2002 at 05:07:20PM -0400, Michael G Schwern wrote:
On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
I realize that sbrk() is a familiar concept to deep C programmers on
BSD-style systems,
As a start for a `normal' interface to the interperters internals, this time
no open hack, but a neat interface.
Very open to additions.
Useful?
Feedback please
NAME
Devel-Internals - Perl extension for internal interpreter statistics
SYNOPSIS
use Devel::Internals;
MemUsed ($msg)
Used in void context reports the number of bytes used since the
previous call to MemUsed with the message passed
Used in scalar context returns the current sbrk value
Used in list context returns the values saved on every call
Ugh, no, seems very
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 02-Oct-02 H.Merijn Brand carved into stone:
As a start for a `normal' interface to the interperters internals, this
time no open hack, but a neat interface.
Very open to additions.
Useful?
Is it accurate?
Feedback please
NAME
On Wed, Oct 02, 2002 at 05:06:53PM +0200, Tels wrote:
On 02-Oct-02 H.Merijn Brand carved into stone:
Going to be a bit hard to change, then :-)
As a start for a `normal' interface to the interperters internals, this
time no open hack, but a neat interface.
Very open to additions.
As a start for a `normal' interface to the interperters internals, this time
no open hack, but a neat interface.
Very open to additions.
Useful?
Feedback please
NAME
Devel-Internals - Perl extension for internal interpreter statistics
SYNOPSIS
use Devel::Internals;
MemUsed ($msg)
Used in void context reports the number of bytes used since the
previous call to MemUsed with the message passed
Used in scalar context returns the current sbrk value
Used in list context returns the values saved on every call
Ugh, no, seems very
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 02-Oct-02 H.Merijn Brand carved into stone:
As a start for a `normal' interface to the interperters internals, this
time no open hack, but a neat interface.
Very open to additions.
Useful?
Is it accurate?
Feedback please
NAME
On Wed, Oct 02, 2002 at 05:06:53PM +0200, Tels wrote:
On 02-Oct-02 H.Merijn Brand carved into stone:
Going to be a bit hard to change, then :-)
As a start for a `normal' interface to the interperters internals, this
time no open hack, but a neat interface.
Very open to additions.
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 02-Oct-02 Nicholas Clark carved into stone:
On Wed, Oct 02, 2002 at 05:06:53PM +0200, Tels wrote:
On 02-Oct-02 H.Merijn Brand carved into stone:
Going to be a bit hard to change, then :-)
:-)
As a start for a `normal' interface to the
On Wed 02 Oct 2002 22:11, Michael G Schwern [EMAIL PROTECTED] wrote:
On Wed, Oct 02, 2002 at 01:50:56PM +0200, H.Merijn Brand wrote:
SYNOPSIS
use Devel::Internals;
A little broad. Perhaps Devel::Memory?
My intent was to gather more internal states. Whatever useful.
On Wed, Oct 02, 2002 at 10:26:32PM +0200, H.Merijn Brand wrote:
SYNOPSIS
use Devel::Internals;
A little broad. Perhaps Devel::Memory?
My intent was to gather more internal states. Whatever useful.
That's a potentially very large number of exported functions and a very
Michael G Schwern [EMAIL PROTECTED] writes:
Giving read() semantics completely unrelated to reading a filehandle would
be a bad choice of syntax.
I wonder what the people who implemented the GNU/Linux procfs think
about this.
-- Johan
Michael G Schwern [EMAIL PROTECTED] writes:
Giving read() semantics completely unrelated to reading a filehandle would
be a bad choice of syntax.
I wonder what the people who implemented the GNU/Linux procfs think
about this.
-- Johan
=1.48 cu=295.17 cs=27.45 scripts=683 tests=69491 cmem=23.567Gb
This would make it possible to see the diff in mem usage between with or
without debugging, with or without PERLIO=perlio with or without longdoubles
and all the other combo's (64bit vs 32bit ain't fair :)
This was just a thought
At 08:56 AM 8/30/02 +0200, H.Merijn Brand wrote:
Would it be a helpful indication to be able to have perl report the upper
memmory bound on exit? Or better, the memory used: upper- minus lower bound
Being able to do so at any point in Perl's execution would be great. Or is
there such a thing
On Fri 30 Aug 2002 10:15, Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
At 08:56 AM 8/30/02 +0200, H.Merijn Brand wrote:
Would it be a helpful indication to be able to have perl report the upper
memmory bound on exit? Or better, the memory used: upper- minus lower bound
Being able to do so
At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
Being able to do so at any point in Perl's execution would be
great. Or is
there such a thing already and I just don't know about it (and I'm not
thinking about GTop)...
I was thinking about highjacking a standard function: read ()
read
On Fri 30 Aug 2002 10:33, Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
Being able to do so at any point in Perl's execution would be
great. Or is
there such a thing already and I just don't know about it (and I'm not
thinking about
On Fri, Aug 30, 2002 at 10:30:22AM +0200, H.Merijn Brand wrote:
I was thinking about highjacking a standard function: read ()
Giving read() semantics completely unrelated to reading a filehandle would
be a bad choice of syntax. So would making it a keyword. Could you do it
(mostly) via XS?
brainstorming with myself about how to trigger runaway
memory from smoke to smoke
I first thought about an environment variable that, once detected on exit of
perl would show the memory use, but that is neither extensible, nor elegant,
and I thought of the read hack. Then my mind wandered and musings
On Fri, 2002-08-30 at 04:30, H.Merijn Brand wrote:
I was thinking about highjacking a standard function: read ()
read filehandle, $var, length [, offset]
and use it like
read [ \PERL_status ], $mem, memory;
which is very illegal at the moment :) but probably easy to catch in the
At 10:28 AM 8/30/02 -0400, Bryan C. Warnock wrote:
Why not a simple(!) magic hash, or an entire namespace?
print $PROC{memory used};
print $PROC::memory_used;
That would work for me... ;-)
Liz
=1.48 cu=295.17 cs=27.45 scripts=683 tests=69491 cmem=23.567Gb
This would make it possible to see the diff in mem usage between with or
without debugging, with or without PERLIO=perlio with or without longdoubles
and all the other combo's (64bit vs 32bit ain't fair :)
This was just a thought
At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
Being able to do so at any point in Perl's execution would be
great. Or is
there such a thing already and I just don't know about it (and I'm not
thinking about GTop)...
I was thinking about highjacking a standard function: read ()
read
On Fri 30 Aug 2002 10:33, Elizabeth Mattijsen [EMAIL PROTECTED] wrote:
At 10:30 AM 8/30/02 +0200, H.Merijn Brand wrote:
Being able to do so at any point in Perl's execution would be
great. Or is
there such a thing already and I just don't know about it (and I'm not
thinking about
On Fri, Aug 30, 2002 at 10:30:22AM +0200, H.Merijn Brand wrote:
I was thinking about highjacking a standard function: read ()
Giving read() semantics completely unrelated to reading a filehandle would
be a bad choice of syntax. So would making it a keyword. Could you do it
(mostly) via XS?
brainstorming with myself about how to trigger runaway
memory from smoke to smoke
I first thought about an environment variable that, once detected on exit of
perl would show the memory use, but that is neither extensible, nor elegant,
and I thought of the read hack. Then my mind wandered and musings
On Fri, 2002-08-30 at 04:30, H.Merijn Brand wrote:
I was thinking about highjacking a standard function: read ()
read filehandle, $var, length [, offset]
and use it like
read [ \PERL_status ], $mem, memory;
which is very illegal at the moment :) but probably easy to catch in the
At 10:28 AM 8/30/02 -0400, Bryan C. Warnock wrote:
Why not a simple(!) magic hash, or an entire namespace?
print $PROC{memory used};
print $PROC::memory_used;
That would work for me... ;-)
Liz
you have no idea what $foo was.
No you can't. Not if you've overridden isa anywhere. (Which is
perfectly possible.)
Ooooh, hadn't thought about that. I've done it myself a few times (to
make a delegation look like inheritance). Now I have to go fix
Test::More to deal with it. Ya know, I
Hallo Michael,
Am 2001-12-16 um 21:20 schriebst du:
On Sun, Dec 16, 2001 at 11:09:29AM -0700, chromatic wrote:
+ like( $$out, qr/could not locate your pod2man/,
+ '... should warn if pod2man cannot be located' );
Gerrit, do you already have a perl installed in the spot
( UNIVERSAL::isa($foo, 'Foo') );
but if it fails you have no idea what $foo was.
No you can't. Not if you've overridden isa anywhere. (Which is
perfectly possible.)
Ooooh, hadn't thought about that. I've done it myself a few times (to
make a delegation look like inheritance). Now I have to go
Michael G Schwern [EMAIL PROTECTED] writes:
On Sun, Dec 16, 2001 at 02:41:31PM +, Piers Cawley wrote:
The equivalent code without isa_ok() would be:
my $foo = Foo-new;
ok( $foo-isa('Foo') );
except should $foo be unblessed or undef that will explode. You have
to start
Hallo Michael,
Am 2001-12-16 um 21:20 schriebst du:
On Sun, Dec 16, 2001 at 11:09:29AM -0700, chromatic wrote:
+ like( $$out, qr/could not locate your pod2man/,
+ '... should warn if pod2man cannot be located' );
Gerrit, do you already have a perl installed in the spot
( UNIVERSAL::isa($foo, 'Foo') );
but if it fails you have no idea what $foo was.
No you can't. Not if you've overridden isa anywhere. (Which is
perfectly possible.)
Ooooh, hadn't thought about that. I've done it myself a few times (to
make a delegation look like inheritance). Now I have to go
Kurt D. Starsinic [EMAIL PROTECTED] writes:
On Dec 15, Dave Rolsky wrote:
Ok, so that's a bit off the topic of why use isa_ok() but I just don't
see why people seem to object to the use of Test::More in the core Perl
tests. I can't see how it couldn't help improve the quality of the tests
On Sun, Dec 16, 2001 at 02:41:31PM +, Piers Cawley wrote:
Nothing wrong with an adaptor/factory returning something that isn't a
Foo, so long as it has the same interface.
That's why its isa_ok() and not ref_ok().
On the off chance Foo-new is supposed to return something that bears
no
On Sun, Dec 16, 2001 at 07:30:37PM +, Nicholas Clark wrote:
I just thought of a better way. Since all we're testing is that
lib.pm does the right things to @INC, we can presume that if one of
require(), do() or use() works, the rest will work.
Can't we just test what @INC now
On Sun, Dec 16, 2001 at 09:30:18PM -0500, Benjamin Goldberg wrote:
Suppose we have RandomThing-new which randomly returns an instance of
one of a few dozen different classes, which have no relation at all with
each other except a common interface.
In such an odd case, don't use isa_ok().
Michael G Schwern [EMAIL PROTECTED] writes:
On Sat, Dec 15, 2001 at 04:09:19AM +0200, Jarkko Hietaniemi wrote:
I don't get all the different (well, only VMS and Cygwin, so far, but
I like to nip buds) MM_XXX test suites: won't they be testing pretty
much the same things?
Yes, but with
On Sunday 16 December 2001 02:10, Gerrit P. Haase wrote:
Thanks for the report.
../lib/ExtUtils/MM_Cygwin.# Failed test
(../lib/ExtUtils/MM_Cygwin.t at line 73) # undef
# doesn't match '(?-xism:could not locate your pod2man)'
# Failed test
On Sun, Dec 16, 2001 at 02:41:31PM +, Piers Cawley wrote:
Nothing wrong with an adaptor/factory returning something that isn't a
Foo, so long as it has the same interface.
That's why its isa_ok() and not ref_ok().
On the off chance Foo-new is supposed to return something that bears
no
On Sun, Dec 16, 2001 at 07:30:37PM +, Nicholas Clark wrote:
I just thought of a better way. Since all we're testing is that
lib.pm does the right things to @INC, we can presume that if one of
require(), do() or use() works, the rest will work.
Can't we just test what @INC now
Michael G Schwern wrote:
On Sun, Dec 16, 2001 at 02:41:31PM +, Piers Cawley wrote:
Nothing wrong with an adaptor/factory returning something that isn't
a Foo, so long as it has the same interface.
That's why its isa_ok() and not ref_ok().
On the off chance Foo-new is supposed to
On Sun, Dec 16, 2001 at 09:30:18PM -0500, Benjamin Goldberg wrote:
Suppose we have RandomThing-new which randomly returns an instance of
one of a few dozen different classes, which have no relation at all with
each other except a common interface.
In such an odd case, don't use isa_ok().
On Sun, 16 Dec 2001 19:30:18 -0700, Benjamin Goldberg wrote:
I think that if all we know about the returned type is that it is supposed
to provide some specific interface, it would be more robust to test that the
returned thing actually *does* provide the interface.
Agreed. You have my
Hello again Gerrit,
You know, I didn't put the MOST important line in the block. Here's a better
patch. I blame Jeffrey Friedl. :)
Any better?
-- c
--- lib/ExtUtils/~MM_Cygwin.t Sun Dec 16 11:02:04 2001
+++ lib/ExtUtils/MM_Cygwin.t Sun Dec 16 19:59:44 2001
@@ -69,12 +69,17 @@
On Sat, Dec 15, 2001 at 02:19:21PM -0800, Kurt D. Starsinic wrote:
On Dec 15, Dave Rolsky wrote:
Ok, so that's a bit off the topic of why use isa_ok() but I just don't
see why people seem to object to the use of Test::More in the core Perl
tests. I can't see how it couldn't help improve
1 - 100 of 114 matches
Mail list logo
