>>>>> "MM" == Martin Maechler <[EMAIL PROTECTED]>
>>>>> on Sat, 16 Dec 2006 22:31:21 +0100 writes:
>>>>> "Vladimir" == Vladimir Dergachev <[EMAIL PROTECTED]>
>>>>> on Wed, 13 Dec 2006 13:03:21 -0500 writes:
Vladimir> On Wednesday 13 December 2006 6:01 am, Martin Maechler wrote:
>>>
>>> - Vladimir, have you verified your 'take2' against recent versions
>>> of R-devel?
Vladimir> Yes.
MM> indeed it applies cleanly
>>> - If they still work, could you re-post them to R-devel, this
>>> time using a proper MIME type,
>>> i.e. most probably one of
>>> application/x-tar
>>> application/x-compressed-tar
>>> application/x-gzip
>>>
>>> In case you don't know how to achieve this,
>>> I'd be interested to get it by "private" e-mail.
Vladimir> No problem. The old e-mail did have a mime type: "text/x-diff".
Vladimir> I am resending the patch - now compressed, hopefully it will get
pass whatever
Vladimir> filters are in place.
MM> It did pass --- and "text/x-diff" should pass through too from
MM> now on.
MM> However, even though the patch looks quite ok
MM> {apart from one border case: swiss[2, , drop = TRUE] should give a
list;
MM> and that was easy to fix; see the attached dataframe.R-diff
MM> file which incorporates that fix (and my other cosmetic changes)}
MM> but running 'make check-all' then shows segmentation faults --- only on
one platform of the
MM> two I've tested {in mgcv's gam() example, boot's boot()
MM> example, and I think one other place}
Correction: the problems show on both platforms;
one is in mgcv, gam(), an error in [[ <- -- pretty clearly linked to your
changes but not reproducible when tried isolatedly
interactively,
the other one is a seg.fault "memory not mapped" when running
the example
> nuke.boot <- boot(nuke.data, nuke.fun, R=999, m=1,
+ fit.pred=new.fit, x.pred=new.data)
MM> My guess: typically when dealing with model.frames (which
MM> internally are "just" data frames with a particular "terms" attribute)
MM> but the problems are not reproducible when run interactively.
MM> It may really be that .subset() and .subset2() are sometimes
MM> used in cases they should not be in your new code; or they even have a
bug that
MM> is not triggered unless by using them in the new context of [.data.frame
MM> So I'm sorry, but we might have to wait for a "take 3"
MM> or rather try to find the problem with your patch.
MM> Maybe you can try yourself?
[my diff for dataframe.R]
MM> Thanks anyway, Vladimir!
MM> Regards,
MM> Martin Maechler, ETH Zurich
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
