Great Job. This is really a useful tool and it is exactly what I was looking for. Thanks a lot!
Just 2 small issues (bugs) (Matlab R2011a):
1.: if I have a function within a class which has the following form:
function test
switch
…
end
end
then
I got an parser error. The problem is that the switch command must be indented:
function test
switch
…
end
end
then it works.
2.: this issue does not affect everyone. I modified some of my code using other editors. For some reasons I got ‘\n’ replaced for line break by ‘\r\n’ which causes an parse error. I replaced in all my m-files single ‘\n’ by ‘\r\n’ and now it works.
Hey Justin,
the way we handle varargin is to define a type called that way, so that doxygen automatically creates a link to that whenever it occurs somewhere. as it turns out, it will be linked in a classes functions summary (at the parameter list), but then of course not in the detailed function description as long as it is not explicitly included there.
here's my suggestion for the current version: in the "Parameters:" section, declare varargin as a single parameter and add a description what should be contained in there. (if you also add the "@type varargin" tag behind, will get double varargin in the fcn signature list but a type in the detailed description).
we haven't fully decided what to do best about the whole varargin thing, as the ways to use it (i.e. inputParser etc) are way too numerous.
however, we will think about an easy way to also include varargin-parsing into mtoc++, maybe something like a "Varargin:" section with "<name>: <desc> @type <type> @default <default>".
you are more than welcome to share your thoughts on that with us!
regards,
Daniel
Hi Daniel,
Do you have any suggestions on how to handle varagin? I use inputParser to validate optional parameters of the type ('ParamName', paramValue) in my constructors and other functions.
Is it possible to have the type show under the 'Parameters:' heading instead of only in the function definition line of the doxygen output?
Hey gg,
well i'd also complain to parse that code :-)
fun aside, the reason for the error is simply the missing matlab indentation. our parser relies on the files to have that, as the original matlab parser mlint is of course not available to us and we need some means to know where we are and what .c to produce of that.
when i take your above example and run matlab's builtin indentation on it, the error disappears. you might find this post "http://www.mathworks.com/matlabcentral/answers/11457-how-to-apply-smart-indent-to-a-file-programmatically" interesting.
however, as we frequently find people coming up with the same errors we might include some more explicit hints toward this issue into the documentation.
Daniel,
several classes of mine produce errors when parsing. Following below I include one log-file and following that a simple example.
Regards,
gg
--------------snip!-------------------
MTOCPP:C:/Users/fango/tmp/test/errorClass.m: PARSE ERROR in line 20
Message: Grrrr!!!!
Next 20 characters to parse:
0;
end
end
end
---------------snip!------------------
classdef errorClass
properties
end
methods
function ob = errorClass
end
function po = innocent_method
if 1
end
po=0;
end
end
end
---------------snip!------------------
Think I got it figured out. Was missing MSVCP100.dll. I installed Microsoft Visual C++ 2010 SP1 Redistributable from here: http://www.microsoft.com/download/en/confirmation.aspx?id=8328
I found an interesting thread on the topic of static vs dynamic linking of these libraries here: http://social.msdn.microsoft.com/Forums/en-US/Vsexpressvc/thread/3a007184-80e9-4e25-b5ad-ff31b028c051
Everything went pretty smooth, got some good looking documentation. I did however, manage to get a Grrr! message :). Here's the output:
MTOCPP:C:/HopkinsSynergySandbox/CSI/CSI_CORE/0.0/jhopkin/CsiPlottingTool/@AmsPlotManager/AmsPlotManager.m: PARSE ERROR in line 27
Message: Grrrr!!!!
Next 20 characters to parse:
% Matlab class for c
Comment only