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, bu
-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 neat interface.
>>
>> Very op
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 i
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
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'l
-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 wi
]
I did a talk about 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
d, or not) in
> >> Devel::MemUses
> >> * it doesn't reflect the true usage of a perl structure anyway, 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 si
s, since:
>>
>> * your system might not have it, so you either get nothing, or something
>> incompatible (depending on how it is implemented, or not) in
>> Devel::MemUses
>> * it doesn't reflect the true usage of a perl structure anyway, it just
>> rep
ule to maintain :-) The function 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 though you'll probably want
> to do it File::Spec style with Proc::Memory::FreeBS
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,
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 P
-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
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 C
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
s
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 though you'll probably want
to do it File::Spec style with Proc::Memory
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 t
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] writes:
> 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 Ha
Michael G Schwern <[EMAIL PROTECTED]> writes:
> 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 usefu
[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.
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 usag
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 th
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 rea
On Thu, Oct 03, 2002 at 11:39:42AM -0400, Green, Paul wrote:
> 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
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
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
.
My initial sbrk probe used
--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
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
calcul
> 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'
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-s
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
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
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 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 ",
> sbrk () - $end,
-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 t
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 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
>
> 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 ver
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;
my
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
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
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 catc
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 30-Aug-02 H.Merijn Brand carved into stone:
> 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.
is available to the
world. I was just 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
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?
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
> > > thin
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 ()
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
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
=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
"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
>> >>
>> >> ok (eval { ref($foo) && $foo->isa('Foo') });
>> >
>> > As Kurt already pointed out, you can do:
>> >
>> > ok( UNIVERSAL::isa($foo, 'Foo') );
>> >
>> > but if it fails you
Hallo chromatic,
Am 2001-12-16 um 19:09 schriebst du:
> 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 '(?-
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
a('Foo') });
> >
> > As Kurt already pointed out, you can do:
> >
> > ok( 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
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.
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 @@
$args->{
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
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 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 su
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.
>
>
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 r
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 you're about
to put this new one? If so, it might be seein
On Sun, Dec 16, 2001 at 04:20:33PM +, Nicholas Clark wrote:
> Does that mean that it should have its own tests placed in t/lib, so that
> they run before ext/ and lib/?
Yes, it would be nice if they ran before the rest, but I really don't
want to start shuffling tests around this close to 5.8
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 (../li
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, b
Hallo Jarkko,
Am 2001-12-15 um 20:47 schriebst du:
> On Fri, Dec 14, 2001 at 05:20:24PM -0700, chromatic wrote:
>> On Fri, 14 Dec 2001 15:18:43 -0700, Michael G Schwern wrote:
>>
>> > ExtUtils::MM_Cygwin
>>
>> Here's a test for that. It could use someone on Cygwin testing it. Tels said
>> he
Thinks like use_ok, require_ok, isa_ok, can_ok, etc... are all
functions that I threw into Test::More because I found myself needing
them and suspected others did, too. If you prefer to use ok() instead
of one of the above special purpose functions, I'm not going to jump
up and down and fling poo
> 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
> while providing a standardized way to do the things that all the tests
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
> while providing a standardized way to do
On Sat, 15 Dec 2001, Kurt D. Starsinic wrote:
> > my $foo = Foo->new;
> > ok( defined $foo && $foo->isa('Foo') );
> >
> > which rapidly gets tiresome.
>
> Or ok(UNIVERSAL::isa(Foo->new, 'Foo'));
Under 5.005 it spits out warnings if Foo->new returns undef. Plus you
still don't get an
On Dec 14, Michael Schwern wrote:
> Constructors fail often enough that I felt it worthwhile to write a
> test function for them.
>
> You could leave off the test entirely and just trust that you use $foo
> later on down in the test and it'll explode there, but its better to
> put the point of fa
-BEGIN PGP SIGNED MESSAGE-
Moin,
On 15-Dec-01 Jarkko Hietaniemi tried to scribble about:
>> 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 impr
On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote:
> Te"One day Math::Big* will have more tests than Perl;)"ls
One day Perl will have more tests than Bit::Vector. 67255 at last count.
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance
On Sat, Dec 15, 2001 at 11:46:29PM +, Nicholas Clark wrote:
> On Sat, Dec 15, 2001 at 05:59:22PM -0500, Michael G Schwern wrote:
> > On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote:
> > > Te"One day Math::Big* will have more tests than Perl;)"ls
> >
> > One day Perl will have more tests
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 i
On Sat, Dec 15, 2001 at 11:46:29PM +, Nicholas Clark wrote:
> On Sat, Dec 15, 2001 at 05:59:22PM -0500, Michael G Schwern wrote:
> > On Sat, Dec 15, 2001 at 11:48:29PM +0100, Tels wrote:
> > > Te"One day Math::Big* will have more tests than Perl;)"ls
> >
> > One day Perl will have more tests
On Fri, Dec 14, 2001 at 05:20:24PM -0700, chromatic wrote:
> On Fri, 14 Dec 2001 15:18:43 -0700, Michael G Schwern wrote:
>
> > ExtUtils::MM_Cygwin
>
> Here's a test for that. It could use someone on Cygwin testing it. Tels said
> he would, but apparently got busy.
Thanks, applied.
--
$jhi+
On Fri, Dec 14, 2001 at 05:20:24PM -0700, chromatic wrote:
> On Fri, 14 Dec 2001 15:18:43 -0700, Michael G Schwern wrote:
> > ExtUtils::MM_Cygwin
>
> Here's a test for that. It could use someone on Cygwin testing it.
> Tels said he would, but apparently got busy.
Checks out ok on Cygwin98.
--
On Fri, 14 Dec 2001 15:18:43 -0700, Michael G Schwern wrote:
> ExtUtils::MM_Cygwin
Here's a test for that. It could use someone on Cygwin testing it. Tels said
he would, but apparently got busy.
-- c
--- ~MANIFEST Sun Nov 25 19:50:46 2001
+++ MANIFESTSun Nov 25 21:08:01 2001
@@ -930,6
t; A simple way to trick 'use' is to clear the entry from %INC and then
> eval "use Yup".
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
On Fri, Dec 14, 2001 at 05:50:16PM -0500, Michael G Schwern wrote:
> On Sat, Dec 15, 2001 at 12:21:08AM +0200, Jarkko Hietaniemi wrote:
> > On Fri, Dec 14, 2001 at 05:18:43PM -0500, Michael G Schwern wrote:
> > > The good news is Nick Clark just wrote a test for Benchmark! The bad
> > > news is I
On Fri, Dec 14, 2001 at 02:48:07PM -0800, Brent Dax wrote:
> I don't know what directory this should go into,
lib/lib.t I guess.
> so I'm not providing a
> patch, just pasting the body of lib.t in here. Good enough?
>
> #!./perl
>
> use Test::More tests => 3;
> use lib 'stuff';
>
> #create
On Sat, Dec 15, 2001 at 12:21:08AM +0200, Jarkko Hietaniemi wrote:
> On Fri, Dec 14, 2001 at 05:18:43PM -0500, Michael G Schwern wrote:
> > The good news is Nick Clark just wrote a test for Benchmark! The bad
> > news is I made the mistake at looking closer at ext/B/ today, so the
> > list just g
Michael G Schwern:
# lib *new*
I don't know what directory this should go into, so I'm not providing a
patch, just pasting the body of lib.t in here. Good enough?
#!./perl
use Test::More tests => 3;
use lib 'stuff';
#create a directory and a module
mkdir('stuff', 0666)
On Fri, Dec 14, 2001 at 02:26:35PM -0800, Russ Allbery wrote:
> I forget where the wiki is.
WikiHere
http://www.pobox.com/~schwern/cgi-bin/perl-qa-wiki.cgi?UntestedModules
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl Quality Assurance <[EMAIL PROTECTE
The good news is Nick Clark just wrote a test for Benchmark! The bad
news is I made the mistake at looking closer at ext/B/ today, so the
list just got bigger and quite a bit harder.
There's still some fruit that's below giraffe-level, lib and re.
B::Asmdata *new*
B::Assembler
88 matches
Mail list logo
