doxygen-develop — List for discussing new features, submitting patches, etc.

Re: [Doxygen-develop] bug (typo) in memberdef.cpp: defArgList vs declArgList

[Dimitri v. H. <do...@gm...>]

On 10/30/07, Konstantin Serebryany <kon...@gm...>
wrote:
>
> Hi,
>
> I've hit a seg fault in doxygen 1.5.3 with stack like this:
> #0  0x082540ab in QGListIterator (this=0xffffd500, l=@0x0) at qglist.cpp
> :1058
> #1  0x08071b5a in QListIterator (this=0xffffd500, l=@0x0) at
> ../qtools/qlist.h:111
> #2  0x0812ad71 in MemberDef::copyArgumentNames (this=0x369b2d70,
> bmd=0xe4d5b938) at memberdef.cpp:3913
> #3  0x08054673 in inheritDocumentation () at doxygen.cpp:7152
> #4  0x0806f36c in parseInput () at doxygen.cpp :9785
> #5  0x0804a1a9 in main (argc=2, argv=0xffffd8a4) at main.cpp:37
>
> It looks like this is a simple typo (copy-paste bug), and the following
> fixed my problem.
>
> @@ -3908,7 +3908,7 @@
>    }
>    {
>      LockingPtr<ArgumentList> arguments = bmd->declArgumentList();
> -    if (m_impl->defArgList && arguments!=0)
> +    if (m_impl->declArgList && arguments!=0)
>      {
>        ArgumentListIterator aliDst(*m_impl->declArgList);
>        ArgumentListIterator aliSrc(*arguments);
> @@ -3920,5 +3920,3 @@
>      }
>    }
>  }
>
> Latest svn version seems to have this issue as well.



That's a bug indeed! Thanks for analysing and reporting it.

Regards,
  Dimitri

[Doxygen-develop] bug (typo) in memberdef.cpp: defArgList vs declArgList

[Konstantin S. <kon...@gm...>]

Hi,

I've hit a seg fault in doxygen 1.5.3 with stack like this:
#0  0x082540ab in QGListIterator (this=0xffffd500, l=@0x0) at qglist.cpp
:1058
#1  0x08071b5a in QListIterator (this=0xffffd500, l=@0x0) at
../qtools/qlist.h:111
#2  0x0812ad71 in MemberDef::copyArgumentNames (this=0x369b2d70,
bmd=0xe4d5b938) at memberdef.cpp:3913
#3  0x08054673 in inheritDocumentation () at doxygen.cpp:7152
#4  0x0806f36c in parseInput () at doxygen.cpp:9785
#5  0x0804a1a9 in main (argc=2, argv=0xffffd8a4) at main.cpp:37

It looks like this is a simple typo (copy-paste bug), and the following
fixed my problem.

@@ -3908,7 +3908,7 @@
   }
   {
     LockingPtr<ArgumentList> arguments = bmd->declArgumentList();
-    if (m_impl->defArgList && arguments!=0)
+    if (m_impl->declArgList && arguments!=0)
     {
       ArgumentListIterator aliDst(*m_impl->declArgList);
       ArgumentListIterator aliSrc(*arguments);
@@ -3920,5 +3920,3 @@
     }
   }
 }

Latest svn version seems to have this issue as well.

Thanks,

-kcc

[Doxygen-develop] Found a fix for bug 356399

[Maurice E. <mel...@fr...>]

Hi All,
Hi Dimitri,

I'm completely new to Doxygen development but since I had a couple of =20=

problems on my own doxygen-based documentation build system, I found =20
at least an answer for one !

I encountered bug 356399 (http://bugzilla.gnome.org/show_activity.cgi?=20=

id=3D356399) and traced it down on my MacBook. Here was the kind of =20
message I had:

	path/to/my/tagfile.tag:63: Duplicate anchor \240\241\225=01 =
found

