Re: [Rd] [R] incoherent conversions from/to raw
WK == Wacek Kusnierczyk waclaw.marcin.kusnierc...@idi.ntnu.no
on Thu, 19 Mar 2009 10:17:20 +0100 writes:
WK Wacek Kusnierczyk wrote:
interestingly,
c(1, as.raw(1))
# error: type 'raw' is unimplemented in 'RealAnswer'
WK three more comments.
WK (1)
WK the above is interesting in the light of what ?c says:
WK
WK The output type is determined from the highest type of the
WK components in the hierarchy NULL raw logical integer real
WK complex character list expression.
WK
WK which seems to suggest that raw components should be coerced to whatever
WK the highest type among all arguments to c, which clearly doesn't happen:
WK test = function(type)
WK c(as.raw(1), get(sprintf('as.%s',type))(1))
WK for (type in c('null', 'logical', 'integer', 'real', 'complex',
WK 'character', 'list', 'expression'))
WK tryCatch(test(type), error = function(e) cat(sprintf(raw won't
WK coerce to %s type\n, type)))
WK which shows that raw won't coerce to the four first types in the
WK 'hierarchy' (excluding NULL), but it will to character, list, and
WK expression.
WK suggestion: improve the documentation, or adapt the implementation to
WK a more coherent design.
Thank you, Wacek.
I've decided to adapt the implementation
such that all the above c(raw , type) calls' implicit
coercions will work.
WK (2)
WK incidentally, there's a bug somewhere there related to the condition
WK system and printing:
WK tryCatch(stop(), error=function(e) print(e))
WK # works just fine
WK tryCatch(stop(), error=function(e) sprintf('%s', e))
WK # *** caught segfault ***
WK # address (nil), cause 'memory not mapped'
WK # Traceback:
WK # 1: sprintf(%s, e)
WK # 2: value[[3]](cond)
WK # 3: tryCatchOne(expr, names, parentenv, handlers[[1]])
WK # 4: tryCatchList(expr, classes, parentenv, handlers)
WK # 5: tryCatch(stop(), error = function(e) sprintf(%s, e))
WK # Possible actions:
WK # 1: abort (with core dump, if enabled)
WK # 2: normal R exit
WK # 3: exit R without saving workspace
WK # 4: exit R saving workspace
WK # Selection:
WK interestingly, it is possible to stay in the session by typing ^C. the
WK session seems to work, but if the tryCatch above is tried once again, a
WK segfault causes r to crash immediately:
WK # ^C
WK tryCatch(stop(), error=function(e) sprintf('%s', e))
WK # [whoe...@wherever] $
WK however, this doesn't happen if some other code is evaluated first:
WK # ^C
WK x = 1:10^8
WK tryCatch(stop(), error=function(e) sprintf('%s', e))
WK # Error in sprintf(%s, e) : 'getEncChar' must be called on a CHARSXP
WK this can't be a feature. (tried in both 2.8.0 and r-devel; version
WK info at the bottom.)
WK suggestion: trace down and fix the bug.
[not me, at least not now.]
WK (3)
WK the error argument to tryCatch is used in two examples in ?tryCatch, but
WK it is not explained anywhere in the help page. one can guess that the
WK argument name corresponds to the class of conditions the handler will
WK handle, but it would be helpful to have this stated explicitly. the
WK help page simply says:
WK
WK If a condition is signaled while evaluating 'expr' then
WK established handlers are checked, starting with the most recently
WK established ones, for one matching the class of the condition.
WK When several handlers are supplied in a single 'tryCatch' then the
WK first one is considered more recent than the second.
WK
WK which is uninformative in this respect -- what does 'one matching the
WK class' mean?
WK suggestion: improve the documentation.
Patches to tryCatch.Rd are gladly accepted
and quite possibly applied to the sources without much changes.
Thanks in advance!
Martin Maechler, ETH Zurich
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] incoherent conversions from/to raw
Martin Maechler wrote:
(...)
WK which shows that raw won't coerce to the four first types in the
WK 'hierarchy' (excluding NULL), but it will to character, list, and
WK expression.
WK suggestion: improve the documentation, or adapt the implementation
to
WK a more coherent design.
Thank you, Wacek.
I've decided to adapt the implementation
such that all the above c(raw , type) calls' implicit
coercions will work.
great!
WK (2)
WK incidentally, there's a bug somewhere there related to the condition
WK system and printing:
WK tryCatch(stop(), error=function(e) print(e))
WK # works just fine
WK tryCatch(stop(), error=function(e) sprintf('%s', e))
WK # *** caught segfault ***
WK # address (nil), cause 'memory not mapped'
WK # Traceback:
WK # 1: sprintf(%s, e)
WK # 2: value[[3]](cond)
WK # 3: tryCatchOne(expr, names, parentenv, handlers[[1]])
WK # 4: tryCatchList(expr, classes, parentenv, handlers)
WK # 5: tryCatch(stop(), error = function(e) sprintf(%s, e))
WK # Possible actions:
WK # 1: abort (with core dump, if enabled)
WK # 2: normal R exit
WK # 3: exit R without saving workspace
WK # 4: exit R saving workspace
WK # Selection:
WK interestingly, it is possible to stay in the session by typing ^C.
the
WK session seems to work, but if the tryCatch above is tried once again,
a
WK segfault causes r to crash immediately:
WK # ^C
WK tryCatch(stop(), error=function(e) sprintf('%s', e))
WK # [whoe...@wherever] $
WK however, this doesn't happen if some other code is evaluated first:
WK # ^C
WK x = 1:10^8
WK tryCatch(stop(), error=function(e) sprintf('%s', e))
WK # Error in sprintf(%s, e) : 'getEncChar' must be called on a CHARSXP
WK this can't be a feature. (tried in both 2.8.0 and r-devel; version
WK info at the bottom.)
WK suggestion: trace down and fix the bug.
[not me, at least not now.]
sure; i might try to find the bug in spare time, but can't promise.
WK (3)
WK the error argument to tryCatch is used in two examples in ?tryCatch,
but
WK it is not explained anywhere in the help page. one can guess that the
WK argument name corresponds to the class of conditions the handler will
WK handle, but it would be helpful to have this stated explicitly. the
WK help page simply says:
WK
WK If a condition is signaled while evaluating 'expr' then
WK established handlers are checked, starting with the most recently
WK established ones, for one matching the class of the condition.
WK When several handlers are supplied in a single 'tryCatch' then the
WK first one is considered more recent than the second.
WK
WK which is uninformative in this respect -- what does 'one matching the
WK class' mean?
WK suggestion: improve the documentation.
Patches to tryCatch.Rd are gladly accepted
and quite possibly applied to the sources without much changes.
ok, if you're willing to accept my suggestions i can try to suggest a
patch to the rd.
Thanks in advance!
you're welcome.
best,
vQ
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Re: [Rd] [R] incoherent conversions from/to raw
Wacek Kusnierczyk wrote:
interestingly,
c(1, as.raw(1))
# error: type 'raw' is unimplemented in 'RealAnswer'
three more comments.
(1)
the above is interesting in the light of what ?c says:
The output type is determined from the highest type of the
components in the hierarchy NULL raw logical integer real
complex character list expression.
which seems to suggest that raw components should be coerced to whatever
the highest type among all arguments to c, which clearly doesn't happen:
test = function(type)
c(as.raw(1), get(sprintf('as.%s',type))(1))
for (type in c('null', 'logical', 'integer', 'real', 'complex',
'character', 'list', 'expression'))
tryCatch(test(type), error = function(e) cat(sprintf(raw won't
coerce to %s type\n, type)))
which shows that raw won't coerce to the four first types in the
'hierarchy' (excluding NULL), but it will to character, list, and
expression.
suggestion: improve the documentation, or adapt the implementation to
a more coherent design.
(2)
incidentally, there's a bug somewhere there related to the condition
system and printing:
tryCatch(stop(), error=function(e) print(e))
# works just fine
tryCatch(stop(), error=function(e) sprintf('%s', e))
# *** caught segfault ***
# address (nil), cause 'memory not mapped'
# Traceback:
# 1: sprintf(%s, e)
# 2: value[[3]](cond)
# 3: tryCatchOne(expr, names, parentenv, handlers[[1]])
# 4: tryCatchList(expr, classes, parentenv, handlers)
# 5: tryCatch(stop(), error = function(e) sprintf(%s, e))
# Possible actions:
# 1: abort (with core dump, if enabled)
# 2: normal R exit
# 3: exit R without saving workspace
# 4: exit R saving workspace
# Selection:
interestingly, it is possible to stay in the session by typing ^C. the
session seems to work, but if the tryCatch above is tried once again, a
segfault causes r to crash immediately:
# ^C
tryCatch(stop(), error=function(e) sprintf('%s', e))
# [whoe...@wherever] $
however, this doesn't happen if some other code is evaluated first:
# ^C
x = 1:10^8
tryCatch(stop(), error=function(e) sprintf('%s', e))
# Error in sprintf(%s, e) : 'getEncChar' must be called on a CHARSXP
this can't be a feature. (tried in both 2.8.0 and r-devel; version
info at the bottom.)
suggestion: trace down and fix the bug.
(3)
the error argument to tryCatch is used in two examples in ?tryCatch, but
it is not explained anywhere in the help page. one can guess that the
argument name corresponds to the class of conditions the handler will
handle, but it would be helpful to have this stated explicitly. the
help page simply says:
If a condition is signaled while evaluating 'expr' then
established handlers are checked, starting with the most recently
established ones, for one matching the class of the condition.
When several handlers are supplied in a single 'tryCatch' then the
first one is considered more recent than the second.
which is uninformative in this respect -- what does 'one matching the
class' mean?
suggestion: improve the documentation.
vQ
version
_
platform i686-pc-linux-gnu
arch i686
os linux-gnu
system i686, linux-gnu
status
major 2
minor 8.0
year 2008
month 10
day20
svn rev46754
language R
version.string R version 2.8.0 (2008-10-20)
version
_
platform
i686-pc-linux-gnu
arch
i686
os
linux-gnu
system i686,
linux-gnu
status Under development
(unstable)
major
2
minor
9.0
year
2009
month
03
day
19
svn rev
48152
language
R
version.string R version 2.9.0 Under development (unstable) (2009-03-19
r48152)
__
