pasdoc-main

[Pasdoc-main] PasDoc2 (was: public type problem)

[Michalis K. <mic...@gm...>]

> 2. Then I tested it on "a.pas"
> 3. I tried tests/ok_generic.pas from trunk test-suite

To clarify: I was testing PasDoc2 on these files to find what new
ObjectPascal features are implemented in PasDoc2 branch. If there are
none (only unproven promises of better design) then I don't see a point
of PasDoc2.

Michalis

Re: [Pasdoc-main] public type problem

[Michalis K. <mic...@gm...>]

Aleš Pavel wrote:
> Thanks for your help but , change all source for documentation? No thanks :)
> 

I guess you're answering to my initial response, with "{$ifndef PASDOC}"
trick? See my and Arno later mails --- my initial response was
incorrect, we actually have this already implemented in pasdoc.

Just use PasDoc from SVN, for example by downloading
http://michalis.ii.uni.wroc.pl/pasdoc-snapshots/ , and you'll get what
you need :)

Michalis

[Pasdoc-main] PasDoc2 (was: public type problem)

[Michalis K. <mic...@gm...>]

(I changed the subject, we diverged from original Ales question here.)

First of all, looks like we already have what we need in trunk. It was
done quickly, without any major redesign of everything, and without
breaking anything that worked, by Arno. That was the solution I was
hoping to see, and we already have it. Remember that my initial response
("patches welcome") to thread "public type problem" was my mistake ---
we already have this implemented in pasdoc trunk. Local types, local
constants etc. already work.

Maybe the current trunk solution needs to be improved --- testcases that
fail are welcome, and let's make a solution that fixes them. If you can
provide examples that fail to be handled by trunk, but are handled by
PasDoc2 --- that would be great.

> 1. Provide a renewed internal structure, that can handle all the new
> syntax elements, and optionally the parsing of the implementation
> section. If you don't like the PasDoc2 model, provide your own or accept
> some other model.

No. Sorry, but that's equivalent to just doing the whole work myself. If
I would have time, I would do this. And I don't want to block other
people's work, but if it breaks pasdoc (introduces regressions and bad
design), I can't merge it to trunk.

To put in bluntly, I'm not interested in PasDoc2 anymore. It introduces
in a complicated and buggy way something that we already have, nice and
bug-free, in trunk.

I tested PasDoc2 again right now (from SVN branches/closed/PasDoc2,
compiled with simple "make", using FPC 2.4.4), and here are the results:

1. It's broken, answering "Fatal Error: No Source Files have been
specified." no matter what is on the command-line. Ok, so I debugged and
fixed it (needs "Generator.Options := Options;" inside TPasDoc.Execute
before calling Generator.Execute).

2. Then I tested it on "a.pas" that was attached to my previous mail in
"public type problem" thread. This tests Ales' example with type inside
class, and tests FPC
http://wiki.lazarus.freepascal.org/class_extensions_examples . PasDoc2
not only fails to parse it (unhandled section in CIO: reserved word
"type"), but also does "Fatal Error: Access violation" at the end.

3. I tried tests/ok_generic.pas from trunk test-suite. PasDoc2 again
fails to parse it, and also again does additional "Fatal Error: Access
violation" at the end.

I'm sorry, but that's the kind of experience I always have with PasDoc2.
New bugs, and no visible new features. The fact that since a long time
you're only talking about PasDoc2, not addressing any bugs that are
mentioned on this list, doesn't help.

So I simply don't see any need to work on integrating the remaining of
PasDoc2.

Michalis

Re: [Pasdoc-main] public type problem

[Aleš P. <ta...@su...>]

Thanks for your help but , change all source for documentation? No thanks :)

A.

