[Rd] Help on mapping memory
Dear everyone, I have maintained JL Schafer's package 'pan' for a while and recently been contacted for the possibility to fix a crash but it turned to be elusive -- I am wondering what is the best to resolve this. First, the error message is as follows, *** caught segfault *** address 0x1b001b3, cause 'memory not mapped' Traceback: 1: pan(test$Y1, test$ID, X, 1:4, 4, prior, seed = m, iter = 100) An irrecoverable exception occurred. R is aborting now ... and I gather this is to do with R/fortran mismatch nevertheless the tricky thing is that it works fine with the documentation data and even with this data there were times it could be tweaked to work (therefore PAN.txt, test.rda and test.log were as intended there). I have extracted the pan.f, pan.R from the package and leave the Bash/R scripts all here, https://github.com/jinghuazhao/R/tree/master/tests, short of adding a driver program to pan.f and debug without R but before doing that any idea/insight would be greatly appreciated. Thank you so much, Jing Hua Zhao [[alternative HTML version deleted]] __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] one thing to check
Hi, Jim: Could you please look at svd2.Rd and see what it says? It may give an example, where it gave a better answer than svd -- i.e., a marginal case, where svd2 honestly gave a better answer than svd. If we find -- either in svd2.Rd or in one of the revdepchecks -- an example where svd2 gives a demonstrably different answer, we need to consider what to do about that. 1. Is the different answer demonstrably better? If yes, can we fix it without LINPACK? If yes, do that. If no, we document those concerns, send them to R-Devel , and retain svd2 in fda and keep its use as it was. Then R-Devel can deal with the problem however they want, and it won't affect fda -- at least not right now. 2. Does the different answer break something in revdepcheck because of a cosmetic problem? If yes, try to communicate that issue with the maintainer(s) of the package(s) that would be affected by such a change. I suggest you send them tell then that svd2 is now deprecated -- AND mark svd2.Rd with such a message -- while also sending them code for the function(s) they call that give them an error message, and tell them that you plan to remove svd2 from the next release, and ask them to fix that so a revdepcheck with that new code won't be flagged as an error. AND ask them to notify you when they have a version on CRAN that works with your new code. 3. If the new code gives a different answer that doesn't seem better in at least one example AND deleting svd2 doesn't break anything in revdepcheck, then delete it. 4. If you still need to retain svd2 because of a revdepcheck problem, I'd also document that in "cran-comments.md". What do you think? spencer On 2020-11-10 07:10, James Ramsay wrote: Hi Spencer, One thing I’d like check with you: I removed svd2 because CRAN indicated that LINPACK had been deprecated. I replaced calls to svd2 with svd in geigen and CSTRfn. This could be the issue with the two broken codes … or not. But what is your view about using svd instead of svd2, and do you have an idea of what to do about the LINPACK calls? Best, Jim __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] one thing to check
Please excuse: I did NOT intend to send this to R-Devel at this time. I was suggesting to Jim Ramsay a question we MIGHT want to pose to R-Devel. (I've since decided we probably won't need to.) Spencer On 2020-11-10 07:58, Spencer Graves wrote: Hi, Jim: Could you please look at svd2.Rd and see what it says? It may give an example, where it gave a better answer than svd -- i.e., a marginal case, where svd2 honestly gave a better answer than svd. If we find -- either in svd2.Rd or in one of the revdepchecks -- an example where svd2 gives a demonstrably different answer, we need to consider what to do about that. 1. Is the different answer demonstrably better? If yes, can we fix it without LINPACK? If yes, do that. If no, we document those concerns, send them to R-Devel , and retain svd2 in fda and keep its use as it was. Then R-Devel can deal with the problem however they want, and it won't affect fda -- at least not right now. 2. Does the different answer break something in revdepcheck because of a cosmetic problem? If yes, try to communicate that issue with the maintainer(s) of the package(s) that would be affected by such a change. I suggest you send them tell then that svd2 is now deprecated -- AND mark svd2.Rd with such a message -- while also sending them code for the function(s) they call that give them an error message, and tell them that you plan to remove svd2 from the next release, and ask them to fix that so a revdepcheck with that new code won't be flagged as an error. AND ask them to notify you when they have a version on CRAN that works with your new code. 3. If the new code gives a different answer that doesn't seem better in at least one example AND deleting svd2 doesn't break anything in revdepcheck, then delete it. 4. If you still need to retain svd2 because of a revdepcheck problem, I'd also document that in "cran-comments.md". What do you think? spencer On 2020-11-10 07:10, James Ramsay wrote: Hi Spencer, One thing I’d like check with you: I removed svd2 because CRAN indicated that LINPACK had been deprecated. I replaced calls to svd2 with svd in geigen and CSTRfn. This could be the issue with the two broken codes … or not. But what is your view about using svd instead of svd2, and do you have an idea of what to do about the LINPACK calls? Best, Jim __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