It took me a couple of hours to setup a Xcode project around doxygen =20
source code (if anybody is interested ?) so that I can reproduce =20
exactly my own documentation build system runtime constraints =20
(doxygen being part of a whole), therefore I did not spend too much =20
time to try to reduce the problem.

Anyway... this bug is due to the fact that va_args is stacked twice, =20
once in TagFileParser::warn, then again in ::warn  (in message.cpp). =20
I've found a quick patch by creating 2 overloaded prototypes for =20
TagFileParser::warn, corresponding to their current use.

Another solution would be to make the do_warn routine available =20
outside of message.cpp.

Here is my patch:

Index: src/tagreader.cpp
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- src/tagreader.cpp   (revision 590)
+++ src/tagreader.cpp   (working copy)
@@ -237,14 +237,16 @@
        m_inputFileName =3D fileName;
      }

-    void warn(const char *fmt,...)
+    void warn(const char *fmt)
      {
-      va_list args;
-      va_start(args, fmt);
-      ::warn(m_inputFileName,m_locator->lineNumber(),fmt,args);
-      va_end(args);
+      ::warn(m_inputFileName,m_locator->lineNumber(),fmt);
      }

+    void warn(const char *fmt, const char * s)
+    {
+      ::warn(m_inputFileName,m_locator->lineNumber(),fmt,s);
+    }
+
      void startCompound( const QXmlAttributes& attrib )
      {
        m_curString =3D "";
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

My 2 cents, hope this helps !

It helped me as well, since I found that my error was only caused by =20
a duplicate tag file in my TAGFILES list ;-/

I'm still in the process of registering for Bugzilla access so I did =20
not submit my comments/resolution there yet.

Best regards,
--=20
Maurice Elallouf

Re: [Doxygen-develop] ExtCmd debug information disabled in portable_system

[Dimitri v. H. <do...@gm...>]

On 10/24/07, Olivier Croquette <ocr...@fr...> wrote:
>
> Hi
>
> Actually, this debug information is available only if NODEBUG is not set.
>
> It seems the official version is compiled with NODEBUG. I think it's not a
> good
> idea, since prohibits debugging possibilities and bug reports from the
> users.



No the official version (1.5.3) still had the code with the command
commented out
(see
http://svn.planetsaphire.com/viewvc.cgi/trunk/src/portable.cpp?root=doxygen&r1=566&r2=578
)
I need the NODEBUG flag for doxywizard, which also uses portable.cpp but not
the
debug mechanism (that's why I commented it out earlier).

I spent because of that a very long time to find out what the following
> error
> messages were about:
> Error: Problems running epstopdf. Check your TeX installation!
> epstopdf: The input file does not exist.
> (with no other information)
>
> Would it be possible to enable the debug (when using the -d switch) in the
> releases?


Sure, it will work in the next release (and already in the latest SVN
release as well).

Regards,
  Dimitri

Re: [Doxygen-develop] ExtCmd debug information disabled in portable_system

[Olivier C. <ocr...@fr...>]

Hi

Actually, this debug information is available only if NODEBUG is not set.

It seems the official version is compiled with NODEBUG. I think it's not a good
idea, since prohibits debugging possibilities and bug reports from the users.

I spent because of that a very long time to find out what the following error
messages were about:
Error: Problems running epstopdf. Check your TeX installation!
epstopdf: The input file does not exist.
(with no other information)

Would it be possible to enable the debug (when using the -d switch) in the
releases?

Regards

Olivier

Re: [Doxygen-develop] Fortran Support and Doxygen

[Alin M E. <ali...@qu...>]

Hi Dimitri,

> Just look in config.l, and you'll find the list with configuration options.
> Just add a boolean
> entry for yours, let's call it OPTIMIZE_FOR_FORTRAN for clarity.

It worked like a charm.

> I suggest to just implement them in translator.h only, then I'll make a
> translator_adapter for
> it and others can fill in the various translations.

You lost me here. 
Can you give me an example. Let's say I want that 
 virtual QCString trNamespaceDocumentation()
{return "Namespace Documentation"; }
to give me
return "Module Documentation";  if the variable OPTIMIZE_FOR_FORTRAN=YES

I have tried to document my code and I got a list of bugs/problems.
I put in the Doxygen file that I use and a fortran file that replicate the 
problems.
Any help in how to solve them is more than welcome.

Alin




-- 
____________________________________________________________________
"...if the universities will not study useless subjects, who will?"
                           G. F. Fitzgerald, Nature, 45/46, 392 (1892)
______________________________________________________________________
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
ali...@ya...
ali...@qu...
______________________________________________________________________

[Doxygen-develop] ExtCmd debug information disabled in portable_system

[Olivier C. <ocr...@fr...>]

Hi

I am having a hard time tracking down the following messages in a very big
project:

Error: Problems running epstopdf. Check your TeX installation!
epstopdf: The input file does not exist.

I need to know what Doxygen wants epstopdf to do.

The ExtCmd debugging would be very helpful for that.

Unfortunately, the corresponding line:
Debug::print(Debug::ExtCmd,0,"Executing external command %s`\n",fullCmd.data());

has been commented out in the body of portable_system() with this commit:

    Revision 578
    Modified Sun Sep 2 19:15:32 2007 UTC (7 weeks, 1 day ago) by dimitri
    File length: 8962 byte(s)

    Release-1.5.3-20070902

Is there any reason for that?
I really miss this debug information!

Thanks for your help.

Regards
-- 
Olivier

[Doxygen-develop] Anonymous compounds in XML output and typename

[Stephan T. <and...@gm...>]

Hi,

Currently doxygen does not output anonymous enums, structs, unions and 
namespaces in the generated XML. Instead the members of these compounds 
are output as members of the surrounding scope, except in the case of 
enums. Anonymous namespaces are additionally given their own 
"namespace@(...).xml" files, though their members are not documented.

In my opinion it would be desirable if the anonymous compounds weren't 
omitted from the output and its members be outputted as members of the 
compounds. This way the XML output would be closer to the original C++ 
code and would allow for reconstructing the HTML output, which currently 
is not possible.

Similarly, I'd argue that the "typename" qualifier for dependent types 
should not be automatically stripped from types, as it is indispensable 
for correct c++ code and trivial to delete if one doesn't need it.

Best regards,
   Stephan

Re: [Doxygen-develop] Fortran Support and Doxygen

[Dimitri v. H. <do...@gm...>]

Hi Alin,

On 10/12/07, Alin M Elena <ali...@qu...> wrote:
>
> Hi,
>
> I was glad to find out that doxygen supports fortran now. (I have waited
> few
> years for it).
>
> Now I would like to make the output of doxygen to look more fortran like.
> change class -> module, struct -> type ...
> Probably one of the simplest methods will be to have a variable
> OPTIMIZE_OUTPUT_FOR_FXX similar with C.
>
> I had a look in the code and seems that the file(s) that have to be
> changed
> will be src/translator_xx.h. I can invest some time in making the changes
> there.


I suggest to just implement them in translator.h only, then I'll make a
translator_adapter for
it and others can fill in the various translations.


> For that I have to "register" OPTIMIZE_OUTPUT_FOR_FXX (or whatever name is
> found useful). I do no have the time to read the sources to see how to add
> correctly this variable.
> Can you give me some hints about?


Just look in config.l, and you'll find the list with configuration options.
Just add a boolean
entry for yours, let's call it OPTIMIZE_FOR_FORTRAN for clarity.

Regards,
  Dimitri

[Doxygen-develop] Fortran Support and Doxygen

[Alin M E. <ali...@qu...>]

Hi,

I was glad to find out that doxygen supports fortran now. (I have waited few 
years for it).

Now I would like to make the output of doxygen to look more fortran like.
change class -> module, struct -> type ...
Probably one of the simplest methods will be to have a variable
OPTIMIZE_OUTPUT_FOR_FXX similar with C.

I had a look in the code and seems that the file(s) that have to be changed 
will be src/translator_xx.h. I can invest some time in making the changes 
there.
For that I have to "register" OPTIMIZE_OUTPUT_FOR_FXX (or whatever name is 
found useful). I do no have the time to read the sources to see how to add 
correctly this variable. 
Can you give me some hints about?

Alin




-- 
____________________________________________________________________
"...if the universities will not study useless subjects, who will?"
                           G. F. Fitzgerald, Nature, 45/46, 392 (1892)
______________________________________________________________________
Mr. Alin M. ELENA
Atomistic Simulation Centre
School of Mathematics and Physics
Queen's University Belfast
Office: +44 (0)28 9097 1428
Fax: +44 (0)28 9097 5359
http://titus.phy.qub.ac.uk/group/Alin/
ali...@ya...
ali...@qu...
______________________________________________________________________

[Doxygen-develop] CVS -> SVN Conversion Status: Finally got ViewVC Working

[Kevin M. <km...@pt...>]

Hello everyone,

As you all know, I have performed a conversion of my newest project,
stick2xyz, from CVS to SVN.  It can be accessed anonymously with the
following command:

svn co svn://svn.planetsaphire.com/stick2xyz

And now, ViewVC:

http://svn.planetsaphire.com/viewvc.cgi?view=roots

Dimitri: I am ready to begin converting the doxygen CVS over to
Subversion.  Just let me know when you are ready.

- KJM

[Doxygen-develop] Feature Questions

[John M. <jm...@mm...>]

In the code base that I am using Doxygen with there are many classes
that are of the form:
=20
   public static class Severity implements java.io.Serializable
   {
      public static final int INDETERMINATE =3D 0;
      public static final int CRITICAL =3D 1;
      public static final int MAJOR =3D 2;
      public static final int MINOR =3D 3;
      public static final int WARNING =3D 4;
      public static final int CLEARED =3D 5;
   }

=20
After running Doxygen I get a class reference that lists the attributes.
There are two additional things that I think would be nice to happen but
am not sure if Doxygen already does, or someone is working on, or I
could implement, or is not really useful or doable.
=20
One thing would be for all uses of any of the static public attributes
in other files to link back to the definition in the generated class
reference like function calls do.
=20
The other is for the class reference to have links to each use of each
static public attribute in other generated class references.  Currently
the Member Data Documentation for one of the attributes looks something
like:
=20
   final int com.Example Severity.INDETERMINATE =3D 0 [static]
      Definition at line 34 of file AlarmDefine.java.

I'm thinking of something like:
=20
   final int com.Example.Severity.INDETERMINATE =3D 0 [static]
      Definition at line 34 of file Define.java.
      Usage at line 78 of Mapper.java
      Usage at line 238 of Mapper.java
      Usage at line 21 of Processor.java
=20
Do these ideas make sense?  Would they be useful in general?
=20
Thanks for any info or feedback,
=20
John Morey

Re: [Doxygen-develop] Feature request/discussion: Trace to requirements

[Greg S. <gre...@gm...>]

> Larry and others,
>
> What you stated below brings me to my next / parallel project idea  
> I have been thinking about. Managing requirements and traceability  
> is a difficult thing when you get to the concept of platforms,  
> multiple products which may use the platform to do slightly  
> different things (and at some point branch off, etc).
>
> Really what you need is your requirements "branching" and your code  
> "branching" need to be in sync. The other end of the project I have  
> been considering is a web-based requirements management system  
> which would handle this, amongst other things.
>
> But back to the Doxygen point in hand; at some point, I think you  
> have to specify for each branch, a code or groups of code root  
> requirements. Either you do that in the requirements/design  
> documents or you do it in the code. I think it is better for the  
> code to know about the requirements rather than the requirements to  
> "know" about the code.
>
> However, the "set of code" brings me to the next point I have been  
> thinking about. Generally when you trace from requirements to code,  
> you often go through design (software design doc). In my previous  
> company, we were writing our SDDs in Doxygen and at the end of a  
> SDD we would list the groups of code that implemented the design.
>
> So to generalize this, I think @defgroup should be able to trace to  
> requirements, which means every class in that group will trace to  
> the requirements that the group traces to. (Which is also one way  
> to manage what you were stating, then you only have to change the  
> groups requirement tracing, rather than each class).
>
> This also brings me to another point: tracing from requirements ->  
> design -> code -> test. Doxygen can clearly play a strong role in  
> the code -> test (at least some tests) and I believe naturally  
> design -> code. What is missing is the requirements -> design or  
> requirements -> code and knowledge of design -> code. Some options/ 
> ideas I have been thinking about; one is to add an option to @page  
> to stated that the page is an SDD and if a class description  
> references the SDD than it could auto link to the SDD (and create  
> the trace). Or you could require a special command to trace.
>
> My next step is to capture all of these ideas down into stories/ 
> requirements and to start researching the doxygen implementation to  
> investigate feasibility.
>
> Let me know if anyone is interested in these project ideas. I  
> always appreciate a good discussion and viewpoints (and code).
>
> Greg
>
> On Sep 7, 2007, at 11:59 AM, Randall, Larry wrote:
>
>> Well,  I "fat fingered" send instead of save...
>>
>> I was going to say that test cases are constantly added, and software
>> requirements may trace to different code in different release  
>> streams.
>>
>> Perhaps, rather than trying to maintain a set of "traceability  
>> links" in
>> code, we could maintain a unique ID for each "set" of code (i.e.,
>> function, feature, API,.....).  We could then automate traceability
>> linkages in a database.
>>
>> Other ideas ????
>>
>> Regards,
>> Larry
>>
>
> Greg Stern
> gre...@gm...
>
>
>

Greg Stern
gre...@gm...

Re: [Doxygen-develop] Feature request/discussion: Trace to requirements

[Randall, L. <l-r...@ti...>]

Well,  I "fat fingered" send instead of save...

I was going to say that test cases are constantly added, and software
requirements may trace to different code in different release streams. =20

Perhaps, rather than trying to maintain a set of "traceability links" in
code, we could maintain a unique ID for each "set" of code (i.e.,
function, feature, API,.....).  We could then automate traceability
linkages in a database.

Other ideas ????

Regards,=20
Larry=20

Re: [Doxygen-develop] Feature request/discussion: Trace to requirements

[Randall, L. <l-r...@ti...>]

If you are trying to meet CMMI, you actually need BI-DIRECTIONAL
traceability to both requirements and to test cases.  (It would be
interesting to know if anyone has done this in code.)

We could use aliases in code, but that does not address the issue of how
one traces from the test case(s), through the code, through the detailed
software requirement(s), through the functional requirement, to the
conceptual or marketing requirement -- AND the reverse.

The solution we implemented is a traceability matrix.

Regards,=20
Larry Randall

-----Original Message-----
From: dox...@li...
[mailto:dox...@li...] On Behalf Of Greg
Stern
Sent: Thursday, September 06, 2007 22:44
To: dox...@li...
Subject: [Doxygen-develop] Feature request/discussion: Trace to
requirements

Hello.

I was thinking about creating a tool which would add traceability from
code=20
and doxygen pages to "requirements". Requirements traceability analysis
(in=20
my professional experience) seems to be a major gap in existing tools
out=20
there today.

Basically, I'm thinking of adding two tags:
@traceTo (output) and @traceFrom (input/source).  Perhaps more future
advanced=20
requirements would define layers/groups of traces (from Software
Designs,=20
Software Requirments, System Requirements, etc).

In general, I think this could create:
1) Hyperlinks to source requirements in a page
2) Pages of requirements analysis, specifically: Trace matrix, Code that
has=20
no requirements, Code that has no output, etc.

