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 exceptions
--
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
On Mon, Oct 21, 2002 at 08:05:32PM +0200, Peter Gibbs wrote:
Steve Fink wrote:
I currently get three test failures when running with GC_DEBUG on, but
not always the same three (depending on how I muck with unrelated
parts of the code.)
On my system I get failures with op/string.t tests
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
the new_bufferlike_header created earlier.
I
Juergen Boemmels wrote:
Leopold Toetsch [EMAIL PROTECTED] writes:
What happens if you try to use it on an object which has no real
components like a bitvector or a packed structure?
The substituted code for an aggregate is:
set Py, P1[k1]
and for a non keyed operand:
set Py, {N,S,I}1
Dan Sugalski wrote:
Copying is the right thing to do here. If the compiler wants to put
copies of things into an aggregate, it can make copies first.
Ok, fine. I'll update comments WRT clone.
leo
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{,_int} variants plus exists_keyed and defined_keyed. And,
we would
Dan Sugalski wrote:
For plain PerlHash PMCs, yes, they should be PMCs only. The union went
into them in a fit of enthusiasm and generality. :) More specialized
aggregates can hold more specialized things, but I'm not sure we're
going to have a need for something that really efficiently holds
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
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, but
On Mon, 21 Oct 2002, Clinton Pierce wrote:
* With bad arguments, the assembler returns 1 to the OS. Peachy.
Please can we have...
#include sysexits.h
exit(EX_USAGE); // 64 on most platforms
* Upon failure, the assembler returns the status 0 to the OS and writes
some bytecode. No
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{,_int} variants
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 .pbc
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 on
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
# New Ticket Created by Matthew Zimmerman
# Please include the string: [perl #18054]
# in the subject line of all future correspondence about this issue.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18054
These changes to the root .cvsignore and to the MANIFEST fix
two file
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
# 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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18056
This patch is the beginning of an effort to make PackFile format
extendible. At
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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=18054
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 to
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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17936
There are
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.
# URL: 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.
# URL: http://rt.perl.org/rt2/Ticket/Display.html?id=17506
lib/Parrot/Configure/Step.pm, in sub cc_clean, is
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 (defined $stuff) and now it
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
the
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
28 matches
Mail list logo
