Andrà Pang writes:
> On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote:
>
> >3) The copying collector isn't integrated yet. But that should be easy.
> >After finishing sweep and if there is some possible wastage in the
> >memory pools, these get compacted.
>
> I thought Parrot wasn't using copying
On 21/08/2004, at 5:48 AM, Leopold Toetsch wrote:
3) The copying collector isn't integrated yet. But that should be easy.
After finishing sweep and if there is some possible wastage in the
memory pools, these get compacted.
I thought Parrot wasn't using copying collectors, since you're exposing
PM
Dan Sugalski wrote:
Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote:
Examples from the 2th aoudad book (page 127) did not
turn out as expected. Being completely new to this,
I did not know where to put the testcode.
And now the
Well, after I had something that made comparing
differences easier, I reverted back CVS. While I
noticed a speed difference, it was very minor which
means the significant speed bump is likely related to
something non-parrot related. I am going to rebuild
the latest/greatest gcc on Monday to see i
Dan Sugalski wrote:
As part of the DOD/GC rework, we need to have a clean, well-documented
API for the garbage collector. Things were clean, though not documented,
for the original DOD and things have gotten significantly messier since.
First is of course one of the goals of these changes. Second
At 9:36 PM +0200 8/20/04, Leopold Toetsch wrote:
Dan Sugalski <[EMAIL PROTECTED]> wrote:
At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote:
Examples from the 2th aoudad book (page 127) did not
turn out as expected. Being completely new to this,
I did not know where to put the testcode.
And n
At 9:48 PM +0200 8/20/04, Leopold Toetsch wrote:
0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD"
subsystem is the stop-the-world mark & sweep collector that recycles
object headers. The "GC" is the copying collector for variable sized
string and other buffer memory.
The incrementa
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> On Fri, 20 Aug 2004 16:26:33 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
>> And yes, I'm really thinking of inserting these A* nodes. Freezing an
>> object does need it. DOD of course not really.
> How is space going to be made for these? DOD
[ Oops that one got the wrong address, resent ]
Original Message
To: perl6-internals-subscribe ...
Some remarks
0) Parrot's nomenclature DOD vs GC is a bit misleading. The "DOD"
subsystem is the stop-the-world mark & sweep collector that recycles
object headers. The "GC" is t
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote:
>>Examples from the 2th aoudad book (page 127) did not
>>turn out as expected. Being completely new to this,
>>I did not know where to put the testcode.
> And now the test's in. Thanks!
And fails with
Joshua Gatcomb <[EMAIL PROTECTED]> wrote:
> I recently noticed that the benchmarks in
> examples/benchmarks was running significantly slower.
That might very likely be related to current patches WRT garbage
collection. I've turned off ARENA_DOD_FLAGS, which was on since quite a
time. Turning that
Joshua Gatcomb wrote:
I recently noticed that the benchmarks in
examples/benchmarks was running significantly slower.
I update Cygwin and Parrot daily - so there have been
a lot of changes to account for. I idly asked on IRC
if anyone was regularly tracking benchmark performance
because I was fee
As part of the DOD/GC rework, we need to have a clean,
well-documented API for the garbage collector. Things were clean,
though not documented, for the original DOD and things have gotten
significantly messier since.
Part of the point of the GC/DOD rework is to allow alternate GC
implementatio
Leo~
On Fri, 20 Aug 2004 16:26:33 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> And yes, I'm really thinking of inserting these A* nodes. Freezing an
> object does need it. DOD of course not really.
How is space going to be made for these? DOD probably does not want
to allocate the dummy
I recently noticed that the benchmarks in
examples/benchmarks was running significantly slower.
I update Cygwin and Parrot daily - so there have been
a lot of changes to account for. I idly asked on IRC
if anyone was regularly tracking benchmark performance
because I was feeling lazy.
Dan said n
At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote:
Examples from the 2th aoudad book (page 127) did not
turn out as expected. Being completely new to this,
I did not know where to put the testcode.
And now the test's in. Thanks!
--
Dan
---
Matt Fowles <[EMAIL PROTECTED]> wrote:
> Leo~
> Nice summary of the issues, but I have a few nits to pick
Thanks. I'll only look at DFS. It more cache-friendly.
> Thus I don't think that BFS works. Now lets consider DFS of both sets.
> A refs C,B; B refs D, E; C refs E; D refs G; E refs A
Dan Sugalski wrote:
print 0X2A
Fixed.
leo
Dan Sugalski <[EMAIL PROTECTED]> wrote:
>> print 0x2A
>> print "\n"
>> print 0X2A
>
> on this line.
> Leo, any reason to be case sensitive on this stuff you can think of?
Nah. Not really. The lexer evolves, as it did with float parsing. And
all untested stuff doesn'
Dan~
Sounds good. I will start on that, but don't hold your breath as it
may take a little while. I will try to keep abreast of current CVS.
Matt
On Fri, 20 Aug 2004 10:37:14 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 10:12 AM -0400 8/20/04, Matt Fowles wrote:
> >Dan~
> >
> >Just a fe
At 10:12 AM -0400 8/20/04, Matt Fowles wrote:
Dan~
Just a few small questions about scons to clarify...
On Fri, 20 Aug 2004 09:16:24 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
Whatever we use is fine as long as:
a) We can edit the dependency file without having to know the
language the tool'
On Fri, 20 Aug 2004 14:56:25 +0100, Simon Wistow <[EMAIL PROTECTED]> wrote:
> Interesting - I wrote Python::Serialise::Marshal in May last year to
> snarf Mailman config files and I didn't realise it was so close to
> Python bytecode.
Mailman config files ARE python bytecode -- they're just python
Since I need this, and need to get it done reasonably soon, I'm
spec'ing out the syntax of the charset and encoding files.
Since there's been no more complaint or discussion, I'm taking the
encoding and charset APIs proposed as acceptable, with the caveat
that my docs suck and are going to be p
Dan~
Just a few small questions about scons to clarify...
On Fri, 20 Aug 2004 09:16:24 -0400, Dan Sugalski <[EMAIL PROTECTED]> wrote:
> Whatever we use is fine as long as:
>
> a) We can edit the dependency file without having to know the
> language the tool's written in
I believe that scons wil
At 4:16 PM -0700 8/18/04, Will Coleda (via RT) wrote:
# New Ticket Created by Will Coleda
# Please include the string: [perl #31229]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31229 >
Index: build_tools/c2str.pl
Applied,
On Fri, Aug 20, 2004 at 08:38:21AM -0400, Matt Diephouse said:
> That's me. I don't think I ever announced this to the list though. Any
> newbie lurkers can check it out: http://matt.diephouse.com/parrot
"The rest of the bytecode is made up of objects. Objects are preceeded
by a char denoting the
At 4:03 PM +0200 8/17/04, Bernhard Schmalhofer wrote:
currently I'm looking into 'libtool' for turning 'libsyck.a' into a
shared library.
This brings me to the idea, wether it would it be an option to use
'libtool' for library building stuff within parrot.
'libtool' from the commandline seems t
At 3:10 PM -0700 8/16/04, Danny Werner (via RT) wrote:
# New Ticket Created by Danny Werner
# Please include the string: [perl #31197]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org:80/rt3/Ticket/Display.html?id=31197 >
Hi bugtracker,
Examples from the 2
At 10:10 AM -0700 8/17/04, Steve Fink wrote:
Still, I won't commit this patch directly, because I have only
recently delved into the latest incarnation of the keyed code, and it
scares me.
Well, I will. :) It's in, with the test.
--
Dan
--
At 8:29 AM -0700 8/18/04, Dave Whipp wrote:
"Leopold Toetsch" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
Rather not. Python is AFAIK not as portable as Perl. But there is a Perl
based make somewhere, the named just escaped my mind.
We use Makepp (http://makepp.sourceforge.net/) h
Leo~
Nice summary of the issues, but I have a few nits to pick
On Fri, 20 Aug 2004 10:29:28 +0200, Leopold Toetsch <[EMAIL PROTECTED]> wrote:
> a) The mark phase of the garbage collection creates the graph of *all*
> life (reachable) objects[1].
> b) Freezing a PMC creates the graph of reacha
On Fri, 20 Aug 2004 00:05:10 -0700, Steve Fink <[EMAIL PROTECTED]> wrote:
> I know someone else was blogging his initial experiences
> slogging through the Parrot source -- that's where I got the idea,
> though I'm not exactly a newbie around here so I'll be assuming a bit
> more familiarity with t
3) Incremental collection interfers badly with freeze & thaw, at least
if freeze uses the next_for_GC pointer to keep track of duplicates.
OTOH both freezing and creating the graph of live objects during DOD are
basically the same. The problem currently is that chaining objects
together is done
As I prepared to dive into a big area of parrot that I'm completely
unfamiliar with, I decided to log my travels in hopes of helping out
the next poor soul who happens along a similar path.
For now, the focus is on converting my toy languages/regex compiler
into more of a real Perl6-style rule com
34 matches
Mail list logo
