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:
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 ne
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
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
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 earlie
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
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? INTVAL, IMHAOSBRPO[1], is overused internally.
I see little relative performance and size damage if INTVAL is made 64
bits and re
Bryan C. Warnock sent the following bits through the ether:
> Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe
> for floating point numbers?
For the JVM:
http://java.sun.com/docs/books/vmspec/2nd-edition/html/Concepts.doc.html#19511
"The floating-point types are float and
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 Classic processors and Palm DragonBalls?
By t
At 10:35 PM +0100 10/21/02, Nicholas Clark wrote:
On Mon, Oct 21, 2002 at 04:54:48PM -0400, Dan Sugalski wrote:
At 9:27 PM +0100 10/21/02, Nicholas Clark wrote:
>On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote:
>
>> I'm currently committing the new splice vtable method for arr
"Jürgen" "Bömmels" (via RT) <[EMAIL PROTECTED]> writes:
> # 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 are again
On Mon, Oct 21, 2002 at 04:54:48PM -0400, Dan Sugalski wrote:
> At 9:27 PM +0100 10/21/02, Nicholas Clark wrote:
> >On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote:
> >
> >> I'm currently committing the new splice vtable method for array classes.
> >> And finally, PMCs are currently
At 7:21 PM +0530 10/20/02, Gopal V wrote:
If memory serves me right, Bryan C. Warnock wrote:
> It looks like we're going to need 8,16,32,64 bit types...
Interesting read. Dan skimmed over this, but what do .NET (and JVM) doe
for floating point numbers?
IL (Ecma-335)
--
134.
# New Ticket Created by Rhys Weatherley
# Please include the string: [perl #18034]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18034 >
The attached patch adds some missing expression node types to the
imcc syntax. In pa
Dan Sugalski wrote:
> I think so. I'm going to add in some conversion ops for the shorter
> float forms, and for the partial-sized integers. I'm unsure at the
> moment whether I want to commit to full 64 bit integers in I
> registers. On the one hand it means a lot more can be done at the low
> le
At 9:27 PM +0100 10/21/02, Nicholas Clark wrote:
On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote:
I'm currently committing the new splice vtable method for array classes.
And finally, PMCs are currently only copied in, not cloned - I don't
know, what is correct.
"clone" is a
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 96 and 97 and
pmc/pmc.t test 76 (aka 75)
The first two can be fix
Leopold Toetsch wrote:
2. Proposal for _keyed opcodes
--
The thread with subject "pdd06_pasm, pdd08_keys: _keyed ops" clearly
showes the shortcomings of the current _keyed opcodes and the
implementation of these.[1]
The 3 operand keyed add @a[$i] = @b[3] + %h{"k"}
>I just wanted to obsolete this Patch, because the missing files now
>have entered the MANIFEST. But bugs6.perl.org only tells me "Permission
>denied". Im logged in, and the bugtracker recognizes this patch as
>mine.
I've tweaked the permissions, try again.
-R
On Mon, Oct 21, 2002 at 03:18:37PM +0200, Leopold Toetsch wrote:
> I'm currently committing the new splice vtable method for array classes.
> And finally, PMCs are currently only copied in, not cloned - I don't
> know, what is correct.
"clone" is a deep copy? whereas "copied" means that another
Leopold Toetsch <[EMAIL PROTECTED]> writes:
> Leopold Toetsch wrote:
>
> > 2. Proposal for _keyed opcodes
> > --
> > The thread with subject "pdd06_pasm, pdd08_keys: _keyed ops" clearly
>
> > showes the shortcomings of the current _keyed opcodes and the
> > implementa
# New Ticket Created by Clinton Pierce
# Please include the string: [perl #18044]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18044 >
* With bad arguments, the assembler returns 1 to the OS. Peachy.
* Upon success,
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)
--
Dan
---
I think, I can answer a few of these questions.
> -Original Message-
> From: Allen Short [mailto:washort@;twistedmatrix.com]
>
> The ops described in PDD 6 and docs/parrot_assembly.pod for
> scratchpads appear to be subtly different from the ones actually in
> core.ops. In particular, i wa
At 5:46 PM +0200 10/21/02, Leopold Toetsch wrote:
Leopold Toetsch wrote:
2. Proposal for _keyed opcodes
--
The thread with subject "pdd06_pasm, pdd08_keys: _keyed ops" clearly
showes the shortcomings of the current _keyed opcodes and the
implementation of these.[1]
I haven't been applying many patches recently, partly because I
haven't had much time available, and partly because there are
gc-related bugs lurking in the code that I regard as higher priority.
I tried tracking them down, but somewhere in the middle I realized
that I really ought to be trying to
At 9:30 AM +0200 10/21/02, Leopold Toetsch wrote:
Jason Gloudon wrote:
The vtable PDD refers to type_keyed returning the type of the *PMC*. This
isn't accurate given the question. Should we change the PDD ?
As we are now (almost) able to generate packed arrays of chars,
shorts , we shou
Rhys Weatherley (via RT) wrote:
# New Ticket Created by Rhys Weatherley
# Please include the string: [perl #18034]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=18034 >
The attached patch adds some missing expression nod
28 matches
Mail list logo
