Re: perlbug HOWTO

[Robert Spier]

> > I'd rather something that can actually live on bugs.perl.org.
> How about a bugs.perl.org Kwiki?

I have not yet drunk that particular Kool Aid.  

I'm happy to accept patches.  I also want to retain some level of
editorial control over it, to make sure we don't make right-turns.

-R

Re: Tinderboxens

[Joshua Hoblitt]

> This might be a time to do a Tinderbox v2 rev. The current tinder
> model works pretty well, but it's got some error identification
> issues, and since it works in a "fetch, build, test, sleep, repeat"
> mode if something goes horribly wrong the box stops. A cron-style
> periodic fire-off job might be more robust in the face of things
> going really wrong.

I have to agree - I'm a big cron junkie.  The current implementation seems to crash on 
me about once a month.

Btw - Are there any specific platforms you'd like to see added?

-J

--

Re: Tinderboxens

[Joshua Hoblitt]

> What happend to the tinderboxens? ATM only two are running:
> galactic-tcc and adrastea.

I restarted the scripts on aniani.  I'm at a loss as to why they stopped running.

-J

--

Re: Copyrights

[Josh Wilmes]

I can make such a change if you tell me exactly how it should be done.

(I am not a lawyer, so i don't want to do this inappropriately).

I'd think a safe first step would be to change any "When this is 
determined" to "Yet Another Society".   But beyond that it gets fuzzy to 
me.

--Josh


At 12:16 on 07/10/2003 PDT, Dan Sugalski <[EMAIL PROTECTED]> wrote:

> At 11:56 AM -0700 7/10/03, Robert Spier wrote:
> >s/Yet Another Society/The Perl Foundation/g
> 
> The Perl Foundation is just a dba of YAS. The name should, unless 
> things have changed, be YAS.
> 
> >Gregor N. Purdy wrote:
> >>All --
> >>
> >>I noticed that there are many files with copyrights of
> >>"when this is determined...", while some files have a
> >>copyright of Yet Another Society. Seems like they should
> >>all be Yet Another, or none should be...
> 
> 
> -- 
>  Dan
> 
> --"it's like this"---
> Dan Sugalski  even samurai
> [EMAIL PROTECTED] have teddy bears and even
>teddy bears get drunk

Re: Small perl task for the interested

[Josh Wilmes]

At 12:48 on 07/14/2003 +0200, Lars Balker Rasmussen <[EMAIL PROTECTED]> wrote:

> I've taken this very simple approach to the problem.  A perl-wrapper
> for the CC lines in makefiles/root.in
> 
> .c$(O) :
>   $(PERL) tools/dev/cc_flags.pl $(CC) $(CFLAGS) ${cc_o_out}$@ -c $<

I would go a bit further, and create a tools/build/compile, tools/build/
link_executable, tools/build/link_library, etc.

Take all the flags out of the makefile altogether.  Just a thought.

--Josh

Re: [WIP PATCH] core.ops split-up

[Lars Balker Rasmussen]

Benjamin Goldberg <[EMAIL PROTECTED]> writes:
> (ChangeLog, Configure.pl, parrot.spec, and whatever else is really
> needed to build and distribute parrot (make.pl?)).

Nothing is currently using make.pl, and it's way out of date compared
to the configure system - delete it?
-- 
Lars Balker Rasmussen  Consult::Perl

Re: Aliasing an array slice

[Luke Palmer]

Benjamin Golberg writes:
> Luke Palmer wrote:
> > 
> > > David Storrs wrote:
> > > >
> > > > Thinking about it, I'd rather see lvalue slices become a nicer version
> > > > of C.
> > > >
> > > >  my @start = (0..5);
> > > >  my @a = @start;
> > > >
> > > >  @a[1..3] = qw/ a b c d e /;
> > > >  print @a;   #  0 a b c d e 4 5
> > >
> > > What would happen if I used 1,2,3 instead of 1..3?  Would it do the
> > > same thing?
> > 
> > Of course.
> > 
> > > I wanna know what happens if I do:
> > >
> > >@a[0,2,4] = qw/ a b c d e /;
> > 
> > It would probably do the same as in Perl 5; the same thing as:
> > 
> > @a[0,2,4] = << a b c >>;
> > 
> > (those << >> brackets are new shorthand for qw, not that qw is going
> > anywhere)
> 
> Hmm... so, if I were to do:
> 
>@x = map int(rand(6)), 1..3;
>@[EMAIL PROTECTED] = "a" .. "e";
>print @a.length;
> 
> Then, if the three integers in @x are consecutive, @a grows, but
> otherwise it doesn't?

You know what would be nice?  If I actually read what we were talking
about (which can be seen at the top of this message %-).

In general, (partially) because of this, I don't think slice splicing
is a good idea; that's what the C function is for.  The idea
of lexical expansion is good, and slice splicing kills that. For
example:

@a[1..3] = << a b c d e >>

Can be expanded in people's heads to:

(@a[1], @a[2], @a[3]) = << a b c d e >>

And I don't think that's something we want to get rid of.

Luke

> -- 
> $a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
> );{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
> ]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Re: Aliasing an array slice

[Benjamin Goldberg]

Dave Whipp wrote:
> "Luke Palmer" wrote:
> > Benjamin Goldberg wrote:
> > > David Storrs wrote:
> > > >  @a[1..3] = qw/ a b c d e /;
> > > >  print @a;   #  0 a b c d e 4 5
> > >
> > > What would happen if I used 1,2,3 instead of 1..3?
> > > Would it do the same  thing?
> >
> > Of course.
> 
> I tend to agree, I think. But see below
> 
> > > I wanna know what happens if I do:
> > >
> > >@a[0,2,4] = qw/ a b c d e /;
> >
> > It would probably do the same as in Perl 5; the same thing as:
> >
> > @a[0,2,4] = << a b c >>;
> 
> But that would be awful:
> 
>@a[$x,$y] = <>
> 
> would insert all 5 elements if ($y == $x+1); but only the first two
> otherwise. Belch.
> 
> If we wanted the array-splice thing to resize arrays for us, then either
> we trigger the behavior only when rx/ \[  \.\.  \]/, or

AFAIK, in perl6, $a..$b doesn't create an expanded list... it creates a
lazy list, which gets expanded as-needed.  Most likely, this list
object, and the list object representing the values being stored there,
would be handed directly to the @a array object, just as if we'd done
code like:

   @a[ new LazyIntRange(1,3) ] = new LazyStrRange("a","e");

So, @a can say, "hey, this is a Range, not merely a list of 1,2,3... I
should instead splice() the values in"

> we need to define the spilling algorithm in a way that makes sense (e.g.
> all remaining items go into the element of the righmost index).
>
> But perhaps there's a better way to beet the desire. Perhaps ellipses
> could be emplyed to indicate that the splice is allowed to resize the
> array:
> 
>   @a[1...3] = qw(a b c d e);

That might work, too.

My way is more invisible, but then again, if someone *wants* to have
@a[1,2,3,4,5,6,7,8,9] = @x, and writes it as @a[1..9] = @x, and is
surprised by perl doing a splice, it would be bad; with "..." it would
only splice when the user asks for a splice.

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Re: Aliasing an array slice

[Dave Whipp]

"Luke Palmer" <[EMAIL PROTECTED]> wrote:
> Benjamin Goldberg wrote:
> > David Storrs wrote:
> > >  @a[1..3] = qw/ a b c d e /;
> > >  print @a;   #  0 a b c d e 4 5
> >
> > What would happen if I used 1,2,3 instead of 1..3?  Would it do the same
> > thing?
>
> Of course.