2011/6/29 Hans-Peter Diettrich <DrD...@ao...>:
> Michalis Kamburelis schrieb:
>
>> Rereading my own mail a couple of hours later, I probably wrote this too
>> harsh, sorry for that. I just felt like this was discussed and closed
>> already.
>
> The same for me :-(
>
> I'm still willing to contribute, but my efforts should not end up again
> in the current fruitless situation. That's what I want to prevent by the
> listed prerequisites. I'd be comfortable with the implementation of an
> alternative parser, that I could use myself, without an obligation to
> make it the official PasDoc parser.
>
> After my recent work on the FPC parser, and now also having a copy of
> Delphi XE at hand, I can proceed with the implementation of an parser
> for the new syntax (including implementation sections). The remaining
> work would be reduced to the integration of that parser into PasDoc.
>
> DoDi
>
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Pasdoc-main mailing list
> Pas...@li...
> https://lists.sourceforge.net/lists/listinfo/pasdoc-main
>

Re: [Pasdoc-main] public type problem

[Hans-Peter D. <DrD...@ao...>]

Michalis Kamburelis schrieb:

> Rereading my own mail a couple of hours later, I probably wrote this too
> harsh, sorry for that. I just felt like this was discussed and closed
> already.

The same for me :-(

I'm still willing to contribute, but my efforts should not end up again 
in the current fruitless situation. That's what I want to prevent by the 
listed prerequisites. I'd be comfortable with the implementation of an 
alternative parser, that I could use myself, without an obligation to 
make it the official PasDoc parser.

After my recent work on the FPC parser, and now also having a copy of 
Delphi XE at hand, I can proceed with the implementation of an parser 
for the new syntax (including implementation sections). The remaining 
work would be reduced to the integration of that parser into PasDoc.

DoDi

Re: [Pasdoc-main] public type problem

[Hans-Peter D. <DrD...@ao...>]

Michalis Kamburelis schrieb:
> Hans-Peter Diettrich wrote:
>> What's wrong with the "patches" in PasDoc2?
>>
> 
> We already discussed this long time ago, way too many times. To repeat:
> 1. There are bugs in PasDoc2 branch. And it seems noone had time to fix
> them.

Depends on what is considered a bug. I've stripped down the accepted 
syntax to D7, because all later extensions require changes to the 
internal PasDoc structure.

> 2. They break the design (like separation between parser and
> generators) too much.

I've touched the generators only for debugging purposes, i.e. to obtain 
some output from given input. (see below)

> And they are using large commits, that change many
> things at once --- so they cannot be separated and tested easily.

Right, many commits cannot be broken down, because intermediate steps 
won't compile (e.g. lots of units affected).

> And by the way, some useful changes *were* applied to trunk from PasDoc2
> (like PasDoc_Languages, or SimpleXML changes). The rest is not usable,
> as far as I'm concerned. Of course, anyone is always welcome to extract
> useful changes from it and submit.

I only see one chance for further cooperation:

1. Provide a renewed internal structure, that can handle all the new 
syntax elements, and optionally the parsing of the implementation 
section. If you don't like the PasDoc2 model, provide your own or accept 
some other model.

I can provide some information about the requirements of these 
extensions, the complete syntax still has to be explored.

2. Make the generators work with that new structure, e.g. add 
capabilities for handling local type declarations. The according 
implementation may require further changes to the internal structures.

3. Make sure that the new structure is usable by the new parser.

Most requirements herefore should be known from step 1, I'm willing to 
check the new parser interface for completeness.


When all this has been done, the existing parser can be extended 
according to the new syntax, or an alternative parser can be implemented 
independently. Only then I can resume my work, without being made 
responsible for anything outside the parser.


> See the thread "[Pasdoc-main] PasDoc 0.12.0 release next week, and
> decisions for PasDoc2 branch" in mailing list archives. And see threads
> linked from there.

Sorry, the supplied link (about PasDoc2) is broken, leads to "VR 
Juggler" :-(

> Please, let's not repeat the same discussion over and
> over, and please don't repeat something you already said many times
> (like "I'm waiting for someone to design a better model" or "the bugs
> are unavoidable").

I've tried to summarize my expectations above. If these don't please 
you, suggest an alternative procedure.

DoDi

Re: [Pasdoc-main] public type problem

[Michalis K. <mic...@gm...>]

Michalis Kamburelis wrote:
> Hans-Peter Diettrich wrote:
>> What's wrong with the "patches" in PasDoc2?
>>
> 
> We already discussed this long time ago, way too many times. To repeat:

Rereading my own mail a couple of hours later, I probably wrote this too
harsh, sorry for that. I just felt like this was discussed and closed
already.

Michalis

Re: [Pasdoc-main] PasDoc snapshots generated automatically every night

[Michalis K. <mic...@gm...>]

Michalis Kamburelis wrote:
> For now only the command-line pasdoc is compiled in the snapshots.
> I may install later lazarus on the server, and compile also pasdoc_gui
> (by lazbuild) for snapshots, if there's a demand :)

Update:

- pasdoc_gui is now included in the snapshots. Both for Linux/32 and
Windows/32. So the snapshots now really contain everything, just like
regular releases.

- I added my snapshot script to SVN, inside trunk/www/snapshots/. Maybe
it will be useful as an example how to set such thing.

Michalis

[Pasdoc-main] PasDoc snapshots generated automatically every night

[Michalis K. <mic...@gm...>]

Hi,

On this page:

  http://michalis.ii.uni.wroc.pl/pasdoc-snapshots/

you will find PasDoc snapshots, build every night from latest SVN code.
For now, these are for Linux/32-bit and Windows/32-bit. This is for
people that want to try the latest pasdoc features, without downloading
and compiling themselves pasdoc sources from SVN.

This page is also linked from
http://pasdoc.sipsolutions.net/DevelopmentSnapshots .

For now only the command-line pasdoc is compiled in the snapshots.
I may install later lazarus on the server, and compile also pasdoc_gui
(by lazbuild) for snapshots, if there's a demand :)

Some more info if you're curious:

- The server itself runs Linux/32-bit, and I setup necessary files to
cross-compile to Windows/32-bit.

- I attach the trivial bash script I use to prepare the snapshots.

- This is run by cron every night at 4:05 in local Polish time, which
equals 2:05 UTC in the summer (right now) and 3:05 UTC in the winter.
(Yes, we hate DST :)

- It's compiled using FPC 2.4.4. I use this server to also host
snapshots of my other FPC projects, so I usually quickly upgrade FPC to
latest stable FPC release.

- To keep disk space low, we only keep builds from last 7 days (this can
be probably increased to larger but reasonable numbers, like a month or
longer, if a need arises). That is, after building the snapshot
succeeded, we delete older snapshots. When something failed, we do not
delete any snapshots (so, even in case pasdoc compilation is broken for
some time, we'll always have some good version in snapshots).

Have fun,
Michalis

Re: [Pasdoc-main] public type problem

[Michalis K. <mic...@gm...>]

Hans-Peter Diettrich wrote:
> What's wrong with the "patches" in PasDoc2?
> 

We already discussed this long time ago, way too many times. To repeat:
1. There are bugs in PasDoc2 branch. And it seems noone had time to fix
them. 2. They break the design (like separation between parser and
generators) too much. And they are using large commits, that change many
things at once --- so they cannot be separated and tested easily.

And by the way, some useful changes *were* applied to trunk from PasDoc2
(like PasDoc_Languages, or SimpleXML changes). The rest is not usable,
as far as I'm concerned. Of course, anyone is always welcome to extract
useful changes from it and submit.

See the thread "[Pasdoc-main] PasDoc 0.12.0 release next week, and
decisions for PasDoc2 branch" in mailing list archives. And see threads
linked from there. Please, let's not repeat the same discussion over and
over, and please don't repeat something you already said many times
(like "I'm waiting for someone to design a better model" or "the bugs
are unavoidable").

Michalis

Re: [Pasdoc-main] public type problem

[Hans-Peter D. <DrD...@ao...>]

Michalis Kamburelis schrieb:
> Aleš Pavel wrote:
>> I used to studio 20011 abd exists some solution for error by
>> generating  public type?
>> without rewrite sources, of course.
>>
>> example:
>>
>>   { Metric class }
>>   TMetricClass = class
>>     public type <-- ERROR
> 
> Unfortunately, PasDoc doesn't support such constructs for now. (FPC also
> has them, see
> http://wiki.lazarus.freepascal.org/class_extensions_examples ). Patches
> (changes will be needed at least in PasDoc_Parser, and in PasDoc_Items
> hierarchy) are welcome. This isn't so trivial to implement, but should
> be doable.

What's wrong with the "patches" in PasDoc2?

DoDi

Re: [Pasdoc-main] public type problem

[Michalis K. <mic...@gm...>]

Arno Garrels wrote:
> Huch? Works fine here, am I missing something? It's a nested record which
> should be supported. However I'm not using the latest SVN revision.
> 

Ah, you're right!

I tested with old released PasDoc 0.12.1 binary, and saw the example
fail there. As embarrassing as it sounds, I simply forgot that we
actually have this implemented in SVN (and thanks to you, as far as I
remember!). Looks like it's been too long since I've done active work on
pasdoc :)

So, Ales: the good news is that your example works fine with PasDoc from
SVN, thanks to Arno Garrels work. For now, you either have to compile
PasDoc yourself (links to SVN and compilation instructions are at the
bottom of http://pasdoc.sipsolutions.net/ ), or you have to wait for
next PasDoc 0.13.0 release. Maybe someone can post here a Windows binary
of pasdoc svn? (I can post a Linux 32-bit one.)

For reference, I attach a test unit with Ales record, and with some
additions from
http://wiki.lazarus.freepascal.org/class_extensions_examples . They all
work fine with PasDoc SVN now :)

Michalis

Re: [Pasdoc-main] public type problem

[Arno G. <arn...@gm...>]

----- Original Message ----- 
From: "Michalis Kamburelis" <mic...@gm...>
To: "Discussion, announcements,questions concerning pasdoc" <pas...@li...>
Sent: Tuesday, June 28, 2011 6:33 PM
Subject: Re: [Pasdoc-main] public type problem


Aleš Pavel wrote:
> I used to studio 20011 abd exists some solution for error by
> generating  public type?
> without rewrite sources, of course.
> 
> example:
> 
>   { Metric class }
>   TMetricClass = class
>     public type <-- ERROR

Unfortunately, PasDoc doesn't support such constructs for now. (FPC also
has them, see

Huch? Works fine here, am I missing something? It's a nested record which
should be supported. However I'm not using the latest SVN revision.

-- 
Arno Garrels

Re: [Pasdoc-main] public type problem

[Michalis K. <mic...@gm...>]

Aleš Pavel wrote:
> I used to studio 20011 abd exists some solution for error by
> generating  public type?
> without rewrite sources, of course.
> 
> example:
> 
>   { Metric class }
>   TMetricClass = class
>     public type <-- ERROR

Unfortunately, PasDoc doesn't support such constructs for now. (FPC also
has them, see
http://wiki.lazarus.freepascal.org/class_extensions_examples ). Patches
(changes will be needed at least in PasDoc_Parser, and in PasDoc_Items
hierarchy) are welcome. This isn't so trivial to implement, but should
be doable.

Until then, you may trick PasDoc into omitting the problematic code by

  { Metric class }
  TMetricClass = class
    public

    {$ifndef PASDOC}
    type
      { Metric struct }
      TMetricStruct = record
        MinTime: integer;
        MaxTime: integer;
        AvgTime: integer;
        Attempts: integer;
        TotalTime: integer;
        LastAttempt: integer;
      end;
    {$endif}

...

and then define PASDOC symbol when generating the docs. For example, run
"pasdoc --define PASDOC yoursources.pas" if you use pasdoc from
command-line (pasdoc_gui also has appropriate tab to set this). Of
course, this means that docs will be a little incomplete.

Michalis

[Pasdoc-main] public type problem

[Aleš P. <ta...@su...>]

I used to studio 20011 abd exists some solution for error by
generating  public type?
without rewrite sources, of course.

example:

  { Metric class }
  TMetricClass = class
    public type <-- ERROR
      { Metric struct }
      TMetricStruct = record
        MinTime: integer;
        MaxTime: integer;
        AvgTime: integer;
        Attempts: integer;
        TotalTime: integer;
        LastAttempt: integer;
      end;



sorry for my bad english

Ales

[Pasdoc-main] [ pasdoc-Feature Requests-3314651 ] Parsing implementation section

[SourceForge.net <no...@so...>]

Feature Requests item #3314651, was opened at 2011-06-10 13:16
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GUI interface (pasdoc_gui)
Group: None
Status: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing implementation section

Initial Comment:
Hi, Im a brazilian guy.
Sorry for my poor english, but Ill try.
When "Parsing implementation section", will be implemented? If this will.
I know PasDoc Yesterday.
Can I help in this feature?
My e-mal: ro...@so...
Regards

----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2011-06-13 04:58

Message:
Changes to internal data structures (PasDoc_Items) and generators are of
course allowed, and can be done by anyone. As long as they are sensible and
don't break existing features. No need to discourage here anyone.

For basic implementation of "getting comments from implementation
section", I don't think that such changes are really necessary --- you just
add comments (from the implementation section) to the items you already
seen in the interface. That's assuming that you only want to document
things visible in the interface, which is what people usually want from
this feature (I guess; see the thread linked from the bottom of
http://pasdoc.sipsolutions.net/WantedFeaturesParsingImplementation , you
can make command-line option like --parse-implementation=only-for-interface
/ --parse-implementation=all).

In any case, the required changes to any data structures are of course
allowed, no one said they are cast in stone.

----------------------------------------------------------------------

Comment By: Dr. Diettrich (drdiettrich)
Date: 2011-06-11 00:17

Message:
Parsing additional sections (also in classes) requires changes to the
internal data structures, where the parse results are stored, and to the
document generators, which have to deal with these changed structures.
You'll find out yourself what has to be added, when you update the parser,
but it's unlikely that somebody else will touch the internal data
structures and generators.


----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2011-06-10 19:29

Message:
Right now no one is working on this, I'm afraid. If you need this feature,
you're most welcome to implement it yourself. See
http://pasdoc.sipsolutions.net/WantedFeaturesParsingImplementation

I'm closing this (duplicate of item #2859413, "Parse Comments in
Implementation Section").

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3314651 ] Parsing implementation section

[SourceForge.net <no...@so...>]

Feature Requests item #3314651, was opened at 2011-06-10 13:16
Message generated for change (Comment added) made by drdiettrich
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GUI interface (pasdoc_gui)
Group: None
Status: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing implementation section

Initial Comment:
Hi, Im a brazilian guy.
Sorry for my poor english, but Ill try.
When "Parsing implementation section", will be implemented? If this will.
I know PasDoc Yesterday.
Can I help in this feature?
My e-mal: ro...@so...
Regards

----------------------------------------------------------------------

Comment By: Dr. Diettrich (drdiettrich)
Date: 2011-06-11 00:17

Message:
Parsing additional sections (also in classes) requires changes to the
internal data structures, where the parse results are stored, and to the
document generators, which have to deal with these changed structures.
You'll find out yourself what has to be added, when you update the parser,
but it's unlikely that somebody else will touch the internal data
structures and generators.


----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2011-06-10 19:29

Message:
Right now no one is working on this, I'm afraid. If you need this feature,
you're most welcome to implement it yourself. See
http://pasdoc.sipsolutions.net/WantedFeaturesParsingImplementation

I'm closing this (duplicate of item #2859413, "Parse Comments in
Implementation Section").

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3314651 ] Parsing implementation section

[SourceForge.net <no...@so...>]

Feature Requests item #3314651, was opened at 2011-06-10 13:16
Message generated for change (Comment added) made by kambi
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GUI interface (pasdoc_gui)
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing implementation section

Initial Comment:
Hi, Im a brazilian guy.
Sorry for my poor english, but Ill try.
When "Parsing implementation section", will be implemented? If this will.
I know PasDoc Yesterday.
Can I help in this feature?
My e-mal: ro...@so...
Regards

----------------------------------------------------------------------

>Comment By: Michalis Kamburelis (kambi)
Date: 2011-06-10 19:29

Message:
Right now no one is working on this, I'm afraid. If you need this feature,
you're most welcome to implement it yourself. See
http://pasdoc.sipsolutions.net/WantedFeaturesParsingImplementation

I'm closing this (duplicate of item #2859413, "Parse Comments in
Implementation Section").

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

[Pasdoc-main] [ pasdoc-Feature Requests-3314651 ] Parsing implementation section

[SourceForge.net <no...@so...>]

Feature Requests item #3314651, was opened at 2011-06-10 11:16
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: GUI interface (pasdoc_gui)
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Parsing implementation section

Initial Comment:
Hi, Im a brazilian guy.
Sorry for my poor english, but Ill try.
When "Parsing implementation section", will be implemented? If this will.
I know PasDoc Yesterday.
Can I help in this feature?
My e-mal: ro...@so...
Regards

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=354213&aid=3314651&group_id=4213

[Pasdoc-main] Spam in [ pasdoc-Bugs-1595890 ], disabled anonymous bug reporting

[Michalis K. <mic...@gm...>]

As you can see, our bugtracker was just spammed. (The actual bugreport,
"[ pasdoc-Bugs-1595890 ] uncompilable in Delphi 5", is resolved since a
long time, the only new thing was the comment from anonymous containing
some links.)

This was just a single spam comment. I hide it, although you (people
subscribed to pasdoc-main) were able to see it :)

To prevent further spamming, I disabled anonymous posting to our bug
tracker (at least for now). You will have to sign in with SourceForge
account to submit bugs/comment from now on. A pity (I liked the idea to
allow people to submit/comment without registering), but there's no
other easy solution as far as I know for SF tracker.

Michalis

[Pasdoc-main] [ pasdoc-Bugs-1595890 ] uncompilable in Delphi 5

[SourceForge.net <no...@so...>]

Bugs item #1595890, was opened at 2006-11-13 21:14
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=1595890&group_id=4213

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Burov Dmitry (arioch_bdv)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncompilable in Delphi 5

Initial Comment:
1) there is no such thing as BoolToStr in Delphi 5
2) PasDoc_GenHtml.pas: need path in INCLUDE comments

