This now lives at
http://svn.perl.org/parrot/cvs/ (use guest/guest)
http://svn.perl.org/viewcvs/parrot/cvs/trunk/
It is updated from CVS once an hour.
Have fun!
-R
At Sat, 7 Aug 2004 09:52:30 +0100,
Chia-liang Kao wrote:
>
> [1 ]
> Hi,
>
> I've just setup a Subversion mirror of the parrot
Andrew Pimlott wrote:
> I got this error, which I traced down to accidentally calling is() with
> a hashref as the third argument, where the name should have been:
>
> use Test::More 'no_plan';
> is(1,1,{});
Autrijus has fixed this bug in bleadperl, see the patch at
http://public.act
On Fri, Aug 27, 2004 at 09:24:20AM +0200, Rafael Garcia-Suarez wrote:
> In this case that's a bug in Test::Builder, not in perl.
Sure, but it is a very easy bug to make. For perfectly normal code to
break with threads is scary to me. And the fix looks fragile,
especially without a comment. I wo
Andrew Pimlott wrote:
>
> Can you tell me where this limitation in perl threads is documented?
> Is there any hope that it will be removed in the future?
It's not a limitation, if you share a hash it looks normal to me
that you should share its elements too. (or you end up with weird
quantum hash
Joshua Gatcomb wrote:
This might help shed some light:
$ cd t/pmc
$ parrot nci_1.pasm
Not really. bash: parrot: command not found ;)
You got an old parrot around somewhere in the path?
$ parrot --gc-debug nci_1.pasm
Segmentation fault (core dumped)
Well, I just don't have these segfaults. Wait ..
Steve Fink wrote:
On Aug-26, Leopold Toetsch wrote:
.sub @regex_at_foo_imc_line_4711 # e.g.
Yes, this illustrates what I was really getting at. My compiler can
certainly take a subroutine name (or file and line number, or whatever)
to use to generate the code with, but what is the proper way to
At 10:06 AM +0200 8/27/04, Leopold Toetsch wrote:
Joshua Gatcomb wrote:
$ parrot --gc-debug nci_1.pasm
Segmentation fault (core dumped)
Well, I just don't have these segfaults. Wait ... Oops, I've turned
on incremental GC here, which could make it succeed. Recompiling ...
another coffee ...
No.
At 1:43 PM -0700 8/26/04, Bernhard Schmalhofer (via RT) wrote:
This patch adds some test for the Undef PMC.
Apparently not -- the patch wasn't included...
--
Dan
--it's like this---
Dan Sugalski
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> Joshua Gatcomb wrote:
> > This might help shed some light:
> >
> > $ cd t/pmc
> > $ parrot nci_1.pasm
>
> Not really. bash: parrot: command not found ;)
> You got an old parrot around somewhere in the path?
No - believe it or not I only ever ke
At 8:15 AM -0700 8/26/04, Joshua Gatcomb wrote:
I found a few and have erradicated them. I also added
some new functionality. You can now switch between
CPU time and real (wall-clock) time
Applied, thanks.
--
Dan
--it's like this
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Current CVS parrot looks to be losing track of NCI PMCs. Once a DOD
> run goes they get swept collected up, which is a Bad Thing.
I think I could track it down. It wasn't strictly NCI related, though.
The split of dynamic loaders init/load code caused an
--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can trigger the problem locally, though not with
> the nci tests.
> (And, indeed, it may not be the NCI tests ultimately
> at fault) The
> core dump shows things dying in the dod run. GDB's
> backtrace is:
>
> Dan
Ok, I tracked it down to a CVS
Dan --
I think it would be interesting to find out how, say, gcc
behaves on the pathological code structures you've run into.
Could your compiler spit out a structurally (although not
semantically! :) equivalent piece of C code that could be
used with a C compiler to see how we do vs. C compilers i
--- Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> I think I could track it down. It wasn't strictly
> NCI related, though.
I guess you didn't need me to track down the CVS
changes as this fixed the problem - THANKS.
Cheers
Joshua Gatcomb
a.k.a. Limbic~Region
__
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> I can trigger the problem locally, though not with the nci tests.
> (And, indeed, it may not be the NCI tests ultimately at fault) The
> core dump shows things dying in the dod run.
It's fixed. See answer to your ticket.
leo
At 3:32 PM +0200 8/27/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
I can trigger the problem locally, though not with the nci tests.
(And, indeed, it may not be the NCI tests ultimately at fault) The
core dump shows things dying in the dod run.
It's fixed. See answer to you
In S5, the following is stated:
The tr/// quote-like operator now also has a subroutine form.
* It can be given either a single PAIR:
$str =~ tr( 'A-C' => 'a-c' );
* Or a hash (or hash ref):
$str =~ tr( {'A'=>'a', 'B'=>'b', 'C'
Joshua Gatcomb wrote:
I guess you didn't need me to track down the CVS
changes
Well, I just started updating some slides for tomorrows Perl workshop in
Bupapast: http://www.perl.org.hu/english/ changed a single line of code
and got a segfault in the slide presentation program (slpod.imc). The
g
On Fri, 2004-08-27 at 01:09, Andrew Pimlott wrote:
> I would still prefer that Test::Builder not use threads if I don't ask
> for it.
if( $] >= 5.008 && $Config{useithreads} ) {
require threads;
require threads::shared;
threads::shared->import;
}
If you don't have
Aaron Sherman writes:
> Specifically, hashes do not maintain ordering, so a program like this:
>
> $downcaserule = 'A-Z' => 'a-z';
> $l33trule = 'EISTA' => '31574';
> $str =~ tr( { $l33trule, $downcaserule } );
>
> may or may not do what the naive reader expects, and randomly so
On Mon, 2004-08-23 at 03:17, Leopold Toetsch via RT wrote:
> I'd rather not have the cloning in the C code. If you don't reuse the
> nested structure descriptor, it's wasting resources.
There could be another property that tells how many times someone is
using it. I don't think you will like th
On Fri, Aug 27, 2004 at 10:16:48AM +0200, Rafael Garcia-Suarez wrote:
> Andrew Pimlott wrote:
> >
> > Can you tell me where this limitation in perl threads is documented?
> > Is there any hope that it will be removed in the future?
>
> It's not a limitation, if you share a hash it looks normal to
On Fri, Aug 27, 2004 at 09:20:09AM -0700, chromatic wrote:
> If you don't have an ithreads-capable Perl, T::B won't use threads.
>
> If you do, it must,
Ideally, I would agree. But I think a compromise is in order, because
perl threads aren't that mature and are error-prone to program. And
most
On Fri, 2004-08-27 at 11:03, Andrew Pimlott wrote:
> And most tests, even of threaded code, will call T::B from a single thread
> anyhow.
How do you know what tests people will write? How do you know where
people will run those tests?
> There are two ways to do the compromise:
>
> 1. Go threa
On Fri, Aug 27, 2004 at 12:06:47PM -0700, chromatic wrote:
> It doesn't matter how *you* see Perl threads if users who may run your
> tests see them as worth using
First, as I said, I agree with you "ideally". I understand all the
points you're making, and they're basically valid. But the realit
I just reread the table of smart matches in Synopsis 4, and I realized
that it doesn't say what is returned by a ~~ b. For example, the first line
of this table says
$_ $xType of Match ImpliedMatching Code
== = ==
Hello,
should they be? I think they are covered by the statemente in
pdd11 (... about the same level of access to Parrot
that bytecode programs ...).
Regards
Mattia
27 matches
Mail list logo
