Mike Lambert wrote:
> ... Attached patch gets IMCC building on MSVC without
> cygwin (lex/bison/yacc/etc).
Good.
> t/rx/basic.t 2 512 52 40.00% 3-4
> t/rx/call.t1 256 21 50.00% 2
>
> Any idea on how to go about fixing the rx ones? They're failing on
> i
The 'DEVELOPING' file accidentally made its way into the MANIFEST, but
doesn't actually exist in the tarball. It's not a problem, as you can
delete the appropriate line in the MANIFEST and continue, but given the
large file size I thought I should alert you. 0.0.8.1 is being uploaded
at the moment
Ooo I need your code, babe
Guess you know it's true
Hope you need this build babe
Just like I need you
-- Apologies to John Lennon
(alternate codename: Octarine)
News collected from Piers Cawley's excellent summaries:
Working Perl6 REs
Multidimensional keyed access
JIT for the ARM
Lexical scope
> > Is there any fundamental reason why we *cannot* just enter a generated
> > imcparser.c and imcparser.h into CVS and save users the step of building
> > them on these platforms?
>
>
> Ack, so we should just delete the lines:
> imclexer.c
> imcparser.c
> imcparser.h
>
> from .cvsignore
Yep, alt
> "DW" == David Wheeler <[EMAIL PROTECTED]> writes:
DW> On Sunday, September 1, 2002, at 05:30 AM, Damian Conway wrote:
>> Sure. But the right solution is to permanently eliminate the
>> sesquipedalian
>> name (so you don't have to retype it for every single typed variable):
>>
Markus Laire wrote:
>
> > Codename Octarine
> >
> > Schedule as follows:
> >
> > August 29, 8am EDT: Code slush, only bug and warning fixes allowed.
> > August 30, 11:59pm EDT: Code freeze and pretag
> > August 31, 00:59 EDT: Tag and Release
>
> Is there any reason to not to use GMT times in gen
> And, furthermore, that you could easily define special semantics
> for void-context constructor calls via undef'd but typed variables,
> so that you could just write:
>
> (my Date $date).new('June 25, 2002');
>
> and have the interpreter autovivify the object.
That's pretty close to wha
On Sunday, September 1, 2002, at 05:30 AM, Damian Conway wrote:
> Sure. But the right solution is to permanently eliminate the
> sesquipedalian
> name (so you don't have to retype it for every single typed variable):
>
> class Date is Really::Long::Package::Name::Ugh;
Oh, that's nice. As
> "SC" == Simon Cozens <[EMAIL PROTECTED]> writes:
SC> [EMAIL PROTECTED] (Damian Conway) writes:
>> > hashes can now take objects as keys and won't just stringify them.
>>
>> Correct. But I believe that's only if the hash has a property that marks
>> its keys as being objects, not
The thing I'd like to do right now is turn on :w
for all rules. A Fortran grammar might want to turn
on :i for all rules.
Maybe add modifiers to the grammar declaration?
grammar Fortran :i { ... }
It would also be convenient to allow the :w
modifier to have lexically scoped behavior so a
gra
[EMAIL PROTECTED] (Damian Conway) writes:
> > hashes can now take objects as keys and won't just stringify them.
>
> Correct. But I believe that's only if the hash has a property that marks
> its keys as being objects, not strings:
>
> my %hash is keyed(REF);
>
> And, even if that's the d
David Wheeler wrote:
> Yes, but this:
>
>my Really::Long::Package::Name::Ugh $date is now {.init 'June 25,
> 2002' };
>
> Is shorter than this:
>
> my Really::Long::Package::Name::Ugh $date =
>Really::Long::Package::Name::Ugh.new( 'June 25, 2002' );
>
> It's not the short package nam
Uri Guttman wrote:
> but what simon was saying (and i agree) is the the pair IS a single
> item. it becomes the key and its value is 'scalars'.
No. If it's a PAIR, then its key is the key and its value is the value.
> hashes can now take objects as keys and won't just stringify them.
Correct.
Mike Lambert wrote:
> Is there any fundamental reason why we *cannot* just enter a generated
> imcparser.c and imcparser.h into CVS and save users the step of building
> them on these platforms?
Ack, so we should just delete the lines:
imclexer.c
imcparser.c
imcparser.h
from .cvsignor
> Mik
Steven W McDougall wrote:
> The align_1 parameter to mem_allocate() does not--as you might
> think--control the alignment of the allocated block. Rather, it
> controls the *size* of the allocated block, rounding it up to the next
> multiple of the power of 2 indicated by align_1. This means that
15 matches
Mail list logo
