Re: S_mergesortsv is naughty

> On Sat, Aug 21, 2004 at 07:11:25PM +0200, Mattia Barbon wrote:

> > call, when marking the array/stack live. The workaround I used
> 
> If you need a mark() at all on your PVAV implementation, does this mean
> that the SVs, well, PMCs within it are not reference counted?

  The whole of the patch started when I tried to call
Parrot from Ponie. Then I realized I needed to mark
PMCs in Perl collections (I started with PVAV but was thinking
about foing it for all collection-like SVs), then I thought it would
be better if Perl5 PMCs could call Perl5 internal functions
croak(), SvPV(), SvIV(), ... hence the various build patches.

  Now I have something working I thought I better announce
 here for discussion.

> Have you solved how to avoid reference counting inside the perl core, letting
> parrot's GC do all the work? I saw that as the thing to do before working
> on AVs or HVs

  ISTR, but maybe I am dreaming, that it was mentioned here or
in a crosspost to perl6-internals that Ponie would use GC and
the greedy DOD (no, this is not the real name, but it is something
like this) inside Parrot to avoid reference counting and maintain
early destruction of SVs. I thought that marking SV contents
as live was a priority anyway.
 
> Also, can the stable qsort be used in place of the mergesort as default?
> (and disable the sort pragma entirely for ponie)
> This would seem to avoid both hacks and re-implementation, assuming that
> the qsort isn't also cheating in what is stores.

  Probably yes. But when I finally realized why Ponie was segfaulting
inside sort, I mindlessly went on coding and had this done
before noticing there also was a qsort implementation in pp_sort.c.

Regards
Mattia