Re: [perl #17159] imcc / Mac OS X problem

Kevin Falcone wrote: >>"LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes: >> > > LT> Leon Brocard (via RT) wrote: > >>># New Ticket Created by Leon Brocard # Please include the string: >>>[perl #17159] > LT> Either remove -fno-common or do something like this: > > Apple's perl5.6.0

Re: [PATCH] Re: [perl #17091] 64-bit-int builds broken

On Tue, Sep 10, 2002 at 07:53:10PM +0100, Nicholas Clark wrote: > On Tue, Sep 10, 2002 at 12:08:31PM -0400, Andy Dougherty wrote: > > This won't necessarily work if sizeof(INTVAL) != sizeof(INT). (And since > > the prototypes are hidden in the C file, not in a shared header file, the > > compiler

Re: [perl #17159] imcc / Mac OS X problem

> "LT" == Leopold Toetsch <[EMAIL PROTECTED]> writes: LT> Leon Brocard (via RT) wrote: >> # New Ticket Created by Leon Brocard # Please include the string: >> [perl #17159] >> # in the subject line of all future correspondence about this >> issue. # http://rt.perl.org/rt2/Ticket/Display.html

Re: [perl #17159] imcc / Mac OS X problem

Leon Brocard (via RT) wrote: > # New Ticket Created by Leon Brocard > # Please include the string: [perl #17159] > # in the subject line of all future correspondence about this issue. > # http://rt.perl.org/rt2/Ticket/Display.html?id=17159 > > > > There is a problem building imcc under Mac

[perl #17159] imcc / Mac OS X problem

# New Ticket Created by Leon Brocard # Please include the string: [perl #17159] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17159 > There is a problem building imcc under Mac OS X at the moment, but I'm afraid I don't k

[perl #17158] [PACTH] reduce size of core_ops_prederef.* by a fair amount

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #17158] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17158 > This patch eliminates identical function bodies in core_ops_prederef.* thus saving

Re: [RFC] building core.ops op_hash at runtime

Nicholas Clark wrote: > On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote: > I like this idea. (but I've no idea of the subtle implications) There are only PDB_eval, pxs.c and imcc as users currently, I can't really see subtle implications whatsoever. > Where you thinking of b

[RFC] move op_info_table out of core_ops*

While I'm already at oplib, interpreter and predereferenced code, I've another one: Currently we have 3 incarnations of one core.ops: - core_ops.c - core_ops_cg.c - core_ops_prederef.c While the 1st and the the 3rd have an op_info_table (and and op lib descriptor, core_ops_cg.c doesn't has the

Re: [RFC] building core.ops op_hash at runtime

On Wed, Sep 11, 2002 at 12:50:28PM +0200, Leopold Toetsch wrote: > The op_code() function in op_lib_t does look up an op_info_table entry > by the op's full_name. To accomplish this, the current implementation > builds via ops2c.pl basically a static hash table, which get's appended > to core_o

[perl #17143] [PATCH] interpreter.c:prederef()

# New Ticket Created by Leopold Toetsch # Please include the string: [perl #17143] # in the subject line of all future correspondence about this issue. # http://rt.perl.org/rt2/Ticket/Display.html?id=17143 > This patch make predereferenced run mode working again (all perl6 tests are ok, whe

[RFC] building core.ops op_hash at runtime

The op_code() function in op_lib_t does look up an op_info_table entry by the op's full_name. To accomplish this, the current implementation builds via ops2c.pl basically a static hash table, which get's appended to core_ops.c and core_ops_prederef.c. My proposal is: build a hash table at runt