Re: PDD 23 Exceptions - ready for implementation

2006-07-14 Thread chromatic
On Friday 14 July 2006 16:07, Bob Rogers wrote: > One way to ensure that a handler is not in scope > when invoked (though possibly not the only way) is to keep the list of > active handlers in a dynamic variable binding. Here's what I don't understand. Why is there talk of a stack to keep track

Re: PDD 23 Exceptions - ready for implementation

2006-07-14 Thread Chip Salzenberg
On Sat, Jul 08, 2006 at 04:51:38PM -0700, Allison Randal wrote: > Chip did a fantastic job on the Exceptions PDD. With a few refinements, > I'm pronouncing it "ready to implement". Excellent. Mad properties to Allison for creating the first draft (updating is so much easier than starting from

PDD 23 Exceptions - ready for implementation

2006-07-14 Thread Bob Rogers
I've had an idea. One way to ensure that a handler is not in scope when invoked (though possibly not the only way) is to keep the list of active handlers in a dynamic variable binding. The code for C can then *rebind* that variable, popping handlers off (in a way that is not destructive, i.e.

suggestions for new pdd21

2006-07-14 Thread Patrick R. Michaud
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. : A non-nested namespace may appear in Parrot source code as the string : C<"a"> or the key C

[svn:parrot-pdd] r13295 - in trunk: . docs/pdds

2006-07-14 Thread allison
Author: allison Date: Fri Jul 14 12:21:29 2006 New Revision: 13295 Modified: trunk/docs/pdds/pdd21_namespaces.pod Changes in other areas also in this revision: Modified: trunk/ (props changed) Log: [pdds]: Namespaces - A new plan for easier access to the various virtual namespace roots.

Re: [perl #39829] [PATCH] accept() always fails

2006-07-14 Thread Chris Dolan
On Jul 14, 2006, at 4:56 AM, Leopold Toetsch wrote: Am Donnerstag, 13. Juli 2006 23:41 schrieb Kay-Uwe Huell: Hi parrot, unfortunatly you fail when I call your accept() op. I have fixed this issue with attached patch. The Parrot documentation can now be accessed at http:// localhost:123

Re: [perl #39796] [TODO] Implement .loadlib pragma in IMCC

2006-07-14 Thread Will Coleda
So, does .loadlib wipe the current .HLL pragma that's in effect? (if it's intereacting with the other dot-pragmas, we need to document.) Regards. On Jul 14, 2006, at 7:17 AM, Audrey Tang wrote: 在 2006/7/14 上午 6:45 時,Audrey Tang 寫到: Changing it back to :immediate makes tests pass again. Al

Re: [perl #39796] [TODO] Implement .loadlib pragma in IMCC

2006-07-14 Thread Audrey Tang
在 2006/7/14 上午 6:45 時,Audrey Tang 寫到: Changing it back to :immediate makes tests pass again. Alternately, skipping the Parrot_register_HLL part in IMCC makes tests pass again. After several rounds of trial-and-error, I've committed r13294 that works around the problem: * Tcl: Change bac

Re: [perl #39796] [TODO] Implement .loadlib pragma in IMCC

2006-07-14 Thread Audrey Tang
在 2006/7/14 上午 5:26 時,Leopold Toetsch via RT 寫到: Err, t/dynpmc/dynlexpad.t is using .loadlib and is testing fine. Please try to provide a minimal parrot test showing the problem. Trying (though it remained a bit elusive), but if you "make realclean", and then change languages/tcl/src/tcls

Re: [perl #39829] [PATCH] accept() always fails

2006-07-14 Thread Leopold Toetsch
Am Donnerstag, 13. Juli 2006 23:41 schrieb Kay-Uwe Huell: > Hi parrot, > > unfortunatly you fail when I call your accept() op. I have fixed this > issue with attached patch. >The Parrot documentation can now be accessed at http://localhost:1234 . >accept: errno=22unknown method:'' I don'

Re: [perl #39796] [TODO] Implement .loadlib pragma in IMCC

2006-07-14 Thread Leopold Toetsch
Am Freitag, 14. Juli 2006 04:02 schrieb Will Coleda via RT: > Whoops, re-opening. > > This apparently isn't quite ready yet, as converting tcl to use the new > syntax results in a nearly- complete fail of the test suite. > > Per Audrey: .loadlib 'dynlexpad' stopped working, because > Parrot_regist

RE: PL/Parrot

2006-07-14 Thread Butler, Gerald
Would it make sense to implement the PostgreSQL SPI interface as a set of Parrot PMC's; then ANY HLL on Parrot could use those PMC's? Or could the SPI be wrapped by PERL for example, and then the OTHER HLL's simply use the classes/objects of the PERL interface? -Original Message- From: D

[perl #39829] [PATCH] accept() always fails

2006-07-14 Thread via RT
# New Ticket Created by Kay-Uwe Huell # Please include the string: [perl #39829] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt3/Ticket/Display.html?id=39829 > Hi parrot, unfortunatly you fail when I call your accept() op. I have fixed this issue

Re: PL/Parrot

2006-07-14 Thread David Fetter
On Thu, Jul 13, 2006 at 12:57:18PM -0400, Butler, Gerald wrote: > Would it make sense to implement the PostgreSQL SPI interface as a > set of Parrot PMC's; then ANY HLL on Parrot could use those PMC's? > Or could the SPI be wrapped by PERL for example, and then the OTHER > HLL's simply use the cla