Luke Palmer <[EMAIL PROTECTED]> writes:
>> From: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
>> Date: Tue, 15 Oct 2002 14:33:28 -0400
>
> I like the idea of this. The finer details, like returning what to
> do, could be more elegant. But the extensibility idea is golden.
>
>> To change how certain e
--
On Mon, 21 Oct 2002 16:49:57
Dan Sugalski wrote:
>
>Almost. At least perl 5's macros look like C. Emacs' macro horrors
>make C look like Lisp...
This is because C is _clearly_ a dialect of Lisp . . .
-Erik
>--
> Dan
>
>-
On Tue, 22 Oct 2002, Erik Steven Harrison wrote:
: On Mon, 21 Oct 2002 16:49:57
: Dan Sugalski wrote:
: >
: >Almost. At least perl 5's macros look like C. Emacs' macro horrors
: >make C look like Lisp...
:
: This is because C is _clearly_ a dialect of Lisp . . .
Yeah, look at all the extra p
Dan Sugalski wrote:
For the moment, I'd rather things stay the way they are. If we can
produce demonstrable speed wins, then I'll change my mind.
I have some preliminary numbers:
- changed core.ops to include add_keyed [1]
- did implement add_keyed_int in array
- hacked set_pmc_keyed_int()
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Okay, I'm about ready to just bite the bullet and declare that
> INTVALs have to be 64 bit integers.
>
> Does anyone know of a platform that has neither native nor emulated
> 64 bit integers? (One we're likely to run on, rather)
I'm fairly new to Parrot
On Mon, 21 Oct 2002, Clinton Pierce wrote:
> * With bad arguments, the assembler returns 1 to the OS. Peachy.
Please can we have...
#include
exit(EX_USAGE); // 64 on most platforms
> * Upon failure, the assembler returns the status 0 to the OS and writes
> some bytecode. No telling how
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Dan Sugalski wrote:
>
> > At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
>
>
> >> With an approach like this, we could cut down the VTABLE to roughly
> >> 1/3 of it's current size. The _keyed entrys would only consist of
> >> the set_.._keyed{,_i
If memory serves me right, Piers Cawley wrote:
/me is a newcomer from DotGNU ... and has missed the mails quoted,
hence here's what I have ..
> Regarding JVM - Parrot Compatibility
> Newcomer Karthik Kumar is interested in writing a tool to convert java
> ".class" files to parrot ".
Juergen Boemmels wrote:
Leopold Toetsch <[EMAIL PROTECTED]> writes:
No, take the "new px, .PerlUndef" out of the opcode, it must only be
done once. This temporary Px can be reused by _all_ _keyed ops.
Im not sure about this. This really depends on the fact if the
op does something depending
At 3:59 PM -0700 10/21/02, Brent Dax wrote:
Dan Sugalski:
# Okay, I'm about ready to just bite the bullet and declare that
# INTVALs have to be 64 bit integers.
#
# Does anyone know of a platform that has neither native nor emulated
# 64 bit integers? (One we're likely to run on, rather)
Mac Clas
# New Ticket Created by Matthew Zimmerman
# Please include the string: [perl #18054]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18054 >
These changes to the root .cvsignore and to the MANIFEST fix
two file accounting is
At 6:25 PM -0400 10/21/02, Bryan C. Warnock wrote:
On Mon, 2002-10-21 at 15:11, Dan Sugalski wrote:
Okay, I'm about ready to just bite the bullet and declare that
INTVALs have to be 64 bit integers.
Which INTVALs?
I registers.
INTVAL, IMHAOSBRPO[1], is overused internally.
I see little re
# New Ticket Created by Jürgen Bömmels
# Please include the string: [perl #18056]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18056 >
This patch is the beginning of an effort to make PackFile format
extendible. At the mo
Martin D Kealey wrote:
> I was wondering if anyone else followed the discussion in comp.std.c about
> integer types, prior to the adoption of the C99 standard? There was a
> substantial paper put out by Frank Farance, entitled "specification based
> extended integer range" or SBEIR for short; see
On Tue, Oct 22, 2002 at 05:34:18PM +, Matthew Zimmerman wrote:
> # New Ticket Created by Matthew Zimmerman
> # Please include the string: [perl #18054]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=18054 >
>
>
> Th
On Thu, Oct 17, 2002 at 02:51:24PM +0200, Leopold Toetsch wrote:
> Steve Fink wrote:
>
>
> >I don't know exactly who has the permissions to do these things, but
> >I'm pretty sure that if you have commit access then you also have RT
> >futzing access.
>
> I tried to set the status of my patches
On Mon, Oct 14, 2002 at 11:06:05PM +, J?rgen B?mmels wrote:
> # New Ticket Created by J?rgen B?mmels
> # Please include the string: [perl #17936]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17936 >
>
>
> There ar
On Sep-22, Bruce Gray wrote:
> # New Ticket Created by Bruce Gray
> # Please include the string: [perl #17502]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17502 >
>
>
> To specify a rule to build object files from C
On Sep-22, Bruce Gray wrote:
> # New Ticket Created by Bruce Gray
> # Please include the string: [perl #17506]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=17506 >
>
>
> lib/Parrot/Configure/Step.pm, in sub cc_clean,
On Oct-08, Dakkar wrote:
> I discovered the problem:
>
> print "Yes r\n" if "0" =~ /0/;
> print "Yes s\n" if "0" =~ "0";
>
> printed only "Yes s"
>
> The problem is NOT in the RE engine, but in the string literal code in
> P6C/Tree/String.pm
>
> I replaced some "if ($stuff)" with "if (defin
On Oct-22, Steve Fink wrote:
> On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote:
> > The last one looks like a fundamental problem in MultiArray.
> > The line
> > b->cell_buffer = new_buffer_header(interpreter);
> > in function new_marray is creating a new buffer header, overwriting
> >
On Oct-19, Bryan C. Warnock wrote:
> On Fri, 2002-10-11 at 15:19, Erik Lechak wrote:
>
> Almost got to this one within a week! ;-)
>
> >
> > 2) When I reply should I 'reply to all' or just reply to
> > perl6-internals? (This is my first mailing list)
>
> I know Dan addressed part of this in
The Perl 6 Summary for the week ending 20021020
I'm sorry to have to inform you that I've returned from my holiday (no,
base jumping and paragliding were *not* involved) and that this week's
summary will not be written by the estimable Leon Brocard. Sorry about
that. Leon is current
23 matches
Mail list logo
