takers wanted: a C job - list.c and arrays

0 views
Skip to first unread message

Leopold Toetsch

unread,
May 25, 2005, 10:25:01 AM5/25/05
to Perl 6 Internals
src/list.c is the base for several array-ish PMC inside classes. But
it's mostly outdone by other PMCs like ResizableIntegerPMC.

OTOH it has some features which are not covered by other array classes:
- implementation of splice, shift, unshift, ...
- chunked allocation with (limited) support for sparse arrays
- much faster shift/unshift for big arrays

I think we should do:

1) implement missing vtables (shift,unshift,splice,push,pop,delete) in
*all* {Fixed,Resizable}<type>Array PMCs

2) cleanup and simplify list.c. E.g. the growing policy for allocation
can be dropped. We need only fixed-sized chunks of e.g one page size
(and maybe sparse chunks).

3) get rid of Parrot_allocate* inside list.c because on each GC run the
memory might move. We just use mem_sys_allocate (_realloc) instead.

4) treat list.c just as another policy: namely chunked array storage and
use it when necessary. That is:
- new (small) arrays start as one of the mentioned types in 1)
- if the array gets big or has considerable shift/unshift operations,
switch the array vtable to use the chunked based approach of list.c
where the existing allocated memory is just one list chunk.

These are several more or less independent steps, 1) and 2+3) can be
done in parallel.

Takers wanted & thanks
leo

Jerry Gay

unread,
May 25, 2005, 3:30:20 PM5/25/05
to Leopold Toetsch, Perl 6 Internals
On 5/25/05, Leopold Toetsch <l...@toetsch.at> wrote:
> src/list.c is the base for several array-ish PMC inside classes. But
> it's mostly outdone by other PMCs like ResizableIntegerPMC.
>
> OTOH it has some features which are not covered by other array classes:
> - implementation of splice, shift, unshift, ...
> - chunked allocation with (limited) support for sparse arrays
> - much faster shift/unshift for big arrays
>
> I think we should do:
>
> 1) implement missing vtables (shift,unshift,splice,push,pop,delete) in
> *all* {Fixed,Resizable}<type>Array PMCs
>
i've added pop to ResizablePMCArray. i'll make sure the others are
added and move on to FixedPMCArray next.

> These are several more or less independent steps, 1) and 2+3) can be
> done in parallel.
>
> Takers wanted & thanks
> leo
>
>

BTW if you enter these as tickets into RT, we can truly have "takers." :)
~jerry

Jerry Gay

unread,
May 25, 2005, 6:37:40 PM5/25/05
to Leopold Toetsch, Perl 6 Internals
On 5/25/05, Leopold Toetsch <l...@toetsch.at> wrote:
> jerry gay wrote:
> > On 5/25/05, Leopold Toetsch <l...@toetsch.at> wrote:
>
> > i've added pop to ResizablePMCArray. i'll make sure the others are
> > added and move on to FixedPMCArray next.
>
> Great, thanks. WRT fixed arrays - its a policy thing: do these map to
> not resizable, not changable (Python tuples) or watever ...
>
i'll just stick to the resizable* variants for now, until the fixed*
design is firmed up. until i run out of things to do. (hopefully
design is done by then.)

as far as fixed* goes... are they immutable, or just unresizable? is
there a need for both? and, what happens when errors (bounds,
autovivify, etc.) occur? throw an exception? return undef pmc? return
null? there are many questions to be answered.

> >>These are several more or less independent steps, 1) and 2+3) can be
> >>done in parallel.
>

> > BTW if you enter these as tickets into RT, we can truly have "takers." :)
>

> Yeah. As these are several steps, I'd like to have some takers first, or
> interest, or ...Except the first item its more a long term plan. I don't
> know if tickets really track it all.
>
i'd like to track my work using tickets. i suppose i could enter them
myself, and track them that way, but i'm hoping the gods who sprang
from zeus' forehead and rule this great flat land will provide us with
all we need.

~jerry

Leopold Toetsch

unread,
May 25, 2005, 6:03:47 PM5/25/05
to jerry gay, Perl 6 Internals
jerry gay wrote:
> On 5/25/05, Leopold Toetsch <l...@toetsch.at> wrote:

> i've added pop to ResizablePMCArray. i'll make sure the others are
> added and move on to FixedPMCArray next.

Great, thanks. WRT fixed arrays - its a policy thing: do these map to

not resizable, not changable (Python tuples) or watever ...

>>These are several more or less independent steps, 1) and 2+3) can be
>>done in parallel.

> BTW if you enter these as tickets into RT, we can truly have "takers." :)

Yeah. As these are several steps, I'd like to have some takers first, or

interest, or ...Except the first item its more a long term plan. I don't
know if tickets really track it all.

> ~jerry

leo

William Coleda

unread,
May 25, 2005, 8:37:38 PM5/25/05
to Leopold Toetsch, jerry gay, Perl 6 Internals
They certainly can. Tickets can have child tickets, or pre-requisite tickets, each of which can have its own takers.

The long term planning is the sort of thing that could also go in docs/ROADMAP.

Regards.

Reply all
Reply to author
Forward
0 new messages