[inlinedocs] Problems with S4 method definitions

[Markus Müller]

Hi
I have two new problems, which somebody with a deeper understanding of
inlinedocs could probably help to solve much quicker, because they might
involve strategic decisions.
They both revolve around the way *apply.parsers*() works

   1. Since the update to R2.14 I could not run package.skeleton.dx at all
   when a file with method definitions for a generic function was contained in
   the package.
   I traced the error to apply.parsers and the call of R original *
   package.skeleton* (without the *.dx*) therin.
   some code inside package.skeleton complained than in the following way:
   Error in methods::promptMethods(item, filename = file.path(docs_dir,
   sprintf("%s-methods.Rd",  :
     No generic function found corresponding to "TParallelModel"
   Fehler in package.skeleton(name, code_files = code_files, namespace =
   isTRUE(namespace)) :
     Error in methods::promptMethods(item, filename = file.path(docs_dir,
   sprintf("%s-methods.Rd",  :
     No generic function found corresponding to "TParallelModel"
   >
   It could obviously not find the generic function (which worked however
   if not called from inlinedocs)

   I found that I could call *package.skeleton *when I used
   e=globalenv() instead of
   e=new.env()
   However as the comment in apply.parsers suggests Inlinedocs will then
   not be able to produce its own
   documentation and does not pass its R CMD check.

   I am not sure what the preferred solution would look like. Should one
   somehow enrich the new.env created in apply.parsers or is this new
   environment already a workaround that could be avoided
   altogether?

   2. After I had worked out how to come that far I had a look at the way
   apply.parsers iterates over the objects created by expressions parsed from
   the  source code.
   The expressions of the form setMethod("someGeneri...
   however don't produce objects. They  are called for there side effects.
   This leads to the curios situation that not even the ### lines in the
   methods are found. (by *prefixed.lines*)
   It seems that one is forced to apply a second loop to find those
   expressions and than put the parsers to work on them.
   I can not see up to now how that would fit in the general strategy.



I would very much appreciate any suggestions as how to proceed.
Some explanation is also welcome
Although I am not altogether new to functional programming I am still an
R-newby and inlinedocs seems pretty much at the frontier.

Thanks in advance

Markus


2011/11/22 Toby Dylan Hocking <Toby.Hocking at inria.fr>

> Markus, thanks very much for your interest in inlinedocs. I'm sorry
> for the delayed response to your very detailed email. In short, I have
> approved you for the inlinedocs group on R-Forge and I invite you to
> contribute any code you can to improve the inlinedocs S4 support.
>
> The error message
>
> extra.code.docs prefixed.lines Error in UseMethod("combine") :
>  no applicable method for 'combine' applied to an object of class "NULL"
> Calls: package.skeleton.dx ... apply.parsers -> combine -> combine.list ->
> combine
> Execution halted
>
> suggests that the error occured sometime in the execution of the
> prefixed.lines Parser Function, so I suggest you start by looking at
> its definition in inlinedocs/R/parsers.R if you have not already.
>
> And when you commit code to SVN please run R CMD check inlinedocs to
> run the unit tests and make sure the changes that you make do not
> introduce backwards-incompatible changes. If everything passes OK,
> there should be no errors when running the package check.
>
> Thanks again and please do not hesitate to ask further questions on
> the inlinedocs-support list.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.r-forge.r-project.org/pipermail/inlinedocs-support/attachments/20111215/d85fe752/attachment.htm>