[Rd] Suggestion: Allow packages to add additional information to sessionInfo()

Henrik Bengtsson hb at stat.berkeley.edu
Thu Sep 3 20:10:31 CEST 2009


On Thu, Sep 3, 2009 at 10:38 AM, Kevin R.
Coombes<krcoombes at mdacc.tmc.edu> wrote:
> [1] I agree that sessionInfo() can be taken further.
> [2] I even more strongly agree that it would be a bad idea to allow packages
> to add features that cause the base sessionInfo() function to fail.
>
> Why not add an extra function called something like "packageSessionInfo()"
> that would provide the desired hooks but keep them from breaking the base
> functionality?

The point is that (if so) there should only be *one function* to call
for all packages, not one per package, because that would be a pain
due to dependencies.  But, sure I'm happy to start with a
package[s]SessionInfo() such that

c(sessionInfo(), extras=packagesSessionInfo())

pretty much return what I wish. Then it might be easier to argue for
incorporating the above in sessionInfo() ;)

Sorry for not getting it, but I still don't see how adding extra
information would break the base functionality?  Can you give some
examples?

As I said, timeouts can be a problem and possibly also if the hook
functions have side effects that, say, would load new packages, could
give funny results, but I also think a package developer who is
capable to setting up hook function would no how to avoid this.

With the default argument of 'extras' to be FALSE, sessionInfo() would
work as now, with the extra feature that 'extras=TRUE' can give lots
of additional useful information.

/Henrik

>
> (Of course, this ignores the possibility that someone could create a package
> within which they make sessionInfo into a generic and cause things to break
> through the S4 class mechanism...)
>
>   Kevin
>
> Henrik Bengtsson wrote:
>>
>> On Thu, Sep 3, 2009 at 10:16 AM, Gabor
>> Grothendieck<ggrothendieck at gmail.com> wrote:
>>
>>>
>>> The danger is that it could introduce bugs into the process
>>> of reporting bugs.
>>>
>>
>> If you mean that sessionInfo() will result in an error, that is easily
>> solved by a tryCatch() statement.  Timeouts are harder.  One can also
>> consider providing an sessionInfo(..., extras=TRUE) option.
>>
>> The purpose is to save the maintainer (and those who try to help
>> troubleshooting) time.  There are tons of time spend on sending follow
>> up requests on basic things.  We took a great leap when introducing
>> sessionInfo() and think we can take it further.
>>
>> /Henrik
>>
>>
>>>
>>> On Thu, Sep 3, 2009 at 1:05 PM, Henrik Bengtsson<hb at stat.berkeley.edu>
>>> wrote:
>>>
>>>>
>>>> Hi,
>>>>
>>>> sessionInfo() has been proven really useful, but you still often have
>>>> to ask for additional information in order to help troubleshooting.
>>>> For instance, for troubleshooting the aroma.affymetrix, it is very
>>>> helpful to know what the current working directory is, for other
>>>> packages certain system environment variables might be useful and so
>>>> on.
>>>>
>>>> One solution could be to provide support for hook functions of
>>>> sessionInfo(), which package then can register and append to the
>>>> 'sessionInfo' list structure.  Does this make sense?
>>>>
>>>> /Henrik
>>>>
>>>> ______________________________________________
>>>> R-devel at r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>>>
>>>>
>>
>> ______________________________________________
>> R-devel at r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-devel
>>
>
> ______________________________________________
> R-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>



More information about the R-devel mailing list