hi, all.
to build parrot under freebsd need insert
# include
# include
before
include
into file
include/parrot/parrot.h
"Adam Thomason" (via RT) <[EMAIL PROTECTED]> writes:
> 4) 'cc: "io.ops", line 466: warning 950: Shift amount should be in
> the range of zero through 31 bits'
> It's moaning about 32-bit shifts in the 64-bit tell op in io.ops. I
> don't know what the desired failure behavior is for that op in a
--- Paul Johnson <[EMAIL PROTECTED]> wrote:
> Initially I wanted something with few, or better yet no dependencies. I
> also wanted something that required little or no work when I changed the
> internal data structures.
Well, SQLite fails the first and *might* fail on the second. On the other h
On Mon, Oct 20, 2003 at 02:10:51PM -0700, Ovid wrote:
> I'm trying to talk my boss into letting me poke into the internals of
> Devel::Cover more, but I doubt that will be approved. If it is, maybe
> I can work on this.
If you or anyone else does get to look at this the code should all be
locali
Hi all,
After much agony, I finally managed to get our test suite running with 5.8.1.
Unfortunately, the
suite of 15,000 tests takes about an hour to run. After it finished, Devel::Cover
proceeded to
use more and more memory until finally someone on our night crew killed the process.
I'm wond
--- Ovid <[EMAIL PROTECTED]> wrote:
> I'm wondering if coverage results are cumulative? If I have tests in four different
> directories ...
Of course they are, if the -merge option is on. I missed that.
You may now return to your regularly scheduled programming.
Whoops,
Ovid
=
Silence i
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 04:07, Andrew Savige wrote:
> I noticed in Test::Tutorial:
> "Taint mode is a funny thing. It's the globalest of all global features.
> Once you turn it on it effects all code in your program and all modules
> used (and all the mo
On Mon, Oct 20, 2003 at 08:34:50AM -0700, Ovid wrote:
> the suite of 15,000 tests takes about an hour to run.
Devel::Cover issues aside, has anyone else looked at interesting ways of
making test suites run faster?
We insist on a full regression test on checkin, so having the test suite
take a lon
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 18:35, Tony Bowden wrote:
> On Mon, Oct 20, 2003 at 08:34:50AM -0700, Ovid wrote:
> > the suite of 15,000 tests takes about an hour to run.
>
> Devel::Cover issues aside, has anyone else looked at interesting ways of
> making test
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 18:26, Ovid wrote:
> --- Ovid <[EMAIL PROTECTED]> wrote:
> > I'm wondering if coverage results are cumulative? If I have tests in
> > four different directories ...
>
> Of course they are, if the -merge option is on. I missed th
--- Tony Bowden <[EMAIL PROTECTED]> wrote:
> We insist on a full regression test on checkin, so having the test suite
> take a long time to run puts people off making small changes. :(
>
> On one project a full regression test takes about 8 minutes, which is at
> least an order of magnitude longer
> Devel::Cover issues aside, has anyone else looked at interesting ways of
> making test suites run faster?
One of the drums I beat heavily in my discussion of testing of large
projects is that you shouldn't care how long your tests take, so long as
they run within the smokebot window.
The way we
At 10:00 AM 10/20/2003 -0700, Ovid wrote:
--- Tony Bowden <[EMAIL PROTECTED]> wrote:
> We insist on a full regression test on checkin, so having the test suite
> take a long time to run puts people off making small changes. :(
>
> On one project a full regression test takes about 8 minutes, which i
-BEGIN PGP SIGNED MESSAGE-
Moin,
On Monday 20 October 2003 19:10, Andy Lester wrote:
> > Devel::Cover issues aside, has anyone else looked at interesting ways of
> > making test suites run faster?
>
> One of the drums I beat heavily in my discussion of testing of large
> projects is that
On Mon, Oct 20, 2003 at 10:25:17AM -0700, Bob Goolsby (bogoolsb) wrote:
> There is another side to the "made-up" data issue. There are instances
> where you legally can _not_ use live data. Consider a Hospital or
> Insurance company, for example ...
In Europe it's pretty much illegal for any c
On Mon, Oct 20, 2003 at 12:10:33PM -0500, Andy Lester wrote:
> One of the drums I beat heavily in my discussion of testing of large
> projects is that you shouldn't care how long your tests take, so long as
> they run within the smokebot window.
This doesn't work so well with aegis, which has a me
--- Andy Lester <[EMAIL PROTECTED]> wrote:
> One of the drums I beat heavily in my discussion of testing of large
> projects is that you shouldn't care how long your tests take, so long as
> they run within the smokebot window.
Sorry Andy, I can't quite agree with you on this one. Technically, yo
On Mon, Oct 20, 2003 at 10:47:02AM -0700, Ovid wrote:
> The way we're doing tests is simply foolish and we could experience some significant
> productivity
> gains if we were to improve the test performance. Of course, I think it's fair to
> point out that
> much of the performance is due to a p
Tony Bowden wrote:
>
> One other interesting idea I had, although I have no idea how
> practical it is at all really, it to have some way of telling from the
> Devel::Cover reports (or otherwise) what tests aren't actually adding
> any value as the stuff they're testing is already adequately te
--- Tels <[EMAIL PROTECTED]> wrote:
> Well, still it would be good to improve the speed of Devel::Cover, on my box
> (lowly 500 Mhz, yes, I could upgrade to 2 Ghz AMD or so :) a particulary
> project takes 33 minutes for one run... not exactly what I call "interactive"
> :)
Frankly, I think some m
On Mon, Oct 20, 2003 at 07:02:56PM +, [EMAIL PROTECTED] wrote:
> Practically, the only way to do this is to save the results of each test
> in a seperate cover_db and then selectively merge them to see whether or
> not your coverage changed. Even then, finding the minimal set of tests
> that
On Mon, Oct 20, 2003 at 12:24:14PM -0700, Ovid wrote:
> --- Tels <[EMAIL PROTECTED]> wrote:
> > Well, still it would be good to improve the speed of Devel::Cover,
> > on my box (lowly 500 Mhz, yes, I could upgrade to 2 Ghz AMD or so :)
> > a particulary project takes 33 minutes for one run... not e
On Mon, Oct 20, 2003 at 10:16:40PM +0200, Paul Johnson wrote:
> I wrote "database" in quotes because currently we are talking about a
> flat file, written using Data::Dumper and eval'd in. I have considered
> other options - specifically YAML and Storable. I have found YAML to be
> even slower an
On Mon, Oct 20, 2003 at 08:41:12PM +0100, Tony Bowden wrote:
> On Mon, Oct 20, 2003 at 07:02:56PM +, [EMAIL PROTECTED] wrote:
> > Practically, the only way to do this is to save the results of each
> > test in a seperate cover_db and then selectively merge them to see
> > whether or not your co
Tels wrote:
test. I know I have at least written one that did "setup and compile" some
stuff in test 00, and then runs the rest,
Theres something of a nascent convention here;
00_*.t and 99_*.t could be 'reserved' to be 1st and last
respectively, with others randomized.
begin_* and end_* ar
> Theres something of a nascent convention here;
> 00_*.t and 99_*.t could be 'reserved' to be 1st and last
> respectively, with others randomized.
That's pretty much what I was thinking about doing. [0-4]*.t = startup,
in that order, and [5-9]*.t = shutdown, in that order. The rest are
shuff
On Mon, Oct 20, 2003 at 09:34:38PM +0100, Tony Bowden wrote:
> On Mon, Oct 20, 2003 at 10:16:40PM +0200, Paul Johnson wrote:
> > I wrote "database" in quotes because currently we are talking about a
> > flat file, written using Data::Dumper and eval'd in. I have considered
> > other options - spec
On 10/20/2003 2:41 PM, Tony Bowden wrote:
> On Mon, Oct 20, 2003 at 07:02:56PM +, [EMAIL PROTECTED] wrote:
>>
>> If the code has been properly designed (i.e. factored into separate
>> pieces without lots of ugly interdependancies) it should be
>> possible to run the module-level test for that
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
>> The encoding methods for freezing (and corresponding decoding methods for
>> thawing) may be overridden to provide an alternate serialization format.
>> The only requirement of t
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #24257]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=24257 >
Currently ICU is part of the parrot-tree but its not build in any way.
The attached p
Since this has come up again, and it's apparent that the last time around
I wasn't sufficiently clear, it's time to go through this again, and for
the final time. (I will beat this thing into the ground by the time we're
done)
The way object serialization will be handled from the bytecode level i
Note that I forgot to account for the possibility of freezing code and
environment. As such, the freeze and thaw opcodes have the following
variant:
freeze Sx, Py, Iz
thaw Py, Sx, Iz
where Z is the freeze/thaw level. O (the default) is the PMC only, 1
includes the global/class data for the
It would be nice to know if anyone plans to start tackling this soon so
others don't
waste time. Whoever it may be, please notify p6i beforehand so others know
whether to bother or not, rather than submitting the monster stealth patch
that
happens often. Or commit incrementally so we can follow a
At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
The encoding methods for freezing (and corresponding decoding methods for
thawing) may be overridden to provide an alternate serialization format.
The only requirement of the serialziation format is that it starts with a
minimally valid piece of XML
At 08:41 PM 10/20/2003 -0400, Uri Guttman wrote:
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> At 04:38 PM 10/20/2003 -0400, Dan Sugalski wrote:
>> The encoding methods for freezing (and corresponding decoding
methods for
>> thawing) may be overridden to provide an alternate se
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> That answers my question of overhead with regards to XML headers.
MS> If there is a single header for defining the type of "stream" then the
MS> actual serialization can be dense enough.
MS> I just needed clarification. :)
well,
At 09:56 PM 10/20/2003 -0400, Uri Guttman wrote:
> "MS" == Melvin Smith <[EMAIL PROTECTED]> writes:
MS> That answers my question of overhead with regards to XML headers.
MS> If there is a single header for defining the type of "stream" then the
MS> actual serialization can be dense enoug
As mentioned in a previous post, I've been working on getting ordered
destruction working. I actually have a mostly-working version of this
now, which will merit its own discussion, but there's a particular
aspect which I wanted to call out in light of Dan's recent post on
"Object freezing".
A
> the xml header is only for the top level thing in the serialized
> tree. if it is nonstandard you have to mark the serialized string so you
> can call the matching thaw methods. each object in the serialized tree
> will have to support that method or some code has to be supplied to
> handle all
On Oct 20, 2003, at 10:09 PM, Gregor N. Purdy wrote:
Here's an example of a wrapper:
That's a bit better, although bear in mind that if the intent is that
you could throw the entire chunk at an XML parser and have it not
complain, you are going to have to take some care in generating t
On Mon, 20 Oct 2003, Andrew Savige wrote:
> I noticed in Test::Tutorial:
> "Taint mode is a funny thing. It's the globalest of all global features.
> Once you turn it on it effects all code in your program and all modules
> used (and all the modules they use). If a single piece of code isn't
> tai
On Tue, Oct 21, 2003 at 12:24:03AM -0500, Dave Rolsky wrote:
> On Mon, 20 Oct 2003, Andrew Savige wrote:
> > I noticed in Test::Tutorial:
> > "Taint mode is a funny thing. It's the globalest of all global features.
> > Once you turn it on it effects all code in your program and all modules
> > used
42 matches
Mail list logo
