在 2006/7/18 上午 1:21 時，Allison Randal 寫到：
LOL :) Audrey, I love you dear, but you always have an interesting
way of interpreting what I say. :)
Yes, I'm not willing to start a 6+ month project to gut IMCC. The
cost is too great and the benefit isn't great enough.
Indeed, and I'd like to ap
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
在 2006/7/17 下午 3:41 時，Joshua Hoblitt 寫到：
4th Option: fix flex. ;)
Turns out flex 2.5.30+ has a reentrant mode. However, it also has an
incompatible API with earlier flex,
even in non-reentrant mode. I've attached a patch under http://
rt.perl.org/rt3//Public/Bug/Display.html?id=34669
(ne
On Jul 17, 2006, at 10:03 PM, Chip Salzenberg wrote:
I've dumped all your suggestions into cage/todo.pod.
Thanks. That you're editing cage and herding the cage cleaners is
a load
off my mind.
That's my job. I flap my lips a lot, stir the soup, organize it, and
hand it off to other pe
On Mon, Jul 17, 2006 at 09:38:22PM -0500, Andy Lester wrote:
> I've dumped all your suggestions into cage/todo.pod.
Thanks. That you're editing cage and herding the cage cleaners is a load
off my mind.
--
Chip Salzenberg <[EMAIL PROTECTED]>
On Jul 17, 2006, at 9:22 PM, Chip Salzenberg wrote:
Ideas I've got:
* standarizing on "interp" or maybe even "intr" as the interpreter
variable, for brevity & consistency
Yeah, that one's bugged me, too.
I've dumped all your suggestions into cage/todo.pod. Thanks for
taking the t
I've got a few source cleanups in mind, and I figured I'd share the ideas
I have kicking around my head, and ask if anyone else has been thinking of
cleanups as well.
Note that I don't want to make the eventual STM merge more difficult than
necessary, so I don't think we can make these cleanups ye
On Mon, Jul 17, 2006 at 09:26:12PM -0400, Bob Rogers wrote:
>But what I really meant was: Shouldn't Parrot do a 'setrlimit' on
> itself in order to detect these sorts of bugs sooner, and more usefully?
> Or, maybe 'ulimit -s' would be appropriate before running test cases?
Running the test su
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
> Let's go for an agile, iterative approach to the spec. Write up some
> initial thoughts on the shape of the API and post them to
> parrot-porters. The group can do sanity-checking/brainstorming, and then
> you can start a prototype based on the result. After we've played with
> the prototype
From: Leopold Toetsch <[EMAIL PROTECTED]>
Date: Mon, 17 Jul 2006 11:50:35 +0200
Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers:
> BTW, it doesn't seem right that I can run Parrot for only a second or
> two and get more than 300K stack frames deep. Isn't there a way to
> li
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
On Mon, 2006-07-17 at 14:49 -0700, Allison Randal wrote:
> re2c and lemon aren't enough of an improvement over flex and bison to be
> worth the pain of rewriting IMCC from scratch. If we do create a new way
> of producing bytecode (and it's a safe bet that we will at some point),
> I would lean
On 17 Jul 2006, at 05:22, Audrey Tang wrote:
在 2006/7/16 下午 11:57 時，Vishal Soni 寫到：
I think that the lemon+re2c, being the more modern parsing tools,
will make refactoring/hacking considerably easier.
For future reference Ragel is definitely worth a look too:
http://www.cs.queensu.ca/~th
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
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
Author: allison
Date: Mon Jul 17 13:48:29 2006
New Revision: 13335
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[pdd21]: Backing out optional argument on a low-level PMC.
Modified: trunk/docs/pdds/pdd
On Mon, Jul 17, 2006 at 09:52:35AM -0700, Allison Randal wrote:
> >: =item get_global
> >:
> >: $P1 = $P2.get_global($S3)
> >:
> >: Retrieve a global variable $P1 from the namespace $P2, with the name
> >: $S3.
> >
> >What's the meaning of "global" in this context? Some part of me
> >wants t
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
Am Donnerstag, 13. Juli 2006 23:41 schrieb Kay-Uwe Huell:
> Hi parrot,
>
> unfortunatly you fail when I call your accept() op.
This should be fixed now with r13332 (there was some confusion about sockaddr*
types and the len of these).
leo
4th Option: fix flex. ;)
-J
--
On Sun, Jul 16, 2006 at 10:57:07PM -0500, Vishal Soni wrote:
> Hi,
>
> Please disregard the previous mail. Hit the wrong shortcut key!!
>
> I have been working on trying to make reenterant and/or thread-safe. There
> are couple of things that have come up which mi
# New Ticket Created by Chip Salzenberg
# Please include the string: [perl #39855]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39855 >
It's great to have INTVAL and UINTVAL, but without MAX_INTVAL it's kind of
hard to wo
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.)
Thus, to support both of these interfaces:
=item get_namespace
Am Montag, 17. Juli 2006 18:52 schrieb Allison Randal:
> > Since we have slurpy named parameters in Parrot, why not simply leave $P3
> > off and use (optional) named parameters here to specify options?
>
> Chip/Leo, do the various named parameter passing techniques work on
> low-level PMC's defined
# New Ticket Created by Kevin Tew
# Please include the string: [perl #39854]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39854 >
adds preamble section to tge grammar to allow for includes and global
defines at the top
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
Author: allison
Date: Mon Jul 17 09:49:44 2006
New Revision: 13331
Modified:
trunk/docs/pdds/pdd21_namespaces.pod
Changes in other areas also in this revision:
Modified:
trunk/ (props changed)
Log:
[pdd21]: Some wordsmithing from Patrick Michaud.
Modified: trunk/docs/pdds/pdd21_namespa
Am Sonntag, 16. Juli 2006 18:46 schrieb Ron Blaschke:
> Possible Solution: Attached patch adds a block around the MMD
> initializer code, which should bring the generated code back to valid C.
Thanks, applied - r13329.
leo
Parrot Bug Summary
http://rt.perl.org/rt3/NoAuth/parrot/Overview.html
Generated at Mon Jul 17 13:10:47 2006 GMT
---
* Numbers
* New Issues
* Overview of Open Issues
* Ticket Status By Version
* Requestors with m
# New Ticket Created by Ron Blaschke
# Please include the string: [perl #39849]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt3/Ticket/Display.html?id=39849 >
Problem: languages/lua doesn't compile on Win32, with the following
error message.
l
Am Montag, 17. Juli 2006 03:30 schrieb Bob Rogers:
> BTW, it doesn't seem right that I can run Parrot for only a second or
> two and get more than 300K stack frames deep. Isn't there a way to
> limit the stack to something sane, since more than a few MB of C stack
> usage is a pretty sure sign
31 matches
Mail list logo
