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
On 6/6/02 11:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
>> / $2:=(.*?), \h* $1:=(.*) /
>>
>> Does this imply that $1, $2, etc are now read-write outside of regexen?
>
> No.
Maybe this is a RTFM question, but does Perl 6 (or Perl 5, for that matter)
have some magical array that
--- David Wheeler <[EMAIL PROTECTED]> wrote:
> On 6/6/02 11:43 PM, "Damian Conway" <[EMAIL PROTECTED]> claimed:
>
> >> / $2:=(.*?), \h* $1:=(.*) /
> >>
> >> Does this imply that $1, $2, etc are now read-write outside of regexen?
> >
> > No.
>
> Maybe this is a RTFM question, but does
On 6/7/02 10:12 AM, "Jonathan E. Paton" <[EMAIL PROTECTED]> claimed:
> A5, under "RFC 072: Variable-length lookbehind":
>
> "Did I mention that the magical @+ and @- arrays are gonna be real dead?
>Never could remember which one was which anyway..."
Not to mention kinda useless. I was hop
On 6/7/02 11:21 AM, "David Wheeler" <[EMAIL PROTECTED]> claimed:
> Not to mention kinda useless. I was hoping for a magic array that would hold
> the actual *matches*, rather than pointers to their character positions.
And it appears to be C<@$0>. Duh. Sorry for the noise, folks.
David
--
Dav
On Fri, 7 Jun 2002, David Wheeler wrote:
> I was hoping for a magic array that would hold
> the actual *matches*, rather than pointers to their character positions.
A5 says that @$0 is that array.
Larry
On Fri, 7 Jun 2002, Damian Conway wrote:
> Dave Storrs wrote:
>
> > Somehow, this feels like we're trying to roll all of Prolog
> > into Perl,
>
> No. We're rolling in all of yacc/lex/RecDescent instead. ;-)
And this should reassure me _why_? *grin*
> > Just to verify, this:
> >
> >
On Fri, 7 Jun 2002, Dave Storrs wrote:
> Just to be sure I understood: you meant that (A) yes, you can use
> fail in a subroutine outside a regex, and (B) if you do, it is no
> different from die. Is that correct?
Depends on the caller's use of "use fatal". If they don't use fatal,
it re
>> Can we please have a 'reverse x' modifier that means "treat whitespace as
>> literals"?
> I'll talk about that with Larry. If he were to approve it, it might possibly
> be :W.
Likewise, could we please have a modifier that makes <> literal, and aliases
<> as something else so *ml can match ea
> The most serious objection to this was 'well, use modules for matching *ml" -
> which simply points out that the current incarnation of perl6 regex doesn'
> t handle a very large class of matching problems very well.
The modules use regexes. They just spend more time on them and make them
bet
In a message dated Fri, 7 Jun 2002, [EMAIL PROTECTED] writes:
> The most serious objection to this was 'well, use modules for matching *ml" -
> which simply points out that the current incarnation of perl6 regex doesn'
> t handle a very large class of matching problems very well.
I don't think th
On 6/7/02 4:48 PM, Luke Palmer wrote:
> rule tag($name) {:w \< $name %opts:=[ (\S+)=(\S+) ]* \> }
>
> Then, you can match an img tag with:
>
> / /
>
> See, isn't that great?
Don't you mean, "see, isn't that massively over-simplified?" ;)
(but yeah, we get the idea... :)
-John
On 6/7/02 4:51 PM, Damian Conway wrote:
> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD.
Then use those to make
On Fri, 7 Jun 2002, John Siracusa wrote:
> On 6/7/02 4:48 PM, Luke Palmer wrote:
> > rule tag($name) {:w \< $name %opts:=[ (\S+)=(\S+) ]* \> }
> >
> > Then, you can match an img tag with:
> >
> > / /
> >
> > See, isn't that great?
>
> Don't you mean, "see, isn't that massively over-simplifie
John Siracusa wrote:
> > I have no doubt that, once Perl 6 is available, we'll see a rash of modules
> > released in the Grammar:: namespace. Including Grammar::HTML and Grammar::XML.
>
> Why not just make Grammar::DTD, and then make Grammar::Generator::FromDTD.
> Then use those to make all the
f
On Fri, Jun 07, 2002 at 05:10:49PM -0400, Trey Harris wrote:
> In a message dated Fri, 7 Jun 2002, [EMAIL PROTECTED] writes:
> > The most serious objection to this was 'well, use modules for matching *ml" -
> > which simply points out that the current incarnation of perl6 regex doesn'
> > t han
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
On 6/7/02 5:44 PM, Damian Conway wrote:
> John Siracusa wrote:
>>> I have no doubt that, once Perl 6 is available, we'll see a rash of modules
>>> released in the Grammar:: namespace. Including Grammar::HTML and
>>> Grammar::XML.
>>
>> Why not just make Grammar::DTD, and then make Grammar::Genera
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
40 matches
Mail list logo