I tend to agree, I think. But see below

> > I wanna know what happens if I do:
> >
> >@a[0,2,4] = qw/ a b c d e /;
>
> It would probably do the same as in Perl 5; the same thing as:
>
> @a[0,2,4] = << a b c >>;

But that would be awful:

   @a[$x,$y] = <>

would insert all 5 elements if ($y == $x+1); but only the first two
otherwise. Belch.

If we wanted the array-splice thing to resize arrays for us, then either we
trigger the behavior only when rx/ \[  \.\.  \]/, or we need
to define the spilling algorithm in a way that makes sense (e.g. all
remaining items go into the element of the righmost index).

But perhaps there's a better way to beet the desire. Perhaps ellipses could
be emplyed to indicate that the splice is allowed to resize the array:

  @a[1...3] = qw(a b c d e);


Dave.

Re: Aliasing an array slice

[Benjamin Goldberg]

Luke Palmer wrote:
> 
> > David Storrs wrote:
> > >
> > > Thinking about it, I'd rather see lvalue slices become a nicer version
> > > of C.
> > >
> > >  my @start = (0..5);
> > >  my @a = @start;
> > >
> > >  @a[1..3] = qw/ a b c d e /;
> > >  print @a;   #  0 a b c d e 4 5
> >
> > What would happen if I used 1,2,3 instead of 1..3?  Would it do the
> > same thing?
> 
> Of course.
> 
> > I wanna know what happens if I do:
> >
> >@a[0,2,4] = qw/ a b c d e /;
> 
> It would probably do the same as in Perl 5; the same thing as:
> 
> @a[0,2,4] = << a b c >>;
> 
> (those << >> brackets are new shorthand for qw, not that qw is going
> anywhere)

Hmm... so, if I were to do:

   @x = map int(rand(6)), 1..3;
   @[EMAIL PROTECTED] = "a" .. "e";
   print @a.length;

Then, if the three integers in @x are consecutive, @a grows, but
otherwise it doesn't?

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Aren't we supposed to be using VTABLE_ macros?

[Benjamin Goldberg]

