ESS-Model again

[Thaddy]

Old or not, let's get the damn thing working again. I am busy with it. Modelling tools for FPC are hard to find if any...

@ Graeme: you can of course reply to {$ifdef objfpc}@{$endif}me.

[JD]

Old or not, let's get the damn thing working again. I am busy with it. Modelling tools for FPC are hard to find if any...

@ Graeme: you can of course reply to {$ifdef objfpc}@{$endif}me.

Kudos to you all for your efforts.

[dicepd]

Todays changes.

2012/12/21 Re-enabled the sizing of the background after dragging classes around the diagram.

2012/12/21 Fixed interface inheritance in parser, replaced << with « and >> with » as per UML specs. Ifdefed and reversed <<>> change for Linux. Need to look at this for Linux at some point. ? Does Mac have guillemets in default font?

2012/12/21 Fixed Layout so that classes with interface inheritance show the interfaces above the class.

2012/12/21 Auto width sizing now works in Linux. Separator now fully width aware.

A question! What is the best way if any of only enabling RTTI for some units (and or classes)  and not others. Really only need RTTI on core model but not any of the supporting program classes. Enabling RTTI whacked up the executable size significantly.

[marcov]

Do not inherit from tpersistent. Only classes in the $M state or that inherit from such classes (in the LCL/VCL, tpersistent or descendants like tcomponent)

[dicepd]

Do not inherit from tpersistent. Only classes in the $M state or that inherit from such classes (in the LCL/VCL, tpersistent or descendants like tcomponent)

So basically most of the bloat is in the GUI which you can't disable the moment you add a single RTTI control? Fine I'll live with it then at is really has not hit performance.

[marcov]

Do not inherit from tpersistent. Only classes in the $M state or that inherit from such classes (in the LCL/VCL, tpersistent or descendants like tcomponent)

So basically most of the bloat is in the GUI which you can't disable the moment you add a single RTTI control?

Only used or registered components should be linked in. If you want to get a feeling for what is linked in, generate a .MAP file.

It is the penalty for not having to write persistence for every component like in the predecessor Turbo Vision (which of course also costs space). You win some, you lose some.

[dicepd]

A new dev branch in github which is RTTI enabled with a simplistic TreeView and Property Editor implemented as a ViewIntegrator. Not the proper way to implement one of these but it serves it's purpose for checking the Model as I get the parser into shape.

It will only be available in debug mode.

It only updates other views on the current entity change atm if you edit anything, but this not its real purpose. It was a "will it work" test, and is proving useful as a development aid.

I will not get much done now over the Chistmas period until first week jan.

 I have guillemets working in linux in the dev branch, to do this I forced the code to UTF8.
I don't know if delphi will handle UTF8 files. if this could be a problem then may have to put certain consts in a UTF8 don't edit unless you are sure your editor can keep the UTF8 encoding.

Peter

[dicepd]

Christmas break over and a few things done in and amongst the falmily commitments.

All the following are in the dev branch in github.

Emunerations display in diagrams.

Small improvements is Parameter parsing/modelling.

Test units added for DataTypes and general parsing.  Test files contain musings on Model improvement requirements.

DataTypes show names in mainform treeview and test treeview.

General thoughts from lots of reading of FPC 3.0.0 and UML 2.5 docs.

We will have to introduce certain fields to the model to support single file parsing support, such as IsConst on an In operation parameter as we may not know the calling convention of the overridden parent operation parameter.

A general rewrite of associations to support DataType membership/hierarchy. This is the main reason for the addition of the tests to try to classify what is required to model the pascal language as UML itself is very Java biased/driven.

[JuhaManninen]

@dicepd, impressive work so far!
I remember I tried to port it many years ago but failed. One reason may have been the limited support for delegated interfaces in FPC at that time. Not sure.
ESS-Model uses sophisticated data structure and language features IIRC. I must study the code again later.
Anyway you don't need to worry about Delphi compatibility. As Graeme mentioned this project has been dead for years and it does not support latest Delphi syntax. The Lazarus port may have a future if you and other people put effort to it.

I tested your "dev" branch. It works well on Linux when compiled for QT bindings. It parses EssModel.lpr well, lazbuild.lpr and startlazarus.lpr give errors. Did not try others yet.
When I tried with both Lazarus and ESS-Model compiled for GTK2 bindings, opening the File menu froze the whole system. I will try to find reasons for it.
I use KDE, bad behaving GTK2 programs can apparently freeze it.

Many GUI controls and labels seem not properly aligned. Non-standard font size may be used, too. Not sure. Somebody should go through the forms.

How is your policy with the branches? Is "master" the stable release branch? "dev" will be merged when it is ready? If I fix something, should I do it against master or dev? Just master could be enough when there are not a huge number of contributors.

I have guillemets working in linux in the dev branch, to do this I forced the code to UTF8.
I don't know if delphi will handle UTF8 files. if this could be a problem then may have to put certain consts in a UTF8 don't edit unless you are sure your editor can keep the UTF8 encoding.

What files are you referring to? Why would an editor not keep the UTF8 encoding? Pretty much all editors support Unicode.

What is the purpose of commit 7bd0f246755, "UTF8 test", in "dev" branch?
Gitk shows identical lines. Then I created a patch and opened it in an editor and saw this:

