Re: [PATCH] POD TITLE blocks

At 12:11 AM -0400 8/27/02, Bryan C. Warnock wrote: >www.parrotcode.org/docs seems to like them, so here they are. >This rolls in the byteorder.dev patch previously submitted. > Applied, thanks. -- Dan --"it's like this

Re: [PATCH] byteorder.dev

At 10:51 PM -0400 8/26/02, Bryan C. Warnock wrote: >The web conversion (www.parrotcode.org/docs) results in a blank page as >this file isn't PODified. Patch remedies. Applied, thanks. -- Dan --"it's like this"

significant imcc commit

Okay, I just added a big chunk of code to imcc. The code does two main things: - changes imcc syntax to disallow newlines within ops. You can still have all the newlines you want between ops and after labels, but this: if $P1 goto label will no longer work. Since no one app

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

> It currently works on my version of MSVC with nmake and friends. A few > minutes ago, it worked on cygwin/GCC as well. Unfortunately, I broke > something, I'm not sure what, and it doesn't work on cygwin anymore. I'm > going to sleep now, and will probably pick up again on this tomorrow > night.

[PATCH] POD TITLE blocks

www.parrotcode.org/docs seems to like them, so here they are. This rolls in the byteorder.dev patch previously submitted. (I see in the patch that we're not consistent with what a line ending should be. I've left that alone.) -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com) Index: intro.

[PATCH?] File deletion

How does one patch a file to delete? docs/a5_draft.html can go away now, thank you for playing. -- Bryan C. Warnock bwarnock@(gtemail.net|raba.com)

[PATCH] byteorder.dev

The web conversion (www.parrotcode.org/docs) results in a blank page as this file isn't PODified. Patch remedies. (I forget whether attachments are verboten or preferred - I can't seem to find any included documentation on how to submit patches. I should probably add that to the list of things

Re: rule, rx and sub

On Mon, 26 Aug 2002, Glenn Linderman wrote: : Damian Conway wrote: : > For an C without modifiers, (...) are certainly unambiguous as delimiters. : > So I think they should be allowed. Of course, it's Larry's call and he may : > well prefer the simplicity of a blanket prohibition. : : So one thin

Re: is MANIFEST up-to-date?

On Mon, 26 Aug 2002, Andy Dougherty wrote: > Currently, a fresh checkout of the cvs tree contains 2215 files, but only > 497 of them are listed in MANIFEST. Most are the icu/ files, but there > are scattered others as well. I'm unsure if all of them are supposed > to be in MANIFEST yet (e.g. is

is MANIFEST up-to-date?

Currently, a fresh checkout of the cvs tree contains 2215 files, but only 497 of them are listed in MANIFEST. Most are the icu/ files, but there are scattered others as well. I'm unsure if all of them are supposed to be in MANIFEST yet (e.g. is icu a work-in-progress?) but could those who have

Re: rule, rx and sub

On Mon, 26 Aug 2002, Glenn Linderman wrote: > because the rules and patterns are no longer regular, but if rx isn't a > short form of regex, what is it a short form of? It's a short form of "r$x" for some value of "$x" ;). /s

Re: rule, rx and sub

Glenn Linderman asked: > So one thing that bothers me in the whole discussion of rule vs rx > differences and similarities, is that there was a previous discussion > that said "regular expression" and "regex" should be deprecated terms > because the rules and patterns are no longer regular, but i

Re: rule, rx and sub

Damian Conway wrote: > For an C without modifiers, (...) are certainly unambiguous as delimiters. > So I think they should be allowed. Of course, it's Larry's call and he may > well prefer the simplicity of a blanket prohibition. So one thing that bothers me in the whole discussion of rule vs rx

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN isnever defined

On Mon, 26 Aug 2002, Markus Laire wrote: > On 25 Aug 2002 at 23:01, Sean O'Rourke wrote: > > > Ah, _parser_ tests! (hits self on head). Those are out-of-date, and > > should be disabled. The fact that all the compiler tests pass is a > > relief, and indicates that all is well. How does t/rx/bas

Re: DOD etc

On Mon, 26 Aug 2002, Nicholas Clark wrote: > All ways of doing deterministic destruction seem to have considerable > overhead. One possible alternative would be to have file handles and other objects with destructors that have to be called in a timely fashion keep ref-counts. When the refcount d

