PIO/io_stdio?
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 possible at this time. I haven't really dug into the PIO code yet- i wanted to check with whoever had been working on it before I do anything. --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
[netlabs #691] [PATCH] Documentation update
# 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 === RCS file: /cvs/public/parrot/RESPONSIBLE_PARTIES,v retrieving revision 1.1 diff -u -r1.1 RESPONSIBLE_PARTIES --- RESPONSIBLE_PARTIES 23 May 2002 18:24:33 - 1.1 +++ RESPONSIBLE_PARTIES 7 Jun 2002 07:21:02 - @@ -5,6 +5,5 @@ Project lead Jeff Goff JITDaniel Grunblatt -GC/Memory Management Peter Gibbs Configure Brent Dax I/OMelvin Smith -- Peter Gibbs EmKel Systems
Re: PIO/io_stdio?
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), NULL); #else PIO_push_layer(interpreter, PIO_base_new_layer(&pio_win32_layer), NULL); #endif Should just be transparently 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. >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 >possible at this time. When you say io_stdio, I assume you mean STDIO, right? According to Dan, the goal for Parrot was to run without STDIO, period. Anway, io_stdio is dreadfully incomplete. Its sort of frozen where I left it in January, but it needs to be renamed to io_buf or something. The one you are looking at is not going to be a wrapper for STDIO, it is going to be a buffered IO layer on top of an OS layer. If you want, just rename it to io_buf.c and commit, and then you can use io_stdio as the name implies. >I haven't really dug into the PIO code yet- i wanted to check with whoever >had been working on it before I do anything. Have at it. Dan had said no stdio when I first started, so thats what I'm assuming until further notice. -Melvin
Re: PIO/io_stdio?
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:
>
> #ifndef WIN32
> PIO_push_layer(interpreter, PIO_base_new_layer(&pio_unix_layer), NULL);
> #else
> PIO_push_layer(interpreter, PIO_base_new_layer(&pio_win32_layer), NULL);
> #endif
>
> Should just be transparently
>
> 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 the way platform.[ch] work then? copy
io_{unix|win32|stdio} to io_sys.c during the build process?
If we're serious about this miniparrot stuff, i'd like to see the code
reorganized so that all the platform-specific stuff lives in one place,
and everything else has to be pure ANSI C.
But for now i'm just doing a proof-of-concept.
> >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
> >possible at this time.
>
> When you say io_stdio, I assume you mean STDIO, right?
>
> According to Dan, the goal for Parrot was to run without STDIO, period.
> Anway, io_stdio is dreadfully incomplete. Its sort of frozen where
> I left it in January, but it needs to be renamed to io_buf or
> something. The one you are looking at is not going to be a wrapper
> for STDIO, it is going to be a buffered IO layer on top of an OS layer.
> If you want, just rename it to io_buf.c and commit, and then you
> can use io_stdio as the name implies.
>
> >I haven't really dug into the PIO code yet- i wanted to check with whoever
> >had been working on it before I do anything.
>
> Have at it. Dan had said no stdio when I first started, so thats what I'm
> assuming until further notice.
I'd like some clarification from Dan then, before I proceed further along
that path.
Just to give you an idea, here's where i'm at now with my miniparrot stuff:
$ perl Configure.pl --miniparrot; make lib_deps_object
Parrot Version 0.0.6 Configure 2.0
Copyright (C) 2001-2002 Yet Another Society
Hello, I'm Configure. My job is to poke and prod your system to figure out
how to build Parrot. The process is completely automated, unless you passed in
the `--ask' flag on the command line, in which case it'll prompt you for a few
pieces of info.
Since you're running this script, you obviously have Perl 5--I'll be pulling
some defaults from its configuration.
Checking MANIFEST...done.
Setting up Configure's data structures...done.
Checking for --miniparrot...Yes..done.
Loading platform hints file...no hintsdone.
Determining what C compiler and linker to use...done.
Determining what types Parrot should use...done.
Determining what opcode files should be compiled in...done.
Setting up experimental systems...done.
Probing for C headers...done.
Determining some sizes...done.
Computing native byteorder for Parrot's wordsize...done.
Figuring out how to pack() Parrot's types...done.
Figuring out what formats should be used for sprintf...done.
Determining if your C compiler is actually gcc...done.
Determining architecture, OS and JIT capability...done.
Verifying that the compiler supports function pointer casts...done.
Determining if your compiler supports computed goto...done.
Generating config.h...done.
Writing Parrot::Config module...done.
Generating Makefiles...done.
Moving platform files into place...done.
Okay, we're done!
You can now use `make' (or your platform's equivalent to `make') to build your
Parrot. After that, you can use `make test' to run the test suite.
Happy Hacking,
The Parrot Team
perl vtable_h.pl
perl make_vtable_ops.pl > vtable.ops
perl ops2c.pl C core.ops debug.ops io.ops rx.ops vtable.ops
perl ops2c.pl CPrederef core.ops debug.ops io.ops rx.ops vtable.ops
cc -DMINIPARROT -ansi -pedantic -I./include -o exceptions.o -c exceptions.c
cc -DMINIPARROT -ansi -pedantic -I./include -o global_setup.o -c global_setup.c
cc -DMINIPARROT -ansi -pedantic -I./include -o interpreter.o -c interpreter.c
cc -DMINIPARROT -ansi -pedantic -I./include -o parrot.o -c parrot.c
cc -DMINIPARROT -ansi -pedantic -I./include -o register.o -c register.c
cc -DMINIPARROT -ansi -pedantic -I./include -o core_ops.o -c core_ops.c
cc -DMINIPARROT -ansi -pedantic -I./include -o core_ops_prederef.o -c
core_ops_prederef.c
cc -DMINIPARROT -ansi -pedantic -I./include -o memory.o -c memory.c
cc -DMINIPARROT -ansi -pedantic -I./include -o packfile.o -c packfile.c
cc -DMINIPARROT -ansi -pedantic -I./include -o stacks.o -c stacks.c
cc -DMINIPARROT -ansi -pedantic -I./include -o string.o -c string.c
cc -DMINIPARROT -ansi -pedantic -I./include -o encoding.o -c encoding.c
cc -DMINIP
Re: PIO/io_stdio?
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 parrot should by default compile without stdio, but provide an >"OS" layer that is actually stdio. That way new platforms can initially run >on stdio (if they have it) until the platform porter implements a direct >interface. Which makes porting less steep. Probably makes sense. -Melvin
Re: PIO/io_stdio?
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 the way platform.[ch] work then? copy
>io_{unix|win32|stdio} to io_sys.c during the build process?
Yeh, thats what I was thinking.
>If we're serious about this miniparrot stuff, i'd like to see the code
>reorganized so that all the platform-specific stuff lives in one place,
>and everything else has to be pure ANSI C.
I think thats a good idea even if we didn't have miniparrot. The
exposed interface in io.c is platform independant.
>Found 1911 symbols defined within the 48 supplied object files.
>Found 57 external symbols
>Of these, 8 are not defined by ANSI C89:
> close (in io/io_unix.o)
> creat (in io/io_unix.o)
> isatty (in io/io_unix.o)
> lseek (in io/io_unix.o)
> open (in embed.o,io/io_unix.o)
> read (in core_ops.o,core_ops_prederef.o,embed.o,io/io_unix.o)
> stat (in embed.o)
> write (in core_ops.o,core_ops_prederef.o,io/io_unix.o)
>
>
>Ideally, for miniparrot, there should be nothing spit out here. All told,
>this isn't too bad. Most are in the IO layer and embedding.
A few other issues I've seen:
The direct stat and mmap calls should be moved out of embed.c
Also, I think interpreter.c has platform specific oplib loading code,
and assumes unix .so paths.
-Melvin
Re: Apoc 5 questions/comments
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 holds all the matches from the last match? e.g., ($1, $2, $3, ...)? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Apoc 5 questions/comments
--- 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 Perl 6 (or Perl 5, for that matter)
> have some magical array that holds all the matches from the last match?
> e.g., ($1, $2, $3, ...)?
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..."
Another great loss to the golfing community, I guess. I pose my own question:
Q. Will Perl 6 be an interesting language to golf? Or will be the shortest
solutions also be the most obvious (using day-to-day programming)?
CC to [EMAIL PROTECTED] if you have a __meaningful__ answer, like you've just
re-implemented one of The Perl Review golf winners in less or a similar
number of characters.
I guess the golfing community would appreciate a mini-exegsis for what
Perl 6 can do for them :) [hint, hint]
Jonathan Paton
=
s''-//--/\\///|-\/\|--\--/-\-/\-//\-|/\\\|/\///|-\--',
s''/-\\\/|///|-|/|/--\--/--//\|\/\||/|/-/\\\-/\///|-\-\-',
y'|\/-'3210',$_=join qq\\,map{s|2|10|||s|3|11|||s|^|0|;$_}
m|.|g;map{print chr unpack'N',pack'B32','0'x24 .$_}/.{8}/g
__
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
Re: Apoc 5 questions/comments
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 hoping for a magic array that would hold the actual *matches*, rather than pointers to their character positions. 'Course, such a thing might be rather resource intensive. And probably unnecessary, since Perl 6 regexes can simply assign to an array. Perl 5 is another matter. > I guess the golfing community would appreciate a mini-exegsis for what > Perl 6 can do for them :) [hint, hint] I rather expect that whatever Perl 6 does for golfers is a side-effect of what Perl 6 is doing for programmers who just need to get their work done. David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Apoc 5 questions/comments
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 -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: Apoc 5 questions/comments
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
Re: Apoc 5 questions/comments
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:
> >
> > s:3rd /foo<3>/bar/
> >
> > would do the 3rd, 4th, and 5th, correct?
>
> Yes, but only if they were consecutive.And it would only replace them with a
> single "bar".
Sorry, my question was poorly phrased. Good, this did what I
expected it to do.
> > I am a little unclear on what the difference is between these two:
> > my @foo = <$rx>;
> > my @foo = m/<$rx>/;
>
> In Perl 5 terms, the first is equivalent to:
>
> my @foo; while (m/\G($rx)/gc) { push @foo, $1 }
>
> The first is equivalent to:
>
> my @foo; foreach (m/($rx)/g) { push @foo, $1 }
>
> That is, the first one is implicitly anchored to the end of the last match, so
> the matches have to be contingous. Whereas the second is unanchored, so the
> matches can occur anywhere in the string.
Urm...ok. I understand what you've said, (although you said
"first is equiv..." both times :>) but I guess I'll need to go back and
reread A5 to map your answer to the original text.
> > You could also use the {'...'} construct for comments, but then
> > you risk warnings about "useless use of a string in void context".
> >
> > Could we automagically turn off that warning inside such constructs, when
> > the only thing there was a string?
>
> Depends how much Larry wants to discourage inline comments, I guess. ;-)
> He's fairly strongly opposed to them.
I don't actually care one way or the other, I was just throwing
out a suggestion.
> > / pattern ::: { code() or fail } / # fails entire rule
> >
> > Farther down:
> >
> > A pattern nested within a closure is classified as its own rule,
> > however, so it never gets the chance to pass out of a {...}
> > closure.
> >
> > If I understand correctly, that means that this:
> >
> > / pattern ::: { $regex or fail } /
> >
> > would NOT fail the entire rule...correct?
>
> As I understand it, it definitely *would*.
>
> The code:
>
> $regex or fail
>
> has the $regex object in a boolean context, so it matches (if it can)
> and returns true or false. If it fails to match the C fires off
> a failure, which causes the closure to fail, which causes the top-level
> regex to backtrack, whereupon it hits the :::, which causes the top-level
> rule to immediately fail.
Yikes. Ok, I obviously badly misunderstood that. I'll go back
and reread it. So, can you provide an example of a "pattern nested
within a closure", since I obviously didn't understand?
> > my &rx := /(xxx)/;
> >
> > Should that be a $ instead of a & on the rx variable?
>
> That ain't a variable, friend, that there's a gen-u-ine subroutine!
> And it's being bound to a regex!!
> (It's really just another way to give a regex a name ;-)
Hmmm...what are the implications, here? The results of the match
are passed as arguments to the func? When you run the func, the regex is
called? Something else?
> > Can subroutines that aren't used in regexen use 'fail' to throw an
> > exception? If so, how is it different from 'die' when used outside a
> > regex?
>
> As I understand it, it isn't (currently).
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?
Dave Storrs
Re: Apoc 5 questions/comments
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 returns undef. Larry
Re: Apoc 5 questions/comments
>> 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 easier? 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. Ed
Re: Apoc 5 questions/comments
> 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
better than you could on the fly. Plus, I don't see what's keeping you
from writing a rule that matches a tag. I think it would go something like
this:
rule tag($name) {:w \< $name %opts:=[ (\S+)=(\S+) ]* \> }
Then, you can match an img tag with:
/ /
See, isn't that great?
Luke
Re: Apoc 5 questions/comments
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 that's what people were saying at all. They were saying you
should use modules, not because it's too hard to do in Perl 6 regexes, but
because *ml are well-formed, well-published languages and it doesn't make
sense to reinvent the wheel when you're nearly certain to miss cases
handled by the standard modules.
Unless I'm missing something, I'm assuming that those modules, when
rewritten in Perl 6, will be able to dump the specialized parsers and go
to using grammars as given in A5.
I guess this is as good an opportunity as any to be sure I've got what's
going on. So, here's a first, simple, addmitedly broken hack at a simple
parser for xml-ish start tags and empty entities:
rule lt { \< }
rule gt { \> }
rule identifier {
# I don't know the XML identifier rules, but let's pretend:
[ | \d | _ ]*
}
rule val {
[ # quoted
$b := <['"]>
( [ \\. | . ]*? )
$b
] | # or not
(\H+)
}
rule parsetag :w {
$tagname :=
%attrs := [ () =
()
]*
/?
}
for <$fh> {
while m:e// {
print "Found tag $0{tagname}\n";
print " $a = '$v'\n" for $0{attrs}.kv -> $a, $b;
}
}
My questions are:
1. Does the match in my rule get passed correctly? I.e., I have
parens in alternations, will whichever one gets matched become the
return value of the whole rule?
2. Did I do the binding to the hash correctly?
3. Will my I/O loop work like I expect?
Trey
Re: Apoc 5 questions/comments
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
Re: Apoc 5 questions/comments
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 all the other usual suspects for you ;) -John
Re: Apoc 5 questions/comments
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-simplified?" ;)
D'oh! Yes, quotes, right
I like the idea that regular expressions, er, I mean, pattern matching
does grammar-like things now. And the fact that you can derive. I would
love to see perl replace yacc, for the most part. Perl's looking like a
*very* powerful text processing language, on a higher level than it was
before.
I'm just expressing my respect for the new design.
> (but yeah, we get the idea... :)
Thanks.
Re: Apoc 5 questions/comments
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 other usual suspects for you ;) That could certainly be an efficient way to populate the Grammar:: namespace. Thanks for volunteering, John! ;-) Damian
Re: Apoc 5 questions/comments
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 handle a very large class of matching problems very well. > > I don't think that's what people were saying at all. They were saying you > should use modules, not because it's too hard to do in Perl 6 regexes, but > because *ml are well-formed, well-published languages and it doesn't make > sense to reinvent the wheel when you're nearly certain to miss cases > handled by the standard modules. hmm. I thought that was perl's forte - doing quick and dirty, small scripts. No matter how intuitive, well thought-out, or polished, working through a module is always going to be more restrictive than doing it through a regular expression. It might be better in some cases, yes, but sometimes you just want the freedom to do stuff by hand. > Unless I'm missing something, I'm assuming that those modules, when > rewritten in Perl 6, will be able to dump the specialized parsers and go > to using grammars as given in A5. No, you're not missing anything. I just don't want to be forced to be used modules/rules, that's all. And I *don't* want to backslash every damn $@#$% < I see in a XML document. We have syntactic sugar to stop people from having to backslash \ in window's paths, to stop people from having to backslash / inside of regular expressions. I'd argue that being able to match *ml cleanly (and without modules or rules or APIs) would be a hell of a lot more important. Ed ( ps - and no, I don't want to be forced to go back to use perl5's regex. If people do, that just shows the shortcomings of the perl6 system, IMO )
Naming
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. -Melvin (getting tired of typing Parrotfoo all the time)
[netlabs #590] Can't Print the Sequence slash + zero
--- 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 be fixed when we've got the Parrot IO support rolled out." Have you any idea how far down the line that's going to be? Joe Yates At 05:28 PM 07-06-02 +, you wrote: >According to our records, your request regarding > "Can't Print the Sequence slash + zero" >has been resolved. > >If you have any further questions or concerns, please respond to this >message. --- end of forwarded message --- --
Re: Apoc 5 questions/comments
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::Generator::FromDTD. >> Then use those to make all the other usual suspects for you ;) > > That could certainly be an efficient way to populate the Grammar:: namespace. > Thanks for volunteering, John! Sorry, number one on my list is a Perl 6 URI module that lets me manipulate the query portion without pain. Yep, it's low-hanging fruit for me... :) -John
[COMMIT] Subs and co-routines in Parrot
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 PMC so I didn't want to get into any conflicts with that, so I'm waiting until he's done with the PMC cleanup. I committed 2 examples to the examples/assembly directory, and I'll patch them inline here at the bottom. Warning: This is not the final convention, it is still up in the air. Dan has spec'd some of it out, but for now, we can work with this. The support isn't complete, for example, co-routines, etc. need to swap in their own context, which right now they don't do. Also we'll have to do fun stuff like copy return values off of the co's local stack onto the returnee's stack, unless someone has suggestion. I know JVM does something like this. However, you can write resumeable routines with the support that is there now. Have fun! -Melvin # 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 subroutine address SUB: print "Hello subroutine\n" # Sample co-routines in Parrot # # Create 2 coroutines # set_addr I0, MYCOROUTINE new P0, .ParrotCoroutine, I0 save P0 new P0, .ParrotCoroutine, I0 # Calling convention says P0 will contain the sub so.. print "Calling 1st co-routine\n" callco callco callco restore P0 print "Calling 2nd co-routine\n" callco callco callco end # A coroutine MYCOROUTINE: print "Entry\n" yield print "Resumed\n" yield print "Done\n" ret
[PATCH PDD 7] Update type-naming conventions
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 warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
Index: docs/pdds/pdd07_codingstd.pod
===
RCS file: /cvs/public/parrot/docs/pdds/pdd07_codingstd.pod,v
retrieving revision 1.5
diff -u -r1.5 pdd07_codingstd.pod
--- docs/pdds/pdd07_codingstd.pod 2 Apr 2002 07:08:43 -
1.5
+++ docs/pdds/pdd07_codingstd.pod 8 Jun 2002 00:04:50 -
@@ -391,7 +391,50 @@
=item *
-Variables and structure names should be all lower-case, eg C.
+Variables should be all lower-case.
+
+=item *
+
+Structures should have the following:
+
+=over 4
+
+=item *
+
+A structure definition with a name such as C.
+
+=item *
+
+A typedef of the form C. This should I be typedefed to a
pointer.
+(Note that some parts of the core are still using typedefs of the form
C;
+we're currently working on changing that.)
+
+=item *
+
+If the typedef is to be externally visible, a second typedef of the
form
+C is also necessary. For virtually all structs, this
should be
+typedefed to a pointer to the struct. If the struct is to be
externally
+visible, this (and a forward declaration of the C form) should
be the o
nly
+externally visible parts.
+
+=back
+
+A typedef of a built-in C type (like C or C) should
have the
+following forms:
+
+=over 4
+
+=item *
+
+A typedef of the form C. (Note that some parts of the core are
still using
+typedefs of the form C; we're currently working on changing
that.)
+
+=item *
+
+If the type is to be externally visible, a second typedef of the form
C.
+Often, the C form is defined in terms of the C
form.
+
+=back
=item *
Re: [PATCH PDD 7] Update type-naming conventions
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
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
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 worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
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]>
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
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 PROTECTED]>
@roles=map {"Parrot $_"} qw(embedding regexen Configure)
Early in the series, Patrick Stewart came up to us and asked how warp
drive worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
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 didn't get the > attachment. Outlook users beware: Attachments sent using Pine (my mailer) tend to be somewhat invisible to you. They don't appear in the message list but they're there. You have to open up the message and (I think) click on the paperclip icon to get at them. Or something like that. - D <[EMAIL PROTECTED]>
Re: [COMMIT] Subs and co-routines in Parrot
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 subroutine address >SUB: >print "Hello subroutine\n" There should be a 'ret' instruction there at the end
RE: [NON-PATCH-DO-NOT-APPLY] PMC Up-To-Spec diffs
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 think anybody minds an attached patch, but I didn't get the
# > attachment.
#
# Outlook users beware: Attachments sent using Pine (my mailer)
# tend to be somewhat invisible to you. They don't appear in
# the message list but they're there. You have to open up the
# message and (I think) click on the paperclip icon to get at
# them. Or something like that.
Double-click on the message and go to File | Save Attachments. Anyway,
the only thing that looks suspect to me is the whole s/BOOLVAL/INTVAL/g
thing.
--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 worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
Near-term schedule
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 trouble, I think. I'll start getting design specs out. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
several changes committed (IO, miniparrot)
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. When used, this option causes Configure to disable to use of any gcc features, and to only make available those header files which are guaranteed by ANSI C89. The resulting binary showed most of the non-ansi functionality was coming from io_unix.c, which was still being used. To address that, I have written a new io_stdio.c that uses STDIO functions only, and have reworked the way an appropriate IO layer is chosen, so that the STDIO-only version is used for this miniparrot environment. Finally, I've changed embed.c to use the PIO layer to load in bytecode files, rather than calling open/read/close directly. The result is that I can now build a miniparrot binary that only has the following dependencies: josh@galactic:~/devel/parrot-rw% make lib_deps_object perl tools/dev/lib_deps.pl object exceptions.o global_setup.o interpreter.o parrot.o register.o core_ops.o core_ops_prederef.o memory.o packfile.o stacks.o string.o sub.o encoding.o chartype.o runops_cores.o trace.o pmc.o key.o hash.o platform.o resources.o rx.o rxstacks.o embed.o warnings.o misc.o packout.o byteorder.o debug.o io/io.o io/io_buf.o io/io_unix.o io/io_win32.o io/io_stdio.o classes/default.o classes/array.o classes/perlint.o classes/perlstring.o classes/perlnum.o classes/perlarray.o classes/perlundef.o classes/perlhash.o classes/parrotpointer.o classes/parrotsub.o classes/parrotcoroutine.o classes/intqueue.o encodings/singlebyte.o encodings/utf8.o encodings/utf16.o encodings/utf32.o chartypes/unicode.o chartypes/usascii.o Found 1922 symbols defined within the 52 supplied object files. Found 56 external symbols 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) Pretty good! --Josh -- Josh Wilmes ([EMAIL PROTECTED]) | http://www.hitchhiker.org
RE: several changes committed (IO, miniparrot)
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've added a --miniparrot option to Configure.pl.
# When used,
# this option causes Configure to disable to use of any gcc
# features, and to
# only make available those header files which are guaranteed
# by ANSI C89.
# 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)
#
# Pretty good!
Indeed. Those should probably be surrounded with ifdefs--does Configure
generate a HAS_HEADER for these?.
The only thing that jumped out at me were the direct calls to fprintf
with warnings--perhaps you should use the standard warnings mechanism
instead.
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 Configure tests for them in the first place,
though!)
The other thing I'd suggest is that we wrap mmap and munmap in
something. I think Windows has similar functionality through a
different API, so Parrot_map and Parrot_unmap might be in order.
--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 worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
Re: several changes committed (IO, miniparrot)
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--does Configure > generate a HAS_HEADER for these?. Not sure- haven't looked at them yet. > The only thing that jumped out at me were the direct calls to fprintf > with warnings--perhaps you should use the standard warnings mechanism > instead. You're right- I meant to go back and fix those and totally forgot. > 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 Configure tests for them in the first place, > though!) It's actually doing that already (it's in config/auto/headers.pl) > The other thing I'd suggest is that we wrap mmap and munmap in > something. I think Windows has similar functionality through a > different API, so Parrot_map and Parrot_unmap might be in order. Agreed. I'll take a look at that as well. --Josh
RE: several changes committed (IO, miniparrot)
[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 should probably be surrounded with ifdefs--does
# > Configure generate a HAS_HEADER for these?.
#
# Not sure- haven't looked at them yet.
#
# > The only thing that jumped out at me were the direct calls
# to fprintf
# > with warnings--perhaps you should use the standard warnings
# mechanism
# > instead.
#
# You're right- I meant to go back and fix those and totally forgot.
#
# > 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 Configure tests for them in the
# first place,
# > though!)
#
# It's actually doing that already (it's in config/auto/headers.pl)
So you did. I kinda skipped past that. *smacks his forehead*
# > The other thing I'd suggest is that we wrap mmap and munmap in
# > something. I think Windows has similar functionality through a
# > different API, so Parrot_map and Parrot_unmap might be in order.
#
# Agreed. I'll take a look at that as well.
If you do that, I'd further suggest that on ANSI's Parrot_map you just
malloc() the memory and slurp the file in, then free() it in
Parrot_unmap. That way we never have to check to see if mmap or an
equivalent is actually available.
--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 worked. We explained some of the hypothetical principles . . .
"Nonsense," Patrick declared. "All you have to do is say, 'Engage.'"
--Star Trek: The Next Generation Technical Manual
Re: several changes committed (IO, miniparrot)
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 Configure tests for them in the first place, > > though!) > > It's actually doing that already (it's in config/auto/headers.pl) Although I should mention that it's not verifying the presence of these headers- it just assumes they are available. It does that because the intent is to use this has_header.h for miniparrot, where we won't be doing any probing. The assumption is that if C89 says it will be there, it will be there, darn it. --Josh
Re: [COMMIT] Subs and co-routines in Parrot
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 types by Dan. >David has some pending patches for PMC so I didn't want to >get into any conflicts with that, so I'm waiting until he's done >with the PMC cleanup. > >I committed 2 examples to the examples/assembly directory, >and I'll patch them inline here at the bottom. > >Warning: This is not the final convention, it is still up in the air. Dan >has spec'd some of it out, but for now, we can work with this. > >The support isn't complete, for example, co-routines, etc. need to >swap in their own context, which right now they don't do. > >Also we'll have to do fun stuff like copy return values off of the co's >local stack onto the returnee's stack, unless someone has >suggestion. I know JVM does something like this. > >However, you can write resumeable routines with the support that is >there now. Cool. Two things: First, we need to beef up ret, but that's a problem of definition. It should walk the control stack until it hits something it can return, so we can undo exception handler pushes, scope change, and suchlike things. (My problem, I'll update the docs) Second, in the final go, the callco op won't be needed--call should be sufficient, but that'll need support in the PMCs. I'm not sure about return values yet. We'll see what that brings. -- Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