--- a/Integrator/View/RtfdDiagram/uRtfdComponents.pas
+++ b/Integrator/View/RtfdDiagram/uRtfdComponents.pas
@@ -1,6 +1,6 @@
 {
   ESS-Model
-  Copyright (C) 2002  Eldean AB, Peter Söderman, Ville Krumlinde
+  Copyright (C) 2002  Eldean AB, Peter Söderman, Ville Krumlinde
   Portions (C) 2016 Peter Dyson. Initial Lazarus port
 
   This program is free software; you can redistribute it and/or
@@ -815,7 +815,7 @@ begin
 {$IFDEF LINUX}
   Self.Caption := '<<' + ACaption + '>>';
 {$ELSE}
-  Self.Caption := '«' + ACaption + '»';
+  Self.Caption := '«' + ACaption + '»';
 {$ENDIF LINUX}
 end;
 
--
Looks like you changed valid UTF-8 characters into something else, maybe Windows codepage.
Please consult me about any Unicode issue if needed.
As you know LCL inherently uses UTF-8. Most files in Windows and in other systems are saved as UTF-8.
Things work well when everything is Unicode. We should get rid of the old Windows codepages ASAP.

[dicepd]

Changes.

New test file utstClassOperations.pas Now all class operations and variables are parsed and modelled

Very basic implementation of docs from comments. Requires more work in passrc mainly.
           
Classifiers in Interface section now all viPublic.

@JuhaManninen

RE: Branches. Mostly doing stuff in dev atm as the RTTI gives me feedback to changes while developing. Master is still non RTTI. Dev branch was created in case RTTI was not required/ I messed up  . Patches to dev would be best for the time being as I can rip RTTI out easily, although RTTI seems to be a really good fit when we get to Editing/Creating Models.

RE: Errors in other projects. This is fully down to the passrc codebase which I am not inclined to fork at this early stage. From this point on if it is not  marked as working in the test classes it is on the todo list, or if marked as working in test classes it is a bug, which may or may not need extra test cases.

[JuhaManninen]

I made a pull request in GitHub.
I fixed a crash when closing with File -> Exit, and removed some left-over stuff.
The freeze with GTK2 happens only under IDE. It is related to debugging somehow but I didn't find the reason.

There are some other memory management problems, too, but fortunately they don't cause crashes.
When running under IDE, the app refuses to stop. The IDE shows it is still running and the "Stop" button must be clicked.
I bet this is caused by the complex use of interfaces in EssModel. Some objects are freed automatically, some not.
However this does not cause problems in normal usage when running without Lazarus IDE.

I organized uses sections because I want to see dependencies better. The FCL / LCL units should be always in interface section as they can never cause a circular dependency.
I like to see all unit references in interface section unless they truly create a circle. Earlier FPC had bugs related to circular dependencies (through implementation uses section), although the memory bugs are not likely caused by that.

[dicepd]

Ok that one broke my build, did not see any lfm changes?

Scratch that, it required a scrub out of lib dir and then a full rebuild.

[JuhaManninen]

Ok that one broke my build, did not see any lfm changes?

It was based on the latest "dev" branch. Should merge ok.
BTW, are the Unicode issues solved? I did not fully understand what the problem was.

Juha

[dicepd]

 Latest Changes

• more tests
• search model for related Enums in other packages to add to diagram.
• Fixed annoying gaps when stereotype was drawn above classname.
• And the BIG one, Documentation generation in multiple languages via FPDoc

Ok that last one may raise a few eyebrows as to why FPDoc?

• I need to do some serious documentation of the existing model before updating its internals to cope with more functional UML modeling capabilities
• Personally I do not like huge amounts of comments in code, it messes with my code folding.
• Nothing out there currently allows program documentation to be easily done in multiple languages.
• I may in the future allow the model to import documentation from fpdoc.
• Use FPDoc as a central single doc store which can be accessed/updated via Laz-Model, FPDoc Editor, or any suitable editor. the more ways to update documentation the more likely it is it will get done.
• Allows better granularity of contributions for documentors to engage in a project
• If I eventually don't like this the docs I make are in xml whcih can be easily transformed into something else.

How it works.

From the programmers point of view, Click the menu! Thats it!

What happens is that the program looks in the configured DocRoot directory (selectable via directory dialog, with a default in Config of ProjectRoot/FPDoc).
It searches the directory for subdirs with 2 letters (ISO country codes, only by convention). These are the languages this run will generate for.
For each language
  get or create a FPDoc project file (FPDoc.xml).
  For each Unit in Model
    check project for inclusion, add entries if not there.
    get or create a Unit descriptions file {unitname}.xml
        check for or create element entries for all classifiers in the unit.

As you can see you can safely run and rerun this adding new items to
be documented as you go along. (Future feature some mechanism to remove entries which are no longer in the codebase, probably only needed to be used just before a release. Not a hard thing to do.)

Source control should store only the lang directories.
(Future feature) Diagrams to be generated in DocRoot/images with links auto inserted into description files.

To generate docs for a language a symlink is made below the lang dir to the images dir. This is a workaround for FPDoc not generating all doc types properly unless images is a subdir of where the project/desc files are.

If you need to support another language just add an empty directory, generate and let your new collaborators at it.

So I am going to be dogfooding this

[dicepd]

Latest changes

• Forwards are now handled correctly for classes. See forward test.
• Project parsing is now recursing down the units as they are parsed instead of after file parse. This now means no model entities in the unknown bucket(new test bug aside).
• Bug test for qualified names.
• Parser memory leaks eleminated.
• Small code clean ups.

@Juha  The memory leaks are the cause the program not shutting down in the IDE. You will probably find a heap.trc file in your debug dir. I have experienced the crash on file open, again I think this is down to the heap trace.

All the extra searching of both passrc and own model to ensure all model items are in the model and not in the unknown bin has slowed the parser down a bit. I think this will be the final speed it will work at.

Peter