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

Friedrich Leisch Friedrich.Leisch at stat.uni-muenchen.de
Fri Sep 4 11:04:20 CEST 2009


>>>>> On Thu, 3 Sep 2009 11:10:31 -0700,
>>>>> Henrik Bengtsson (HB) wrote:

  > 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.

I think the concept of hook functions for sessionInfo() makes absolute
sense. Yes it should be optional to run them, but the default should
be pkghooks=TRUE, because I don't see why they shouldn't run OK in
99.9% of all cases. If a hook doesn't run on a certain platform that
would be a bug to me and need to be fixed. Could those who seem to
think such hooks are not a good idea elaborate on what the "danger"
really is? 

Best,
Fritz



More information about the R-devel mailing list