Om documenten te genereren.
http://dephicodetodoc.sourceforge.net/
Om documenten te genereren.
http://dephicodetodoc.sourceforge.net/
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
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)
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.
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 #%&#&%*.
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.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.
Nee. We hebben een redelijk dedicated documentator, die ook veel tijd in de tooling steekt.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?
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.
Ik heb net even zitten experimenteren met DoxyGen en Pas2Dox (http://www.stack.nl/~dimitri/doxygen/) en dat werkt ook prima.
Groeten,
Stefaan
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.
- 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".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 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.
Kortom, jij vindt het zelf leuk als iemand anders die documentatie schrijft? Of ben je zelf die dedicated documentator?Nee. We hebben een redelijk dedicated documentator, die ook veel tijd in de tooling steekt.
Last edited by Paul-Jan; 09-Jan-09 at 17:46.
Hehe. Het was maar een plaagstootje, zoals de hele msg overigens.
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.- Wij wel. Een eigen parser schrijven was ietwat duur voor het genereren van wat documentatie. De compilerbouwers hier vonden 't geen leuk grapje.
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.
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)- Natuurlijk heeft pascal wel een grammatica, net als iedere andere taal.
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).
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.Leuk dat je geen formele grammar-specificatie gebruikt bij het bouwen van je pascal-parser, maar daar had ik 't niet over.
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).
Nee, ik ben niet die documentator, maar heb me wel altijd veel met de documentatie bemoeid, maar dat is meer hand en span.Kortom, jij vindt het zelf leuk als iemand anders die documentatie schrijft? Of ben je zelf die dedicated documentator?
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)
There are currently 1 users browsing this thread. (0 members and 1 guests)
Bookmarks