Hi List,

Is the fpclasschart program still maintained?

I get a runtime A/V trying to create a class chart from one of my source files.

Kind regards,
Torsten Bonde Christiansen.

Torsten Bonde Christiansen wrote

Hi List, Is the fpclasschart program still maintained?

It is.

I get a runtime A/V trying to create a class chart from one of my source files.

Can you isolate the problem a bit more ?

Michael.

The best I can give is the output when it crashes. If you wish I can put the class it's trying to create the chart for on pastebin.

This is the output i get when run:

$ fpclasschart --input="epicustombase.pas" --output=classchart.txt fpClassTree - Create class tree from pascal sources Version 2.4.0 [2010/03/24]
(c) 2008 - Michael Van Canneyt,

An unhandled exception occurred at $00000000004843DF : EParserError : Expected "," or ":" at token ";"
$00000000004843DF line 207 of src/pparser.pp
$00000000004887EA line 1196 of src/pparser.pp
$000000000048B433 line 2145 of src/pparser.pp
$0000000000487688 line 995 of src/pparser.pp
$0000000000486927 line 799 of src/pparser.pp
$00000000004864C6 line 713 of src/pparser.pp
$000000000048BFD5 line 2301 of src/pparser.pp
$00000000004020AE line 569 of fpclasschart.pp
$0000000000403171 line 759 of fpclasschart.pp

I hope it helps.

Kind regards,
Torsten Bonde Christiansen.

The error means there is an unsupported pascal construct in the file. But without the file, there is nothing more useful I can say.

Michael.

That's strange, because I have no problems compiling the file (and program) at all.

The entire file can be found here:
http://pastebin.org/167517

Kind regards,
Torsten Bonde Christiansen.

Hi,

I had a look. The problem is the use of the 'Static' keyword. the fcl-passrc parser doesn't seem to understand it.

(fpdoc and friends do not share the compiler's scanner/parser)

Michael.

Michael Van Canneyt het geskryf:

I had a look. The problem is the use of the 'Static' keyword. the fcl-passrc parser doesn't seem to understand it. (fpdoc and friends do not share the compiler's scanner/parser)

Hopefully with my new project such limitations in the fcl-passrc parser will be detected earlier. I'm about to integrate the parser with the new fpGUI IDE.

BTW:
Any idea why Lazarus IDE doesn't use fcl-passrc parser? It would just make sense to reuse (and improve) as much as possible of the features included with FPC.

Regards,
- Graeme -

There should be not so many. It scans the full packages. But 'static' is simply not used in the packages.

Timing:
The codetools of the IDE were developed before fcl-passrc was fully developed.

Maybe now the fcl-passrc parser is at a stage where it becomes an option to use it in the IDE.

Michael.

In our previous episode, Michael Van Canneyt said:

Hmm, I thought that it was because fcl-passrc is for code that is mostly correct, while an editor parser (e.g. highlighting etc) must be able to recover to a sane (but not necessarily 100% correct) state after errors?

That is certainly an element; Although I don't think the highlighter uses the codetools, as it is based on synedit. The codetools themselves are much less forgiving about wrong code. It's usually impossible to get any of the codetools to work if there is an error in the code somewhere, and not necessarily in the unit that you happen to be working in.

Michael.

No. The fcl-passrc is not optimized for speed (it uses TList and creates a lot of strings) and I would estimate it supports only half of the fpc languages features.

The idea is to help find errors early. It helps me a lot. Maybe not that much for others.
But I plan to add some more skips/ignores.

Mattias

Mattias Gaertner het geskryf:

No. The fcl-passrc is not optimized for speed (it uses TList and creates a lot of strings) and I would estimate it supports only half of the fpc languages features.

Excluding your comment on lacking fpc language features... Is the speed difference between fcl-passrc parser and CodeTools parser really noticeable from a developer (end-user) using a IDE point of view, or is the speed difference only noticeable in "speed test" environments.

As far as I know fpdoc uses fcl-passrc, and I can't say I have really noticed a speed issue when generating docs. This brings me to another point. If fpdoc uses fcl-passrc parser, then surely it [the parsel] should support "more that half the fpc language features" otherwise fpdoc wouldn't be able to document (parse) the RTL and FCL. Correct?? So maybe your "supports only half" comment is a slight exaggeration? Just my personal observation, I don't know fcl-passrc code at all.

The idea is to help find errors early. It helps me a lot. Maybe not that much for others. But I plan to add some more skips/ignores.

Like many other features, wouldn't it be worth improving the code that is included with FPC instead of always reinventing the wheel? Maybe incorporate the CodeTools speed & features into fcl-passrc so that eventually CodeTools and any other project wanting to parse Object Pascal source code, could use fcl-passrc parser?

Regards,
- Graeme -

Well, the codetools are (too) slow on some operations. So adding a magnitude won't help.

modifiers, special compiler directives, nested classes) and not all the Delphi "bugs" like ommitting semicolons.
Try the fcl-passrc or fpdoc on the test units.

The parser is only 10% of the codetools and has different goals. It allows back tracking, that means it knows where a token came from. This is needed for editing. It allows parsing only the compiler directives. It has unit interdependencies. It has various caches supporting reparsing of units without rebuilding everything. It is not optimized to parse sources once, but often.

It is good to have a simple parser in the fcl.

Mattias