From dhinds at sonic.net  Tue Sep  6 07:48:26 2005
From: dhinds at sonic.net (dhinds@sonic.net)
Date: Tue, 6 Sep 2005 05:48:26 +0000 (UTC)
Subject: [Rd] A memory management question
References: <dfe1fp$buj$1@sea.gmane.org>
	<Pine.LNX.4.63.0509041814200.5751@itasca2.wildberry.org>
	<dfgrti$6tn$1@sea.gmane.org>
	<Pine.LNX.4.63.0509050624390.5751@itasca2.wildberry.org>
	<dfhuki$jvv$1@sea.gmane.org>
	<Pine.LNX.4.63.0509051338000.5751@itasca2.wildberry.org>
Message-ID: <dfjaja$or4$1@sea.gmane.org>

Luke Tierney <luke at stat.uiowa.edu> wrote:

> I am not comfortable making this available at this point.  It might be
> useful to have but would need careful thought.  Without some way to
> find out the true length there are potential problems.  Without some
> way of making sure the fields in VECSXP and STRSXP that are added are
> valid there are potential problems (not the first time but if the size
> is shrunk and then increased).  Not that this can't be resolved but it
> would take time that I don't have now, and this isn't high priority
> enough to schedule in the near future.  So for now you should not use
> SETLENGTH if you want your code to work beyond 2.2.0.

Ok, that's fine... given the lack of other valid uses of SETLENGTH, it
doesn't seem worth preserving it just for this one debatable usage.

> It may be possible to expand the semantics by adding a logical
> argument that controls whether the vector is to be over-allocated and
> filled with zero length strings and truncated to the true length on
> close.  Another variant would be to have a logical argument that says
> to keep the input internally and provide a function, say
> textConnectionOutput, to retrieve the internal output.

These are possible... or optionally just don't reveal the intermediate
output at all, and just make the final result visible on close...

-- Dave



[Rd] A memory management question
dhinds@sonic.net