Hi<br>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.<br>They both revolve around the way <b>apply.parsers</b>() works<br>
<ol><li>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.<br>I traced the error to apply.parsers and the call of R original <b>package.skeleton</b> (without the <b>.dx</b>) therin.<br>
some code inside package.skeleton complained than in the following way:<br>Error in methods::promptMethods(item, filename = file.path(docs_dir, sprintf("%s-methods.Rd", : <br> No generic function found corresponding to "TParallelModel"<br>
Fehler in package.skeleton(name, code_files = code_files, namespace = isTRUE(namespace)) : <br> Error in methods::promptMethods(item, filename = file.path(docs_dir, sprintf("%s-methods.Rd", : <br> No generic function found corresponding to "TParallelModel"<br>
> <br>It could obviously not find the generic function (which worked however if not called from inlinedocs)<br><br>I found that I could call <b>package.skeleton </b>when I used <br>e=globalenv() instead of <br>e=new.env() <br>
However as the comment in apply.parsers suggests Inlinedocs will then not be able to produce its own<br>documentation and does not pass its R CMD check.<br><br>I am not sure what the preferred solution would look like. Should one <br>
somehow enrich the new.env created in apply.parsers or is this new environment already a workaround that could be avoided<br>altogether?<br><br></li><li>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.<br>
The expressions of the form setMethod("someGeneri...<br>however don't produce objects. They are called for there side effects.<br>This leads to the curios situation that not even the ### lines in the methods are found. (by <b>prefixed.lines</b>) <br>
<span dir="ltr"></span>It seems that one is forced to apply a second loop to find those expressions and than put the parsers to work on them.<br>I can not see up to now how that would fit in the general strategy.<br><br><br>
</li></ol><p>I would very much appreciate any suggestions as how to proceed. <br>Some explanation is also welcome <br>Although I am not altogether new to functional programming I am still an R-newby and inlinedocs seems pretty much at the frontier.</p>
<p>Thanks in advance</p><p>Markus</p><p><br></p><div class="gmail_quote">2011/11/22 Toby Dylan Hocking <span dir="ltr"><<a href="mailto:Toby.Hocking@inria.fr">Toby.Hocking@inria.fr</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Markus, thanks very much for your interest in inlinedocs. I'm sorry<br>
for the delayed response to your very detailed email. In short, I have<br>
approved you for the inlinedocs group on R-Forge and I invite you to<br>
contribute any code you can to improve the inlinedocs S4 support.<br>
<br>
The error message<br>
<div class="im"><br>
extra.code.docs prefixed.lines Error in UseMethod("combine") :<br>
no applicable method for 'combine' applied to an object of class "NULL"<br>
Calls: package.skeleton.dx ... apply.parsers -> combine -> combine.list -><br>
combine<br>
Execution halted<br>
<br>
</div>suggests that the error occured sometime in the execution of the<br>
prefixed.lines Parser Function, so I suggest you start by looking at<br>
its definition in inlinedocs/R/parsers.R if you have not already.<br>
<br>
And when you commit code to SVN please run R CMD check inlinedocs to<br>
run the unit tests and make sure the changes that you make do not<br>
introduce backwards-incompatible changes. If everything passes OK,<br>
there should be no errors when running the package check.<br>
<br>
Thanks again and please do not hesitate to ask further questions on<br>
the inlinedocs-support list.<br>
</blockquote></div><br>