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
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
> > "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
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/
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
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
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
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
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
> > 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
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 -
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
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 --
>>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
> > 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
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
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
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
# 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
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
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
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
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
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
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
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
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
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
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)
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.
> 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.
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
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"
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
34 matches
Mail list logo