Maybe someone should write a script like this:

   #!/usr/local/bin/perl -wlpi.bak
   s/
  (\$?\w+) \s* -> \s* vtable \s* -> \s* (\w+) \s*
  \( \s* (interp\w*) \s* , \s* \1 \s*,
   /VTABLE_$2($3, $1,/xg;
   __END__

[untested]

Then run it on all the code, except that which actually defines the
VTABLE_ macros.

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Re: [WIP PATCH] core.ops split-up

[Benjamin Goldberg]

With this increase in the number of files, I'm going to ask for
something I've thought of for a while, but not had the guts to ask for.

Could we try and clean up the parrot/ directory?  Specifically, I'd like
all of the source code itself moved into a single subdirectory, leaving
at the toplevel only directories, the all-caps files, and a few others
(ChangeLog, Configure.pl, parrot.spec, and whatever else is really
needed to build and distribute parrot (make.pl?)).

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Re: Aliasing an array slice

[Luke Palmer]

> David Storrs wrote:
> > 
> > Thinking about it, I'd rather see lvalue slices become a nicer version
> > of C.
> > 
> >  my @start = (0..5);
> >  my @a = @start;
> > 
> >  @a[1..3] = qw/ a b c d e /;
> >  print @a;   #  0 a b c d e 4 5
> 
> What would happen if I used 1,2,3 instead of 1..3?  Would it do the same
> thing? 

Of course.

> I wanna know what happens if I do:
> 
>@a[0,2,4] = qw/ a b c d e /;

It would probably do the same as in Perl 5; the same thing as:

@a[0,2,4] = << a b c >>;

(those << >> brackets are new shorthand for qw, not that qw is going
anywhere)

Luke

> -- 
> $a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
> );{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
> ]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

RE: [WIP PATCH] core.ops split-up

[Brent Dax]

Brent Dax:
# Since I don't think it's polite to flood peoples' mailboxes, I have
# uploaded the 205 kb (9213 line) patch to
# .

The version I originally posted contained a patch to classes/timer.pmc,
basically disabling its guts.  That was included by mistake--Parrot
won't compile on Windows without it.  I just uploaded a new version that
doesn't contain that part.  Sorry about that.

--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
 
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."

Re: Events

[Adam Turoff]

On Fri, Jul 18, 2003 at 01:06:03PM -0700, Damien Neil wrote:
> Also, given that asynchronous IO is a fairly unpopular programming
> technique these days (non-blocking event-loop IO and blocking
> threaded IO are far more common), I would think long and hard before
> placing support for it as a core design goal of the VM.  

What makes you think that Dan hasn't already thought long and hard about AIO?

This design issue has been settled for months now.  And if you don't
think it's a particularly *good* design decision, think about this quote
from Alan Perlis[1]:

Symmetry is a complexity-reducing concept (co-routines include
subroutines); seek it everywhere. 

AIO with files simplifies *all* IO handling.  You get sync IO through a
thin wrapper over AIO.  Socket IO is already async, so why have multiple
incompatible models?  Why repeat the mistakes of the C standard library
for the umteenth time?

Z.

[1] Alan Perlis: (n) definately not an idiot

Re: Aliasing an array slice

[Benjamin Goldberg]

David Storrs wrote:
> 
> Thinking about it, I'd rather see lvalue slices become a nicer version
> of C.
> 
>  my @start = (0..5);
>  my @a = @start;
> 
>  @a[1..3] = qw/ a b c d e /;
>  print @a;   #  0 a b c d e 4 5

What would happen if I used 1,2,3 instead of 1..3?  Would it do the same
thing?  I wanna know what happens if I do:

   @a[0,2,4] = qw/ a b c d e /;

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Re: Events

[Uri Guttman]

> "BG" == Benjamin Goldberg <[EMAIL PROTECTED]> writes:

  BG> Damien Neil wrote:
  BG> [snip]
  >> Also, given that asynchronous IO is a fairly unpopular programming
  >> technique these days (non-blocking event-loop IO and blocking
  >> threaded IO are far more common), I would think long and hard before
  >> placing support for it as a core design goal of the VM.  If there
  >> is a compelling reason to use AIO, the implementation may better
  >> be handled at a lower level than Parrot; even if Parrot itself does
  >> not support AIO at the opcode level, Parrot programs could still
  >> use it by calling down to a C library.

  BG> AIO is unpopular because it's not widely/portably supported, whereas
  BG> non-blocking event-loop IO is, (one generally does have either select or
  BG> poll), as is blocking threaded IO (even if the thread starting stuff may
  BG> need to be different on some platform, it's *mostly* portable).

and event loop i/o doesn't usually support async file i/o. many people
conflate the two. event i/o handles sockets, pipes and such but none
support files. the issue is that the async file i/o api is so different
(or non-existant) on all the platforms. dan wants to make clean async
file i/o in the core by using a blocking thread on each i/o request and
synchronizing them with this event queue in the main thread. it has the
advantage of being easier to code and should work on most platforms
which have threads. and he wants async file i/o in parrot core since it
is faster and has to be in the core to be properly supported at higher
levels.

  BG> If we make it a core part of parrot, it will become more popular,
  BG> simply because of parrot's availability.

that is a major win since no other system i (or dan) has heard of has
portable async file i/o. and it will be integrated into the core event
handling so you will be able to mix and match async socket, terminal (on
unix at least) and file i/o with timers. this is what i want. :)

uri

-- 
Uri Guttman  --  [EMAIL PROTECTED]   http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs    http://jobs.perl.org

[WIP PATCH] core.ops split-up

[Brent Dax]

 core.ops is...monolithic.
 core.ops could use a good splitting out, definitely

At 108k, core.ops is the second largest file in the Parrot distribution.
It's larger than all but five or six C files in bleadperl.  It has
nearly five hundred more lines than pp.c--and that's with several lines
of macros per opcode.

core.ops is also a file that gets hacked on a lot--at version 311, it
has nearly twice as many revisions as its nearest competitor
(interpreter.c, at version 171).  As of this writing, it was involved in
the most recent commit to touch the root directory.

Finally, core.ops is one of the most important parts of the
distribution, for reasons that should be easy to understand.

I understand that Parrot's nature--its language-independence, its
register-based nature, etc.--requires more opcodes than Perl 5, and I
don't mind that.  What I do mind is that core.ops has become
unmanageably large.  I believe it's time to split it up.

Since I don't think it's polite to flood peoples' mailboxes, I have
uploaded the 205 kb (9213 line) patch to
.  It moves most
of core.ops into nine other opcode files; seven are brand new, while two
are dramatically expanded from their previous lives.  core.ops remains,
containing the first eight opcodes, basic control flow operations
(including subroutine operations), and interpreter introspection.

The ten files affected are:
core.ops   [20k] contracted
math.ops   [17k] expanded
pmc.ops[ 9k] expanded
sys.ops[ 9k] new
set.ops[ 9k] new
cmp.ops[ 8k] new
string.ops [13k] new
bit.ops[ 5k] new
stack.ops  [14k] new
var.ops[ 5k] new

With the patch, rx.ops becomes the largest opcode file, at 25k.  (Sizes
here assume that 1000 bytes=1k, because 'dir' is stupid and I'm too lazy
to round properly.)

This patch is *not* complete, as the documentation needs a lot of fixing
up.  However, I'd like to know what people think of the general idea of
splitting core.ops, and of the arrangement I've chosen.  Other than the
documentation, the patch should work fine--but note that this patch
*will* change the opcode numbers, so you'll have to re-assemble all your
Parrot bytecode files.

Configure will automatically detect the new opcode files and include
them in the build, and a MANIFEST patch is also included.  Test pass
rate is 96.49%, which is roughly as expected on my Windows 2000 system;
I don't know how well it works on a system with less "noise" in the
tests.

Please test this out and let me know if it works or not, as well as if
I've split things well.

--Brent Dax <[EMAIL PROTECTED]>
Perl and Parrot hacker
 
"Yeah, and my underwear is flame-retardant--that doesn't mean I'm gonna
set myself on fire to prove it."

Re: Events

[Benjamin Goldberg]

Damien Neil wrote:
[snip]
> Also, given that asynchronous IO is a fairly unpopular programming
> technique these days (non-blocking event-loop IO and blocking
> threaded IO are far more common), I would think long and hard before
> placing support for it as a core design goal of the VM.  If there
> is a compelling reason to use AIO, the implementation may better
> be handled at a lower level than Parrot; even if Parrot itself does
> not support AIO at the opcode level, Parrot programs could still
> use it by calling down to a C library.

AIO is unpopular because it's not widely/portably supported, whereas
non-blocking event-loop IO is, (one generally does have either select or
poll), as is blocking threaded IO (even if the thread starting stuff may
need to be different on some platform, it's *mostly* portable).

If we make it a core part of parrot, it will become more popular, simply
because of parrot's availability.

> > It's not just signals, there's a lot of stuff that falls into this
> > category. We've got to deal with it, and deal with it properly, since
> > not dealing with it gets you an 80% solution.
> 
> Outside of signals and AIO, what requires async event dispatch?
> User events, as you pointed out above, are better handled through
> an explicit request for the next event.

Inter-thread notification and timers?  True, these *could* be considered
to be "user events", but IMHO, there are times when we want a "user
event" to have the same (high) priority as a system signal.

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "[EMAIL PROTECTED]
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Re: TODO tests for outstanding bugs?

[Rafael Garcia-Suarez]

chromatic wrote in perl.qa :
> One idea is attaching a simple test case to every bug report that 
> doesn't have test code that's nearly right for the core.  It's a lot 
> easier to touch up a test case than it is to write one, so we could do 
> a lot of good by turning bug reports into executable tests without 
> having to worry about where they'll eventually end up.

"Write tests before fixes" :) This always help.

For such standalone 1-bug test scripts, Test::More is (most of the time)
ok. However there are places in the core where Test::More can't be used,
simply because they're tests for core features used by Test::More.

Re: Events

[Damien Neil]

On Fri, Jul 18, 2003 at 11:29:27AM -0400, Dan Sugalski wrote:
> Nope, that won't work. A lot of what's done is really "main thread 
> with interrupts" and that doesn't map well to doing all signal 
> handling in separate threads. You really do want to pause the main 
> program to handle the events that are coming in, if they're events of 
> sufficient importance. Generally I put them in three classes--hard 
> interrupts (signals), soft interrupts (IO completion stuff), and 
> events (fuzzy user-level stuff). Hard and soft interrupts should get 
> dealt with as soon as possible, events should probably wait until 
> something explicitly decides to process an event.

In my experience, interrupt handlers in Perl code generally fall
into three categories: Ones that set a flag to be checked later,
ones that perform an action and terminate the program, and buggy
ones subject to race conditions.

IO completion events in particular should not be handled by
interrupting the main execution thread.  The appropriate action
required to handle these events will almost invariably require
access to data structures shared between the interrrupt handler
and the main thread.  If you place the interrupt handler in the
main thread, you can't use locks to control access to these
structures (as the handler will wait on the main thread's lock,
while the main thread will block on the handler returning).
This leads to Unix-style signal masks, where interrupts are
blocked during critical sections.  While this works, I strongly
feel that a platform with thread support is better off dispatching
interrupts to a separate thread and using the existing interthread
synchronization mechanisms, rather than introducing a separate
interrupt masking system.

Also, given that asynchronous IO is a fairly unpopular programming
technique these days (non-blocking event-loop IO and blocking
threaded IO are far more common), I would think long and hard before
placing support for it as a core design goal of the VM.  If there
is a compelling reason to use AIO, the implementation may better
be handled at a lower level than Parrot; even if Parrot itself does
not support AIO at the opcode level, Parrot programs could still
use it by calling down to a C library.


> It's not just signals, there's a lot of stuff that falls into this 
> category. We've got to deal with it, and deal with it properly, since 
> not dealing with it gets you an 80% solution.

Outside of signals and AIO, what requires async event dispatch?
User events, as you pointed out above, are better handled through
an explicit request for the next event.

  - Damien

Re: TODO tests for outstanding bugs?

[chromatic]

On Friday, July 18, 2003, at 10:36 AM, Tony Bowden wrote:

What's the current approach to turning perlbugs into tests?
In general, the person who fixes the bug writes a regression test for 
the bug.  The pumpkings and other porters are really good about making 
sure patches have tests.

Should they be done as TODOs? Is there a distinct set of test files for
them? etc? Can they use Test::More?  etc. etc. etc.
I like the idea and I can see how it would make some things easier.  We 
might get a lot of benefit from a little simpler idea, though.

Putting them as TODO tests might just shift the problem -- too many 
bugs, not enough people looking at RT to solve them -- into "not enough 
people are looking at the TODO tests to solve them".  Library bugs can 
use Test::More.  Language bugs may or may not, depending on how complex 
the bug seems to be.  (A bug in print would likely need testing in 
t/op/print.t.)

I could imagine a test case being massaged and mangled a couple of 
times before it's ready to be checked in.  As a matter of policy, if it 
were up to me, I'd hesitate to go quite that far.

e.g. http://bugs6.perl.org/rt2/Ticket/Display.html?id=5430

can have a fairly simple test like:

package main;
eval '::is(__PACKAGE__, "main", "Package is main inside eval")';
package Foo;
eval '::is(__PACKAGE__, "Foo", "Package is Foo inside eval")';
But how we actually get that into the core somewhere?
One idea is attaching a simple test case to every bug report that 
doesn't have test code that's nearly right for the core.  It's a lot 
easier to touch up a test case than it is to write one, so we could do 
a lot of good by turning bug reports into executable tests without 
having to worry about where they'll eventually end up.

-- c

[perl #23044] [PATCH] Fix some warnings in nci.c

[Jürgen]

# New Ticket Created by  Jürgen Bömmels 
# Please include the string:  [perl #23044]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=23044 >


nci.c generates a bunch of prototype warnings when compiled with gcc
and callframes are not build at runtime. The attached patch removes
these warnings. While at it the function definitions are changed to
match PDD07.

bye
boe



-- attachment  1 --
url: http://rt.perl.org/rt2/attach/61352/45287/493625/build_nativecall.diff

Index: build_nativecall.pl
===
RCS file: /cvs/public/parrot/build_nativecall.pl,v
retrieving revision 1.14
diff -u -r1.14 build_nativecall.pl
--- build_nativecall.pl	14 Jun 2003 17:48:31 -	1.14
+++ build_nativecall.pl	18 Jul 2003 20:46:27 -
@@ -26,6 +26,18 @@
 		  v => "void",
  );
 
+my (%proto_type) = (p => "void *",
+		i => "int",
+		l => "long",
+		c => "char",
+		s => "short",
+		f => "float",
+		d => "double",
+		t => "char *",
+		v => "void",
+		I => "struct Parrot_Interp *",
+		   );
+
 my (%other_decl) = (p => "PMC *final_destination = pmc_new(interpreter, enum_class_UnManagedStruct);");
 
 my (%ret_type_decl) = (p => "void *",
@@ -108,7 +120,9 @@
 /* All our static functions that call in various ways. Yes, terribly
hackish, but that's just fine */
 
-static void set_return_val(struct Parrot_Interp *interpreter, int stack, int ints, int strings, int pmcs, int nums) {
+static void 
+set_return_val(struct Parrot_Interp *interpreter, int stack, int ints, 
+   int strings, int pmcs, int nums) {
 INT_REG(0) = stack;
 INT_REG(1) = ints;
 INT_REG(2) = strings;
@@ -135,7 +149,9 @@
 }
 
 # Header
-generate_func_header($ret, $args, (join ",", @arg), $ret_type{$ret}, $ret_type_decl{$ret}, $func_call_assign{$ret}, $other_decl{$ret},  $ret_assign{$ret});
+generate_func_header($ret, $args, (join ",", @arg), $ret_type{$ret}, 
+			 $ret_type_decl{$ret}, $func_call_assign{$ret}, 
+			 $other_decl{$ret},  $ret_assign{$ret});
 
 # Body
 
@@ -151,8 +167,10 @@
 /* This function serves a single purpose. It takes the function
signature for a C function we want to call and returns a pointer
to a function that can call it. */
-void *build_call_func(struct Parrot_Interp *interpreter, PMC *pmc_nci,
-  String *signature) {
+void *
+build_call_func(struct Parrot_Interp *interpreter, PMC *pmc_nci,
+String *signature)
+{
 #if defined(CAN_BUILD_CALL_FRAMES)
 /* This would be a good place to put the code that builds the
frames. Undoubtedly painfully platform-dependent */
@@ -206,33 +224,46 @@
 
 sub set_return_count {
 my ($stack, $int, $string, $pmc, $num) = @_;
-print NCI "  set_return_val(interpreter, $stack, $int, $string, $pmc, $num);\nreturn;\n}\n\n"
+print NCI cache.struct_val);
 $return_assign ($ret_type)(*pointer)($call_params);
 $final_assign
 HEADER
   }
   else {
 print NCI cache.struct_val);
 $return_assign ($ret_type)(*pointer)();
 $final_assign
 HEADER

-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Re: perlbug HOWTO

[Robert Spier]

At Fri, 18 Jul 2003 18:19:19 +0100,
Tony Bowden wrote:
> I've been chatting with Casey about how we should best be dealing with
> the perlbug RT interface - e.g. what to do when you come across a bug
> that's resolved, what the various statuses mean etc.

The proper place for this particular discussion is probably the
currently-defunct bugmongers list.

> There doesn't seem to be any documentation anywhere on this, and we
> thought the QA wiki might be a useful place to try putting it
> together.

I'd rather something that can actually live on bugs.perl.org.

> Thoughts, suggestions, ideas?

Here's my document for the old perlbug.  It's horribly out of date.
But would be a good place to start.



adminfaq
Description: Binary data

Re: [perl #23040] [PATCH] Fix one double free in io.c

[Dan Sugalski]

At 5:51 PM + 7/18/03, "J¸rgen" "B–mmels" (via RT) wrote:
i,

finally I found one of the double free errors in io.c:
At Parrot_exit the PIOs are destroyed and the buffer memory is
freed. Unfortunatly the pointer is not cleared, so if there is a
second PMC pointing to the same PIO the buffer is freed a second time.
Attached patch fixes this
Applied. Things still die, just less violently. :)
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Problems with new object ops

[Dan Sugalski]

At 1:34 PM -0400 7/18/03, Simon Glover wrote:
 Of course this still doesn't work, because we never actually add anything
 to the class_hash. Patch below fixes this, as well as various bugs in
 Parrot_single_subclass, and adds a couple of regression tests.
Thanks Simon. Applied.
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: [perl #23028] t/op/stacks fails on FreeBSD/i386

[Lars Balker Rasmussen]

On Fri, Jul 18, 2003 at 12:04:39PM -0400, Simon Glover wrote:
>  OK, this should be fixed in CVS 

Yup.
-- 
Lars Balker RasmussenConsult::Perl

[perl #23040] [PATCH] Fix one double free in io.c

[Jürgen]

# New Ticket Created by  Jürgen Bömmels 
# Please include the string:  [perl #23040]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=23040 >


Hi,

finally I found one of the double free errors in io.c:
At Parrot_exit the PIOs are destroyed and the buffer memory is
freed. Unfortunatly the pointer is not cleared, so if there is a
second PMC pointing to the same PIO the buffer is freed a second time.

Attached patch fixes this

bye
boe



-- attachment  1 --
url: http://rt.perl.org/rt2/attach/61326/45270/835a84/io15.diff

Index: io/io.c
===
RCS file: /cvs/public/parrot/io/io.c,v
retrieving revision 1.46
diff -u -r1.46 io.c
--- io/io.c	16 Jul 2003 05:46:23 -	1.46
+++ io/io.c	18 Jul 2003 17:46:20 -
@@ -100,8 +100,11 @@
 ParrotIO *io = PMC_data(pmc);
 UNUSED(interpreter);
 
-if (io->b.startb && (io->b.flags & PIO_BF_MALLOC))
+if (io->b.startb && (io->b.flags & PIO_BF_MALLOC)) {
 mem_sys_free(io->b.startb);
+io->b.startb = NULL;
+io->b.flags &= ~PIO_BF_MALLOC;
+}
 mem_sys_free(io);
 PMC_data(pmc) = NULL;
 pmc->cache.struct_val = NULL;

-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Re: Problems with new object ops

[Simon Glover]

 Of course, if you apply the previous patch, you'll also need to apply
 this one...

 Simon

--- MANIFEST.oldFri Jul 18 13:35:04 2003
+++ MANIFESTFri Jul 18 13:35:41 2003
@@ -1861,6 +1861,7 @@
 t/pmc/managedstruct.t []
 t/pmc/multiarray.t[]
 t/pmc/nci.t   []
+t/pmc/objects.t   []
 t/pmc/perlarray.t []
 t/pmc/perlhash.t  []
 t/pmc/perlint.t   []

TODO tests for outstanding bugs?

[Tony Bowden]

What's the current approach to turning perlbugs into tests?

Should they be done as TODOs? Is there a distinct set of test files for
them? etc? Can they use Test::More?  etc. etc. etc.

e.g. http://bugs6.perl.org/rt2/Ticket/Display.html?id=5430

can have a fairly simple test like:

package main;
eval '::is(__PACKAGE__, "main", "Package is main inside eval")';
package Foo;
eval '::is(__PACKAGE__, "Foo", "Package is Foo inside eval")';

But how we actually get that into the core somewhere?

Tony

Re: Problems with new object ops

[Simon Glover]

On Thu, 17 Jul 2003, Dan Sugalski wrote:

> At 9:24 AM +0200 7/17/03, Leopold Toetsch wrote:
> >Simon Glover <[EMAIL PROTECTED]> wrote:
> >
> >  >   For instance, in findclass, you have:
> >
> >>if (VTABLE_get_pmc_keyed(interpreter, interpreter->class_hash,
> >> key_new_string(interpreter, $2))) {
> >>  $1 = 1;
> >>   } else {
> >>  $1 = 0;
> >>   }
> >
> >this should be VTABLE_exists_keyed ...
>
> Point. Updated.

 Of course this still doesn't work, because we never actually add anything
 to the class_hash. Patch below fixes this, as well as various bugs in
 Parrot_single_subclass, and adds a couple of regression tests.

 Simon

--- objects.c.old   Fri Jul 18 12:09:27 2003
+++ objects.c   Fri Jul 18 13:30:14 2003
@@ -31,16 +31,19 @@

   child_class = pmc_new(interpreter, enum_class_ParrotClass);
   child_class_array = PMC_data(child_class);
+
   /* We have the same number of attributes as our parent */
   child_class->obj.u.int_val = base_class->obj.u.int_val;
+
   /* Our parent class array has a single member in it */
   temp_pmc = pmc_new(interpreter, enum_class_Array);
+  VTABLE_set_integer_native(interpreter, temp_pmc, 1);
   VTABLE_set_pmc_keyed_int(interpreter, child_class_array, 0, temp_pmc);
   VTABLE_set_pmc_keyed_int(interpreter, temp_pmc, 0, base_class);

   /* Our penultimate parent list is a clone of our parent's parent
  list, with our parent unshifted onto the beginning */
-  temp_pmc = pmc_new(interpreter, enum_class_PerlUndef);
+  temp_pmc = pmc_new_noinit(interpreter, enum_class_Array);
   VTABLE_clone(interpreter,
   VTABLE_get_pmc_keyed_int(interpreter,
(PMC *)PMC_data(base_class), 1),
@@ -49,7 +52,7 @@
   VTABLE_set_pmc_keyed_int(interpreter, child_class_array, 1, temp_pmc);

   /* Our attribute list is our parent's attribute list */
-  temp_pmc = pmc_new(interpreter, enum_class_PerlUndef);
+  temp_pmc = pmc_new_noinit(interpreter, enum_class_PerlHash);
   VTABLE_clone(interpreter,
   VTABLE_get_pmc_keyed_int(interpreter,
(PMC *)PMC_data(base_class), 2),
@@ -57,7 +60,7 @@
   VTABLE_set_pmc_keyed_int(interpreter, child_class_array, 2, temp_pmc);

   /* And our full keyed attribute list is our parent's */
-  temp_pmc = pmc_new(interpreter, enum_class_PerlUndef);
+  temp_pmc = pmc_new_noinit(interpreter, enum_class_PerlHash);
   VTABLE_clone(interpreter,
   VTABLE_get_pmc_keyed_int(interpreter,
(PMC *)PMC_data(base_class), 3),
@@ -68,7 +71,13 @@
   classname_pmc = pmc_new(interpreter, enum_class_PerlString);
   if (child_class_name) {
 VTABLE_set_string_native(interpreter, classname_pmc, child_class_name);
-  } else {
+
+/* Add ourselves to the interpreter's class hash */
+VTABLE_set_pmc_keyed(interpreter, interpreter->class_hash,
+ key_new_string(interpreter, child_class_name),
+ child_class);
+  }
+  else {
 VTABLE_set_string_native(interpreter, classname_pmc,
 string_make(interpreter, "\0\0anonymous", 11, NULL, 0, 
NULL));
   }
@@ -106,6 +115,10 @@
   VTABLE_set_string_native(interpreter, classname_pmc, class_name);
   VTABLE_set_pmc_keyed_int(interpreter, new_class_array, 4, classname_pmc);

+  /* Add ourselves to the interpreter's class hash */
+  VTABLE_set_pmc_keyed(interpreter, interpreter->class_hash,
+   key_new_string(interpreter,class_name), new_class);
+
   return(new_class);
 }

 --- /dev/null  Thu Aug 30 16:30:55 2001
+++ t/pmc/objects.t Fri Jul 18 13:31:01 2003
@@ -0,0 +1,43 @@
+#! perl -w
+
+use Parrot::Test tests => 2;
+use Test::More;
+
+output_is(<<'CODE', <<'OUTPUT', "findclass (base class)");
+newclass P1, "Foo"
+
+findclass I0, "Foo"
+print I0
+print "\n"
+
+findclass I0, "Bar"
+print I0
+print "\n"
+end
+CODE
+1
+0
+OUTPUT
+
+output_is(<<'CODE', <<'OUTPUT', "findclass (subclass)");
+newclass P1, "Foo"
+subclass P2, P1, "Bar"
+
+findclass I0, "Foo"
+print I0
+print "\n"
+
+findclass I0, "Bar"
+print I0
+print "\n"
+
+findclass I0, "Qux"
+print I0
+print "\n"
+
+end
+CODE
+1
+1
+0
+OUTPUT

perlbug HOWTO

[Tony Bowden]

I've been chatting with Casey about how we should best be dealing with
the perlbug RT interface - e.g. what to do when you come across a bug
that's resolved, what the various statuses mean etc.

There doesn't seem to be any documentation anywhere on this, and we
thought the QA wiki might be a useful place to try putting it together.

Does anyone actually still use that?  Does it matter? Is this is best idea? 

Thoughts, suggestions, ideas?

Tony

[perl #23039] [PATCH] event handling-2

[via RT]

# New Ticket Created by  Leopold Toetsch 
# Please include the string:  [perl #23039]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=23039 >


OK here it is.
Again the description for the record:

1) Initialization:
- normal core: build op_func_table with all opcode #4 [1]
- CG core: build ops_addr[] filled with this opcode
- prederef cores: build a list of (backward) branch instructions
  and the opcode at that offset

2) When an events gets scheduled (signal handler) it calls the running
core with:

 interpreter->op_func_table =
init_func(interpreter, OPLIB_SET_CHK_EV_FT)->op_func_table;

This replaces for normal and CG core the op_func_table or the
ops_addr with that from 1)
Prederefed cores get on all branch instruction from the list built
in 1) an opcode #4 patched.

3) So when the next instruction (normal, CG core) or the branch
instruction (prederefed cores) gets executed, first the op_func_table
or the patched instructions are restored and then the event handler
can be called.

This now works for all cores (except JIT[2]). It doesn't have any 
runtime penalty for an extra check if events are due.
[1] This opcode (check_event__) calls the actual event handling code
 and returns the same address, i.e. doesn't advance the PC.

[2] We could do the same here, but this needs cache sync for ARM and 
PPC, which may or may not be allowed in signal code.

Still needs some cleanup ...

leo


-- attachment  1 --
url: http://rt.perl.org/rt2/attach/61323/45267/aa640c/event handling-2.patch

--- parrot/classes/timer.pmcThu Jul 17 15:46:23 2003
+++ parrot-leo/classes/timer.pmcThu Jul 17 17:55:17 2003
@@ -54,6 +54,7 @@
  * for now we keep all stuff inside the pmc
  */
 
+void do_alarm_handler(void);   /* XXX s. events.c */
 /* interface constants */
 /* &gen_from_enum(timer.pasm) */
 typedef enum {
@@ -203,7 +204,7 @@
stop_sys_timer_ms(handle);
 }
 
-static void
+void
 do_alarm_handler(void)
 {
 parrot_timer_t *t;
@@ -211,6 +212,8 @@
 int recalc = 0;
 
 ms = get_sys_timer_ms(handle);
+if (!ms)   /* no timer running */
+   return;
 for (t = rtimer; t; t = t->next) {
if (!--t->ticks) {
t->state = TIMER_STATE_FIRE;
--- parrot/config/gen/config_h/config_h.in  Sun Mar 16 12:12:04 2003
+++ parrot-leo/config/gen/config_h/config_h.in  Fri Jul 18 13:33:42 2003
@@ -106,7 +106,11 @@
 
 #define PARROT_CORE_OPLIB_NAME "core"
 #define PARROT_CORE_OPLIB_INIT Parrot_DynOp_core_${MAJOR}_${MINOR}_${PATCH}
+
 #define PARROT_CORE_PREDEREF_OPLIB_INIT 
Parrot_DynOp_core_prederef_${MAJOR}_${MINOR}_${PATCH}
+#define PARROT_CORE_SWITCH_OPLIB_INIT 
Parrot_DynOp_core_switch_${MAJOR}_${MINOR}_${PATCH}
+#define PARROT_CORE_CG_OPLIB_INIT Parrot_DynOp_core_cg_${MAJOR}_${MINOR}_${PATCH}
+#define PARROT_CORE_CG_OPLIB_INIT Parrot_DynOp_core_cg_${MAJOR}_${MINOR}_${PATCH}
 #define PARROT_CORE_CGP_OPLIB_INIT Parrot_DynOp_core_cgp_${MAJOR}_${MINOR}_${PATCH}
 
 #define INTVAL_FMT "${intvalfmt}"
--- parrot/core.ops Fri Jul 18 07:34:06 2003
+++ parrot-leo/core.ops Fri Jul 18 16:41:24 2003
@@ -97,7 +97,7 @@
 }
 
 inline op check_events__() {
-  opcode_t *this = CUR_OPCODE;
+  opcode_t *this = CUR_OPCODE; /* repeat the same opcode */
   HANDLE_EVENTS(interpreter);
   goto ADDRESS(this);  /* force this being a branch op */
 }
--- parrot/events.c Sun Jul 13 17:54:46 2003
+++ parrot-leo/events.c Fri Jul 18 16:41:19 2003
@@ -15,30 +15,76 @@
 #ifdef HAS_HEADER_SETJMP
 /* XXX s. exceptions.c */
 void do_exception(exception_severity severity, long error);
-void Parrot_init_signals(void);
 #endif
 
+void do_alarm_handler(void);   /* XXX s. timer.c */
+
+void Parrot_init_signals(Parrot_Interp);
+static Parrot_Interp the_interpreter;
+
+void
+Parrot_do_handle_events(Parrot_Interp interpreter)
+{
+oplib_init_f init_func = interpreter->op_init_func;
+interpreter->op_func_table =
+init_func(interpreter, OPLIB_INIT)->op_func_table;
+if (interpreter->has_events) {
+fprintf(stderr, "got event\n");
+--interpreter->has_events;
+/* TODO pop event off the event queue */
+/* case SIGALRM: */
+do_alarm_handler();
+}
+}
+
+/* synchronous event checker from check_event opcode */
+void
+Parrot_do_check_events(Parrot_Interp interpreter)
+{
+}
+
+/*
+ * next 2 are interrupt code
+ */
+
+static void
+enable_event_checker(Parrot_Interp interpreter) {
+oplib_init_f init_func = interpreter->op_init_func;
+interpreter->op_func_table =
+init_func(interpreter, OPLIB_SET_CHK_EV_FT)->op_func_table;
+}
+
+#if defined(HAS_HEADER_SIGNAL) && defined(SIGFPE) && defined(SIGALRM)
 static void
 sig_handler(int signum)
 {
 switch (signum) {
-default:
-#ifdef HAS_HEADER_SETJMP
-/* quick hack to test signals and exceptions
- */

Re: Events

[Dan Sugalski]

At 6:01 PM +0200 7/18/03, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
 Events should be checked and processed in several instances:

 3) When we do a quick check to see if there are pending events to 
be processed
I have now a patch ready, which does 3) without additioal performacne
penalty for all cores except JIT.
(A short description was in an different thread WRT Event handling from
today).
$ diffstat -w 65 event\ handling-2
 classes/timer.pmc   |5 -
 config/gen/config_h/config_h.in |4
 core.ops|2
 events.c|   68 +++--
 exceptions.c|2
 include/parrot/events.h |   10 +-
 include/parrot/interpreter.h|9 +
 include/parrot/oplib.h  |   11 +-
 interpreter.c   |  125 +
 ops2c.pl|  124 ++--
 t/op/hacks.t|   36 ++-
 11 files changed, 324 insertions(+), 72 deletions(-)
$ l event\ handling-2
-rw-r--r--   1 lt   users   22139 Jul 18 17:53 event handling-2
Should I send it to the list first (or anyone personally) or put it in?
List first, please.
--
Dan
--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Events

[Leopold Toetsch]

Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Events should be checked and processed in several instances:

> 3) When we do a quick check to see if there are pending events to be processed

I have now a patch ready, which does 3) without additioal performacne
penalty for all cores except JIT.
(A short description was in an different thread WRT Event handling from
today).

$ diffstat -w 65 event\ handling-2
 classes/timer.pmc   |5 -
 config/gen/config_h/config_h.in |4
 core.ops|2
 events.c|   68 +++--
 exceptions.c|2
 include/parrot/events.h |   10 +-
 include/parrot/interpreter.h|9 +
 include/parrot/oplib.h  |   11 +-
 interpreter.c   |  125 +
 ops2c.pl|  124 ++--
 t/op/hacks.t|   36 ++-
 11 files changed, 324 insertions(+), 72 deletions(-)

$ l event\ handling-2
-rw-r--r--   1 lt   users   22139 Jul 18 17:53 event handling-2

Should I send it to the list first (or anyone personally) or put it in?

leo

Re: [perl #23028] t/op/stacks fails on FreeBSD/i386

[Simon Glover]

 OK, this should be fixed in CVS -- I just added/subtracted 1 as
 appropriate so that the test is no longer sensitive to whether
 0 == -0  (since this wasn't what we were supposed to be testing here).

 Simon

Re: Events

[Dan Sugalski]

At 2:59 PM -0700 7/17/03, Damien Neil wrote:
On Thu, Jul 17, 2003 at 12:58:12PM -0400, Dan Sugalski wrote:
 The first is done in the case of readw or writew, for example. The
 second for event-driven programs that set up callbacks and park
 themselves forever in one big ProcessEvent call. (Tk programs come to
 mind) The third is to be scattered in generated code to make sure
 that events are occasionally checked for, and will probably drain
 only high-priority events and at most a single low-priorty event.
While it's possibly politically impossible (many people are very
attached to Unix signals), I'd really rather work with a system
that does async event dispatch exclusively through threads.
Interrupting a thread in the middle of its execution and sending
it haring off to an interrupt handler is not only clumsy and difficut
to implement, it's a recipe for buggy code.
We're not doing the traditional C-style interrupt. That's infeasable 
at the level we operate at generally, so we're not. We *are* 
simulating it, since potentially some of Parrot's instructions will 
be 'interruptable' or check interrupts, or whatever you want to call 
it. (I call it annoying but necessary :)

Much nicer would be if events were always dispatched in one of two ways:
  - Synchronously, by calling a GetNextEvent or ProcessEvent function.
  - Asynchronously, by spawning a new thread and executing the signal
handler within it.
Nope, that won't work. A lot of what's done is really "main thread 
with interrupts" and that doesn't map well to doing all signal 
handling in separate threads. You really do want to pause the main 
program to handle the events that are coming in, if they're events of 
sufficient importance. Generally I put them in three classes--hard 
interrupts (signals), soft interrupts (IO completion stuff), and 
events (fuzzy user-level stuff). Hard and soft interrupts should get 
dealt with as soon as possible, events should probably wait until 
something explicitly decides to process an event.

Is there any hope for rethinking the desire to expose the ugliness of
Unix signals in the Parrot VM?
It's not just signals, there's a lot of stuff that falls into this 
category. We've got to deal with it, and deal with it properly, since 
not dealing with it gets you an 80% solution.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Tinderboxens

[Dan Sugalski]

At 12:15 PM +0200 7/18/03, Juergen Boemmels wrote:
Hello,

What happend to the tinderboxens? ATM only two are running:
galactic-tcc and adrastea.
I just gave glastig a thump, though only the base (non-JIT) test 
build stuff. It's too short of disk space for anything else, 
unfortunately. I'll see about getting the mutant linux box I have 
here working as well.

This might be a time to do a Tinderbox v2 rev. The current tinder 
model works pretty well, but it's got some error identification 
issues, and since it works in a "fetch, build, test, sleep, repeat" 
mode if something goes horribly wrong the box stops. A cron-style 
periodic fire-off job might be more robust in the face of things 
going really wrong.
--
Dan

--"it's like this"---
Dan Sugalski  even samurai
[EMAIL PROTECTED] have teddy bears and even
  teddy bears get drunk

Re: Where can I help?

[Mitchell N Charity]

I've added Steve's response to the

  Experimental Parrot Wiki
  http://www.vendian.org/parrot/wiki/

Which, of course, has a link to his Tinderbox summary.  Hmm... perhaps a
little tinderbox "weather report" line should appear on the wiki main page?
There are also links to CVS histories, and LXR, and... lots of other things.

It might also be useful to have a response for someone who asks
 "I am a tech writer who knows Perl and C.  How can I help?".

Mitchell

Re: Tinderboxens

[Steve Fink]

On Fri, Jul 18, 2003 at 12:15:37PM +0200, Juergen Boemmels wrote:
> This is the state of the tinderboxens for the last week or so.
> Does anybody actually look at the tinderboxens?

I generally look at them every other day or so, but normally only
through my summarizer interface
(http://foxglove.dnsalias.org/parrot/). Except that I've been away
from home -- or more specifically my home computer -- for over a
month, and my DSL modem crashed two weeks ago. I'm just mentioning
this in case anyone else was accustomed to checking the summary page
also, and wondering what happened to it. It'll be back up in a few
days, after I get back.

Re: [perl #23034] [PATCH] Implementation of methods for PIOs

[Juergen Boemmels]

Leopold Toetsch <[EMAIL PROTECTED]> writes:

> JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> > QUESTION: The calling convention for methods states that P2 should be
> > the object the sub was called on. The current build_call_frames pushes
> > the object starting at P5. How can the NCI-Interface be extended to
> > pass objects in P2 down to the c-functions?
> 
> This calling convention is AFAIK for PASM object code only. I would
> just pass the object itself with your 'P' signature in P5,6,...

Using P5 is the way it's handled now. This works quite well.

But this way the calling code has to know if the called code is a sub
or a nci. If its a sub it has to put the object in P2, if its a nci it
has to put the object in P5. Two possible solutions:
* Fix the calling convention to use P5 for the SELF object
* Allow the passing of registers in non-consecutive order

My idea is to extend the signature to (optionally) append the
registernumber in signature:
build_call_func(interp, pmc, "iP2pPp31")
for calling a function
int func(PMC_REG(2), PMC_REG(5)->data, PMC_REG(6), PMC_REG(31)->data)
How does this sound

> > QUESTION: The class initialisation code seems strange to me. Will the
> > class initialisation be called once for each interpreter (there are
> > interpreter variables in there) or once for each program start (the
> > classes are entered in a static array Parrot_base_vtables)?
> 
> It should probably done only once. We have to sort interpreter->iglobals
> into 2 such lists: per interpreter globals and global globals. When
> that's done, interpreter init can check if the previous interpreter
> already had the real globals and when yes, just sets a pointer to these.
> 
> The make_interpreter() should then be:
> make_interpreter(prev_interpreter);

No need to chain the interpreters. Have a function like this

void* get_globals ()
{
  static void *globals = NULL;

  if (!globals) {
globals = mem_sys_allocate(42);
...
  }

  return globals;
}

This way there is one and only one global data structure. get_globals
can be called anytime in Parrot_init or make_interpreter.

bye
boe
-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

Re: [perl #23034] [PATCH] Implementation of methods for PIOs

[Leopold Toetsch]

JüRgen" "BöMmels <[EMAIL PROTECTED]> wrote:
> QUESTION: The calling convention for methods states that P2 should be
> the object the sub was called on. The current build_call_frames pushes
> the object starting at P5. How can the NCI-Interface be extended to
> pass objects in P2 down to the c-functions?

This calling convention is AFAIK for PASM object code only. I would
just pass the object itself with your 'P' signature in P5,6,...

> QUESTION: The class initialisation code seems strange to me. Will the
> class initialisation be called once for each interpreter (there are
> interpreter variables in there) or once for each program start (the
> classes are entered in a static array Parrot_base_vtables)?

It should probably done only once. We have to sort interpreter->iglobals
into 2 such lists: per interpreter globals and global globals. When
that's done, interpreter init can check if the previous interpreter
already had the real globals and when yes, just sets a pointer to these.

The make_interpreter() should then be:
make_interpreter(prev_interpreter);

> bye
> boe

leo

Re: Event handling (was Re: [CVS ci] exceptions-6: signals, catch a SIGFPE (generic platform)

[Leopold Toetsch]

Benjamin Goldberg <[EMAIL PROTECTED]> wrote:

> Not "the next instruction" ... the next *branch* instruction.  And only
> replace those branch instructions which could be loops.

Works. Many thanks for the input.

I have now running this:

1) Initialization:
   - normal core: build op_func_table with all opcode #4 [1]
   - CG core: build ops_addr[] filled with this opcode
   - prederef cores: build a list of (backward) branch instructions
 and the opcode at that offset

2) When an events gets scheduled (signal handler) it calls the running
   core with:

interpreter->op_func_table =
   init_func(interpreter, OPLIB_SET_CHK_EV_FT)->op_func_table;

   This replaces for normal and CG core the op_func_table or the
   ops_addr with that from 1)
   Prederefed cores get on all branch instruction from the list built
   in 1) an opcode #4 patched.

3) So when the next instruction (normal, CG core) or the branch
   instruction (prederefed cores) gets executed, first the op_func_table
   or the patched instructions are restored and then the event handler
   can be called.

This now works for all cores (except JIT[2]). It doesn't have any runtime
penalty for an extra check if events are due.

[1] This opcode (check_event__) calls the actual event handling code
and returns the same address, i.e. doesn't advance the PC.

[2] We could do the same here, but this needs cache sync for ARM and PPC,
which may or may not be allowed in signal code.

Still needs some cleanup ...

leo

Re: Tinderboxens

[Cal Henderson]

At 11:15 GMT 18.07.03, Juergen Boemmels <[EMAIL PROTECTED]> wrote:
: This is the state of the tinderboxens for the last week or so.
: Does anybody actually look at the tinderboxens?

i run mine (slug) by hand once a day (when i remember), since 
i use the snapshots rather than cvs. i'm running one now.

--cal

Tinderboxens

[Juergen Boemmels]

Hello,

What happend to the tinderboxens? ATM only two are running:
galactic-tcc and adrastea.

adrastea is not very useful because its disk is full
> about to cvs checkout parrot:
> cvs [checkout aborted]: cannot write CVS/Entries.Backup: No space left on device
> cvs checkout complete

galactic-tcc compiles but fails all-pasm test with:
> t/op/arithmetics...dubious
>   Test returned status 38 (wstat 9728, 0x2600)
> DIED. FAILED tests 1-38
>   Failed 38/38 tests, 0.00% okay
The src-test are running fine

This is the state of the tinderboxens for the last week or so.
Does anybody actually look at the tinderboxens?

bye
boe
-- 
Juergen Boemmels[EMAIL PROTECTED]
Fachbereich Physik  Tel: ++49-(0)631-205-2817
Universitaet Kaiserslautern Fax: ++49-(0)631-205-3906
PGP Key fingerprint = 9F 56 54 3D 45 C1 32 6F  23 F6 C7 2F 85 93 DD 47

[perl #23034] [PATCH] Implementation of methods for PIOs

[Jürgen]

# New Ticket Created by  Jürgen Bömmels 
# Please include the string:  [perl #23034]
# in the subject line of all future correspondence about this issue. 
# http://rt.perl.org/rt2/Ticket/Display.html?id=23034 >


Hi,

During searching for memory leaks and hunting bugs only visible on
MacOS, I started a little fun project:
Implementation of methods for the ParrotIO-PMCs.

Actually this is the first pmc implementing the find_method
vtable-call.

The implementation is quite simple: find_method returns an nci-object
which calls the corresponding PIO-function. So far so simple.

But for this to work, i needed to extend the prototype-system of the
native call interface. Currently there is no way to pass a PMC down to
the native function, so I implemented a new type-letter 'P' for a PMC*
valued function (only jit/i386 and call_list.txt).

QUESTION: The calling convention for methods states that P2 should be
the object the sub was called on. The current build_call_frames pushes
the object starting at P5. How can the NCI-Interface be extended to
pass objects in P2 down to the c-functions?

The NCI-Objects are created at class_init time and stored in a
PerlHash. Therefor PerlHash and PerlUndef must get initialised in the
class_init of ParrotIO.

QUESTION: The class initialisation code seems strange to me. Will the
class initialisation be called once for each interpreter (there are
interpreter variables in there) or once for each program start (the
classes are entered in a static array Parrot_base_vtables)?

All tests passed on Linux/i386 with and without JIT.

bye
boe



-- attachment  1 --
url: http://rt.perl.org/rt2/attach/61285/45241/900fb2/io14.diff

? make_test_imcc
Index: build_nativecall.pl
===
RCS file: /cvs/public/parrot/build_nativecall.pl,v
retrieving revision 1.14
diff -u -r1.14 build_nativecall.pl
--- build_nativecall.pl	14 Jun 2003 17:48:31 -	1.14
+++ build_nativecall.pl	18 Jul 2003 06:46:48 -
@@ -201,6 +201,9 @@
 /I/ && do {
 	   return "interpreter";
   };
+/P/ && do {my $regnum = $reg_ref->{p}++;
+   return "PMC_REG($regnum)";
+  };
 
 }
 
Index: call_list.txt
===
RCS file: /cvs/public/parrot/call_list.txt,v
retrieving revision 1.8
diff -u -r1.8 call_list.txt
--- call_list.txt	18 Jan 2003 09:14:30 -	1.8
+++ call_list.txt	18 Jul 2003 06:46:48 -
@@ -13,6 +13,7 @@
 # t - character string
 # PMC reg stuff
 # p - data pointer from PMC (on store into a new UnManagedStruct PMC)
+# P - pointer to a PMC-register
 # special stuff
 # I - Parrot_Interp param
 #
@@ -39,3 +40,10 @@
 i	
 i	ppi
 p	It
+# These are needed for parrotio.pmc
+i	IP
+v	IP
+i	IPi
+i	IPii
+i	IPiii
+i	IPt
Index: interpreter.c
===
RCS file: /cvs/public/parrot/interpreter.c,v
retrieving revision 1.171
diff -u -r1.171 interpreter.c
--- interpreter.c	16 Jul 2003 12:53:01 -	1.171
+++ interpreter.c	18 Jul 2003 06:46:49 -
@@ -503,6 +503,9 @@
  * mem_setup_allocator() is called. */
 interpreter->flags = flags;
 
+/* Set up the memory allocation system */
+mem_setup_allocator(interpreter);
+
 /* PANIC will fail until this is done */
 SET_NULL(interpreter->piodata);
 PIO_init(interpreter);
@@ -517,9 +520,6 @@
 "with DISABLE_GC_DEBUG.\n");
 #endif
 }
-
-/* Set up the memory allocation system */
-mem_setup_allocator(interpreter);
 
 /* initialize classes */
 Parrot_init(interpreter, 0);
Index: classes/parrotio.pmc
===
RCS file: /cvs/public/parrot/classes/parrotio.pmc,v
retrieving revision 1.4
diff -u -r1.4 parrotio.pmc
--- classes/parrotio.pmc	9 Jul 2003 08:33:11 -	1.4
+++ classes/parrotio.pmc	18 Jul 2003 06:46:50 -
@@ -13,12 +13,62 @@
 
 #include "parrot/parrot.h"
 
+static void
+enter_nci_method(struct Parrot_Interp *interpreter, PMC *method_table,
+		 void *func, const char *name, const char *proto)
+{
+PMC *method;
+
+method = pmc_new(interpreter, enum_class_NCI);
+VTABLE_set_string_keyed(interpreter, method, func, 
+			string_make(interpreter, proto, strlen(proto),
+	NULL, 0, NULL));
+VTABLE_set_pmc_keyed(interpreter, method_table,
+			 key_new_string(interpreter,
+	string_make(interpreter, name,
+		strlen(name), NULL,
+		0, NULL)),
+			 method);
+}
+
 pmclass ParrotIO {
 
 STRING* name () {
 	return whoami;
 }
 
+void class_init () {
+PMC *method_table;;
+
+/* These classes are needed now so make sure they are inited */
+Parrot_NCI_class_init(interp, enum_class_NCI);
+Parrot_PerlHash_class_init(interp, enum_class_PerlHash);
+Parrot_PerlUndef_class_init(interp, enum_class_PerlUndef);
+
+method_table