const 
  img_automated : {$I images\automated.gif.inc};
  img_private   : {$I images\private.gif.inc};
  img_public    : {$I images\public.gif.inc};
  img_published : {$I images\published.gif.inc};
  img_protected : {$I images\protected.gif.inc};

----------

3) is there any icons for component palette ?

4) what is that HelpGenerator, referenced in PasDoc 
GUI ? Is there some other GUI for win32 ?

5) Is there any comparision of PasDoc with 
DelphiCodeToDoc or DiPasDoc ?
DCTD is hardly compilable in D5 - it uses class 
variables and properties... Perhaps after patching 
this there'd be more rooks under the feet.
Did not tried DiPasDoc yet.



----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2011-04-06 23:49

Message:
aqQM91  <a href="http://zjtbhqrvopht.com/">zjtbhqrvopht</a>,
[url=http://afckgqoimlbk.com/]afckgqoimlbk[/url],
[link=http://mxmxcwvkuwon.com/]mxmxcwvkuwon[/link],
http://rjfggxnqanjm.com/

----------------------------------------------------------------------

Comment By: Burov Dmitry (arioch_bdv)
Date: 2006-11-22 21:21

Message:
Logged In: YES 
user_id=406841
Originator: YES

in Delphi GUI there is such a thing as ($Delphi) for Delphi installation
folder.
And relatives paths are relative to the project (.dpk or .dpr)

i think (but aint sure) it is the same for dof or cfg

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2006-11-19 09:05

Message:
Logged In: YES 
user_id=987895
Originator: NO

I added your pasdoc_package.cfg and pasdoc_package.dof. Unfortunately I
had to remove search paths as they used absolute paths, so wouldn't work on
anyone's system. You should see if we can put relative filenames there
(does Delphi allow it ?), or people will just have to add search paths
themselves.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2006-11-19 08:53

Message:
Logged In: YES 
user_id=987895
Originator: NO

2) No, it was fixed by setting SVN "svn:eol-style : CRLF". It doesn't
matter what line endings Makefile will generate, they will get converted to
CRLF.

----------------------------------------------------------------------

Comment By: Burov Dmitry (arioch_bdv)
Date: 2006-11-18 18:15

Message:
Logged In: YES 
user_id=406841
Originator: YES

2) as far as ia can tell, it was done manually, not via Makefile editing.
Hence next time You'd update D7 package and run make in d5 folder - the
uncompilable UNIX=endings file would be generated again :(

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2006-11-17 05:01

Message:
Logged In: YES 
user_id=987895
Originator: NO

2) Line ending fixed
1) Because search path is not recorded inside .dpk file. Provide us
according pasdoc_package.cfg and/or pasdoc_package.dof file for Delphi 5
and I'll put it into the repository.

