Some (minor) remarks on the Lazarus release candidate

[simone]

As a habit I have tried the latest Lazarus release candidate with my existing codebase. I have noticed the following minor discrepancies with current release, but perhaps worthy of reporting:

- I usually compile with the -Xg option. Now I'm forced to disable it as I get the following message by IDE: "FpDebug internal Dwarf -debugger" supports only symbols within executable.

- I use a TSynEdit component with the eoHideRightMargin option. Now I'm forced to include the SynEditTypes unit in the uses clause as otherwise the TSynEditorOptions type is not found.

- Now in some cases, when I launch the application from the IDE, it shows me a popup with an exit code.

- The startup of the IDE seems to me a little slower than before. It is a personal impression, I cannot provide an objective measure.

[Martin_fr]

Xg / FpDebug:
This is fixed in trunk 686e81d6e3028cbcd3188f433e26ab95fefca187 , 1c87dc96eb1c86128d80b54fe8bfd8a118167ea9
But it was not merged, as it needs testing.

Not sure, if this are the 2 only commits... If so,you can try applying the patches to your copy of fixes.

You can go back to gdb, it is still included.

The reason that feature was added rather late, is that it was thought a debug build would also be done with -O-, heaptrc, asserts, and -Criot etc. So debug info could be part of the build.
After all, if releases are then build with -O2 (or up), and no/less buildin checks then debug info can be omitted at that stage....

SynEdit:
Please report. Forward declarations should probably be added.

exit code:

* If you mean, your app runs, but if you close your app...:
If that is in the debugger, then it can be turned off in the global options (the dialog itself, afaik also has a checkbox to turn it off).
The exit code is shown, if it is not zero => your app exited, indicating an error.

* If you mean, your app never runs (or at least not to any of your own code) ...:
More details, what error code?
Maybe a dll is not found? Could be an issue with the search PATH. If so, it would be good to know all the pathes involved.
Also, only fpdebug, or also if you switch back to gdb (which is still included)

Startup
no idea... But possible. The IDE also keeps growing.
Though occasionally we also look at (re) improving speed.

[simone]

Thanks Martin, your information is really valuable.  About the IDE exit message, it occurs in a GUI application that keeps a console left open for debugging needs.  To display what is in it, the last line of the main program it has a readln statement.  If I close the console before hit return key, the IDE message appears.  This did not happen before.

[Martin_fr]

Yes, the "exit code" message is a new feature.
It is useful, because apps should not return an error, and if they do, the debugger should tell.

Closing the window, kills stdin, and readln will fail. (or something like that...)

Again, if you don't like it, there is a setting (tools > options > debugger > general)

[Martin_fr]

SynEdit:
Please report. Forward declarations should probably be added.

Ok, I checked.

To forward the symbols something like this is needed in SynEdit

Code: Pascal  [Select][+][-]

1.   TSynEditorOption  = SynEditTypes.TSynEditorOption;
2.   TSynEditorOptions  = SynEditTypes.TSynEditorOptions;
3.   TSynEditorOption2 = SynEditTypes.TSynEditorOption2;
4. const
5.   eoHideRightMargin= SynEditTypes.eoHideRightMargin;
6. .....
7. type
8.  

Options used to be at line 219 after "TSynStateFlags = set of TSynStateFlag;"

Merge-Request would be nice....

[simone]

Thanks Martin for your fix.

[Martin_fr]

It's not fixed yet. It's a matter of time, getting to it before the release....

[simone]

I use a TSynEdit component with the eoHideRightMargin option. Now I'm forced to include the SynEditTypes unit in the uses clause as otherwise the TSynEditorOptions type is not found.

Just to report that the release version has the same problem I reported for the candidate version. It is not a big problem, but it seemed appropriate to point it out.

[JuhaManninen]

- The startup of the IDE seems to me a little slower than before. It is a personal impression, I cannot provide an objective measure.

The startup should be faster. I optimized UTF-8 text related stuff and other IDE parts a while ago with Valgrind and KCachegrind. Also Martin measured a faster startup.
It depends on the set of installed packages of course. I tested with minimal set only. PascalScript package has some initial testing code which slows down the startup. I have not studied it yet but maybe I should.

Merge-Request would be nice....

@Simone, I guess Martin meant you should fix it in your GitLab fork and create a merge request. It can be applied easily, even with a single click in the GitLab page.

[simone]

I did not understand. I thought I shouldn't have to do it, since Martin had found the solution.  I'm sorry.