Well, some victory!
Example.h:
/** This is a block describing enum
*/
enum color { RED, BLUE, GREEN };
/*! This is describing class foo
*/
class Foo {
public:
Foo() { }
enum speed { IMPULSE=10, WARP=20, LUDICROUS=30 };
void enum_test(speed s);
};
/*! This is describing enum test
\param c the color c
\param s the speed
*/
void enum_test(color c, Foo::speed s);
The TOP of foo.java
/* This was generated from emitProxyClassDefAndCPPCasts() */
/**
* This is describing class foo
*
*/
public class Foo {
and finally-
public class example {
/* This was generated from moduleClassFunctionHandler() */
/**
* This is describing enum test
*
* @param s the speed
* @param c the color c
*/
public static void enum_test(color c, Foo.speed s) {
exampleJNI.enum_test(c.swigValue(), s.swigValue());
}
}
Wish I still wasn’t so tired from being sick! But on the nice side, the Olympic opening ceremony was wonderful :) Couldn’t help but watch it!
Trying to finish what I had started on my laptop on my trip has been a little hairy- mostly I’ve been having to rewrite things to get them to actually work, but it’s given me some good opportunities to reconsider how much work I want the language modules to have to do (Which is, of course, as little as possible- and preferably in a manner that leaves all the modules I am not going to mess with untouched!)
With any luck though, my build tomorrow should be putting my javaDoc into the java proxy files. I still haven’t worked out my problem with implementing a %feature, but I decided It would probably be best to get it working end to end first- plus there is the option of simply adding in a new blob of doxygen with a structural command into the interface file itself. (Note to self: make sure to bring this up with Olly TOMORROW!)
First spam comment! How exciting. :p It’s on some post down below. Other than that, committing tomorrow instead . Oof, I feel behind! William’s post on the mailing list gave me a lot to chew on though, need to reply formally to both of my threads tomorrow ( _really_ tomorrow) as well. I also need to make sure to exist on the swig gsoc channel more- haven’t been holding to that.
Other than that- still need to figure out best way to deal with straight C/C++ comments.
Thunderstorms all morning + keeping watch over a very neurotic dog during said storms did not bode well for our heroine. However, tomorrow should be the update of a build with some fixes/extensions to the translator module as well as what I talked about yesterday implemented in SWIG. As well as (hopefully) a good plan for a few of the language modules. Should give me some good talking material :)
also, memo to self- need to still discuss how to appropriately put in a new command line option, or what, in order to make my module run. Seems like disabling the functionality would be as easy as just turning off parsing the tokens or placing them into the tree.
Ahhhh, I feel too tired to clearly articulate myself right now. I think I’m going to have to finish this tomorrow morning. I need to stop working/blogging so late- I’m really much more in my element in the morning… Like Cinderella’s coach, my brain turns into a pumpkin past midnight- which makes my time commitment from 7-11pm M T TH a little inconvenient ><
Plan details
Stage 1:
Picking up comments
in cscanner.c at case SWIG_TOKEN_COMMENT:
(around line 420 in my version)
3 types of tokens will be returned
-for standard doxygen blobs (aka /** or ///, //! etc) DOXYGENSTRING
-for post comments suchas /**< ///< etc (which are associated with the last thing encountered, see “Putting comments after members” at http://www.stack.nl/~dimitri/doxygen/docblocks.html for more info) DOXYGENPOSTCOMMENT
-for normal C/C++ comments CSTYLECOMMENT
Stage 2:
Attachment into the parse tree
in parser.y
General Doxygen Comments:
Spent today doing a few tweaks then more SWIG code review and a lot of reading through some documentation. Instead of my previous “beat SWIG with a stick until it does something” attempts, I’m going to lay out a very technical plan tomorrow. Running it by Olly and hopefully some other SWIG mentors should be a good way to ensure that its actually feasible- and it’s always good to make sure what I believe is the desired functionality… is actually the desired functionality ;) Would be very nice to set out with a good design. I also need to look up a bit more on some things like using error numbers and such so I can develop for SWIG properly.
I also need to figure out what modules are going to want the option to have doxygen, and how best to deal with that.
(output from the latest build of mine)
---ORIGINAL DOXYGEN---
//! A normal member taking two arguments and returning an integer value. This is a very long description for the simple purpose of showing off formatting. Let's make it a bit longer just to be sure.
/*!
\param a an \b integer argument.
\return The test results
\param s a constant character pointer. Let's also make this a very long description!
\bug this command should, for now, be totally ignored
\author cheryl foil
\sa Test(), ~Test(), testMeToo() and publicVar()
*/
---RESULT IN JAVADOC---
/**
* A normal member taking two arguments and returning an integer value.
* This is a very long description for the simple purpose of showing
* off formatting. Let's make it a bit longer just to be sure.
*
* @author cheryl foil
* @param s a constant character pointer. Let's also make this a very
* long description!
(Holding to my promise to update no matter what!)
Didn’t manage to get to much done today due to my boyfriend’s birthday :) Had to leave the house much earlier than I expected! Just means I’ll have to work a bit more tomorrow though.
Few things for me to remember:
-Olly brought up using Google code base to find Doxygen comments to use for examples… must remember to do this!
-Wsfulton brought up attempting to grab any c/c++ comments and putting them without modification into the proxy file, should look in to the best way to catch them
-figure out a good way to catch comments placed after what they are defining (I’m still going to call them “Side comments” for now since there’s no official word. >.<”) such as /**< enum value 2 */
Spent more time on the javaDoc module today! It is so nice to not be staring at more of the parser for a little bit =) Some of it won’t be proper until I deal with the whole autobrief problem so all comments not contained in a command node get placed into a description node so they aren’t sorted funny. I will probably be mailing out my request for example interface files to swig-user and an update to swig-developer as soon as I can get some feedback from Olly on it!
Stuff to work on to-morrow:
Code out the behaviour for the rest of the commands I want to include. (a few more javadoc tags that exist in doxygen as well, and a few small things that translate into html). I’d also like to figure out something more efficient than a giant sea of if-statements for a few things… >.<
Document what does and doesn’t work so I keep it in mind while working on SWIG next.
A general overview of my system:
As SWIG parses the interface file, it picks up any blobs of Doxygen Comments in its parse tree as another attribute of whatever node followed it. My current version of this in my branch is very rudimentary, but it succeeds for traditionally formatted comments.
While the proxy file is being written, the specific language module will interact with my own module in order to incorporate the translated comments.
Doxygen is parsed (via whatever means- I currently use a hand-parser and simple tokeniser, though Olly and I have discussed that there may be more sensible routes to take) and then placed in a tree of “Doxygen Entities”, for example
a comment of
/*! \brief function description
* \param x some random number
* \param y another random number
* return x divided by y
*/
may be in the parse tree, and this SPECIFIC comment blob is passed to my module.