Results 1 to 10 of 10

Thread: Delphi + JavaDoc = DelphiCodeToDoc

  1. #1
    Christophe
    Join Date
    Jan 2004
    Location
    Belgium, West-Vlaanderen, Nieuwkerke
    Posts
    459

    Delphi + JavaDoc = DelphiCodeToDoc

    Om documenten te genereren.

    http://dephicodetodoc.sourceforge.net/

  2. #2
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Er zijn meer dat soort systemen:
    - pasdoc (is geupgrade naar Delphi)
    - FPC's fpdoc (werkt ook met Delphi source, maar geen Delphi IDE, wel Lazarus IDE integratie) heeft als voordeel dat het niet met vervuilende commentaren in de source werkt.

    Voor een idee van fpdoc layout: http://www.freepascal.org/docs-html/fcl/index.html

  3. #3
    SillyMember
    Join Date
    May 2003
    Location
    Gent
    Posts
    7,725

    Thumbs up

    Quote Originally Posted by marcov View Post
    ... heeft als voordeel dat het niet met vervuilende commentaren in de source werkt.
    Kijk, dat vind ik nu eens echt fantastisch!
    Bravo!
    All methodologies are based on fear. -- Kent Beck.

  4. #4
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Je kan geloof ik in lazarus op identifiers klikken en dan de gegevens invoeren (moet wel een plugin voor geinstalleerd worden, maar die is meegeleverd).

    Ik ben geen expert wat betreft de lazarus integratie, ik gebruik het strict cmdline voor de FPC docs.

    CHM : www.stack.nl/~marcov/lcl.chm

    fulltext indexed, geen andere pakketten nodig, ook geen MS SDK (werkt dus ook op Mac OS X/ppc). Dat wil niet zeggen dat er geen problemen zijn. Op dit moment duurt de fulltext index nog erg lang (40 min voor deze 6MB CHM), maar die is nog erg nieuw. Ook zullen D2005+ features vaak nog niet ondersteund worden (for .. in, methods in records, dat soort dingen. Inline natuurlijk wel)

  5. #5
    Counting your refs Paul-Jan's Avatar
    Join Date
    Feb 2002
    Location
    Lage Zwaluwe
    Posts
    2,160
    Die FPC docs lijken verdacht veel op ons in-huis-brouwsel van een aantal jaar geleden (code-parsing op basis van 't inner circle project, dus ook niet echt de meest up-to-date syntax/grammatica). Wij gebruikten xlt's om de xml om te zetten naar chm, niet bepaald 's werelds meest prettig te onderhouden keuze... en ook niet echt van de vlugge, maar de traagheid van de chm compiler van microsoft overtrof al 't andere toch verreweg.

    Ik vind dit soort tools altijd erg leuk om mee te spelen, tot op het moment dat er daadwerkelijk documentatie geschreven moet worden. Hebben jullie dat ook?

    [edit]Excuses, ik zie nu pas dat dit niet de koffiehoek was.[/edit]
    Last edited by Paul-Jan; 08-Jan-09 at 21:24.

  6. #6
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Paul-Jan View Post
    Die FPC docs lijken verdacht veel op ons in-huis-brouwsel van een aantal jaar geleden (code-parsing op basis van 't inner circle project, dus ook niet echt de meest up-to-date syntax/grammatica).
    Laat ik eens subtiel zijn (voor mijn doen dan

    Ten eerste is het niet verdacht. Waarom zou het verdacht zijn.
    Ten tweede gebruiken compiler bouwers geen 3rd party parser
    Ten derde gebruik je geen grammar voor een Wirthian language maar een recursive decent parser. LALR is voor C #%&#&%*.

    Wij gebruikten xlt's om de xml om te zetten naar chm, niet bepaald 's werelds meest prettig te onderhouden keuze... en ook niet echt van de vlugge, maar de traagheid van de chm compiler van microsoft overtrof al 't andere toch verreweg.
    Ach. Voor inhouse grut is dat minder erg. Ik moet eerlijk zeggen dat 40min voor een 6MB chm in de FPC versie mij ook iets teleur stelt (was <1min voor de fulltext search). Een speciaal programmeurs instinct vertelt mij dat daar ergens iets niet geheel optimaal is (TStringList gebruik?). De fulltext search is pas van December, dus dat zal nog wel verbeteren.

    Ik vind dit soort tools altijd erg leuk om mee te spelen, tot op het moment dat er daadwerkelijk documentatie geschreven moet worden. Hebben jullie dat ook?
    Nee. We hebben een redelijk dedicated documentator, die ook veel tijd in de tooling steekt.

    Voor mij persoonlijk is het zelfs een van de aantrekkingskrachten van het FPC gehobby. Dingen direct goed inzetten, en af maken, een lange termijn planning hebben die verder gaat dan 1,2 jaar.

    Het leert je ook veel dingen over het maken van veelgebruikte software, en wanneer je niet spreekt met meer dan een klein nog geen promillage van je gebruikers
    Last edited by marcov; 09-Jan-09 at 17:21.

  7. #7
    Senior Member
    Join Date
    Jul 2008
    Location
    Ertvelde, Belgi?½
    Posts
    158
    Ik heb net even zitten experimenteren met DoxyGen en Pas2Dox (http://www.stack.nl/~dimitri/doxygen/) en dat werkt ook prima.


    Groeten,


    Stefaan

  8. #8
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Doxygen ken ik wel ja. (hint kijk naar mijn homepage in post #4 :-))

    De pas2dox is niet geheel nieuw voor mij, maar ik heb alleen heel oude versie gezien. Goed te zien dat ze wel door zijn gegaan (al is de laatste release van 2006). Maar goed, ik hou niet van in-source documentatie, ik vind dat rommelig.

  9. #9
    Counting your refs Paul-Jan's Avatar
    Join Date
    Feb 2002
    Location
    Lage Zwaluwe
    Posts
    2,160
    Ten eerste is het niet verdacht. Waarom zou het verdacht zijn.
    Ten tweede gebruiken compiler bouwers geen 3rd party parser
    Ten derde gebruik je geen grammar voor een Wirthian language maar een recursive decent parser. LALR is voor C #%&#&%*.
    - Voor de volledigheid, "verdacht veel lijken op" bedoelde ik in de spreektaal-betekenis "goh wat toevallig dat we op een sterk gelijkaardige documentatiemethode zijn uitgekomen, jammer dat ik dat nou nog niet eerder had gezien".
    - Wij wel. Een eigen parser schrijven was ietwat duur voor het genereren van wat documentatie. De compilerbouwers hier vonden 't geen leuk grapje.
    - Natuurlijk heeft pascal wel een grammatica, net als iedere andere taal. Leuk dat je geen formele grammar-specificatie gebruikt bij het bouwen van je pascal-parser, maar daar had ik 't niet over.

    Nee. We hebben een redelijk dedicated documentator, die ook veel tijd in de tooling steekt.
    Kortom, jij vindt het zelf leuk als iemand anders die documentatie schrijft? Of ben je zelf die dedicated documentator?
    Last edited by Paul-Jan; 09-Jan-09 at 17:46.

  10. #10
    mov rax,marcov; push rax marcov's Avatar
    Join Date
    Apr 2004
    Location
    Ehv, Nl
    Posts
    10,357
    Quote Originally Posted by Paul-Jan View Post
    - Voor de volledigheid, "verdacht veel lijken op" bedoelde ik in de spreektaal-betekenis "goh wat toevallig dat we op een sterk gelijkaardige documentatiemethode zijn uitgekomen, jammer dat ik dat nou nog niet eerder had gezien".
    Hehe. Het was maar een plaagstootje, zoals de hele msg overigens.

    - Wij wel. Een eigen parser schrijven was ietwat duur voor het genereren van wat documentatie. De compilerbouwers hier vonden 't geen leuk grapje.
    Ik was misschien wat te sterk; als je source hebt, en in staat bent modificaties te maken is het minder erg. Zonder dat zou ik het niet willen. Voor je weet ben je je eigenlijke code aan het passen om het door de documentatie-parser te krijgen.

    Overigens is een pascal parser niet zo lastig, zolang het geen compiler is. Die van het documentatie tool is zelfs in een herbruikbaar library formaat en ongeveer 160k.

    - Natuurlijk heeft pascal wel een grammatica, net als iedere andere taal.
    Waarom is dat natuurlijk? (Veel talen hebben een heel ruw context-free grammar, maar dat is voor documentatie en studie doeleinden, maar het klopt bij lange na niet genoeg om de taal volledig vast te leggen. Iets wat je in compiler-bouw cursussen vaak niet hoort)

    Want als je een volledig kloppend Delphi grammar hebt, dan hoor ik het graag (en nee, dat in de Delphi documentatie komt niet eens in de buurt).

    Leuk dat je geen formele grammar-specificatie gebruikt bij het bouwen van je pascal-parser, maar daar had ik 't niet over.
    De meeste productie compilers doen dat overigens niet. MSVC, gcc C en C++ (na 4), Delphi zijn vziw allemaal RD. Dat voor C++ doen zou overigens geen hobby zijn voor mij, brr.

    Dit omdat er meer bij een parser komt kijken dan alleen parsen van correcte grammars. Met name de mogelijkheid om zeer specifiek kleine modificaties te doen in een backward compatible manier (zonder bergen regels te moeten dupliceren) en correcte foutmeldingen zijn een pijnpunt bij parsergenerators.

    Al moet ik daarin toegeven dat ik alleen enkele van de honderden Yacc/Lex clonen heb gebruik, en minder het commerciele spul.

    En zoals gezegd is RD voor Wirthian talen eerder regel dan uitzondering. Die zijn doorgaans ruwweg LL(1).

    Kortom, jij vindt het zelf leuk als iemand anders die documentatie schrijft? Of ben je zelf die dedicated documentator?
    Nee, ik ben niet die documentator, maar heb me wel altijd veel met de documentatie bemoeid, maar dat is meer hand en span.

    Overigens ik zou daar geen moeite mee hebben dat te zijn. Michael was me simpel voor, en dedicated documentators zijn vaak nogal territoriaal :-)
    Maar ik was na hem de eerste die de documentatie zelf bouwde en er tijd aan besteedde.

    Op dit moment doe ik vooral faqs tbv interne documentatie. Vaak factfinding over nieuwe domeinen. (crosscompiling in het verleden, nu packages/dynlinking en wat we met de Tiburon functionaliteit gaan doen)

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •