It appears that the mechanism for choosing an os layer for PIO could use
some work, and it also appears that io_stdio is incomplete.
Is this correct?
I'm playing with a miniparrot setup, but one of its requirements is that
it be able to run exclusively on io_stdio, which doesn't appear to be
# New Ticket Created by "Peter Gibbs"
# Please include the string: [netlabs #691]
# in the subject line of all future correspondence about this issue.
# http://bugs6.perl.org/rt2/Ticket/Display.html?id=691 >
Index: RESPONSIBLE_PARTIES
=
At 03:28 AM 6/7/2002 -0400, Josh Wilmes wrote:
>It appears that the mechanism for choosing an os layer for PIO could use
>some work, and it also appears that io_stdio is incomplete.
Yes to both.
The mechanism:
#ifndef WIN32
PIO_push_layer(interpreter, PIO_base_new_layer(&pio_unix_layer),
At 10:23 on 06/07/2002 EDT, Melvin Smith <[EMAIL PROTECTED]> wrote:
> At 03:28 AM 6/7/2002 -0400, Josh Wilmes wrote:
>
> >It appears that the mechanism for choosing an os layer for PIO could use
> >some work, and it also appears that io_stdio is incomplete.
>
> Yes to both.
>
> The mechanism:
At 03:38 PM 6/7/2002 +0100, Nicholas Clark wrote:
>Is the goal to eliminate all the stdio code, so that by release parrot
>can't run on stdio? (ie all OSes must have some sort of direct layer, and
>porting parrot involves creating such a layer if none exists)
As far as I know, yes.
>Or that parr
At 10:42 AM 6/7/2002 -0400, Josh Wilmes wrote:
> > PIO_push_payer(, &pio_sys_layer, ... )
> >
> > This means renaming all of io_unix/io_win32 to io_sys
> > since you would never have 2 OS dependant layers compiled at the
> > same time. I've just been too lazy to rework it.
>
>So something like
Rather than naming all the basic Parrot types (I mean classes
that are exposed at the PASM level) Parrot*
(ParrotPointer, ParrotSub, ...) I propse we name them by their
simple names and require all new languages to prefix their
types ala PerlString, etc. We already have Array and Intqueue
that way
--- start of forwarded message ---
Date: 7 Jun 2002 21:36:26 -
From: Joe Yates (via RT) <[EMAIL PROTECTED]>
Cc: recipient list not shown: ;
Subject: Re: [netlabs #590] Ticket Resolved
Message-Id:
Dear Daniel,
I hope I'm not being a pain. The response to my report was that "This'll
I just did a bunch of commits, people might need a fresh checkout.
Its a start for subroutines and co-routines. The keyword is 'start',
not final product. The ops are call/callco, but these will become
vtable entries for the 4 aforementioned sub types by Dan.
David has some pending patches for PM
Subject says it all. Updates conventions to be consistent with much of
the core. Unfortunately, that doesn't include 'struct Parrot_Interp'.
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how
At 05:16 PM 6/7/2002 -0700, Brent Dax wrote:
>Subject says it all. Updates conventions to be consistent with much of
>the core. Unfortunately, that doesn't include 'struct Parrot_Interp'.
I'll work on bringing the source up to date as soon as pending patches are in.
-Melvin
David M. Lloyd:
# NOTE: DO NOT APPLY THIS PATCH TO PARROT unless you like the
# smell of platforms burning. :-)
Er, what patch?
--Brent Dax <[EMAIL PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive w
On Fri, 7 Jun 2002, Brent Dax wrote:
> Er, what patch?
It was attached because it is 214K. I could resend with it inline if
nobody minds the large message body.
- D
<[EMAIL PROTECTED]>
David M. Lloyd:
# On Fri, 7 Jun 2002, Brent Dax wrote:
#
# > Er, what patch?
#
# It was attached because it is 214K. I could resend with it
# inline if nobody minds the large message body.
I don't think anybody minds an attached patch, but I didn't get the
attachment.
--Brent Dax <[EMAIL PRO
On Fri, 7 Jun 2002, Brent Dax wrote:
> David M. Lloyd:
> # On Fri, 7 Jun 2002, Brent Dax wrote:
> #
> # > Er, what patch?
> #
> # It was attached because it is 214K. I could resend with it
> # inline if nobody minds the large message body.
>
> I don't think anybody minds an attached patch, but I
At 07:40 PM 6/7/2002 -0400, Melvin Smith wrote:
># Sample sub-routines in Parrot
>#
># Create 2 subroutines
>#
>set_addr I0, SUB
>new P0, .ParrotSub, I0
>save P0
>new P0, .ParrotSub, I0
># Calling convention says P0 will contain the sub
>call
>restore P0
># Call second one
>call
>end
>
># A subrou
David M. Lloyd:
# On Fri, 7 Jun 2002, Brent Dax wrote:
#
# > David M. Lloyd:
# > # On Fri, 7 Jun 2002, Brent Dax wrote:
# > #
# > # > Er, what patch?
# > #
# > # It was attached because it is 214K. I could resend with
# it # inline
# > if nobody minds the large message body.
# >
# > I don't th
Okay, here's the near-term schedule, stuff I'd like to get defined
and working by the end of July.
1) Plain subroutines
2) A revamped stack system so we can support exceptions
3) Exceptions
4) Loading up extensions and a simple extension interface
5) Global symbol tables
Doable without much tro
I've been working on the beginnings of a miniparrot (something that can be
built anywhere without the Configure step). The first step was to get
configure to generate appropriate configuration files for an ANSI-only
environment.
To do this, I've added a --miniparrot option to Configure.pl.
Josh Wilmes:
# I've been working on the beginnings of a miniparrot
# (something that can be
# built anywhere without the Configure step). The first step
# was to get
# configure to generate appropriate configuration files for an
# ANSI-only
# environment.
Looks excellent.
# To do this, I'
At 21:51 on 06/07/2002 PDT, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> # Of these, 2 are not defined by ANSI C89:
> # read (in core_ops.o,core_ops_prederef.o)
> # write (in core_ops.o,core_ops_prederef.o)
> #=20
> # Pretty good!
>
> Indeed. Those should probably be surrounded with ifdefs-
[EMAIL PROTECTED]:
# At 21:51 on 06/07/2002 PDT, "Brent Dax" <[EMAIL PROTECTED]> wrote:
#
# > # Of these, 2 are not defined by ANSI C89:
# > # read (in core_ops.o,core_ops_prederef.o)
# > # write (in core_ops.o,core_ops_prederef.o)
# > #=20
# > # Pretty good!
# >
# > Indeed. Those shoul
At 0:48 on 06/08/2002 EDT, Josh Wilmes <[EMAIL PROTECTED]> wrote:
> At 21:51 on 06/07/2002 PDT, "Brent Dax" <[EMAIL PROTECTED]> wrote:
> > I'd suggest that your next steps include modifying
> > config/gen/config_h.pl to output a has_header.h with only ANSI headers
> > enabled. (Make sure that Co
At 7:40 PM -0400 6/7/02, Melvin Smith wrote:
>I just did a bunch of commits, people might need a fresh checkout.
>
>Its a start for subroutines and co-routines. The keyword is 'start',
>not final product. The ops are call/callco, but these will become
>vtable entries for the 4 aforementioned sub t
24 matches
Mail list logo
