[Rd] Tricking Promises into Sending Info Via Args into Caller
The is.pos function below results in the variable, out, being set to
TRUE if the first argument to is.pos is positive and to FALSE
otherwise.
It does this without using the return value or using scoping tricks to
reach into the caller. Instead it tricks the promise into
communicating one bit of information upwardly from the function to its
caller via the second argument.
One would have thought this to be impossible. Is this intended behavior?
is.pos - function(i, x) { if (i 0) x; NULL }
# in this example actual arg1 of is.pos is positive
out - FALSE
is.pos(1, out - TRUE)
out # TRUE
# in this example actual arg1 of is.pos is negative
out - FALSE
is.pos(-1, out - TRUE)
out # FALSE
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tricking Promises into Sending Info Via Args into Caller
On Jan 12, 2013, at 17:02 , Gabor Grothendieck wrote:
The is.pos function below results in the variable, out, being set to
TRUE if the first argument to is.pos is positive and to FALSE
otherwise.
It does this without using the return value or using scoping tricks to
reach into the caller. Instead it tricks the promise into
communicating one bit of information upwardly from the function to its
caller via the second argument.
One would have thought this to be impossible. Is this intended behavior?
Yes, this is a generic consequence of lazy evaluation: delayed and
unpredictable side effects. Whether it is desirable is an open issue; it is the
sort of thing that creates serious headaches for compiler constructors, but it
is pretty much unavoidable once you include the lazy eval feature.
is.pos - function(i, x) { if (i 0) x; NULL }
# in this example actual arg1 of is.pos is positive
out - FALSE
is.pos(1, out - TRUE)
out # TRUE
# in this example actual arg1 of is.pos is negative
out - FALSE
is.pos(-1, out - TRUE)
out # FALSE
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] Tricking Promises into Sending Info Via Args into Caller
In the spirit of this, but AFAIK not due to lazy evaluation, here's
another illustration why it's easy to mistakes when doing inline
assignments:
x - 0
TRUE (x - 1)
[1] TRUE
x
[1] 1
FALSE (x - 2)
[1] FALSE
x
[1] 1
(x - 3) FALSE
[1] FALSE
x
[1] 3
FALSE (x - 4)
[1] FALSE
x
[1] 4
/Henrik
On Sat, Jan 12, 2013 at 9:19 AM, peter dalgaard pda...@gmail.com wrote:
On Jan 12, 2013, at 17:02 , Gabor Grothendieck wrote:
The is.pos function below results in the variable, out, being set to
TRUE if the first argument to is.pos is positive and to FALSE
otherwise.
It does this without using the return value or using scoping tricks to
reach into the caller. Instead it tricks the promise into
communicating one bit of information upwardly from the function to its
caller via the second argument.
One would have thought this to be impossible. Is this intended behavior?
Yes, this is a generic consequence of lazy evaluation: delayed and
unpredictable side effects. Whether it is desirable is an open issue; it is
the sort of thing that creates serious headaches for compiler constructors,
but it is pretty much unavoidable once you include the lazy eval feature.
is.pos - function(i, x) { if (i 0) x; NULL }
# in this example actual arg1 of is.pos is positive
out - FALSE
is.pos(1, out - TRUE)
out # TRUE
# in this example actual arg1 of is.pos is negative
out - FALSE
is.pos(-1, out - TRUE)
out # FALSE
--
Statistics Software Consulting
GKX Group, GKX Associates Inc.
tel: 1-877-GKX-GROUP
email: ggrothendieck at gmail.com
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Peter Dalgaard, Professor,
Center for Statistics, Copenhagen Business School
Solbjerg Plads 3, 2000 Frederiksberg, Denmark
Phone: (+45)38153501
Email: pd@cbs.dk Priv: pda...@gmail.com
__
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
Re: [Rd] Patch for setwd() to show path in error message
On Fri, Jan 11, 2013 at 10:40 PM, Prof Brian Ripley
rip...@stats.ox.ac.uk wrote:
On 11/01/2013 20:22, Henrik Bengtsson wrote:
Below is a patch for setwd() to show path in error message. Current
it just gives error messages such as:
Error in setwd(libdir) : cannot change working directory
with the patch it should (read untested) give:
Error in setwd(libdir) : cannot change working directory to
'path/that/fails/'
And why is this needed? You know it is 'libdir' and could check what that
was (or if doing this programatically, check its existence first).
Risking to state the obvious:
To me, the main purpose of error messages is to make troubleshooting
easier. The more informative the error message is, the easier it is to
troubleshoot and the faster the origin of the error can be resolved.
The other extreme is to provide an empty error message (stop()) and
leave it to whoever needs to troubleshoot to use traceback() and
debug() and/or inspect the source code.
Also, a well written error message makes it more likely that the end
user will be able to resolve the problem without asking others for
help (read r-help, the maintainer, an R savvy person that the user
happens to know, ...). As an example of this, over at
aroma-project.org I receive fewer support emails after updating the
format of file-not-found error messages from:
Pathname not found: R-devel/src/library/base/R/R/utils.R
to:
Pathname not found: R-devel/src/library/base/R/R/utils.R
(R-devel/src/library/base/R/ exists, but nothing beyond; current
directory is 'x:/CRAN')
Moreover, it is not always the person who receives/reads the error
message that is the one who will resolve the problem. In some cases
it is not even possible for that person to access the environment
where the problem occurs. However, as a good R citizen, the more
troubleshooting you can at your end before requesting help by the
person who can take action the better. This also makes it more likely
that the error will be resolved sooner.
As my postscript hinted to, this post originates from an error in the
'R CMD check' service ran by r-forge.r-project.org). That particular
error is likely to occur internally in tools:::.check_packages();
if (nzchar(libdir)) {
setwd(libdir)
...
}
where 'libdir' is an internal object, but there is no way for me (and
all the others who also see this error for their packages) to help out
with the troubleshooting.
/Henrik
As you fumbled towards, it would require all the translations to be redone,
so we don't do this sort of thing lightly. (Redone twice if it were done
correctly, AFAICS.) The .pot and .po files are generated automatically, but
not filled in automatically. This is all in the manuals
In any case, the correct procedure was to file an enhancement request on
R-bugs, with a case and after testing on both platforms you are proposing to
patch.
PATCH:
% diff -u util.c util,patch.c
--- util.c 2012-12-16 13:13:05.002249900 -0800
+++ util,patch.c2013-01-11 11:52:16.843236400 -0800
@@ -696,14 +696,14 @@
{
const wchar_t *path = filenameToWchar(STRING_ELT(s, 0), TRUE);
if(_wchdir(path) 0)
- error(_(cannot change working directory));
+ error(_(cannot change working directory to '%s'), path);
That is a wchar_t*, so the format would need to be %ls.
}
#else
{
const char *path
= R_ExpandFileName(translateChar(STRING_ELT(s, 0)));
if(chdir(path) 0)
- error(_(cannot change working directory));
+ error(_(cannot change working directory to '%s'), path);
}
#endif
return(wd);
TRANSLATIONS:
I have zero experience with GNU gettext/*.po files, but I understand
that the above change requires updates to src/library/base/*.po files,
which now looks like (e.g. de.po):
#: src/main/util.c:699 src/main/util.c:706
msgid cannot change working directory
msgstr kann Arbeitsverzeichnis nicht wechseln
A generic/automatic update would be to use the format:
#: src/main/util.c:699 src/main/util.c:706
msgid cannot change working directory: '%s'
msgstr kann Arbeitsverzeichnis nicht wechseln: '%s'
but I don't think that is in line with the current R style.
/Henrik
PS. Background for this patch:
https://r-forge.r-project.org/tracker/index.php?func=detailaid=2395group_id=34atid=194
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
--
Brian D. Ripley, rip...@stats.ox.ac.uk
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UKFax: +44 1865 272595
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
