Menu
▾
▴
pasdoc-main
|
From: Aleš P. <ta...@su...> - 2011-06-27 09:35:02
|
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
|
|
From: Michalis K. <mic...@gm...> - 2011-06-28 16:33:13
|
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
|
|
From: Arno G. <arn...@gm...> - 2011-06-28 17:17:43
|
----- 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
|
|
From: Michalis K. <mic...@gm...> - 2011-06-28 18:45:05
Attachments:
a.pas
|
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 |
|
From: Hans-Peter D. <DrD...@ao...> - 2011-06-28 22:51:17
|
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
|
|
From: Michalis K. <mic...@gm...> - 2011-06-28 23:40:36
|
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 |
|
From: Michalis K. <mic...@gm...> - 2011-06-29 07:54:59
|
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 |
|
From: Michalis K. <mic...@gm...> - 2011-06-30 14:17:02
|
(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
|
|
From: Hans-Peter D. <DrD...@ao...> - 2011-06-30 18:53:12
|
Michalis Kamburelis schrieb: > (I changed the subject, we diverged from original Ales question here.) > First of all, looks like we already have what we need in trunk. Fine, why then bother about PasDoc2? DoDi |
|
From: Hans-Peter D. <DrD...@ao...> - 2011-06-29 11:56:58
|
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 |
|
From: Hans-Peter D. <DrD...@ao...> - 2011-06-29 12:20:27
|
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 |
|
From: Michalis K. <mic...@gm...> - 2011-06-30 15:20:33
|
> 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 |
|
From: Aleš P. <ta...@su...> - 2011-06-29 16:02:34
|
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 > |
|
From: Michalis K. <mic...@gm...> - 2011-06-30 14:21:17
|
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
|
Thanks for helping keep SourceForge clean.
X