In article <d0la4e$i4n$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>
>Kris wrote:
>
>> .. but it's the config file that does the version() stuff and so  on. It does that by defining certain CPP macros to rename some D keywords.
>
>PREDEFINED             = DOXYGEN_SHOULD_SKIP_THIS \
>                          "version(x)=public class Version##x" \
>                          interface=struct
>
>Interfaces should be able to be handled by Doxygen,
>once the "D mode" is activated (and not crashing...)
>They are pretty similar to Javas, which is supported.
>
>The "missing" semicolons after certain structures
>are also handle with the same "D mode", by the way.
>
>Using "class" for version(x) probably doesn't work
>too good for the "else" statements, or does it ?

Right! It wasn't meant to be 'correct' :-D

I just fussed around with a bunch of different approaches until the Mango documentation started to actually include what it was supposed to. Doxygen is very useful, but there are too many subtle differences going from Java/C++ to D for it to do a primo job. I'll be quite happy when there are better alternatives :-)

Kris wrote:

> I just fussed around with a bunch of different approaches until the Mango
> documentation started to actually include what it was supposed to. Doxygen is
> very useful, but there are too many subtle differences going from Java/C++ to D
> for it to do a primo job. I'll be quite happy when there are better alternatives
> :-)

You mean like "ddoc" or leds html-generator ?
http://dsource.org/projects/ddoc/
http://leds.sourceforge.net/


It's not that there are not alternatives,
see e.g. http://www.doxygen.org/links.html

Just that I find Doxygen to be one of the best.
(have used it for documenting C projects before)


It's really too bad that the D specification doesn't
discuss inline documentation tags ? They're useful...

I use JavaDoc(-ish) tags, because I'm used to them.
But I do find the /// and ///< short forms excellent.

--anders

Kris wrote:
> In article <d0la4e$i4n$1@digitaldaemon.com>,
> =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
> 
>>Kris wrote:
>>
>>
>>>.. but it's the config file that does the version() stuff and so  on. It does
>>>that by defining certain CPP macros to rename some D keywords.
>>
>>PREDEFINED             = DOXYGEN_SHOULD_SKIP_THIS \
>>                         "version(x)=public class Version##x" \
>>                         interface=struct
>>
>>Interfaces should be able to be handled by Doxygen,
>>once the "D mode" is activated (and not crashing...)
>>They are pretty similar to Javas, which is supported.
>>
>>The "missing" semicolons after certain structures
>>are also handle with the same "D mode", by the way.
>>
>>Using "class" for version(x) probably doesn't work
>>too good for the "else" statements, or does it ?
> 
> 
> Right! It wasn't meant to be 'correct' :-D
> 
> I just fussed around with a bunch of different approaches until the Mango
> documentation started to actually include what it was supposed to. Doxygen is
> very useful, but there are too many subtle differences going from Java/C++ to D
> for it to do a primo job. I'll be quite happy when there are better alternatives
> :-)
> 
> 

And I can add a post-commit-hook on SVN (for releases only?) that will do the Doxygen processing on the dsource.org server instead of on your local machine.  Then you don't have to check in the docs as well, and I could move the files over to your public site (i.e. http://mango.dsource.org)

Or do you still want the control down on your local development machine?

BA

In article <d0lbld$jq5$1@digitaldaemon.com>, Brad Anderson says...
>
>Kris wrote:
>> In article <d0la4e$i4n$1@digitaldaemon.com>, =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= says...
>> 
>>>Kris wrote:
>>>
>>>
>>>>.. but it's the config file that does the version() stuff and so  on. It does that by defining certain CPP macros to rename some D keywords.
>>>
>>>PREDEFINED             = DOXYGEN_SHOULD_SKIP_THIS \
>>>                         "version(x)=public class Version##x" \
>>>                         interface=struct
>>>
>>>Interfaces should be able to be handled by Doxygen,
>>>once the "D mode" is activated (and not crashing...)
>>>They are pretty similar to Javas, which is supported.
>>>
>>>The "missing" semicolons after certain structures
>>>are also handle with the same "D mode", by the way.
>>>
>>>Using "class" for version(x) probably doesn't work
>>>too good for the "else" statements, or does it ?
>> 
>> 
>> Right! It wasn't meant to be 'correct' :-D
>> 
>> I just fussed around with a bunch of different approaches until the Mango documentation started to actually include what it was supposed to. Doxygen is very useful, but there are too many subtle differences going from Java/C++ to D for it to do a primo job. I'll be quite happy when there are better alternatives :-)
>> 
>> 
>
>And I can add a post-commit-hook on SVN (for releases only?) that will do the Doxygen processing on the dsource.org server instead of on your local machine.  Then you don't have to check in the docs as well, and I could move the files over to your public site (i.e. http://mango.dsource.org)
>
>Or do you still want the control down on your local development machine?
>
>BA