I'm still working out how to interface with requirements databases /
where the=20
requirements would be stored. But before I started any more in depth=20
research, I figured I would post a query to this mailing list and see if
you=20
have either a) thought of this before / started implementing down this
road=20
or b) know of others that have.

Greg

------------------------------------------------------------------------
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
Doxygen-develop mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-develop

[Doxygen-develop] Feature request/discussion: Trace to requirements

[Greg S. <gre...@ya...>]

Hello.

I was thinking about creating a tool which would add traceability from code 
and doxygen pages to "requirements". Requirements traceability analysis (in 
my professional experience) seems to be a major gap in existing tools out 
there today.

Basically, I'm thinking of adding two tags:
@traceTo (output) and @traceFrom (input/source).  Perhaps more future advanced 
requirements would define layers/groups of traces (from Software Designs, 
Software Requirments, System Requirements, etc).

In general, I think this could create:
1) Hyperlinks to source requirements in a page
2) Pages of requirements analysis, specifically: Trace matrix, Code that has 
no requirements, Code that has no output, etc.

I'm still working out how to interface with requirements databases / where the 
requirements would be stored. But before I started any more in depth 
research, I figured I would post a query to this mailing list and see if you 
have either a) thought of this before / started implementing down this road 
or b) know of others that have.

Greg