----------------------------------------------------------------------

Comment By: Burov Dmitry (arioch_bdv)
Date: 2006-11-16 20:42

Message:
Logged In: YES 
user_id=406841
Originator: YES

It does not compile.

1) Images folder is not in the search path
2) line end is in unix style (LF only), until i converted it to DOS style
(CR, LF) with unired.sf.net - Delphi aborted compilation with "line too
long" error.

PS: i'd have to relook at PG, afair it is console application.
At least You would have the same torubles like me with PasDoc GUI :-)


----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2006-11-16 07:39

Message:
Logged In: YES 
user_id=987895
Originator: NO

I looked at your package file for Delphi 5, and added to pasdoc repository
(in source/packages/delphi/win32/5.0/) an equivalent pasdoc_package.dpk.
Please check it, but it should be equivalent (i.e. Delphi 5 should
understand it) to your attached package. It's automatically generated
(using sed, from the Makefile) from Delphi 7 package, so maintenance will
be easy.

I looked at PackageGenerator from JediVCL and the idea is fine:
automatically generate package files for various Delphi/Kylix versions
based on a single XML file. But the fact that it's only Windows VCL
application (and probably compileable only under Delphi, not FPC) makes it
quite useless for me.

That said, you're welcome to prepare appropriate XML file for
PackageGenerator and generate the pasdoc packages for various versions. And
then I would depend on you to occasionaly rerun PackageGenerator each time
I changed something in package XML file.

