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
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
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
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
> -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
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,
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
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
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,
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
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
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
> 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
Leopold Toetsch wrote:
> $ ./getparrot
> can't create temporary directory /tmp/cvs-serv3864
> No space left on device
Oops.
Fixed.
-R
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
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
$ ./getparrot
can't create temporary directory /tmp/cvs-serv3864
No space left on device
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
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
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,
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
21 matches
Mail list logo