Re: [Doxygen-develop] CVS -> SVN Conversion Status: Currently testing on new project

[Kevin M. <km...@pt...>]

Kevin McBride wrote:
> Hello everyone,
> 
> I have performed a conversion of my newest project, stick2xyz, from 
> CVS to SVN.  It can be accessed anonymously with the following 
> command:
> 
> svn co svn://cvs.planetsaphire.com/svnroot/stick2xyz

Correction here:

I had the svnserve accidentally run as root, so I ended up having to
create a chroot jail for SVN.  To test the SVN checkout on my server:

svn co svn://cvs.planetsaphire.com/stick2xyz

[Doxygen-develop] CVS -> SVN Conversion Status: Currently testing on new project

[Kevin M. <km...@pt...>]

Hello everyone,

I have performed a conversion of my newest project, stick2xyz, from CVS
to SVN.  It can be accessed anonymously with the following command:

svn co svn://cvs.planetsaphire.com/svnroot/stick2xyz

Unfortunately, I am having problems getting ViewVC to work with
Subversion, so we'll have to look for another project who has scripts
capable of performing the task.  Upgrading from subversion 1.1.4 to
1.4.5 is a major move to make, and so, I am unwilling to downgrade back
to 1.1.4 simply because of an unusable web interface.

If anyone knows of a project other than ViewVC that might be helpful,
please let Dimitri and I know.