----------------------------------------------------------------------

Comment By: Burov Dmitry (arioch_bdv)
Date: 2006-11-15 22:16

Message:
Logged In: YES 
user_id=406841
Originator: YES

this is package for Delphi 5
I saw You made changes to Delphi 7 DPK, so i'd rather just upload delphi 5
DPK

Put attention to required list
There was no RTL package in Delphi 5 and "required" needed versions
numbers in package names.

I still think that the best way would be to use PackageGenerator from
JediVCL rather than put into SVN files that "are expected to work" with no
one of developers tyo check/maintain

----------------------------------------------------------------------

Comment By: Burov Dmitry (arioch_bdv)
Date: 2006-11-15 22:11

Message:
Logged In: YES 
user_id=406841
Originator: YES

this is package for Delphi 5
I saw You made changes to Delphi 7 DPK, so i'd rather just upload delphi 5
DPK

Put attention to required list
There was no RTL package in Delphi 5 and "required" needed versions
numbers in package names.

I still think that the best way would be to use PackageGenerator from
JediVCL rather than put into SVN files that "are expected to work" with no
one of developers tyo check/maintain

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2006-11-15 06:55

Message:
Logged In: YES 
user_id=987895
Originator: NO

AD 1) As for common unit names: this was indeed a problem, waiting to be
fixed for SVN migration (renaming files in CVS is a pain, you lose all
logs). I just did a large commit renaming all ambigous files, including
Utils and Hashes (they are now prefixed with PasDoc_).

