I have checked in various changes, cleanups, enhancements:
- classes/default.pmc: 2 step hash creation for properties
- classes/pmc2c.pl: --tree options prints classes hierarchy, missing
constand_FLAG for classnames
- list.h/list.c: move flags out of buffer header
- remove uninitialized warning fo
Dan Sugalski wrote:
At 4:17 PM + 1/9/03, Nicholas Clark wrote:
On Thu, Jan 09, 2003 at 01:32:57PM +0100, Leopold Toetsch wrote:
But I still favor the combination of:
- code reordering, like done for pmc_new
- DOD/GC disabling (e.g. aggregate clone)
- active anchoring to the root set,
On Thu, Jan 09, 2003 at 04:29:19PM +, Matthew Zimmerman wrote:
> # New Ticket Created by Matthew Zimmerman
> # Please include the string: [perl #19870]
> # in the subject line of all future correspondence about this issue.
> # http://rt.perl.org/rt2/Ticket/Display.html?id=19870 >
>
>
> A
On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
> #10 We do MI, but we don't instantiate a class' attributes multiple
> times if its in the hierarchy for a class more than once. If it is, the
> leftmost instance is real, the rest are virtual
This will mean we can't support Eiffel, which
$ ./getparrot
can't create temporary directory /tmp/cvs-serv3864
No space left on device
On Jan-10, Leopold Toetsch wrote:
> Also I was thinking of: trace_system_areas could be run last in marking
> and if it finds some unanchored objects, it could print a warning, so we
> could really check, if we ware safe.
That's what defining GC_VERBOSE in parrot.h will give you right now,
and i
On Jan-09, Leopold Toetsch wrote:
> I have here now ~15 files different to CVS, which I would like to sync
> in either direction for easier future changes.
> So the question is, should I checked it in / partially / forget it.
>
> Changes are:
> - SPMC (small or scalar PMC) with half the size of a
Leopold Toetsch wrote:
> $ ./getparrot
> can't create temporary directory /tmp/cvs-serv3864
> No space left on device
Oops.
Fixed.
-R
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
>> #10 We do MI, but we don't instantiate a class' attributes multiple
>> times if its in the hierarchy for a class more than once. If it is,
>> the leftmost instance is real, the rest are virtual
My only question here is: What is leftmos
At 1:37 PM + 1/10/03, Peter Haworth wrote:
On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
#10 We do MI, but we don't instantiate a class' attributes multiple
times if its in the hierarchy for a class more than once. If it is, the
leftmost instance is real, the rest are virtual
At 10:37 AM -0500 1/10/03, attriel wrote:
> On Thu, 9 Jan 2003 16:40:20 -0500, Dan Sugalski wrote:
#10 We do MI, but we don't instantiate a class' attributes multiple
times if its in the hierarchy for a class more than once. If it is,
the leftmost instance is real, the rest are virtual
My
I did check in the clone changes.
- the clone vtable method get's now a dest ptr of an already created PMC
- so the newly created PMC is already anchored, which makes it possible
to change clone() code, so that no unanchored objects hang around, which
still is a TODO for more complex objects
- do
Steve Fink wrote:
On Jan-09, Leopold Toetsch wrote:
So the question is, should I checked it in / partially / forget it.
Changes are:
- SPMC (small or scalar PMC) with half the size of a PMC, no promotion
or whatever to a PMC, disabled with one define in pmc.c
- pool flags with aligned pools,
Steve Fink wrote:
On Jan-10, Leopold Toetsch wrote:
Also I was thinking of: trace_system_areas could be run last in marking
and if it finds some unanchored objects, it could print a warning, so we
could really check, if we ware safe.
That's what defining GC_VERBOSE in parrot.h will give you
Dan Sugalski wrote:
> and who's got
> questions on how this works? (I can put together examples, but this
> is pretty long as it is, and I think it's reasonably
> self-explanatory. Besides, assembly language isn't generally the best
> way to demonstrate anything... :)
Well, as far as I'm concerned
On Friday, January 10, 2003, at 11:49 AM, Dan Sugalski wrote:
At 1:37 PM + 1/10/03, Peter Haworth wrote:
This will mean we can't support Eiffel
Nope. :)
What it means is that the proposed base object system won't work for
eiffel.
Actually, if you really want Eiffel to compile to Parrot,
> -Original Message-
> From: Leopold Toetsch [mailto:[EMAIL PROTECTED]]
>
> Further remark: the scratchpad clone code looks dubious, the 2 lists in
> the data (lex) entry should probably cloned too - and at least the lex
> ptrs themselves.
> The destroy method leaks, because we can't cleanu
Here are some examples from Object Oriented Software Construction (Second
Edtion), Chapter 15 (Multiple Inheritance):
* Simple multiple inheritance:
class PLANE ...
class ASSET ...
class COMPANY_PLANE inherit PLANE ASSET ...
or
class TREE [G] ... -- Param
The attached patch fixes the problem. It changes Scratchpad's data pointer
to be a pointer to an array of Parrot_Lexicals (rather than an array of
pointers to Parrot_Lexicals). The (name and value) lists are shared but
never the actual Parrot_Lexical ptr. So no more leak.
Patch touches:
-- class
On Jan-10, Leopold Toetsch wrote:
>
> You get double the amount of PMCs into the cache - used during marking
> and freeing. It isn't related to alignment, just more throughput.
Oh. You're right. I was thinking that the unused portion of the PMC
wouldn't need to be loaded into the cache, so that
If memory serves me right, Chris Dutton wrote:
> Actually, if you really want Eiffel to compile to Parrot, it might be
> interesting to work on getting ANSI C to compile to Parrot first, since
> most Eiffel compilers use compilation to C as an intermediate step.
This won't be too much of stretch
21 matches
Mail list logo
