takers wanted: a C job - list.c and arrays
Leopold Toetsch
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
> 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
>
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
> > 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.
>
> 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
> 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
The long term planning is the sort of thing that could also go in docs/ROADMAP.
Regards.