As for StrUtils unit: StrUtils.pas included in our sources is only for
Delphi 5 compatibility, read comments inside. FPC and newer Delphi already
include StrUtils unit.

----------------------------------------------------------------------

Comment By: Burov Dmitry (arioch_bdv)
Date: 2006-11-14 19:25

Message:
Logged In: YES 
user_id=406841
Originator: YES

1. ok.
BTW, names like Utils, Hashes and so one seems to be dangerously common.
For example StrUtils did 

2. quoting D5 help:
Delphi searches in the directories specified in the Search path input box
on the Directories/Conditionals page of the Project|Options dialog box
However to me Search inpud did not helped.
Strange, this time it did the trick. And yesterday Ctrl+Shift+F11 seemed
to open default project options, not PasDoc's one. Strange.
However there is no DOF not DPK nor anything for Delphi's but Delphi 7.0
Perhaps You could consider Package Generator from JediVCL to make them.

3. I am not painter. And i can't comiple pasdoc_gui :-)
It seems that You live in Lazarus and Delphi IDE integration is a hard and
low priority task for You :-)
Perhaps HelpGenerator would be of some help to me :-)

4. Can this be put onto wiki and into gui readme ? Google did not help me
to find the tool and pasdoc_gui is not usable within Delphi.

5. DelphiCodeToDoc seems to cease Delphi 5 support.
While in general their GUI looks promising.
DiPasDoc also claims to have some design-time component.