That would be awesome, Brad!

How would one trigger it? Via the 'admin' page perhaps?

Anders F Björklund wrote:
> Kris wrote:
...
>> for it to do a primo job. I'll be quite happy when there are better alternatives
>> :-)
> 
> 
> You mean like "ddoc" or leds html-generator ?
> http://dsource.org/projects/ddoc/

Not to malign the "ddoc" effort, but it hasn't released any binary or even source yet. At least, all I can find in the repository (http://svn.dsource.org/svn/projects/ddoc/) is a license.

I'm guessing Doxygen has a lot more practical value if you're documenting a project today. :)

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Kris wrote:
>>
>>And I can add a post-commit-hook on SVN (for releases only?) that will do the Doxygen processing on the dsource.org server instead of on your local machine.  Then you don't have to check in the docs as well, and I could move the files over to your public site (i.e. http://mango.dsource.org)
>>
>>Or do you still want the control down on your local development machine?
>>
>>BA
> 
> 
> 
> That would be awesome, Brad! 
> 
> How would one trigger it? Via the 'admin' page perhaps?
> 

Maybe the admin pages as you suggest.  In an extreme case, it can be triggered for every commit.  I'll have to think about it, and how to do it for releases only.  Something like, when you tag a release in /tags.

James Dunne wrote:
> Also, previously unreleased, I have made my own modifications to dfilter.d to
> allow version() blocks translated into #ifdef and #elif and #endif blocks, as
> well as other minor modifications I found helpful.

This has diverged quite a bit from the version I've been maintaining.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/7994

My (not yet implemented) thought on version blocks was that Dfilter should actually filter them, rather than turning them into C preprocessor commands.  Not only does this idea keep all filtering in one place, but having what gets filtered out only dealt with once seems more efficient.

Whatever we do here, we ought to bring versions together on Dsource. Can you remember what your "other minor modifications" do?

> // original author unknown/forgotten by me (feel free to give credit)

Hauke Duden was maintaining it for a while, but hasn't been seen since last July.  Don't know if Hauke was the original author though....

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.

Stewart Gordon wrote:

> My (not yet implemented) thought on version blocks was that Dfilter should actually filter them, rather than turning them into C preprocessor commands.  Not only does this idea keep all filtering in one place, but having what gets filtered out only dealt with once seems more efficient.

That might turn out simpler to do than add support for D
conditional compilation to the Doxygen pre-preprocessor... :-)

> Whatever we do here, we ought to bring versions together on Dsource.

Perhaps even start up a "dfilter" or "ddoxygen" Dsource project for it ?
I put some links on http://www.prowiki.org/wiki4d/wiki.cgi?DoxygenIssues

--anders

In article <d0nag9$2noh$1@digitaldaemon.com>, Stewart Gordon says...
>
>James Dunne wrote:
>> // original author unknown/forgotten by me (feel free to give credit)
>
>Hauke Duden was maintaining it for a while, but hasn't been seen since last July.  Don't know if Hauke was the original author though....

I belive that Burton Radons wrote a dfilter (or at least modified someone else's code) way back when for his Dig library (http://www.opend.org/dig/index.html). I don't know if the current filters are related to his efforts though. It should have looked something like this: http://svn.dsource.org/svn/projects/undig/trunk/net/BurtonRadons/digc/dfilter.d (and I'm sure that any dig edition of dfilter is going to be obsolete).

jcc7

J C Calvarese wrote:
> In article <d0nag9$2noh$1@digitaldaemon.com>, Stewart Gordon says...
> 
>>James Dunne wrote:
>>
>>>// original author unknown/forgotten by me (feel free to give credit)
>>
>>Hauke Duden was maintaining it for a while, but hasn't been seen since last July.  Don't know if Hauke was the original author though....
> 
> 
> I belive that Burton Radons wrote a dfilter (or at least modified someone else's
> code) way back when for his Dig library (http://www.opend.org/dig/index.html). I
> don't know if the current filters are related to his efforts though. It should
> have looked something like this:
> http://svn.dsource.org/svn/projects/undig/trunk/net/BurtonRadons/digc/dfilter.d
> (and I'm sure that any dig edition of dfilter is going to be obsolete).

Burton claimed he managed without a filter.  How, I can't imagine.

http://www.digitalmars.com/drn-bin/wwwnews?digitalmars.D/11272

Stewart.

-- 
My e-mail is valid but not my primary mailbox.  Please keep replies on the 'group where everyone may benefit.