[PATCH PDD07] Document struct naming conventions

2002-08-20 Thread Brent Dax
Since I'm lying in wait to apply the rules in force within most of the core to Parrot_Interp, I figured I might as well document them. :^) --- docs/pdds/pdd07_codingstd.pod 17 Jul 2002 02:57:18 - 1.6 +++ docs/pdds/pdd07_codingstd.pod 20 Aug 2002 07:02:15 - @@ -371,27 +371,19

RE: [PATCH PDD07] Document struct naming conventions

2002-08-20 Thread Brent Dax
Brent Dax: # Since I'm lying in wait to apply the rules in force within most of the # core to Parrot_Interp, I figured I might as well document them. :^) Gah, got wrapped all funny. Here it's attached and sent to bugs-parrot. --Brent Dax [EMAIL PROTECTED] @roles=map {Parrot $_} qw(embedding

[perl #16622] RE: [PATCH PDD07] Document struct naming conventions

2002-08-20 Thread via RT
# New Ticket Created by Brent Dax # Please include the string: [perl #16622] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16622 Brent Dax: # Since I'm lying in wait to apply the rules in force within most of the #

Re: Functional Perl6 compiler doesn't seem to be functioning

2002-08-20 Thread Leopold Toetsch
Chris Dutton wrote: Maybe I'm just doing something wrong... Then when I try to run perl6, via perl perl6 to avoid INC issues, I get: Code must live with a function Trying to compile hw.p6. What does hw.p6 look like? Anyways: sub main() { # your code goes here my $a = 1;

Re: [perl #15907] [PATCH] Make warnings configurable

2002-08-20 Thread Juergen Boemmels
Just replying to [EMAIL PROTECTED] does not seem to forward to the list. Ok, here once again to perl6-internals Mike Lambert (via RT) [EMAIL PROTECTED] writes: Looking at the patch, it seems rather GCC-specific. The checking for no-X versus X in the warnings flags seems to be rather

[perl #16670] [PATCH] find_bucket in hash.c not GC safe

2002-08-20 Thread via RT
# New Ticket Created by Jason Gloudon # Please include the string: [perl #16670] # in the subject line of all future correspondence about this issue. # URL: http://rt.perl.org/rt2/Ticket/Display.html?id=16670 find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing old

Re: [perl #16298] [PATCH] pbc2c.pl startup

2002-08-20 Thread Leopold Toetsch
Leopold Toetsch (via RT) wrote: attached patch uses now a similar startup code for native compiled programs like test_main.c. Rediffed and additional patch to compile natively .pasm containing keyed access (pack_key was not export in lib/Parrot/Types.pm). please apply, leo ---

testing native compiled parrot

2002-08-20 Thread Leopold Toetsch
Hi, Attached shell script (for systems with a shell) runs all parrot tests natively compiled either static or shared. It uses the perl6 driver for this, which has (since I ran out of disc space first ;-) an explicit option to delete the ~2MB static executables after successful tests. (perl6

Re: [perl #16670] [PATCH] find_bucket in hash.c not GC safe

2002-08-20 Thread Leopold Toetsch
Jason Gloudon (via RT) wrote: find_bucket as writen is GC-unsafe. This patch corrects this, by not reusing old values of bucket pointers across calls to string_compare, which can invoke compaction, causing the bucket to move. Dunno, how expensive getBucket is, but wouldn't it be faster,

GC generation?

2002-08-20 Thread Dan Sugalski
Would it make people's lives easier and potentially faster if we added a GC_GENERATION field to the interpreter, one we increment every time we do a GC or DOD run? I expect a UINTVAL should be sufficient to hold the counter. This way things that might have to do pointer recalcs or whatever

Re: [perl #16298] [PATCH] pbc2c.pl startup

2002-08-20 Thread Steve Fink
On Tue, Aug 20, 2002 at 09:12:36PM +0200, Leopold Toetsch wrote: Leopold Toetsch (via RT) wrote: attached patch uses now a similar startup code for native compiled programs like test_main.c. Rediffed and additional patch to compile natively .pasm containing keyed access (pack_key was

Re: GC generation?

2002-08-20 Thread John Porter
Dan Sugalski wrote: I expect a UINTVAL should be sufficient to hold the counter. Why? Because you don't expect a perl process to run longer than a couple hours? Or because rollover won't matter? -- John Douglas Porter

Re: GC generation?

2002-08-20 Thread Dan Sugalski
At 6:16 PM -0400 8/20/02, John Porter wrote: Dan Sugalski wrote: I expect a UINTVAL should be sufficient to hold the counter. Why? Because you don't expect a perl process to run longer than a couple hours? Or because rollover won't matter? Rollover won't really matter much, if we're careful

RE: [DRAFT PPD] External Data Interfaces

2002-08-20 Thread Bryan C. Warnock
On Sun, 2002-08-18 at 18:53, Brent Dax wrote: # And do we need a RFC like definition of should/may/must/mustn't? If so, I'd suggest the definition be patched into PDD0, so it's shared by all PDDs instead of repeating the definitions everywhere. Noted. -- Bryan C. Warnock

[COMMIT] Basic BNF and Parse::RecDescent grammar for Perl6 rx//operator

2002-08-20 Thread Jeff
The subject pretty much says it all. The format pretty much corresponds to the upcoming Exegesis. Major changes were to the modifiers, and a few syntax changes in the depths. Sean, feel free to take what you can use (if anything) from this and delete the rest. -- Jeff [EMAIL PROTECTED]

regexen? rules? patterns?

2002-08-20 Thread Sean O'Rourke
I just put a rough cut at them in CVS. To actually use them, you'll need to apply a rather brutal patch/hack to IMCC, which I'll post to the list shortly. This does not use Jeff's grammar -- I wanted to get what I had into CVS before taking a look at that. Enjoy, /s

imcc hack for perl6 regexes

2002-08-20 Thread Sean O'Rourke
This is what you'll need. It uses dlopen(), and is likely Bad in a number of other ways, but if you're on a fairly normal UNIX, it should allow imcc to grok what P6C produces for regexes. /s ? languages/imcc/a.out ? languages/imcc/anyop.c ? languages/imcc/anyop.h ? languages/imcc/a.pasm ?

Re: [perl #16308] [PATCH] logical right shift

2002-08-20 Thread Mike Lambert
This adds logical shift right opcodes. They are essential for bit shifting negative values without sign extension getting in the way. Applied, thanks. Mike Lambert