As for PasDoc, AFAIR it curently can generate only Latin1-encoded help, if
forget to specify command-line options. 
It seems currently i cannot save options like used charset for reading
sources and for writing help, for using **-mode and others.
PasDoc seems to have little integration into IDE's building process.
Or perhaps there's now quick intro for it :-)

Alas i am quite short of time and cannot contribute now, only to predate.

----------------------------------------------------------------------

Comment By: Michalis Kamburelis (kambi)
Date: 2006-11-14 02:21

Message:
Logged In: YES 
user_id=987895

AD 1) Should be fixed now.

AD 2) This shouldn't be needed. images/ subdirectory should
be in include path of pasdoc project file for Delphi 5. If
it's not, then the project file (I think Delphi 5 uses
pasdoc.dof, although I'm not sure --- I don't have Delphi 5)
should be fixed.

AD 3) There are no icons. Contributions are welcome. (And,
while we'are at it, an icon for pasdoc_gui would be great too!)

AD 4) Quoting HelpGenerator author, Richard B. Winston:
"Help Generator is another GUI for PasDoc.  You can get the
most recent
version as part of GoPhast
(http://water.usgs.gov/nrp/gwsoftware/GoPhast/GoPhast.html)"

AD 5) As for DIPasDoc: See this message on pasdoc-main
mailing list :
[https://sourceforge.net/mailarchive/message.php?msg_id=4463986].
According to it, at 2003-04-30 sources for current PasDoc
were taken from Ralf Junker's DIPasDoc.

I'm not sure what is the current status of DIPasDoc -- as
far as I know it's not developed anymore. I believe PasDoc
has many new features over DiPasDoc, many new @-tags, LaTeX
output, portable to FPC and non-Windows OSes etc.

I don't know about DelphiCodeToDoc. I just found it's
homepage [http://dephicodetodoc.sourceforge.net/]. Maybe
some people on pasdoc-main mailing list have some experience.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=104213&aid=1595890&group_id=4213

[Pasdoc-main] Parsing of generics specialization

[Michalis K. <mic...@gm...>]

Just a quick note: I committed recently small fixes to parser to handle
generics specialization (both in FPC and Delphi style), that is stuff like

  Txxx = class(specialize Tyyy<...>) { FPC style }
  Txxx = class(Tyyy<...>) { Delphi style }

Implemented in a quick and hacky way, but works and generates sensible
documentation for such declarations. In particular testcase
http://pasdoc.svn.sourceforge.net/viewvc/pasdoc/trunk/tests/ok_generic.pas
is parsed Ok now.

Michalis

[Pasdoc-main] Parsing of the implementation section

[Markus J. <jo...@in...>]

Hi, I came across this thread in the mail archive:
http://sourceforge.net/mailarchive/message.php?msg_id=6103275
Apparently Mark de Wever worked on this feature. Unfortunately I 
couldn't find any trace of his work in any svn revision. So could 
anybody tell me what happend to it, and if his changes are available 
somehow, so that I could give them another try?

TIA

Markus

Re: [Pasdoc-main] PasDoc nested types

[Michalis K. <mic...@gm...>]

Hi,

I allow myself to reply to the public pasdoc-main list, as this is also
a reply to the "[Pasdoc-main] Nested types" thread. I hope it's OK :)

Arno Garrels wrote:
[...]
> A design change as DoDi suggested should be considered
> sooner or later. 

I'll welcome a design change. Just make it as gradually as reasonably
possible, and fix the eventual bugs along the way :) Your current patch
is a good first step --- apply it, fix bugs, and then move further :)

