On Nov 8, 2005, at 12:12, Joshua Hoblitt wrote:
Allison has an excellent document on the state of tool development in
her SVN tree. It would be nice to see it included with Parrot's
documentation.
It's still very rough, but will go into the Parrot repository after I
give it another pass o
I've checked in the code to transform PunieGrammar match objects into
AST trees. The core pieces are:
- A tree grammar for the transformation in languages/punie/lib/
pge2past.g
- A series of AST node classes in languages/punie/lib/PAST/
- A script that parses a Punie source file, transforms t
On Nov 29, 2005, at 15:08, Chip Salzenberg wrote:
Comments? Fresh or rotten vegetables?
My objections:
Consider:
P0 = P1
P0 = S1
P0 = I1
P0 = N1
o/~ One of these things is not like the others
One of these things just doesn't belong o/~
And if I have to read:
P0 =
I realize this is a side effect of the fact that method names are
actually strings, but it's an unfortunate result.
If I have a little bit of code that calls a method without quotes
around the name of the method, it calls the method (prints out
"Boojum"), exactly as expected:
.sub main :m
On Oct 17, 2005, at 14:15, Patrick R. Michaud wrote:
I've just added a subrule to PGE,
which is roughly analogous to the "bracketed" function in
Perl 5's Text::Balanced.
Like most PGE subrules, PGE::Text::bracketed can be called
as a subrule in a rule expression or directly via a subroutine ca
On Dec 7, 2005, at 15:34, Patrick R. Michaud wrote:
For this I was following the design of "extract_bracketed" in
Perl 5's Text::Balanced, which returns the delimiters as part
of the string. I agree it would be nice for PGE::Text::bracketed
to also return the string without the outer delimiters
On Jan 17, 2006, at 18:01, Andrew Rodland wrote:
Doesn't that imply that "print print print print 1;" is a valid Punie
program? Is that intentional? It seems to me that the gprint rule
should instead contain "cexpr":
rule gprint { (print) \s* }
"print print print print 1;" is certainly
This'll likely be out-of-date tomorrow, but I found it useful as a
quick snapshot/overview of the Parrot repository.
http://www.lohutok.net/parrot.pdf (200k)
Allison
On Jan 31, 2006, at 16:26, Allison Randal wrote:
This'll likely be out-of-date tomorrow, but I found it useful as a
quick snapshot/overview of the Parrot repository.
http://www.lohutok.net/parrot.pdf (200k)
Sadly, it doesn't display in acrobat, but is fine in xpdf and
P
On Feb 2, 2006, at 15:10, Patrick R. Michaud via RT wrote:
...as of r11409, I'm not seeing the 'make test' error for punie
(on my Linux/x86_64 box).
I don't know if this is because it's now working, or because you've
routed around the particular problem you were seeing, so let
me know if you're
On Feb 3, 2006, at 17:33, Joshua Isom via RT wrote:
But, I've encountered two major problems. On darwin, I can't finish
past_node.t, first parrot takes over 100 megs of ram, then perl(5.8.7)
wants 180 megs. On freebsd, it's actually worse, but more confusing.
It fails with past_*.t and post_*.
On Feb 4, 2006, at 8:09, Patrick R. Michaud via RT wrote:
Like others, problematic.t seems to runs okay on my system
(Linux x86_64). :-( Maybe I can get access to a platform on
which it fails...?
Long ago we had an OS X box available to developers. Is that still
around? If not, I can tempo
On Feb 4, 2006, at 12:26, Leopold Toetsch via RT wrote:
Both on OS/X darwin and x86/linux 'make test' as well as
./parrot -p languages/punie/punie.pbc languages/punie/t/
problematic_1.p1
are succeeding here.
The error is gone here too now. Not sure if it's Leo's fix or unrelated.
Allison
On Feb 4, 2006, at 14:23, Joshua Isom via RT wrote:
Apparently I have a 267 megabyte past_node_5.out file... And if
past_op_2.pir and past_val_2.pir were printed to a file, I imagine
it'd
do the same(printing a lot of spaces). Seems to be more than just
Parrot::Test for me.
Could you send
On Feb 4, 2006, at 16:51, Joshua Isom via RT wrote:
41 callmethodcc P1, "dump" -
P1=Object(PAST::Node)=PMC(0x50ba68),
102 get_params PMC_C[29] (2), P0, I0 - , P0=PMCNULL,
I0=5289976
106 repeat S0, "", I0- , , I0=5289976
110 add I0, 1- I0=5289976,
On Feb 3, 2006, at 12:38, Nicholas Clark wrote:
This'll likely be out-of-date tomorrow, but I found it useful as a
quick snapshot/overview of the Parrot repository.
The process used to created it isn't amenable to automation into a
cron job?
It's just a Perl script, so yeah, could be done
On Feb 5, 2006, at 3:05, Leopold Toetsch via RT wrote:
.sub "dump" method
.param int level
The level argument isn't optional at all. Turning on argument count
checks would prevent such errors.
It has to be:
.sub "dump" method
.param int level :optional
Okay, thanks, changed. Joshua
On Feb 6, 2006, at 10:04, Leopold Toetsch via RT wrote:
Allison Randal wrote:
What's the difference between :optional and :opt_flag? I found a few
lines of documentation on these once I knew what to grep for, but
that's all.
Seed pdd03. :optional is the argument. :opt_flag is
On Feb 5, 2006, at 5:56, dakkar wrote:
I did, and the big problem is that it has a size of 106967 x 2031 pts,
which I think translates to 1485 x 28 inches. This not only makes it
hard to display, but also hard to follow...
That's more a result of Parrot than it is of any particular diagram
f
On Feb 7, 2006, at 13:28, Yuval Kogman wrote:
Apologies if this is insulting to anyone, but personally I think
that Perl 6 (pugs, parrot, everything) is losing too much momentum
lately. I think we need to seriously rethink some of the
implementation plan.
I understand your frustration. I even
On Feb 7, 2006, at 15:31, Stevan Little wrote:
Now I am not as involved in Parrot as I am in Pugs so I might be way
off base here, but from my point of view Parrot still has a long way
to go before it runs Perl 6 code. Part of that is because the bridge
between PIR/PMCs and Perl 6 just does not
On Feb 7, 2006, at 19:21, Stevan Little wrote:
Perl 6 will get implemented.
Oh, of that I have no doubt. Never did, and neither does Yuval (if I
may speak for him while he is asleep :). But all that we are trying to
do here is shake out some cobwebs, a little spring cleaning if you
will.
Ex
On Feb 10, 2006, at 9:56, Andy Dougherty via RT wrote:
I too had seen this memory problem before on Solaris/SPARC, but I'm
pretty sure I saw it even when running t/past_node_5.pir directly.
However, trying again today, I'm happy to report that that particular
problem seems to be gone.
Excellen
The original bug is resolved. I'll move the Solaris/SPARC test
failures to a new ticket.
Allison
On Feb 20, 2006, at 9:56, Bernhard Schmalhofer wrote:
P.S
I suppose that I'm not the only one willing to help facing this
difficulty.
Maybe a tutorial or a FAQ could attract more contributors ?
Yes.
In fact, this may be the best place you can start, even if it's only
in the form of "he
On Feb 20, 2006, at 16:21, Karl Forner wrote:
I was expecting this kind of answer (Just Do It) ;-)
Where/How could I add this kind of FAQ ?
Write a draft, post it here for comments. Then polish it up and if it
looks good, one of us will commit it.
What you add may fit as a patch to docs/g
We're going to try something a little different. With Chip's blessing
I've written a very early draft of the PDD for I/O (not numbered
yet). The attached PDD isn't a completed document with Chip's seal of
approval, it's a seed for discussion.
What I need from you all is comments. What's mis
On Mar 5, 2006, at 15:35, chromatic wrote:
On Sunday 05 March 2006 11:46, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
[It's worth considering making all the network I/O opcodes use a
consistent way of marking errors. At the moment, all retu
On Mar 6, 2006, at 4:08, Leopold Toetsch wrote:
Some remarks re the pdd and discussion so far.
o "write" ... [Is this redundant?]
"write" isn't needed. It is there, as some time ago, "print" was't
able to write strings with "\0"s inside.
Now marked in the PDD as deprecated.
(To make
On Mar 5, 2006, at 13:52, Joshua Isom wrote:
On Mar 5, 2006, at 3:46 PM, Nicholas Clark wrote:
On Sun, Mar 05, 2006 at 02:53:29PM -0600, Joshua Isom wrote:
A pasm include, such as the signal.pasm(even though signals don't
work
yet), would suffice and is generated at compile time. Parsing .h
On Mar 11, 2006, at 2:07, Nicholas Clark wrote:
I feel more comfortable with the idea of IO being methods on PMCs
than raw
OPs.
They are methods on I/O objects internally. (Just as most opcodes on
PMCs actually call vtable methods.) So, the question isn't as
significant as it appears. I
On Mar 3, 2006, at 15:54, Joshua Isom wrote:
Concerning all the byte/character issues, all the string opcodes
except bytelength work with characters. But the io subsystem
currently only deals with bytes. I know there is the speed issue
for things like reading with dealing with utf8, but
On Mar 6, 2006, at 4:06, Nicholas Clark wrote:
On Fri, Mar 03, 2006 at 11:27:05AM -0800, Allison Randal wrote:
=head2 Network I/O Opcodes
Functionality wise, the following are missing:
shutdown
Added.
getpeername/getsockname
getsockopt/setsockopt
These seem rare, and
I just committed a more complete draft of the I/O PDD to docs/pdds/
clip/pddXX_io.pod. I've integrated or responded to the mailing list
comments. I also added a good bit of additional discussion of
asynchronous operations and error handling. The original draft was
"how it works now", while t
On Mar 18, 2006, at 4:18, Leopold Toetsch wrote:
On Mar 18, 2006, at 5:05, Allison Randal wrote:
+=head3 Hybrid solution
+
+Another option is to return a status object from each I/O
operation.
I'm in favour of such a solution.
Also my favorite.
+The disadvantage is that a s
On Mar 19, 2006, at 11:05, Nicholas Clark wrote:
Is the choice of implementation actually visible to a user of the API?
If "yes", where, and can we avoid it?
No.
At which point we have flexibility in
how things are actually implemented.
Yes.
I can see that emulating asynchronous ops with
On Mar 19, 2006, at 0:23, Uri Guttman wrote:
if you look at the rfc's (remember those? :) i wrote on this topic,
you
will see that i proposed just that form of api (not at OO as
these). the
only difference between a sync and async i/o op was the addition of a
callback argument (and an optio
In: docs/pdds/clip/pddXX_exceptions.pod
As with the I/O PDD, this isn't a final form, it's just a draft to
seed discussion. What's missing? What's inaccurate? What's accurate
for the current state of Parrot, but is something you always intended
to write out later? What thoughts have you had
On Apr 8, 2006, at 19:49, Bob Rogers wrote:
. . .
=item *
C creates an exception handler and pushes it onto the
control
stack. It takes a label (the location of the exception handler)
as its
only argument. [Is this right? Treating exception handlers as
label
jumps rathe
On Apr 20, 2006, at 1:32 PM, Damian Conway wrote:
KeywordImplicit adverbsBehaviour
regex (none) Ignores whitespace, backtracks
token :ratchetIgnores whitespace, no backtracking
rule :ratchet :words Skips whitespace, no back
On Wed, 10 May 2006, Damian Conway wrote:
> Allison wrote:
>
> I've never met anyone who *voluntarily* added
> the 'p'. ;-)
You've spent too much time in the U.S. ;)
> > and the fact that everyone knows 'regex(p)'
> > means "regular expression" no matter how may times we say it doesn't.
>
> Su
To summarize a phone call today, the more intelligent defaults we add to
differently named rule keywords the more comfortable I am with having
different names. So, here's what we have so far (posted both as an FYI
and to confirm that we have the coherent solution I think we have):
rule:
- Has
Damian Conway wrote:
skip:
- We keep :words as shorthand for :skip(//)
- And :skip is shorthand for :skip(//)
...where defaults to , but is distinct from it (i.e. it can
be redefined independently).
It also has the benefit that developers redefining can call
as one of the alternates i
Patrick R. Michaud wrote:
On Thu, May 11, 2006 at 08:57:53PM +0800, Audrey Tang wrote:
Patrick R. Michaud wrote:
- is a single character of obligatory whitespace
Hmm, it's literal ' ' (that is, \x20), not "whitespace" in general,
right? For "obligatory whitespace" we have \s.
Oops, you're
Jonathan Scott Duff wrote:
On Wed, May 10, 2006 at 05:58:57PM -0700, Allison Randal wrote:
rule:
- Has :ratchet and :skip turned on by default
- May only be used inside a grammar
Should that be
- Must be declared as part of a grammar or role
???
It is:
- The 'rule' keyword m
Patrick R. Michaud wrote:
Whitespace in regexes and rules is metasyntactic, in that it is
not matched literally. Effectively what the :w (or :words or
:skip) option does it to change the metasyntactic meaning of
any whitespace found in the regex. Or, another way of thinking
of it -- as S05
Oh, and since we're calling them "regexes", I suggest calling them
"regular expressions" too, since both "regex(p)" and "regular
expression" have taken on the popular meaning of "pattern matching". If
we're going to be anti-pedantic, let's be consistently anti-pedantic. :)
Allison
[EMAIL PROTECTED] wrote:
Log:
Changed :words/:w to :sigspace/:s and invented ss/// and ms// (or maybe mm//).
I keep expecting 'sigspace' to have something to do signatures.
Larry++ on :s. :)
Allison
Smylers wrote:
Allison Randal writes:
I keep expecting 'sigspace' to have something to do signatures.
So do I. How about :litspace for 'literal space'? Except they aren't
exactly literal, because they only indicate where _some_ space has to
be, not that it has t
Matt Diephouse wrote:
- languages/forth/
I was actually the last one to provide a patch to forth (there
were some other commits that modified things like copyright info, but
those don't count). That was 20 months ago. The implementation was
horribly dated then and things are far worse n
The fundamental legal point is that we're not reserving all rights,
because we're distributing the code under an open source license. Many
open source developers include "All Rights Reserved." in a cargo-cult
fashion, without understanding what it means.
Will Coleda via RT wrote:
How does thi
Paul Johnson wrote:
I wouldn't have said anything, but your correction seems to indicate
that the (C) is important. Is my information outdated?
It wasn't a correction based on legal requirements, it was a correction
based on "this is what we talked about earlier and decided to
standardize t
(Randal L. Schwartz) via RT wrote:
According to Brad Templeton's copyright FAQ, it really doesn't mean anything
anyway. If I recall, It was needed in a few south american countries, all of
whom have become Berne-convention parties now, so it really means nothing.
It never meant "rights" in a l
Robert Spier wrote:
Nothing is actually _deleted_ from SVN... it just gets harder to
find. So it'll be there later if you want it.
Aye, I wasn't afraid it would disappear forever. But the old "What was
that deleted path I'm looking for, and what revision should I sync back
to?" makes it jus
Nicholas Clark wrote:
Would this be resolved by entries in the ChangeLog?
In Perl5 the version control history is added to a Changes file, which has
each commit message along with the perforce revision number. It makes it
very easy to search for these sorts of things. I assume that it's trivial
Charles Reiss wrote:
So, to start off, a copyright question:
It would be nice to use libraries that provide relatively portable
atomic operation support (needed for good implementations of most
"lock-free" schemes), such as HP's atomic_ops [
http://www.hpl.hp.com/research/linux/atomic_ops/index
I've recently finished up a round of refactors and feature additions to
Parrot's tree grammar engine (TGE). (TGE is the part of the compiler
tools that takes a raw parse tree from a language parser written in PGE
and transforms that parse tree into an abstract syntax tree, then an
opcode syntax
Chip Salzenberg wrote:
Allison, if you give me the OK, I'll recast pdd23 in the alternative way I
had in mind, where:
* exception handlers are closures,
* the closures are called _inside_ the dynamic scope where the throw occurred,
* a closure returning without executing C implies "I didn'
Chip Salzenberg wrote:
Darn, find_global has collided with pdd21.
Currently find_global is prepared to accept a key or a namespace, and
distinguishing namespaces from arrays is starting to get just a little
too polymorphic for an opcode.
I'm thinking that between get_namespace and the untyped n
Patrick R. Michaud wrote:
you change to
$P99 = get_namespace key_or_array
$P0 = $P99['foo']
which also incidentally encourages(!) compilers to cache namespace pointers.
Ooh. I like it very much!
Okay, to flesh this out as a viable alternative, Chip/Patrick we need:
a) a standard
I'm writing a parser for a language that treats a double newline as a
statement terminator. It works if I make every rule a 'regex' (to turn
off smart whitespace). But I want spaces and tabs to act as smart
whitespace, and newlines to act as literal whitespace. I've
overloaded to match only spaces
Audrey Tang wrote:
> 在 2006/7/4 下午 8:50 時，Allison Randal via RT 寫到：
>
>> The :immediate feature isn't really a question of reentrancy (it doesn't
>> hold static data over successive calls, and it doesn't return a pointer
>> to static data).
>
&
Will Coleda via RT wrote:
This feature is needed for how parrot currently handles dynamic pmcs. If :immediate is
deprecated, part of that deprecation needs to include keeping languages which use dynamic
pmcs (perl6, tcl) functioning.
:immediate won't be deprecated. It's a dynamic feature app
Audrey Tang wrote:
>
> But again, it's the architect's decision to make, and I will stop to
> quibble. :-)
I'd rather help you understand why it's the right choice for a virtual
machine targeting dynamic languages, but if I can't, I can't. :)
Allison
Bob Rogers wrote:
If, as seems likely, exception bookkeeping is moved to a separate
stack in the interpreter (with or without dynamic-wind actions), then
C/C addresses can stay in the Parrot_Context, and all of
pdd23_exceptions.pod that is quoted below ceases to be problematic.
Does that seem
Audrey Tang wrote:
>
> But I guess this bug ticket is not an appropriate place...
Indeed. We need a "Document :immediate" ticket.
Vishal is doing a fantastic job putting the IMCC bugs into RT. And that
pretty much wraps up this ticket (except as a parent for the others).
Thanks,
Allison
chromatic wrote:
>
> That doesn't quite seem fair; dynamic is a lot broader than just typing.
> Certainly any statically typed language with decent support for generic
> operations (or at least type-safe polymorphism) and a non-static loading
> scheme would be sufficiently dynamic.
>
> I can'
Audrey Tang wrote:
>
> I already filed that as #39716 a few hours ago; also #39715 and #39714,
> as per your suggestion:
Excellent.
> As I cannot modify links on rt.perl.org, can you do that for me?
Done, and I also added Vishal as a requestor on the relevant tickets.
Thanks!
Allison
Nathan Gray wrote:
>
> Overloading and other builtins was fixed in parrot and pugs
> approaching midnight (hackathon time) on 2006-06-29. If your parrot
> and pugs are both more recent than that, I'm not sure where the bug
> is.
I have the latest checkout of Parrot (I'm not using Pugs).
It may
Patrick R. Michaud wrote:
On Tue, Jul 04, 2006 at 12:57:16PM -0700, Allison Randal wrote:
--
token start { ^*$ }
regex emptyline { ^^ $$ \n }
token ws { [ | \t]* }
--
The above grammar doesn't have a "grammar" statement; as a result
the regexes are being ins
Quick question, is there a syntax specified in Perl 6 for referring to
namespaces from other languages?
I'm reviewing the namespaces PDD and want to update this snippet:
--
IMPLEMENTATION EXAMPLES: Suppose a Perl program were to import some Tcl
module with an import pattern of ``c*'' -- som
Chip Salzenberg wrote:
--- PART 2, IN WHICH AN ELEGANT SOLUTION IS PROPOSED --
On the other hand, we could extend the key PMC to represent emptiness,
i.e. zero dimensions. This seems useful for namespaces and could even prove
useful for real keys. And this makes keys even more compatible wi
Allison Randal wrote:
I had a much longer reply, but I'm going to let it steep overnight and
see what percolates.
I ran through a number of possibilities, but so far my favorite is:
find_global and store_global are truly 'global', that is, they always
require a fully spec
Chip Salzenberg wrote:
On Thu, Jul 06, 2006 at 01:21:08AM -0700, Allison Randal wrote:
The problem is really that we're trying to simultaneously a) refer to
the root HLL namespace directly, and b) pretend that it doesn't exist.
I don't think (b) is quite true. It's more
Chip Salzenberg wrote:
The below patches are my guess as to how to fix PGE and TGE for the recent
change in .namespace. (That is, C<.namespace ['']> now means what it says,
and the HLL root is reachable by C<.namespace> w/o parameters.)
TGE and PGE both need a thorough going-over for the new n
jerry gay wrote:
On 7/6/06, Allison Randal <[EMAIL PROTECTED]> wrote:
meanwhile, back at the ranch, perl6 is failing all
t/00-parrot/08-regex.t tests due to the .namespace changes. chip's
proposed PGE patch fixes those failures.
Oh, I didn't mean "don't apply it
Chip Salzenberg wrote:
Well, I see a lot to like about this, but (and you knew there was a "but"
("but" that's my job now :-))), in descending order of difficulty:
And you do it so well. Thank you. :)
* The division into two categories ("global" and "symbol") leaves the third
category (c
I gave a Parrot talk at a Ruby user group meeting tonight. Someone
mentioned that they had seen somebody on #parrot who was working on a
new Ruby implementation based on Punie. Do you exist? And is there
anything we can do to help you?
Allison
Matt Diephouse wrote:
So for the runtime (this is the HLL runtime, not the PIR runtime, btw)
we're all set. Arrays fill the need perfectly and let us access the
root HLL namespace. That makes me think that we don't need any new
opcodes.
Chip's latest simplification eliminates the need for crea
Kevin Tew wrote:
That would be me!
PRuby is the project.
Suggestions of a better project name are welcome.
Possibly Cardinal? (A ruby-red bird.) The original Cardinal project was
started in 2002, but talking last night we decided it needed a complete
re-write in PGE/TGE (which is when you w
Chip did a fantastic job on the Exceptions PDD. With a few refinements,
I'm pronouncing it "ready to implement". We'll certainly work out more
details as we go along, but the best way to test the design is to start
on the code.
Allison
Chip Salzenberg wrote:
>
> I think it'd be great to maintain a hackathon designated location for those
> who are between tutorials, or who like me just show up during tutorial days
> for the hell of it. :-)
There's a designated room for hackathon/Camp-style sessions inside the
convention center
Chip Salzenberg wrote:
>
> Hrm. Relative is the usual apposite to absolute, but we have a three-way
> logic here, so appositives don't really work. I think that "hll" is the
> best I can think of, and given the existing ".HLL" directive, its meaning
> is immediately clear:
I like that.
> Seems
Bob Rogers wrote:
>From: Chip Salzenberg <[EMAIL PROTECTED]>
>Date: Mon, 10 Jul 2006 19:41:38 -0700
>
>(You'll probably want to know that "get_base_global" has a slight object-
>orientation connotation from my C++ experience; in C++, a superclass is
>called a "base class". Whe
Chip Salzenberg wrote:
[*] Just what it _is_ intended for is an open question. I think the user
base will answer it, if we let them, in time.
To give a concrete and immediately relevant example: the fact that
people are using :immediate to load libraries at compile-time is a good
sign t
Audrey Tang wrote:
That is a sane argument, which is why I think punt-and-see has some merit:
as soon as there is a workaround forced to be expressed at :immediate
level, we can evaluate it and see if it's better handled declaratively.
Excellent. (Er, though you know that .loadlib isn't reall
It occurs to me, after thinking about it overnight, that the .loadlib
directive shouldn't operate at :immediate time, but at :init time,
because it's more common to want a library to load when you run the code
than to load only when you compile the code.
Which leaves us with :immediate for the
Leopold Toetsch wrote:
Well, there was already one very legitimate usage of compile time
loadlib, which is now using C<.loadlib> for that:
We certainly need both compile-time and runtime loading of libraries.
So, it's just a question of which syntax to use for which case.
chromatic suggests
Will Coleda wrote:
I would prefer .include to maintain its current meaning. Not everything
you .include is a complete PIR program.
I think the most common case at the moment is stitching together .pir
files generated by PGE/TGE. Which is useful.
Allison
Patrick R. Michaud wrote:
IIUC, the loadlib opcode (and the new .loadlib directive) are used
strictly for dynamic libraries...
.include is currently compile-time only, and only works with .pir/.pasm
...
Yes, the suggestion is an extreme reuse of existing syntax. Something
that's good to avoi
Leopold Toetsch wrote:
This means, we'd have:
.include "file.pasm/.pir" ... load macros or constants (no code)
>
load_bytecode "file.pbc" ... load a "module"
$P0 = loadlib "file" ... load a shared lib (pmc or ops)
.loadlib "file"... same during compilation
Th
[EMAIL PROTECTED] wrote:
Modified: trunk/languages/perl6/perl6.pir
==
--- trunk/languages/perl6/perl6.pir (original)
+++ trunk/languages/perl6/perl6.pir Wed Jul 12 17:05:26 2006
@@ -24,9 +24,7 @@
.namespace [ '
chromatic wrote:
On Wednesday 12 July 2006 16:11, Allison Randal wrote:
load_bytecode is good for runtime loading of PASM/PIR/PBC.
Except for the misleading name.
Oh, you mean the fact that much of the time it's not loading bytecode at
all? It has crossed my mind, but the irrit
Patrick R. Michaud wrote:
Allison just updated pdd21, it looks great! Here's a first
cut at some suggested changes and wordsmithing to the text.
Feel free to adopt, ignore, or discuss any of the suggestions
below as you see fit.
Thanks, applied!
: =item get_global
:
: $P1 = $P2.get_glob
Kevin Tew (via RT) wrote:
adds preamble section to tge grammar to allow for includes and global
defines at the top of the PIR generated by TGE
For example, I use
preamble{
.include 'interpinfo.pasm'
}
You're on to an important idea, but it still needs refinement.
A bit of background info
Chip Salzenberg wrote:
Looking over the recent editorial improvements in pdd21, I need to point out
that, right now, if a method is written in C, it can't have optional
arguments. (This is per Leo; I haven't checked into how/why this
restriction arose.)
Aye. This went through my mind as I made
Vishal Soni wrote:
The current implementation is implemented using Flex and YACC. Flex
implementation has limitations in C mode. The C lexer generated by flex
cannot be reentrant/threadsafe. Flex generates thread-safe parsers only in
C++ mode. This limition of flex will defeat the whole effort
Vishal Soni wrote:
Allison having said that we need an API for byte code generation that
supports plug n play optimizers would it make sense to start
implementing this layer. This API could be used for OST to byte code
generation. Later when Patrick's PGE to C parser generator is ready we
could
Vishal Soni wrote:
Allison this sounds great. To get started I will need some reference to
the OST format. Can you please point me in the right direction (some
documentation or sample code shall do.)?
Start with languages/punie/lib/POST/ and
languages/punie/lib/PIRGrammar.tg. This is the most
Audrey Tang wrote:
As I'm writing this, I noticed that Allison has ruled that we go with
PIR/PGE and eventually C-based libpge instead
-- since a lexer refactoring that doesn't affect the IMCC API will
somehow throw important projects on Parrot into a
"dead stall", and thread safety for PIR c
1 - 100 of 1020 matches
Mail list logo