[perl #16772] [PATCH] Add format for UINTVAL

# New Ticket Created by Jason Gloudon # Please include the string: [perl #16772] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=16772 > This adds the printf format string for UINTVAL. hash.c needs this, but I'm not includ

Re: [perl #16741] languages/parrot_compiler fixups

On Sun, 25 Aug 2002, Mike Lambert wrote: > # New Ticket Created by Mike Lambert > # Please include the string: [perl #16741] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=16741 > > > > The below patch fixes the languages

Re: [perl #16767] [PATCH] pdb improvements

On Mon, 26 Aug 2002, Steve Fink wrote: > # New Ticket Created by Steve Fink > # Please include the string: [perl #16767] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=16767 > > > > - eliminates a bunch of seg faults from

Re: rule, rx and sub

Luke Palmer wrote: > Hang on... I thought parens weren't allowed as delimiters. Or does that > not apply to rx()? Well, yes, we *did* say that in A5 and E5. But we were thinking of m// and s/// in particular and of patterns with modifiers (which might take argument lists) in general. For an

Re: rule, rx and sub

> > The only extra piece of syntactic sugar that C is giving us over > > C[*] is the ability to have arbitrary delimiters. > > Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or > parens. Aww, no alphanumerics anymore. That's too bad; it was so nice in poetry to be able to wri

Re: rule, rx and sub

>>Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or >>parens. > > Of course. I didn't want to poison my entire sentence with footnotes > for the obvious exceptions. Yes. It wasn't directed at you particularly, but at those for whom the exception isn't obvious. The problem bei

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

On 26 Aug 2002 at 13:48, Leopold Toetsch wrote: > > I got new cvs and applied same 2 patches (dlopen-patch & imcc-patch) > > only t/rx/basic.{3,4} fails, both with same error: > > Please rebuild the grammar (there is currently no Makefile autmagic for > this): > > $ perl6 --force -v --tree --

Re: Dynamic keys

In message Dan Sugalski <[EMAIL PROTECTED]> wrote: > Have you taken a look at the proposed ops in PDD6? They may not be > what we ultimately want to use, but it might be a place to start. > (And I'd rather avoid generic vtable access to keys if at

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

Markus Laire wrote: > On 25 Aug 2002 at 23:01, Sean O'Rourke wrote: > I got new cvs and applied same 2 patches (dlopen-patch & imcc-patch) > > only t/rx/basic.{3,4} fails, both with same error: Please rebuild the grammar (there is currently no Makefile autmagic for this): $ perl6 --force -

Re: rule, rx and sub

> > The only extra piece of syntactic sugar that C is giving us over > > C[*] is the ability to have arbitrary delimiters. > Not quite arbitrary. Alphanumerics aren't allowed, nor are colon or > parens. Of course. I didn't want to poison my entire sentence with footnotes for the obvious excepti

Re: E5: questions

Markus Laire asked: > So, would this be right short explanation: > > o: backtrack fails preceding atom (as atom fails, it's skipped) > o:: backtrack fails surrounding group (OK) > o::: backtrack fails rule (OK) > obacktrack fails whole match > > S

Re: rule, rx and sub

Debbie Pickett wrote: > So . . correct me if I'm wrong . . . > > C allows us to define both named and anonymous rules, Yes. > depending on context. Depending on whether or not you provide a name. > C allows us to define only anonymous rules. Yes. And they can't take parameter lists. > C

Re: Dynamic keys

At 10:56 AM +0100 8/26/02, Tom Hughes wrote: >The one part of the keyed access puzzle that my last patch did not >attempt to address is that of constructing keys dynamically. > >As things stand you can create a key PMC and you can set the value >of that PMC to a given integer, number, string or PM

Dynamic keys

The one part of the keyed access puzzle that my last patch did not attempt to address is that of constructing keys dynamically. As things stand you can create a key PMC and you can set the value of that PMC to a given integer, number, string or PMC value. What you can't do is join several key PMC

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

On 25 Aug 2002 at 23:01, Sean O'Rourke wrote: > Ah, _parser_ tests! (hits self on head). Those are out-of-date, and > should be disabled. The fact that all the compiler tests pass is a > relief, and indicates that all is well. How does t/rx/basic.t do? I got new cvs and applied same 2 patches

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

Markus Laire wrote: > I just checked all failed tests. Worst problem seems to be that tests > returns int/str instead of PerlInt/PerlString > > t/parser/apoc1.t 1 256 11 100.00% 1 parser test's are currently broken due to changes in the Parser and should be disabled in t/

Re: [perl #16755] imcc requires Parrot_dlopen but HAS_DLOPEN is never defined

> > "make shared" dies with 'missing .h files' > > More competent and/or Windows-savvy hands than mine are working on this as > we speak. I believe the proper term is stubbornly persistent. Attached is a patch to fix up parrot shared-libraries, imcc, and perl6 all to work on win32. It currently

Re: DOD etc

How does this work? 1 my $fh = IO::File->new(...); # Compiler can know that the new object is still linked. 2 &some_sub ($fh); # Who knows? :-) # Compiler will assume that new object is still linked. 3 undef $fh; # Er? Need a DOD run right now, because that may have been the las

Re: A few thoughts on inheritance

On Sat, Aug 24, 2002 at 09:57:17PM -0400, Chris Dutton wrote: > We are supposedly going to be able to set a class to be > "uninheritable". Err, I believe the result of that discussion was that unihertiable classes is a Bad Idea and very easy to work around using delegation. http:[EMAIL PROTECT