>So before I risk to have to revert my changes in svn
> I send you my patch for a brief review of the parser changes, the other
> stuff should be 100% o.k.. If you think it is o.k. I'll commit that
> work. 
> 

On a quick glance, the code looks OK, I have no objections. There are
however two failures on the test suite (html output), be prepared to fix
them (before committing, or you can commit current patch and fix them
afterwards --- we can live with these two failures for a short time :)

- ok_abstract_sealed fails: looks like "var" keyword is changed into
"internal" in the output.

- ok_record_case_parsing and ok_record_with_case fail with "Fatal Error:
Invalid type cast" and do not generate any output.

Michalis

Re: [Pasdoc-main] Nested types

[Arno G. <arn...@gm...>]

Michalis Kamburelis wrote:
> Arno Garrels wrote:
>> Hi,
>> 
>> I worked a bit on support for nested types and uploaded
>> a HTML output of a test case here:
>> http://www.duodata.de/misc/delphi/PasDoc/
> 
> That's cool. It's not committed yet as far as I see?

No, not committed yet, I sent you a patch today, the parser changes
are sligthly hacky but at least they work without breaking too much.
IMO DoDi's approach of a design change is something we should
consider seriously sooner or later.
 
> 
>> 
>> Currently unit relative qualified names are used for the
>> nested types in overviews. IMO the class hierarchy of all
>> classes should show full qualified names (including unit
>> names) but that looks a bit strange with external,
>> unknown base classes :-( Anyway, what do you think?
>> 
> 
> The "external classes" feature can be improved to contain unit names,
> that's not a big problem. But I don't know if I like this --- class
> hierarchy page would become full of text, and be very difficult to
> read, 
> if you add there unit names. That's IMHO of course, others input is
> welcome.

Agreed, that made it less readable, but took namespace into account.
Anyway, it's easy to change.  
 
-- 
Arno Garrels