Dimitri: I am ready to begin converting the doxygen CVS over to
Subversion when you're ready, despite the lack of a web interface for
subversion until an alternative to ViewVC is found.  In your home
directory on Planet Saphire is an automatically generated tarball
containing the contents of your project's CVS repository, named
'doxygen-cvs-raw.tar.gz'.  The subversion tarball will be called
'doxygen-svn-raw.tar.gz'.

The technical issue behind ViewVC is stated in a bug report with its
developers, although I gave them a different excuse as to why I did not
want to downgrade:

http://viewvc.tigris.org/issues/show_bug.cgi?id=315

The authors of subversion apparently made some sweeping changes to the
subversion python bindings, which is keeping ViewVC from working
properly.  When I looked at the ViewVC bug reports, hardly any of them
were tended to, so I doubt that the changes will be made to ViewVC
anytime soon.

- KJM

[Doxygen-develop] templates and namespaces

[Chuck P. <cp....@tw...>]

Consider

namespace xyzzy {
class A {
public:
     int payloadl;
};
template <class T>
class B :
     public T
{ };
class C :
      public B<A>
{ };
}

The above gives very differnt, and IMO better, result is the outside
namespace
is commented out.

The first major difference I found is difference is driven by the

   while (scopeOffset > 0)

towards the bottom of findClassRelation. I'm just not positive what to do
about it. It pretty obvious that the loop is required to find things not
found in the current scope.  I think I don't want to add the additonal
relation if I find its only related to a relation I've already added.

