After my posting "Status of my patches" a lot of patches went in -
thanks again to Tom. But now unapplied patches accumulate again e.g.
imcc, perl6 examples ...
So please ...
leo
I did post 3 major proposals for the next big changes in parrot
internals - but I'm lacking somehow final answers on these.
There seems to be a general consens to do these changes though.
So here is a summary of the next changes to parrot:
1) restructure class dependencies
(s. #17352, #173
Peter Gibbs wrote:
> Simon Cozens wrote:
>>Put another loop in, which sets I1 to every array element in turn,
>>(maybe make this an inner loop which runs each time you extend) and
>>re-benchmark.
> 25000: CVS = 47 seconds, grey = 1 second
Please compare to intlist.
leo
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17731]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17731 >
As adviced by Dan, this patch integrates the possibility of using a
Lea-like alloca
Nicholas Clark wrote:
>
> Which in C terms scares me, as *how* can the allocator know for sure?
> Sure it can stack walk, and probe all the CPU registers for pointers to buffers,
> but there are defined C behaviours you can do (such as storing only a pointer
> somewhere into your buffer at fix
On Thu, Oct 03, 2002 at 12:26:53AM -0400, Matt Fowles wrote:
> I don't like Java that much (for many reasons), but I have nothing but
> respect for the massive amount of documentation that is easily accessible as
> a direct result of JavaDoc. I personnaly feel that it greatly helped java
> achiev
> I disagree.
>
> I don't like Java that much (for many reasons), but I have nothing but
> respect for the massive amount of documentation that is easily accessible
as
> a direct result of JavaDoc. I personnaly feel that it greatly helped java
> achieve the success it has. If all of parrot's mod
All~
I disagree.
I don't like Java that much (for many reasons), but I have nothing but
respect for the massive amount of documentation that is easily accessible as
a direct result of JavaDoc. I personnaly feel that it greatly helped java
achieve the success it has. If all of parrot's module w
On Wed, 2 Oct 2002, Erik Lechak wrote:
> I'm looking at it right now. Thanks for the link. This is the first
> time I have heard of doxygen.
I meant the pointer at least partly as a reminder that this is one wheel
we shouldn't have to reinvent. I think there are plenty of solutions out
there t
I hate to say this, but I'm still in favor of POD. It has all of the
functionality required
and is the official commenting style of parrot and perl. I personally find
POD distasteful,
but since it is the norm, then I think we should stick with it.
- Original Message -
From: "Erik Lechak"
Sean O'Rourke wrote:
>Have you had a chance to look at doxygen? It doesn't support Perl, but
>Perl is on the todo list, and (at least a couple of years ago) its C++
>support was pretty impressive.
>
>http://www.stack.nl/~dimitri/doxygen/
>
>/s
>
>
>
I'm looking at it right now. Thanks for t
On Wed, Oct 02, 2002 at 03:46:33PM +0200, Leopold Toetsch wrote:
> Nicholas Clark wrote:
>
> >On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> >>+if (buffer->bufstart && !(buffer->flags &
> >>+(BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
> >>+free(buffe
On Wed, 2 Oct 2002, Erik Lechak wrote:
> I was wondering if you could take a look at it and tell me if it has any
> merrit, or if I should not waste my time on it and get back to the
> "getting started guide".
Have you had a chance to look at doxygen? It doesn't support Perl, but
Perl is on the
Hi,
I asked a while ago if a "getting started manual" was a good idea. But
I got caught up on another issue, the format. I spent a couple of days
throwing together this demo of a self documenting comment style that can
be used in perl and c without the compiler freaking out. It also works
Leopold Toetsch wrote:
> Peter Gibbs wrote:
> Did you look at indexed access, shift, unshift, splice ;-)
I have simply modified classes/array.pmc, which does not yet
implement shift or unshift; grey aims to provide alternative
implementations, rather than add new functionality. However,
since Dan
Simon Cozens wrote:
> That's great, but what impact does it have on access to individual
> elements? If you're not careful, you may find that accessing stuff in
> the array gets quite seriously slower. Linked lists being O(n) access
> and all that...
I certainly hope that access gets slower, othe
Peter Gibbs wrote:
> I have been looking at other areas for improvements.
> Arrays seem to be one such area, ...
Yep
> This is using a singly linked list of variable sized chunks,
> without a separate index array. Each chunk is created
> with a minimum size (4 entries at present), then doubl
Dan Sugalski wrote:
> At 2:01 PM +0200 10/2/02, Leopold Toetsch wrote:
>
>> As already posted I incorparated the allocator from
>> http://gee.cs.oswego.edu/dl/html/malloc.html
>> in parrot.
>>
>> Some remarks:
>> - it's totally stable now, runs all tests (parrot and perl6)
>> - memory consumpti
At 12:15 PM +0100 10/2/02, Tim Bunce wrote:
>On a related note, are there any good tools for static code analysis
>around? The usual cross-reference stuff would be handy, but ideally
>something that goes further.
If someone wants to build some and there are things that parrot
doesn't provide th
At 5:27 PM +0200 10/2/02, Peter Gibbs wrote:
>On my machine, CVS parrot completes the above in
>an elapsed time of 13 minutes; grey takes 14 seconds.
Cool. Since this is a PMC class, I expect, and thus self-contained
(right? :) it ought to be fine to check it in as an alternate array.
If you co
At 2:01 PM +0200 10/2/02, Leopold Toetsch wrote:
>As already posted I incorparated the allocator from
>http://gee.cs.oswego.edu/dl/html/malloc.html
>in parrot.
>
>Some remarks:
>- it's totally stable now, runs all tests (parrot and perl6)
>- memory consumption is like CVS or much less ...
>- ...
[EMAIL PROTECTED] (Peter Gibbs) writes:
> On my machine, CVS parrot completes the above in
> an elapsed time of 13 minutes; grey takes 14 seconds.
> Changing the iteration count to 25000 takes 1 second
> with grey versus 46 seconds for CVS.
That's great, but what impact does it have on access
Having decided that life.pasm was not going to get much
better (58 seconds for 5000 generations vs 118 for CVS),
I have been looking at other areas for improvements.
Arrays seem to be one such area, as the current CVS code
expands arrays by creating a new one and copying all the
data. I believe L
On Wed, Oct 02, 2002 at 08:26:20AM -0700, Brent Dax wrote:
> David Chan:
> # I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of
> # RAM, gcc 2.95.4, linux 2.2.17 and parrot out of CVS. Without
> # swap, when I do "make", compiling core_ops_cg.c fails due to
> # lack of memory. Which
David Chan:
# I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of
# RAM, gcc 2.95.4, linux 2.2.17 and parrot out of CVS. Without
# swap, when I do "make", compiling core_ops_cg.c fails due to
# lack of memory. Which is unsurprising, as it is pretty big.
# It works if I use a 70 MB
Jason Gloudon wrote:
> There are many comments indicating that the GNU C
> library uses a derived version of Lea malloc.
$ pwd
/software/source/glibc-2.1.3/malloc
$ grep Lea$ malloc.c
This work is mainly derived from malloc-2.6.4 by Doug Lea
I don't have any later glibc sources handy to check.
Nicholas Clark wrote:
> On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
>>+if (buffer->bufstart && !(buffer->flags &
>>+(BUFFER_COW_FLAG|BUFFER_external_FLAG))) {
>>+free(buffer->bufstart);
>>+}
> The article doesn't mention garbage collection at
Jason Gloudon wrote:
> On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> Whatever source you are using cannot be the original Lea malloc, since it does
> not do garbage collection.
* VERSION 2.7.2 Sat Aug 17 09:07:30 2002 Doug Lea (dl at gee)
There seems to be no need for
On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> As already posted I incorparated the allocator from
> http://gee.cs.oswego.edu/dl/html/malloc.html
> in parrot.
Whatever source you are using cannot be the original Lea malloc, since it does
not do garbage collection. There are m
On Wed, Oct 02, 2002 at 02:01:48PM +0200, Leopold Toetsch wrote:
> As already posted I incorparated the allocator from
> http://gee.cs.oswego.edu/dl/html/malloc.html
> in parrot.
>
> Some remarks:
> - it's totally stable now, runs all tests (parrot and perl6)
> - memory consumption is like CVS o
# New Ticket Created by Leopold Toetsch
# Please include the string: [perl #17722]
# in the subject line of all future correspondence about this issue.
# http://rt.perl.org/rt2/Ticket/Display.html?id=17722 >
Some recent change in P6C did break examples/mandel.p6.
Please apply,
TIA,
leo
--
As already posted I incorparated the allocator from
http://gee.cs.oswego.edu/dl/html/malloc.html
in parrot.
Some remarks:
- it's totally stable now, runs all tests (parrot and perl6)
- memory consumption is like CVS or much less ...
- ... if resources.c is unpatched (#17702)
- runs almost[1] eve
On a related note, are there any good tools for static code analysis
around? The usual cross-reference stuff would be handy, but ideally
something that goes further.
Graphical would be good, interactive better (or at least cooler :).
Perhaps something like www.kartoo.com (needs flash) or
http://
Hi,
I'm using a Pentium 200 (well, Cyrix actually) with 32 MB of RAM, gcc
2.95.4, linux 2.2.17 and parrot out of CVS. Without swap, when I do
"make", compiling core_ops_cg.c fails due to lack of memory. Which is
unsurprising, as it is pretty big. It works if I use a 70 MB swap
partition.
Shou
34 matches
Mail list logo
