Also I was thinking it would be nice to be able to run prove and
Devel::Cover together by possibly adding a -M to prove
prove -MDevel::Cover -Ilib -v t/*
I don't recall this -M/-m suggestion, but I like it.
Can someone please submit it to the CPAN queue?
Thanks,
xoxo,
Andy
--
Andy Lester => [EM
Jeff,
On Nov 5, 2004, at 4:33 PM, Jeff Bisbee wrote:
I was just wondering if there was an easier way where make test whould
like in lib and not blib.
Well if you don't do the 'make test' step, you can just call the test
file individually and add 'lib/' to the @INC from the command line.
Like this
* Stevan Little ([EMAIL PROTECTED]) wrote:
> I tend to not re-make my modules before I test them (then again, they
> are always pure perl so I don't need to do it as much in a C based
> module). I have a small shell script (run_coverage.sh) which just
> removes the cover_db folder, then loops th
[EMAIL PROTECTED] (Jeff Bisbee) wrote in message
news:<[EMAIL PROTECTED]>...
> I have a handy script I keep in my ~/bin directory
called 'pmpath'
>
> #!/usr/bin/perl
> $module = shift;
> ($mod = $module) =~ s#::#/#g;
> die ("Need a module name\n") unless $mod;
> $mod .= '.pm';
At 9:34 PM +0100 11/5/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ Yet another f'up ]
..., except that it caches the top
half of the register sets
[ ... ]
copying the low half registers of the (now old)
Dan, the split in lower and upper half of registers was a premature
o
> prove -MDevel::Cover -Ilib -v t/*
>
> I remember mentioning something to Andy, but at the time he didn't like
> it.
On a related note, I think an -M option to prove might be a useful
feature.
With my own test suite, I want to load and run a perl module
(TestConfig.pm) before each test scri
Dan Sugalski <[EMAIL PROTECTED]> wrote:
[ Yet another f'up ]
> ..., except that it caches the top
> half of the register sets
[ ... ]
> copying the low half registers of the (now old)
Dan, the split in lower and upper half of registers was a premature
optimization with zig opcodes to address t
Piers Cawley <[EMAIL PROTECTED]> wrote:
> The catch with generation GC is that, once you have guaranteed
> destructors being called promptly, you still have to sweep the whole
> arena every time you leave a scope.
Yes. I hope that we can track objects needing timely destruction
directly. We have
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 11:39 AM +0100 11/5/04, Leopold Toetsch wrote:
>>The cache misses are basically in two places
>>
>>a) accessing a new register frame and context
>>b) during DOD/GC
> b) is relatively easy -- I'd bet that the vast majority of the cache
> misses are becau
Nicholas Clark <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 05, 2004 at 09:16:36AM +0100, Leopold Toetsch wrote:
>>
>> So, pbc2cc.pl needs just to hexify that image. And the entry point
> hexify? IIRC the fastest compilable representation of arbitrary byte blocks
> we found for perl 5 was how Encode d
At 11:39 AM +0100 11/5/04, Leopold Toetsch wrote:
The cache misses are basically in two places
a) accessing a new register frame and context
b) during DOD/GC
b) is relatively easy -- I'd bet that the vast majority of the cache
misses are because of the copying collector. That could be cleared up
Sam Ruby wrote:
I have a simple unit test[1], one that was not intended to be a
benchmark.
I probably should have included the following in my email *blush*:
[1] http://intertwingly.net/stories/2004/11/05/parrot/t/dynclass/pyint.t
- Sam Ruby
Dan Sugalski wrote:
At 3:49 PM -0500 11/4/04, Sam Ruby wrote:
Background: Pmc2c.pm emits code which references Parrot_PMC_typenum.
This code is present in libparrot.so, which currently is not
referenced as a library by the link step for dynclasses.
Options include:
1) eliminating this dependen
Jeff,
On Nov 5, 2004, at 10:46 AM, Jeff Bisbee wrote:
I'm also curious how other folks run coverage, update modules
and rerun coverage.
I tend to not re-make my modules before I test them (then again, they
are always pure perl so I don't need to do it as much in a C based
module). I have a small
On 2004-11-05, Jeff Bisbee <[EMAIL PROTECTED]> wrote:
>
> I remember mentioning something to Andy, but at the time he didn't like
> it. I'm also curious how other folks run coverage, update modules
> and rerun coverage.
Using Module::Build, it's easy to run coverage:
./Build testcover [test opt
Miroslav Silovic <[EMAIL PROTECTED]> writes:
> Leopold Toetsch wrote:
>
>>> I believe that you shouldn't litter (i.e. create an immediately
>>> GCable object) on each function call - at least not without
>>> generational collector specifically optimised to work with this.
>>
>>
>> The problem isn'
On Nov 4, 2004, at 10:30 PM, Brent 'Dax' Royal-Gordon wrote:
On Thu, 4 Nov 2004 21:46:19 -0800, Jeff Clites <[EMAIL PROTECTED]> wrote:
On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
This is true. But how do you define a number? Do you include
floating-point? Fixed-point? Bignum? B
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Piers Cawley <[EMAIL PROTECTED]> wrote:
>> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>
>>> Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
Hello,
>>>
I've been playing with closures and subs but I have a little bit of
trouble with those.
>>>
On Fri, Nov 05, 2004 at 09:16:36AM +0100, Leopold Toetsch wrote:
> Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> * a PackFile is a PMC (needed e.g. for "eval" anyway)
> * the binary representation is a frozen PackFile
>
> So, pbc2cc.pl needs just to hexify that image. And the entry point
Jeff Clites wrote:
a) As Sam says, in Python "y**z" is just shorthand for
"y.__pow__(z)"--they will compile down to exactly the same thing
(required for Python to behave correctly). Since __pow__ isn't
"special", we don't need anything to support it that we wouldn't need
for any other arbitrary
Miroslav Silovic <[EMAIL PROTECTED]> wrote:
> The problem with copying GC is that pointers can change under your feet
> at every opportunity.
Basically yes. We have that problem currently with the copying
collection of strings. Normally this is solved by keeping the old object
in place, so that p
Jeff Clites <[EMAIL PROTECTED]> wrote:
> a) As Sam says, in Python "y**z" is just shorthand for
> "y.__pow__(z)"--they will compile down to exactly the same thing
> (required for Python to behave correctly).
I don't think so (and you can replace with add, sub, ... FWIW). All these
binops compile
Leopold Toetsch wrote:
I believe that you shouldn't litter (i.e. create an immediately
GCable object) on each function call - at least not without
generational collector specifically optimised to work with this.
The problem isn't the object creation per se, but the sweep through
the *whole obje
On Nov 4, 2004, at 5:24 AM, Sam Ruby wrote:
From a Python or Ruby language perspective, infix operators are not
fundamental operations associated with specific types, they are
syntactic sugar for method calls.
A the moment, I'm compiling x=y**z into:
x = y.__pow__(z)
There is nothing "reserv
* Jim Keenan ([EMAIL PROTECTED]) wrote:
> This is a report on differences between the output of
> 'make test' and 'prove' which are, well, different
> from those reported by Stevan Little in a thread
> beginning on Sept 4.
Are you sure the tarball and the installed version are the same? My
guess
I would like to thank and encourage everyone who is
working on Perl and Perl6 for doing such wonderful
work on improving and building such a wonderful tool.
I really do appreciate it and i have found Perl to be
the most useful and friendly languages I have
used.CPAN I have found to be an invaluable
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
We have to address both areas to get rid of the majority of cache
misses.
ad a)
For each level of recursion, we are allocating a new context structure
and a new register frame. Half of these is coming from the r
Michael Walter <[EMAIL PROTECTED]> wrote:
> I sense confusion between "closure", "continuation" and "coroutine".
> http://c2.com/cgi/wiki?ContinuationsAndCoroutines
and that's even referencing Dan's blog ;)
leo
Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
[ nested coroutines ]
> Do you think the above code snippet could work? That is, without much
> special code, can this be done in PIR?
As said, coroutine's (argument passing and more) behavior isn't yet
layed out and there are several possibilities for t
Luke Palmer <[EMAIL PROTECTED]> wrote:
> The question is, though, how do compilers think of it? That is, does
> the compiler have the liberty, given the code:
> $x ** $y
> To emit:
> pow $P0, x, y
> Or must it use a named multimethod?
Well, that's a thing compilers (or their writers
Sam Ruby <[EMAIL PROTECTED]> wrote:
> Parts of this should have been done in my previous patch, but at the
> time wasn't needed. As the first to need it, I guess I get to implement
> it. ;-)
The "mmd_clone" is done only for dynclasses, I presume.
Why not create the _temp_mmd_init for dynclasses
Miroslav Silovic wrote:
[EMAIL PROTECTED] wrote:
a) accessing a new register frame and context
b) during DOD/GC
Or it would make sense to use multi-frame register chunks. I kept
locality of access in mind but somehow never spelled it out. But I
*think* I mentioned 64kb as a good chunk size precis
Below (inline/attached) is a longish analysis of fib benchmark timings.
leo
Why is the fib benchmark still slow - part 1
Python runs the fib test roughly twice as fast as Parrot. I don't
like that ;) So what's the problem?
1) CPU cache issues
First, if you like to investigate the issue yourself
This is a report on differences between the output of
'make test' and 'prove' which are, well, different
from those reported by Stevan Little in a thread
beginning on Sept 4.
While teaching myself how to use 'prove' tonight, I
decided to try it out on a Perl core module which I
have also been usin
Jeff Clites writes:
> On Nov 4, 2004, at 8:29 PM, Brent 'Dax' Royal-Gordon wrote:
> >This is true. But how do you define a number? Do you include
> >floating-point? Fixed-point? Bignum? Bigrat? Complex? Surreal?
> >Matrix? N registers don't even begin to encompass all the "numbers"
> >out t
RedHat's 5.8.0 was indeed loaded with several patches that tended to
break Perl in many unexpected ways. I actually suggest compiling from
source rather than using a recent RedHat/Fedora Perl.
Steve Peters
[EMAIL PROTECTED]
Christian Aperghis-Tramoni writes:
> I have the folowing program :
>
> print "Give me an integer number : Ân"
> getstdinP0
> readline S1,P0
>
> Its execution gives :
>
> 10
> Give me an integer number :
>
> How is it possible to flush stdout before reading the number
Klaas-Jan Stol writes:
> Hello,
>
> I spoke (through email) with Roberto Ierusalimschy, one of the creators of
> the Lua programming language, and I said that Parrot has good support for
> implementing coroutines and closures (heck, they are explicitly there).
>
> However, in a reply, Roberto a
# New Ticket Created by Sam Ruby
# Please include the string: [perl #32322]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=32322 >
Parts of this should have been done in my previous patch, but at the
time wasn't needed.
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 4:38 PM -0500 11/4/04, Matt Diephouse wrote:
>>On Tue, 2 Nov 2004 13:35:09 -0500, Dan Sugalski <[EMAIL PROTECTED]> wrote:
>>> What, think this warrants a 0.1.2 release? I'm not so sure about
>>> that. It's not that big a deal...
>>
>>In the past week,
Piers Cawley <[EMAIL PROTECTED]> wrote:
> Leopold Toetsch <[EMAIL PROTECTED]> writes:
>> Klaas-Jan Stol <[EMAIL PROTECTED]> wrote:
>>> Hello,
>>
>>> I've been playing with closures and subs but I have a little bit of
>>> trouble with those.
>>
>> newsub $P0, .Closure, _foo
>> $P0
Brent 'Dax' Royal-Gordon <[EMAIL PROTECTED]> wrote:
> Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> To make this actually work we need some standards, and the ability to
>> embed bytecode segments into an executable (like, say, parrot :) so
>> they're always at hand.
> The attached patch implements
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Since I'm about to start in on some of the Irrevocable Changes (or
> something like that) to the string system with the new
> encoding/charset stuff, I tagged CVS and will be working in a branch
> (I hope).
> If you feel like watching or playing along at h
43 matches
Mail list logo