While namespaces may have had other problems previosuly this particular
problem showed up between doyxgen-1.4.6.2 and 1.4.6.4.

I also noticed that at times there are class names generated of the form
xyzzy::xyzzy::A. This might just be a by product of the first observed
difference. This is likelky what is behind the problem that Brendon
Costa asked about a couple of months ago.


Any comments/guidance would be appreciated.

Chuck

[Doxygen-develop] new release of moritz the nassi-shneiderman generator for doxygen is available

[<Eck...@t-...>]

Hello Everybody.

Since today a new release of moritz the nassi-shneiderman generator for 
doxygen is available under https://sourceforge.net/projects/moritz/.

Due to a bug-report (thanks to Mr. M.-A. Hohm)  moritz generates an 
error-message if the xml-structure of the configuration is corrupted.
Moritz is also a little bit faster now.

Please try it out and use the forum on the sourceforge-side of moritz to 
ask question or to post comments. It is also planed to declear moritz 
stable and to upload the release-version 1.0 . So please don't hasitate 
to use the bug-tracker ( 
https://sourceforge.net/tracker/?group_id=167738&atid=844151 
<https://sourceforge.net/tracker/?group_id=167738&atid=844151> ) if you 
still have problems with moritz.

If you have questions or suggestions please don't hesitate to post them 
in the forum under: https://sourceforge.net/forum/?group_id=167738 
<https://sourceforge.net/projects/moritz/>

Kind Regards,
                        Eckard Klotz.

[Doxygen-develop] multiple return values

[<kra...@gm...>]

Hi!

First of all, thank you for this very useful tool.

I was thinking of writing a parser for MATLAB files or extending the
existing helper, however I found that doxygen does not currently
handle multiple return values. This feature could be useful for
parsing other languages as well I suppose.

Thanks,

Gregoire

Re: [Doxygen-develop] expansion of aliases with multiple references to same argument

[Dimitri v. H. <do...@gm...>]

Hi Robbie,

This is indeed a bug. I'll use a slightly different fix by starting with an
empty result string, i.e.:

  QCString result;
  int p=0,i;
  while ((i=aliasValue.find(paramMarker,p))!=-1) // search for marker
  {
    result+=aliasValue.mid(p,i-p);
    if (i==0 || aliasValue.at(i-1)!='\\') // found unescaped marker
    {
      result += paramValue;
      p=i+markerLen;
    }
    else // ignore escaped markers
    {
      result += aliasValue.mid(i,markerLen);
      p=i+1;
    }
  }
  result+=aliasValue.right(aliasValue.length()-p);

but the result should be the same.

Regards,
   Dimitri

On 7/31/07, Robbie Gates <ro...@m8...> wrote:
>
> Hi All,
>   i'm seeing what looks like a bug with an alias of the form
>     "THING{1} =<a href=\"http://prefix/THING-\1\">THING-\1</a>"
> I was expecting THING{456} to expand to
>     <a href=\"http://prefix/THING-456\">THING-456</a>
> However, with 1.5.3, it looks like i'm getting
>     <a href=\"http://prefix/THING-456\">THING4561</a>
> It looks to me like replaceAliasArgument in util.cpp is the culprit -
> the code uses aliasValue each time around the loop to find the
> replacement index, but uses these as indexes into result. If the alias
> arguments expand to strings of length other than 2, these indexes are
> not in sync after the first replacement.  By replacing aliasValue with
> result in the loop condition and the escaped marker check i get the
> expected behaviour (patch below).
>
> - robbie
>
> 6201c6201
> <   while ((i=aliasValue.find(paramMarker,p))!=-1) // search for marker
> ---
> >   while ((i=result.find(paramMarker,p))!=-1) // search for marker
> 6205c6205
> <     if (i==0 || aliasValue.at(i-1)!='\\') // found unescaped marker
> ---
> >     if (i==0 || result.at(i-1)!='\\') // found unescaped marker
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Doxygen-develop mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-develop
>

[Doxygen-develop] expansion of aliases with multiple references to same argument

[Robbie G. <ro...@m8...>]

Hi All,
  i'm seeing what looks like a bug with an alias of the form
    "THING{1} =<a href=\"http://prefix/THING-\1\">THING-\1</a>"
I was expecting THING{456} to expand to
    <a href=\"http://prefix/THING-456\">THING-456</a>
However, with 1.5.3, it looks like i'm getting
    <a href=\"http://prefix/THING-456\">THING4561</a>
It looks to me like replaceAliasArgument in util.cpp is the culprit -
the code uses aliasValue each time around the loop to find the
replacement index, but uses these as indexes into result. If the alias
arguments expand to strings of length other than 2, these indexes are
not in sync after the first replacement.  By replacing aliasValue with
result in the loop condition and the escaped marker check i get the
expected behaviour (patch below).

 - robbie

6201c6201
<   while ((i=aliasValue.find(paramMarker,p))!=-1) // search for marker
---
>   while ((i=result.find(paramMarker,p))!=-1) // search for marker
6205c6205
<     if (i==0 || aliasValue.at(i-1)!='\\') // found unescaped marker
---
>     if (i==0 || result.at(i-1)!='\\') // found unescaped marker

Re: [Doxygen-develop] [Fwd: Re: CVS still not updated: copy scriptrunning?]

[Arnold.Steve <arn...@en...>]

Yes, I've recently done this on several CVS repositories.  The basic
cvs2svn script preserves all the history, but it puts the entire repo
under one trunk/ directory.

If you have multiple projects in one CVS repo, and you'd prefer each
project under its own trunk/ dir (ie, the standard trunk/, branches/,
tags/ SVN layout) then you need some additional supporting scripts to go
with cvs2svn.  In my case, I wanted the latter setup, and I found this
guy's helper scripts:

http://hoopajoo.net/misc/converting_to_svn.html

which worked fine for me with minor modifications.  And yes, save a copy
of your CVS repo first, and have fun...

Steve


> -----Original Message-----
> From: dox...@li...=20
> [mailto:dox...@li...] On=20
> Behalf Of Dimitri van Heesch
> Sent: Friday, July 27, 2007 7:16 AM
> To: Kevin McBride
> Cc: dox...@li...
> Subject: Re: [Doxygen-develop] [Fwd: Re: CVS still not=20
> updated: copy scriptrunning?]
>=20
> Hi Kevin,
>=20
>=20
> On 7/27/07, Kevin McBride <ke...@pl...> wrote:
>=20
>=20
> 	Dimitri, since I will be going through upgrades, do you=20
> think we're
> 	ready to start using Subversion in place of CVS after=20
> the operating
> 	system rebuild on cvs.planetsaphire.com ?
>=20
>=20
> If I can have a backup of the CVS archive (just in case) and=20
> we can convert the whole archive
> including history to subversion (which should be possible)=20
> then I have not problem with moving.
>=20
> Regards,
>   Dimitri=20
>=20
>=20
>=20

......................................................................
The information contained in this email message is intended only for the us=
e of the individuals to whom it is
addressed and may contain information that is privileged and sensitive. If =
the reader of this message is not
the intended recipient, you are hereby notified that any dissemination, dis=
tribution or copying of this
communication is strictly prohibited. If you have received this communicati=
on in error, please notify the
sender immediately by email at the above referenced address. Thank you.

Re: [Doxygen-develop] [Fwd: Re: CVS still not updated: copy script running?]

[Dimitri v. H. <do...@gm...>]

Hi Kevin,

On 7/27/07, Kevin McBride <ke...@pl...> wrote:
>
>
> Dimitri, since I will be going through upgrades, do you think we're
> ready to start using Subversion in place of CVS after the operating
> system rebuild on cvs.planetsaphire.com?


If I can have a backup of the CVS archive (just in case) and we can convert
the whole archive
including history to subversion (which should be possible) then I have not
problem with moving.

Regards,
  Dimitri