Lazarus

Announcements => Lazarus => Topic started by: mattias on November 04, 2021, 07:27:47 pm

Title: Lazarus Release Candidate 2 of 2.2.0
Post by: mattias on November 04, 2021, 07:27:47 pm
The Lazarus team is glad to announce the second release candidate of Lazarus 2.2.

This release was built with FPC 3.2.2.

Here is the list of changes for Lazarus and Free Pascal:
http://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes
http://wiki.lazarus.freepascal.org/User_Changes_3.2.2

Here is the list of fixes for Lazarus 2.2.x:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/commits/fixes_2_2

The release is available for download on SourceForge:
http://sourceforge.net/projects/lazarus/files/

Choose your CPU, OS, distro and then the "Lazarus 2.2RC2" directory.

Checksums for the SourceForge files:
https://www.lazarus-ide.org/index.php?page=checksums#2_2_0RC2

Minimum requirements:

Windows:
   2k, XP, Vista, 7, 8, 8.1 and 10, 32 or 64bit.

FreeBSD/Linux:
   gtk 2.8 for gtk2, qt4.5 for qt, qt5.6 for qt5, 32 or 64bit.

Mac OS X:
   Cocoa (64bit) 10.12 to 11.4, Carbon (32bit) 10.5 to 10.14, qt and
   qt5 (32 or 64bit).

The gitlab page:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/lazarus_2_2_0_RC2

Last trunk svn revision was r65398.

For people who are blocked by SF, the Lazarus releases from SourceForge are mirrored at:ftp://ftp.freepascal.org/pub/lazarus/releases/

== Why should everybody (including you) test the release candidate? ==

In the past weeks the Lazarus team has stabilized the 2.2 fixes branch. The resulting 2.2RC2 is now stable enough to be used by anyone for test purposes.

However many of the fixes and new features that were committed since the release of 2.0 required changes to the code of existing features too. While we have tested those ourselves, there may still be problems that only occur with very specific configurations or one project in a million.

Yes, it may be that you are the only person with a project, that will not work in the new IDE. So if you do not test, we cannot fix it.

Please do not wait for the final release, in order to test. It may be too late. Once the release is out we will have to be more selective about which fixes can be merged for further 2.2.x releases. So it may be, that we cannot merge the fix you require. And then you will miss out on all the new features.

== How to test ==

Download and install the 2.2 RC2.
- On Windows you can install as a 2ndary install, that will not affect your current install:
http://wiki.lazarus.freepascal.org/Multiple_Lazarus#Installation_of_multiple_Lazarus
- On other platforms, if you install to a new location you need to use --primary-config-path

In either case you should make backups. (including your primary config)

Open your project in the current Lazarus (2.0.x), and use "Publish Project" from the project menu. This creates a clean copy of your project.

You can then open that copy in the RC2. Please test:
- If you can edit forms in the designer
   - rename components / change properties in Object inspector / Add new events
   - Add components to form / Move components on form
   - Frames, if you use them
- If you can navigate the source code (e.g. jump to implementation)
- Auto completion in source code
- Compile, debug and run
- Anything else you use in your daily work
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: BSaidus on November 07, 2021, 08:06:46 am
Hello.
I recompiled Lazarus with anchodocking support, then go to codeexplorer and try to jump to different places, units ( clicked on go to unit emplacement ) but it do not do that.
  There is many things not working ( jumping) from code explorer to editor.


Thanks
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: JuhaManninen on November 07, 2021, 10:15:50 am
I recompiled Lazarus with anchodocking support, then go to codeexplorer and try to jump to different places, units ( clicked on go to unit emplacement ) but it do not do that.
  There is many things not working ( jumping) from code explorer to editor.
It works here.
It must depend on the code. Something confuses the parser. Do Codetools work otherwise with the unit you tested?
Anchodocking should have no effect on CodeExplorer synchronization. Can you please test without it.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: BSaidus on November 07, 2021, 01:21:54 pm
It works here.
It must depend on the code. Something confuses the parser. Do Codetools work otherwise with the unit you tested?
Anchodocking should have no effect on CodeExplorer synchronization. Can you please test without it.
Frankly,I tested a new non saved project.
I'll test later and give more infos.


[Edited to fix quote tags]
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: BSaidus on November 08, 2021, 10:44:45 am
It works well, the code explorer synchronize well with the code.
Tested on saved project.
PS: I used fpcupdeluxe to compile the fixes branche of Lazarus with fpc 3.2.2.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: JuhaManninen on November 08, 2021, 01:48:50 pm
It works well, the code explorer synchronize well with the code.
Tested on saved project.
I guess it should work on non-saved project, too. It may not be important because any code where you want to use CodeExplorer is part of some project or package.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dbannon on November 09, 2021, 03:33:43 am
The current rc2 (and trunk) again have some misspelling of the word "occurred".  All in string literals so, no big deal to fix.

Code: [Select]
grep -rw occured lazarus-lazarus_2_2_0_RC2 [enter]
I reported a number of these some time ago and they were fixed so have to assume they have crept back in again over time.  Last time, my patch was not very well received so will just report for someone else to make a better patch.

I report it because occured is on Debian's hit list and it gets reported by lintian (in pedantic mode).

EDIT : I should have mentioned than most of the "occured" occur in msgid of po files.

Davo
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dsiders on November 09, 2021, 09:00:05 pm
The current rc2 (and trunk) again have some misspelling of the word "occurred".  All in string literals so, no big deal to fix.

Code: [Select]
grep -rw occured lazarus-lazarus_2_2_0_RC2 [enter]
I reported a number of these some time ago and they were fixed so have to assume they have crept back in again over time.  Last time, my patch was not very well received so will just report for someone else to make a better patch.

I report it because occured is on Debian's hit list and it gets reported by lintian (in pedantic mode).

EDIT : I should have mentioned than most of the "occured" occur in msgid of po files.

Davo

In Lazarus: If you look at the matches, you'll see that they are commented entries in the .po files with the following line being the correction.

In FPC: There are source comments with the spelling error too. They need to be reported to the FPC issues tracker.

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dbannon on November 10, 2021, 12:22:55 am
re: "occured"

In Lazarus: If you look at the matches, you'll see that they are commented entries in the .po files with the following line being the correction.
It does not matter to Debian lintian why they are there or why they are there. It just spits them out if it finds them anywhere.

In FPC: There are source comments with the spelling error too. They need to be reported to the FPC issues tracker.

As mentioned, my previous bug report including a patch was unacceptable. Cannot see how i can do any better this time.

Davo

edit: sorry, that sounded very penchant. Having a bad time at home at present, will try harder.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dsiders on November 10, 2021, 07:13:48 am
re: "occured"

In Lazarus: If you look at the matches, you'll see that they are commented entries in the .po files with the following line being the correction.
It does not matter to Debian lintian why they are there or why they are there. It just spits them out if it finds them anywhere.

In FPC: There are source comments with the spelling error too. They need to be reported to the FPC issues tracker.

As mentioned, my previous bug report including a patch was unacceptable. Cannot see how i can do any better this time.

Davo

edit: sorry, that sounded very penchant. Having a bad time at home at present, will try harder.

 I looked for a previous issue to see its disposition. I could not find one. Issue with patch: https://gitlab.com/freepascal.org/fpc/source/-/issues/39434.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dbannon on November 10, 2021, 08:11:18 am
Thanks Don. 

Similar Previous Lazarus Issues -

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/38977

Davo
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dsiders on November 10, 2021, 09:13:06 am
re: "occured"

In Lazarus: If you look at the matches, you'll see that they are commented entries in the .po files with the following line being the correction.
It does not matter to Debian lintian why they are there or why they are there. It just spits them out if it finds them anywhere.

In FPC: There are source comments with the spelling error too. They need to be reported to the FPC issues tracker.

As mentioned, my previous bug report including a patch was unacceptable. Cannot see how i can do any better this time.

Davo

edit: sorry, that sounded very penchant. Having a bad time at home at present, will try harder.

 I looked for a previous issue to see its disposition. I could not find one. Issue with patch: https://gitlab.com/freepascal.org/fpc/source/-/issues/39434.

And removes the commented lines from the .po files. Issue: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39460
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Ñuño_Martínez on November 10, 2021, 12:56:36 pm
Just found an issue with version 2.0.12 that is related with this issue (https://forum.lazarus.freepascal.org/index.php/topic,53652.msg397146.html#msg397146).

The thing is if I try to "Open with Lazarus" from a file explorer (i.e. double click either on Windows' Explorer or Xubuntu's Thunar) it just opens Lazarus IDE with an empty project (or the previous project, it depends on Lazarus documentation).

The link I've post before fixes it using lazarus-ide instead of lazarus, and that works also in the explorer, but installation configures the file explorer to use lazarus so it seems as it's broken.

I've look in the fixes list but I can't see any mention to this.  Does this version changed something about this?
Title: height of Courier New 12pt font not right (windows, Lazarus 2.2.0 RC2)
Post by: robert rozee on November 11, 2021, 02:37:58 pm
would someone running windows (i tested with windows XP VM) please compile and run the attached test with Lazarus 2.2.0 RC2. if everything is correct, then BOTH lines of text should be underlined, and when Button1 is clicked all 4 numbers displayed should be 19.

in XP at least, if underline is set in the font style of a TLabel whose font is 12pt Courier New, then the label autosizes wrongly, 1 pixel short. worse still, this error is reflected in the value returned by TLabel.Canvas.TextHeight().

now it could be that fault lies in the font itself - whereby the underline is defined as sitting outside the character cell, but i'm not sure how to check this. the problem doesn't appear to manifest on sizes other than 12pt. i have only checked with Courier New, and only the version supplied with XP.

when i transplanted the offending font file (cour.ttf) onto a linux machine (lazarus 2.0.12), the odd behaviour partially followed - autosize was wrong, but by 2 pixels this time (expected behaviour with 2.0.12), but the TextHeight() values were correct (at 19).


cheers,
rob   :-)
Title: Re: height of Courier New 12pt font not right (windows, Lazarus 2.2.0 RC2)
Post by: wp on November 11, 2021, 05:00:02 pm
I checked your demo and confirm the issue with Win 11 (Laz main).

The issue is not related to the font file since when I paint the underlined text onto a Paintbox without clipping the underline is always there. Moreover, TStaticText does not show the issue (it is painted by the widgetset, though).

There are some other font sizes at which the underline disappears in the AutoSize=true case. Of course it disappears in the AutoSize=false case when the text height is larger than the control height.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: robert rozee on November 12, 2021, 02:16:13 pm
attached is a revised version of wp's code, with fixed StaticText font (was default, now Courier New), and slightly changed PaintBox code:

Code: Pascal  [Select][+][-]
  1. procedure TForm1.PaintBox1Paint(Sender: TObject);
  2. var I:integer;
  3.     W:integer;
  4. begin
  5.   Paintbox1.Canvas.Brush.Color := clRed;
  6.   Paintbox1.Canvas.FillRect(0, 0, Paintbox1.Width, Paintbox1.Height);
  7.   Paintbox1.Canvas.Brush.Color := clWhite;
  8.   Paintbox1.Canvas.Font.Assign(Label1.Font);
  9.   Paintbox1.Canvas.Textout(4, 4, 'This is underlined text.');
  10.   Paintbox1.Canvas.Font.Color:=clWhite;
  11.   W:=PaintBox1.Canvas.TextWidth('##');
  12.   for I:=0 to 4 do                                                      // 20 characters in total...
  13.   begin
  14.     Paintbox1.Canvas.Font.Style:=[fsUnderline];                         // two characters underlined
  15.     Paintbox1.Canvas.Textout(4+(2*I*W)  , 40, '##');
  16.     Label8.Caption:=IntToStr(PaintBox1.Canvas.TextHeight('#'));
  17.     Paintbox1.Canvas.Font.Style:=[];                                    // two characters NOT underlined
  18.     Paintbox1.Canvas.Textout(4+(2*I*W)+W, 40, '##');
  19.     Label9.Caption:=IntToStr(PaintBox1.Canvas.TextHeight('#'));
  20.   end;                                                                  // repeated 5 times
  21. end;

the paintbox background is now red, so you can see the of boundary what Textout produces. also added is another line of text, with white text on a white background, highlighting the cases where the height of the text is different when underlining on/off. Note the values for TextHeight do not change, while the height of the output does. Also note (in magnified section, below) where the underlining starts one pixel offset from the left.

i vaguely feel that a good portion of the problem is something outside of Lazarus, when the underline is defined as being located below the bottom edge of the character cell. the problem doesn't seem to manifest in Linux.


cheers,
rob   :-)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: wp on November 12, 2021, 06:24:37 pm
There are two ways to draw text with Lazarus:
As the attached demo shows, the underscore issue occurs only with DrawText, not with Canvas.TextOut.

TLabel.Paint finally calls the DrawText method. I am aware that it has advantages in calculating the size of the bounding rectangle when wordwrapping is allowed. Maybe this was the reason why the creators of the LCL chose this method.

This leads to the idea that the reason for the issue is in Windows, and this is confirmed when I do the same test in Delphi XE10.3.3 which shows exactly the same behaviour.

I could imagine that the vertices of the font glyphs are defined either by floating point numbers or by large integers later scaled to the destination font size. Depending on how this is done exactly there may be round-off errors by one pixel which eventually may show or hide the underscore line.

Sounds bad...

On the other hand, as a remedy, we could increment the bottom of the rectangle returned by the DrawText method when DT_CALCRECT is included in the flags.

Since this is needed for Windows only, I'd recommend that you try the following steps:

- Load the file lcl/interfaces/win32/win32winapi.inc (You should make a backup copy of the changed file so that you can restore the original behaviour).

- Find the procedure TWin32WidgetSet.DrawText.

- Towards its end there is block "if lf.lfItalic > 0". Put the following code before this "if". It is supposed to move the bottom of the calculated bounding rectangle of the text by one pixel to avoid clipping of the underscore line.
Code: Pascal  [Select][+][-]
  1.     if lf.lfUnderline<>0 then
  2.       inc(Rect.Bottom);
- Rebuild the IDE and run your tests again

- Report back whether it fixes the issue and whether you see any side effects (it seems to work for me).
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: prof7bit on November 15, 2021, 08:42:18 am
Has the naming scheme of the branch tags changed?

previosly it was

[main|t-fixes]_<version>

now with RC2 it has become

lazarus_<version>[_RCx]

The space in the about box was already quite small for a full git description, but now with this overly long tag name it has become very unreadable. I personally find "lazarus-" in the tag name (and thereby in the revision-"number") quite redundant, because what else would one expect to find in the Lazarus repository? Generally I believe the tag names should follow some consistent scheme that doesn't change with every release candidate, and they should not carry redundant information.

Was this new tag name merely an accident or was there really a naming scheme change? I suspect the former, but fortunately the tags can still be changed afterwards without impacting the revision hash or rewriting history.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 15, 2021, 03:19:33 pm
No, they haven't changed.

Here is how the go (and you can look at the fixes_2_0 branch (and others), and see it's the same.

1) The very first commit is tagged: "main-0_0"

2) Each time a fixes branch diverges (each time the revision number in "main" changed, e.g from 2.1 to 2.3)
- the fixes branch's very first commit is tagged "t-fixes-n_n"
   (the "t-" is to distinguish from the branch name)
- the main branch is tagged: "main-n_n"

3) Each time a release is made from fixes (including RC)
a new tag is added to fixes "lazarus-n_n_n"  (one "_n" less for the first release on the branch)
(There was a discussion to make it "release-n_n_n", but that would not make a diff in the length of the tag)

This had been forgotten for the RC1 => therefore it had not been seen then.
(That RC1 tag should still be added...)

4) Feature branches (if long living) may also have a tag on their very first commit, so they do not report "main-n_n".
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 15, 2021, 03:21:27 pm
Maybe it can be shortened it the display....
Don't know.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 15, 2021, 03:53:40 pm
Lazarus takes a lot of RAM (more then 2Gb) when I start debugging (with FpDebug) small HelloWord. Is it normal?

Reproduce:
1. Start Lazarus (it automatically loads previous simple console application) -> 120 MB of RAM
2. Set one breakpoint and press F9
3. Debugger stopped at breakpoint -> almost 2GB of RAM already allocated!

Windows 8.1, x64, Lazarus with additionally installed ancordock components.

With GDB debugger there is no such RAM issue.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: wp on November 15, 2021, 04:12:25 pm
For me (Win 11/64 bit, Laz 2.2.0RC2/fpc3.2.2/64 bit): empty form with button and ShowMessage(..) in its OnClick handler, breakpoint at ShowMessage --> 106 MB
(fpdebug, almost no additional components)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 15, 2021, 04:54:24 pm
I would not expect that much RAM to be used...

FpDebug will load the debug info (dwarf) from the compiled exe. Even for a project like the IDE, with a lot of code, that is only about 200 or 300MB. Nothing close to a GB.
Also it will build some indexes, they are but a fraction of the info itself.

Further the dwarf is loaded by "mapping" the file to mem. So windows will only load what is needed.

==> So unless your compiled exe is over 1GB on disk....



Tested with "git main"

For a hello word console, running in the debugger I get about 150MB. (including what was used before debugging)

Debugging the IDE within the IDE, I get 900 MB.

There may be a bit more, if I force re-compilation, or if I had another project open before.

If you use gdb, then some of that mem will be used by gdb, instead of the IDE....


Do you more info, maybe an example?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 15, 2021, 05:32:24 pm
Record a video: https://disk.yandex.ru/i/rkTw1IFSLnA2hA

Project with all files attached.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: prof7bit on November 15, 2021, 07:36:30 pm

a new tag is added to fixes "lazarus-n_n_n"  (one "_n" less for the first release on the branch)
(There was a discussion to make it "release-n_n_n", but that would not make a diff in the length of the tag)

I don't get why they need "lazarus" or "release" (or anything besides the version number) at all. This is just redundant and does not carry any information at all. If the convention is to tag the release then the fact that the tag is a release is inherent.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 15, 2021, 07:38:50 pm
Strange, I get 40 MB use (60MB as peak use).

I tried both the 64bit (as you seem to have) and the 32bit release of the RC2.
Even changed the FpDebug limits.
And I installed AnchorDocking (which I normally don't use).

I could not get it up. Rebuilding the IDE, uses 800 MB, but then it restarts, and goes back to normal usage.

I assume, you checked mem usage, after "building", before "running" => so the increase indeed happened when you did run your app?



Do you have any Antivirus software that may get hooked into the IDE (afaik AV can load into other processes)

In the "task manager" go to the "details" page, and add the column "memory (shared work set)".
How much of the 2 GB are shared?


Can you install the IDE again ? You can do a "secondary install" to a diff directory, using a diff config dir.

Then, with that IDE, as it comes => no packages installed, no anchor dock, on other packages => try again?
(You can change the fpdebug options).
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 15, 2021, 07:48:14 pm
I don't get why they need "lazarus" or "release" (or anything besides the version number) at all. This is just redundant and does not carry any information at all. If the convention is to tag the release then the fact that the tag is a release is inherent.

The "lazarus" prefix (as I said, "release" would do too, but we carried "lazarus" from the svn days) is an indicator that this tag marks a release.
If we do add other tags, for whatever other reasons in future, then we need to distinguish.

Already, not every tag is a tag for a release.
Tags starting with main and t-fixes mark the first commit after branch diverge.
But those tags, also look like version numbers. So they need to be distinguished from release tags.


The problem is not the length of the tag. in "git log" imho its fine (but you may see that different).

In the about dialog it may want to be shortened. The long text could be a hint, and could be in the copy to clipboard.


At the moment though, I want look into this myself. If someone else from the teams spots it here, they may respond and may have an idea...
Not all team members do read here though...

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 15, 2021, 10:55:42 pm
I assume, you checked mem usage, after "building", before "running" => so the increase indeed happened when you did run your app?
Yes. There is no memory growing after build and even "Run without debugger". It grows only when I run app with F9 (even without any breakpoint). Attached screenshot with detailed memory info.

I will try install new copy of Lazarus and let you know.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 16, 2021, 08:30:02 am
Secondary installation without additional packages works fine.

The bug appears when I install Anchordocking, Anchordockingdsgn, DockedFormEditor and build IDE with "Optimized IDE" profile. Then I try rebuild IDE with "Normal IDE" profile and the bug is gone! But lazarus.exe size increased from ~30MB up to 300MB...
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: wp on November 16, 2021, 09:33:04 am
But lazarus.exe size increased from ~30MB up to 300MB...
This is the debug information. You can get rid of it by calling "strip -s lazarus.exe" where strip is in the same folder as fpc.exe.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 16, 2021, 09:40:49 am
This is the debug information. You can get rid of it by calling "strip -s lazarus.exe" where strip is in the same folder as fpc.exe.
Thanks, that helps. But what's wrong with "Optimized IDE" profile?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 16, 2021, 05:11:14 pm
and build IDE with "Optimized IDE" profile.

Ok, that I can reproduce (well I get 1GB mem usage, but that is to much too).

The issue happens when the IDE is compiled with optimization -O2 or higher.

This is 99.9% likely being caused by a bug in FPC. https://gitlab.com/freepascal.org/fpc/source/-/commit/e9d318e7e2f772bf455a92461cd5c229e69858d8
=> I have not further debugged the issue to prove that it is indeed the particular bug, but I am pretty sure.

If you must use -O2 or higher to compile the IDE, you must add  -OoNOPEEPHOLE (which unfortunately takes away a good bit of the optimization)

The Issue is present in FPC 3.2.0 and 3.2.2.
It should be fixed in 3.2.4

It is a bug in the optimizer part of FPC.
The bug is very hard to trigger, that is only very very specific code will be compiled incorrectly. FpDebug is know to include such code.
It is unknown, if any other part of the IDE contains code that is affected.

I am not currently sure, if the old version of FpDebug (2.0.12) already had the affected code (maybe not, since there would otherwise have been problems).

Mind that the increased mem usage is just a random outcome of the bug. The bug could cause any symptoms from incorrect data/behaviour to exceptions or hard crashes.


Yes, in theory this bug can affect any project. However as I said you need to have code with just the correct number (and types) of local vars, accessed in just the correct order, with just the correct conditional (if) statements.
So far I have only seen it happen in one function in FpDebug, and only if compiled for 64 bit Windows. (but it could happen to other 64bit targets too / afaik only 64bit, but not sure on that).



Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: 440bx on November 16, 2021, 05:33:47 pm
It should be fixed in 3.2.4
Just curious, any reasonable guesstimate as to when 3.2.4 might be released ?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 16, 2021, 05:53:18 pm
Tested with "FPC 3.2.3-554-g8b21bf1cce [2021/11/14] for x86_64" (fixes_3.2 branch in fpcupdeluxe) - bug is not reproduced.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: PascalDragon on November 16, 2021, 09:01:48 pm
It should be fixed in 3.2.4
Just curious, any reasonable guesstimate as to when 3.2.4 might be released ?

As you can see in this (https://forum.lazarus.freepascal.org/index.php/topic,56864.0.html) other thread, we are currently in the prepration phase. So with luck it will still be this year, though it might probably be early '22.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: trev on November 17, 2021, 08:52:56 am
Lazarus version: 2.2.0RC3
Lazarus revision: lazarus_2_2_0_RC2-33-g33d1906384
Lazarus build date: 2021/11/17
Lazarus was compiled for x86_64-darwin OS X Mountain Lion 10.8.5
Lazarus was compiled with FPC 3.2.2

All of the linker "warnings" below are prefaced by "[red exclamation mark]Error:" in the Lazarus messages window.

Code: Text  [Select][+][-]
  1. Hint: (11030) Start of reading config file /etc/fpc.cfg
  2. Hint: (11031) End of reading config file /etc/fpc.cfg
  3. Free Pascal Compiler version 3.2.2 [2021/11/17] for x86_64
  4. Copyright (c) 1993-2021 by Florian Klaempfl and others
  5. (1002) Target OS: Darwin for x86_64
  6. (3104) Compiling /Users/trev/tmp/project1.lpr
  7. (3104) Compiling unit1.pas
  8. (9009) Assembling unit1
  9. (9009) Assembling project1
  10. (9022) Compiling resource /Users/trev/tmp/lib/x86_64-darwin/project1.or
  11. ld: warning: could not create compact unwind for _SYSTEM_$$_DUMP_STACK$TEXT$LONGINT: stack subq instruction is too different from dwarf stack size
  12. ld: warning: could not create compact unwind for _SYSTEM_$$_DO_GETDIR$BYTE$RAWBYTESTRING: stack subq instruction is too different from dwarf stack size
  13. ld: warning: could not create compact unwind for _UNIX_$$_READTIMEZONEFILE$SHORTSTRING: stack subq instruction is too different from dwarf stack size
  14. ld: warning: could not create compact unwind for _UNIX_$$_POPEN_INTERNAL$TEXT$RAWBYTESTRING$CHAR$$LONGINT: stack subq instruction is too different from dwarf stack size
  15. ld: warning: could not create compact unwind for _CLASSES$_$TPARSER_$__$$_HEXTOBINARY$TSTREAM: stack subq instruction is too different from dwarf stack size
  16. ld: warning: could not create compact unwind for _SYSUTILS_$$_EXTRACTRELATIVEPATH$UNICODESTRING$UNICODESTRING$$UNICODESTRING: stack subq instruction is too different from dwarf stack size
  17. ld: warning: could not create compact unwind for _SYSUTILS_$$_EXTRACTRELATIVEPATH$RAWBYTESTRING$RAWBYTESTRING$$RAWBYTESTRING: stack subq instruction is too different from dwarf stack size
  18. ld: warning: could not create compact unwind for _STRUTILS_$$_FINDMATCHESBOYERMOORECASESENSITIVE$crc7515ABE9: stack subq instruction is too different from dwarf stack size
  19. ld: warning: could not create compact unwind for _STRUTILS_$$_FINDMATCHESBOYERMOORECASEINSENSITIVE$crc7515ABE9: stack subq instruction is too different from dwarf stack size
  20. ld: warning: could not create compact unwind for _FPREADTIFF_$$_DECOMPRESSLZW$POINTER$INT64$PBYTE$INT64: stack subq instruction is too different from dwarf stack size
  21. ld: warning: could not create compact unwind for _FPREADGIF$_$TFPREADERGIF_$__$$_READSCANLINE$TSTREAM$$BOOLEAN: stack subq instruction is too different from dwarf stack size
  22. (9015) Linking /Users/trev/tmp/project1
  23. ld: warning: could not create compact unwind for _JCHUFF_$$_JPEG_GEN_OPTIMAL_TABLE$J_COMPRESS_PTR$JHUFF_TBL_PTR$TLONGTABLE: stack subq instruction is too different from dwarf stack size
  24. ld: warning: could not create compact unwind for _JCMASTER_$$_VALIDATE_SCRIPT$J_COMPRESS_PTR: stack subq instruction is too different from dwarf stack size
  25. ld: warning: could not create compact unwind for _PROCESS$_$TPROCESS_$__$$_READINPUTSTREAM$TINPUTPIPESTREAM$TSTREAM$LONGINT$$BOOLEAN: stack subq instruction is too different from dwarf stack size
  26. (1008) 51 lines compiled, 1.6 sec
  27. (1022) 2 hint(s) issued

This was simply compiling a blank form. It does run despite the scary error messages :)
Title: Lazarus 2.2.0 RC1 & 2 : Disappearance of StringCase methods in lcl/lclproc.pas
Post by: Gilles HEM on November 17, 2021, 09:29:07 am
Hello,

in one of my components, I use the StringCase method implemented in lazarus until version 2.0.12.
Code: Pascal  [Select][+][-]
  1. // case..of utility functions
  2. function StringCase(const AString: String; const ACase: array of String {; const AIgnoreCase = False, APartial = false: Boolean}): Integer; overload;
  3. function StringCase(const AString: String; const ACase: array of String; const AIgnoreCase, APartial: Boolean): Integer; overload;
In Lazarus 2.2.0RC1 & 2 :
So I reimplemented it as it exists in Lazarus 2.0.12 directly in the lclproc.pas file of Lazarus 2.2.0RC1 then 2.2.0.RC2.
Is there any better way ?
Regards. Gilles

Title: Re: Lazarus 2.2.0 RC1 & 2 : Disappearance of StringCase methods in lcl/lclproc.pas
Post by: El Salvador on November 17, 2021, 09:44:31 am
I found in lazstringutils unit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/fixes_2_2/components/lazutils/lazstringutils.pas#L103
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Gilles HEM on November 17, 2021, 02:54:07 pm
Hello El Salvador,

thanks for your help.
I didn't think to look for Stringcase in the components folder. I limited my research to the lcl directory.
I added lazstringutils to the uses of my component and remove the code reimplanted in lclproc. It works well.

Regards. Gilles
Title: Re: Lazarus 2.2.0 RC1 & 2 : Disappearance of StringCase methods in lcl/lclproc.pas
Post by: PascalDragon on November 17, 2021, 03:45:06 pm
I found in lazstringutils unit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/fixes_2_2/components/lazutils/lazstringutils.pas#L103

That some refactoring went on there should probably be mentioned in the Release Notes (https://wiki.lazarus.freepascal.org/Lazarus_2.2.0_release_notes).
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zed on November 18, 2021, 08:28:37 am
Lazarus shows message "Compiler ... does not support target x86_64-win64" but compiler supports it and if I ignore this message and run build project it compiles win64 binary and works fine.

My steps:
1. Using fpcupdelux x32 install fpc 3.2.2 from Basic tab (it will install win32 compiler)
2. From tab Cross install cross-compiler for win64
3. Start Lazarus, configure with fpc binaries (in my case D:\apps\fpc\stable\fpc\bin\i386-win32\fpc.exe) and src (D:\apps\fpc\stable\fpcsrc)
4. Build win64 target - error message showed.

P.S. If I use fpcupdeluxe x64, install fpc win64 and then win32 cross-compiler, all works fine, but this scenario is "ill-advised" and not recommended by fpc/fpcupdeluxe developers (according to this (https://gitlab.com/freepascal.org/fpc/source/-/issues/39348) and this (https://github.com/LongDirtyAnimAlf/fpcupdeluxe/issues/429)).

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: prof7bit on November 18, 2021, 10:50:19 am
I don't get why they need "lazarus" or "release" (or anything besides the version number) at all. This is just redundant and does not carry any information at all. If the convention is to tag the release then the fact that the tag is a release is inherent.

If we do add other tags, for whatever other reasons in future, then we need to distinguish.

Already, not every tag is a tag for a release.
Tags starting with main and t-fixes mark the first commit after branch diverge.
But those tags, also look like version numbers. So they need to be distinguished from release tags.

Those branch start tags start with "t-". My reasoning was that every tag that looks like a version number and does not have a "t-" would then by definition be a release tag. An alternative (if all these special tags should have prefixes to make them stand out) would be to prefix them "r-", this would be more consistent and make much more sense that calling them "lazarus" because literally everything inside this repository is Lazarus.

BTW: I always wondered why these branch start tags are called "t-", I personally would have called them "b-" (branch), but this is not a real problem.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: AFFRIZA 亜風実 on November 18, 2021, 05:17:23 pm
I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  %) I tested KDevelop, it works normal, so it should not my keyboard.

(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?)  :-[
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: JuhaManninen on November 18, 2021, 07:51:35 pm
I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  %) I tested KDevelop, it works normal, so it should not my keyboard.
(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?)  :-[
This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
If you want to discuss the selections more, please open a new thread. This thread is about the coming 2.2 release.
RC3 from fixes_2_2 branch is good.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dsiders on November 18, 2021, 08:21:07 pm
I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  %) I tested KDevelop, it works normal, so it should not my keyboard.
(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?)  :-[
This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
If you want to discuss the selections more, please open a new thread. This thread is about the coming 2.2 release.
RC3 from fixes_2_2 branch is good.

If you check Tools > Options > Editor > Key Mappings > Text Selection commands:

Toggle Comment in Selection is mapped to Ctrl + /.

Works as expected on Windows.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 18, 2021, 08:26:30 pm
I can't comment a line using Ctrl + / in KDE Plasma (Neon 20.04). Anyone experienced this?  %) I tested KDevelop, it works normal, so it should not my keyboard.

Did it (and does it still) work in 2.0.12 on the same machine, with no settings of the machine changed? (I.e. maybe the machine had an update from the distro?)

Toggle comment is bound to: VK_OEM_2,[Ctrl]

VK_OEM_2 just happens to usually be "/" on a normal English keyboard. But if that is not the case on your machine, then you need to edit the key-mapping in the IDE Options.

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: AFFRIZA 亜風実 on November 18, 2021, 08:26:57 pm
This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
If you want to discuss the selections more, please open a new thread. This thread is about the coming 2.2 release.
RC3 from fixes_2_2 branch is good.
Geez, I know this is Lazarus. And I tested again Lazarus in Windows and it works normal, I can use Ctrl + /. Why your words selection is so cold though. Why not answer it normally like "maybe you can try Ctrl + Shift + V". English is not my native language, so I do think since the topic about coming 2.2 I thought I can post here. Do you think I'm not scared to make a new post then you answerd "why you repost this again, did you not using search bar to search simmilar topic?".
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: AFFRIZA 亜風実 on November 18, 2021, 08:50:42 pm
If you check Tools > Options > Editor > Key Mappings > Text Selection commands:

Toggle Comment in Selection is mapped to Ctrl + /.

Works as expected on Windows.
It's already mapped to Ctrl + / though but Ctrl + Shift + V is working normal.

Did it (and does it still) work in 2.0.12 on the same machine, with no settings of the machine changed? (I.e. maybe the machine had an update from the distro?)

Toggle comment is bound to: VK_OEM_2,[Ctrl]

VK_OEM_2 just happens to usually be "/" on a normal English keyboard. But if that is not the case on your machine, then you need to edit the key-mapping in the IDE Options.
I'll try to use 2.0.12, it still downloading, my internet is quite slow today, it feels like taking time forever. I'll update this reply if it finished.

I'm not sure about VK_OEM but when I select grab in the Key Mapping it detected as NumDiv, i'm not sure what does that mean. It's so weird since if I type it, it does write the exact "/" character. It's kinda weird since my keyboard doesn't have NumLock.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dsiders on November 18, 2021, 08:58:56 pm
If you check Tools > Options > Editor > Key Mappings > Text Selection commands:
Toggle Comment in Selection is mapped to Ctrl + /.
Works as expected on Windows.
It's already mapped to Ctrl + / though but Ctrl + Shift + V is working normal.

I'm not sure about VK_OEM but when I select grab in the Key Mapping it detected as NumDiv, i'm not sure what does that mean. It's so weird since if I type it, it does write the exact "/" character. It's kinda weird since my keyboard doesn't have NumLock.

The Slash character (/? key cap) is not the same as the Division symbol (/) on the numeric key pad.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 18, 2021, 09:14:20 pm
As I said, it's about the key (the physical key), not the char that it produces.
Because once you use the ctrl key, there is no "/" produced at all.


It depends on the key layout. And the IDE does not always know what your keys actually are mapped to.

On a German keyboard / is shift-7
But ctrl-shift-7 sets a bookmark, so it can't toggle comments.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: AFFRIZA 亜風実 on November 18, 2021, 09:28:18 pm
As I said, it's about the key (the physical key), not the char that it produces.
Because once you use the ctrl key, there is no "/" produced at all.


It depends on the key layout. And the IDE does not always know what your keys actually are mapped to.

On a German keyboard / is shift-7
But ctrl-shift-7 sets a bookmark, so it can't toggle comments.
I see, I think KDE Neon configuration messed up my keyboard layout maybe since the Windows works normal. I'll try to reach their community.  :)

Thanks for the help.  ;)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: JuhaManninen on November 18, 2021, 10:04:11 pm
Sorry, I forgot the Ctrl - VK_OEM_2 mapping. It shows as '/' in the Key Mappings window indeed.
I have never used it because in my locale keyboard '/' is Shift-7. Ctrl-Shift-7 sets an editor bookmark.
The default requires requires an English keyboard.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: robert rozee on November 20, 2021, 05:08:35 am
in the example file:
/usr/share/lazarus/2.0.12/examples/fontenum.pas

line 375 reads:
Code: Pascal  [Select][+][-]
  1.   L.Add('abcdefhijklmnopqrstuvwxyz');
ie, is missing the letter 'g'. it should be:
Code: Pascal  [Select][+][-]
  1.   L.Add('abcdefghijklmnopqrstuvwxyz');

a minor cosmetic, but it left me puzzled why upper and lower case lines were different lengths.


cheers,
rob   :-)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: dsiders on November 20, 2021, 08:22:29 am
in the example file:
/usr/share/lazarus/2.0.12/examples/fontenum.pas

line 375 reads:
Code: Pascal  [Select][+][-]
  1.   L.Add('abcdefhijklmnopqrstuvwxyz');
ie, is missing the letter 'g'. it should be:
Code: Pascal  [Select][+][-]
  1.   L.Add('abcdefghijklmnopqrstuvwxyz');

a minor cosmetic, but it left me puzzled why upper and lower case lines were different lengths.


cheers,
rob   :-)

Patch submitted. https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39480
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: trev on November 23, 2021, 09:09:42 am
macOS (version independent)

RC2 installs the Lazarus folder in /Applications with the following ownership and permissions which prevents a rebuild by the user:

Code: [Select]
drwxr-xr-x  35 503   admin  1120 31 Oct 19:26 Lazarus
Once that is solved:

Code: [Select]
7.938] Searching file /Users/trev/tmp/project1.res... found
[7.938] Searching file /Library/Developer/CommandLineTools/usr/bin/fpcres... not found
[7.938] Searching file /Library/Developer/CommandLineTools/usr/bin/FPCRES... not found
[7.938] Searching file /usr/local/lib/fpc/3.2.2/fpcres... not found
[7.938] Searching file /usr/local/lib/fpc/3.2.2/FPCRES... not found
[7.938] Searching file /usr/bin/fpcres... not found
[7.938] Searching file /usr/bin/FPCRES... not found
[7.938] Searching file /bin/fpcres... not found
[7.938] Searching file /bin/FPCRES... not found
[7.938] Searching file /usr/sbin/fpcres... not found
[7.938] Searching file /usr/sbin/FPCRES... not found
[7.938] Searching file /sbin/fpcres... not found
[7.938] Searching file /sbin/FPCRES... not found
[7.938] Error: (9021) resource compiler "fpcres" not found, switching to external mode

Lazarus cannot find fpcres which is installed to /usr/local/bin because it never looks there!
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: timppl on November 24, 2021, 07:27:31 am
On my machine ( Mageia 8 ) RC2 of 2.2.0 has a problem setting the colour of the gutter in the editor window. If I set it from the Options window, the colour changes correctly, but when Lazarus restarts it is back to the default black ( this is with the Twilight scheme).
The new settings are saved correctly in editoroptions.xml
Quote
editoroptions.xml:20:          <ahaGutter Background="clInactiveCaption"/>
editoroptions.xml:21:          <ahaOverviewGutter Background="clSilver" Foreground="clGray" FrameColor="clSkyBlue"/>

I also have 2.0.12 installed, and a daily build of trunk, and each version has its' own configuration directory.

regards

Tim
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 24, 2021, 07:36:42 am
On my machine ( Mageia 8 ) RC2 of 2.2.0 has a problem setting the colour of the gutter in the editor window. If I set it from the Options window, the colour changes correctly, but when Lazarus restarts it is back to the default black ( this is with the Twilight scheme).
The new settings are saved correctly in editoroptions.xml
Quote
editoroptions.xml:20:          <ahaGutter Background="clInactiveCaption"/>
editoroptions.xml:21:          <ahaOverviewGutter Background="clSilver" Foreground="clGray" FrameColor="clSkyBlue"/>

I also have 2.0.12 installed, and a daily build of trunk, and each version has its' own configuration directory.

1) Do the editoroptions.xml between the 3 installs you have differ (in the color block)?

If you backup your 2.0.12 or trunk editoroptions.xml and copy the RC2 version there => does it work or fail?

2) Is the issue maybe with it being a system color? "clInactiveCaption" => What happen if you set it to ClGrey (or whatever clInactiveCaption should resolve too)?

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: timppl on November 24, 2021, 08:07:11 am
Hi Martin

The color block is the same in all the files ( except for version number ; 2.0.12 is version 12, the others are version 13).

The RC2 settings work fine in the other versions with the colours being shown correctly.

In RC2 it doesnt matter what colour the gutter is set to, it reverts to black on restart ( but the entry in the colors block does not change ie Lazarus is not writing clBlack in the file )

HTH

Tim
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 24, 2021, 08:33:03 am
Can you please attach:

Any file from your userschemes folder.
Your current editoroptions.xml (from the RC)

------------
After that, can you check, if the color option page, when you select the "gutter" color, shows
"The element uses (and edits) the schemes:"
- selected language
- scheme global

Does changing this setting, and then setting the color make a diff?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: timppl on November 24, 2021, 09:08:06 am
Martin

Attached is the editoroptions.xml for RC2 (cant attach .xml, so renamed it to .xml.pas).

I set the selected language option and saved it.  Restarting lazaus and the gutter shows as grey  ;D.

Just for fun, I went and changed the gutter colour and selected scheme global. On restart the gutter colour was as selected (clyellow  %) ).

So it seems that having changed to language option, it all works correctly subsequently with either the language or scheme options.

Tim
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: af0815 on November 24, 2021, 10:19:07 am
Lazarus 2.2.0RC2 (rev lazarus_2_2_0_RC2-0-gab85f43b84) FPC 3.2.2 i386-win32-win32/win64 have a Problem in TTabControl and Anchors in Frames (in Frames).

Is affected from this problem TTabControl causes ELayoutException in Frames (39478) - only on win32 have other people reported. it pops up with Lazarus trunk, but i have today tested RC2 is also affected. 

I have installed a new fpc stable and Lazarus 2.2.0 RC2 from scratch and tested with the attached layoutproblemWOfs.zip no other dependencies needed.

Run the program an change TS_DUT1 to TS_DUT2 and back - and the Exception raises. If you remove the Anchors from TTabControl it works.

---
Program was working in Lazarus 2.1.0 r65130 FPC 3.2.2 i386-win32-win32/win64

Links:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39478

in German forum
https://lazarusforum.de/viewtopic.php?f=5&t=13936 we have discussed a possible solution, in TTabControlNoteBookStrings.TabControlBoundsChange there is possible that the position change for FNotebook is set wrong. The bounds not changed should be taken from FNotebook, not from TabControl, becaus this added a border. And then a loop is introduced.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Marc on November 25, 2021, 11:52:32 am
Attached is the editoroptions.xml for RC2 (cant attach .xml, so renamed it to .xml.pas).

Fixed this it, xml is allowed now

Marc
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 25, 2021, 11:56:59 am
Attached is the editoroptions.xml for RC2 (cant attach .xml, so renamed it to .xml.pas).

I set the selected language option and saved it.  Restarting lazaus and the gutter shows as grey  ;D.

Just for fun, I went and changed the gutter colour and selected scheme global. On restart the gutter colour was as selected (clyellow  %) ).

So it seems that having changed to language option, it all works correctly subsequently with either the language or scheme options.

I tried to reproduce (though on windows, but that should not matter...).  Tested the RC2 in 32 and 64bit.
Both worked with your xml.

* If you place the old xml back => does the error happen again?

* Did/Does the new/working config have significant diffs in the color section?

Just on the off chance that a wrong file was loaded....

If it still happens:
* Menu: View => IDE internals => About IDE
  What are the values for primary and secondary conf path?
  The only editoroptions.xml you have is in the secondary path? There is none in the primary?

   You may also get to see those pathes, if you start the IDE from a console. It should print them...

If it still happens:
* Do you start the "lazarus" exe directly, or do you start "startlazarus"?
   If the latter, does it make a diff if you directly start "lazarus" ?

If it still happens:
* If you change the font-size together with the color => is the font size correctly loaded?


Also, have you at some point rebuild you IDE? And if so, is your IDE build with -O2 or higher?

There is a bug in FPC (only O2 up), extremely hard to trigger (only known trigger is some code in fpdebug (using a generic from LclBase though), and only if the target is 64bit win, but other code, on other targets could trigger it in theory).
This is fixed in FPC 3.2.3 and 3.3.1 / For what I know, it was first seen in 3.2.0
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: timppl on November 26, 2021, 08:43:27 am
Hi Martin

I have had a bit of a play. If I use the old xml file the error reappears, so I looked at the Color section.

There are a number of differences,
Working
Code: XML  [Select][+][-]
  1.     <Color Version="13">
  2.       <LangObjectPascal Version="13">
  3.         <ColorScheme Value="Twilight"/>
  4.         <SchemeTwilight>
  5.           <ahaGutter Background="clGray"/>
  6.         </SchemeTwilight>
  7.       </LangObjectPascal>
  8.       <Globals Version="13">
  9.         <SchemeTwilight>
  10.           <ahaGutter Background="clGray"/>
  11.         </SchemeTwilight>
  12.       </Globals>
  13.     </Color>
  14.  

Non-working
Code: XML  [Select][+][-]
  1.     <Color Version="13">
  2.       <LangObjectPascal>
  3.         <ColorScheme Value="Twilight"/>
  4.       </LangObjectPascal>
  5.       <Globals Version="13">
  6.         <SchemeTwilight>
  7.           <ahaGutter Background="clGray"/>
  8.         </SchemeTwilight>
  9.       </Globals>
  10.     </Color>
  11.  
so I manually edited the file to see if any were significant.
In short, if i delete the
Quote
Version="13"
from the "LangObjectPascal" section then the fault shows ( i.e. the gutter is black ); put it back in and it works correctly.

Deleting the "Globals" section in the working xml also puts the gutter to black, even though clGrey is also specified in the "ColorScheme" section.

All configuration is in the primary path, secondary path does not exist ( it is set to /etc/lazarus/ )

It is normally started from a desktop file which calls
Quote
Exec=/home/tim/misc/laztest/startlazarus --pcp=/home/tim/.config/laztest

Changing startlazarus to lazarus with the non-working config makes no difference to the bahavior, the gutter is still black.

HTH

Tim
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 26, 2021, 10:47:01 am
Created https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39489

I haven't checked if I can reproduce. But the description give a pretty good idea where to start.
It Might take a bit before I get to it...
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 26, 2021, 10:44:27 pm
I encounter a nasty regression:

- I compile projects last time compiled using 2.2.0 RC1 with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

As result I get not tons of these changes to the .lfm file which are obviously wrong, see the attached screenshot.

is there a fix available or a workaround to prevent this issue?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 26, 2021, 10:49:18 pm
is there a fix available or a workaround to prevent this issue?

there is: I change with a text editor
- LCLVersion = '2.2.0.2'
+ LCLVersion = '2.2.0.3'

Then no conversion for the .lfm file takes place and thus I can avoid the bug. however, it its clear that there might be a conversion for good reason, it is just that in the conversion is the bug.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 26, 2021, 11:37:48 pm
There is an other regression to RC1:

I want to compile on release mode. For this mode I have the settings attached, so no debugger is used. But when I run my compiled result I am asked to set a debug option, see attached.

So why do I have to specify a debugger option despite no debugging is used?

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 26, 2021, 11:42:33 pm
there is: I change with a text editor
- LCLVersion = '2.2.0.2'
+ LCLVersion = '2.2.0.3'

This does not work. I now get also the attached. So the bug is not in the LFM file conversion.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 27, 2021, 12:35:17 am
I encounter a nasty regression:

- I compile projects last time compiled using 2.2.0 RC1 with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-49-gcbc6b141e2)
FPC 3.2.3 x86_64-win64-win32/win64

As result I get not tons of these changes to the .lfm file which are obviously wrong, see the attached screenshot.

Update your Fpc 3.2.3

The snapshot you have as a bug, and that leads to plenty of integer values being replaced with color names.


Be aware, that most likely once an lfm has been "corrupted" it can only be read with the faulty version that wrote it. So check, if you have backups.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 27, 2021, 12:53:54 am
I want to compile on release mode. For this mode I have the settings attached, so no debugger is used. But when I run my compiled result I am asked to set a debug option, see attached.

So why do I have to specify a debugger option despite no debugging is used?

Setting "debug info" to none, does not mean to not have a debugger. (Though admittedly, it leaves the debugger *almost* useless).

With the "debug info" = none, I can
- compile
- run without debugger (from the menu)

Only when I do F9 (or normal "run"), which means run in the debugger, then the dialog comes.

Indeed, the old IDE did not care (and IIRC, if you switch the new IDE to use gdb, then it wont care either).
The old IDE did happily let you run your app in the debugger, without debug info present. That means all the debugger could do, is give you assembler, if you paused the app.

Assign a key to "run without debugger" and use that instead. Since you do not want to debug anyway.


Both behaviours have there pro and con.
- the old: if you really did just want to "run without debugger", you could ignore that there was a debugger present. In *most* cases it was unnoticeable.
- the new: if you do want to debug, its nice to know that you need to fix the settings.

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 29, 2021, 03:01:13 pm
Update your Fpc 3.2.3
The snapshot you have as a bug, and that leads to plenty of integer values being replaced with color names.

Thank you. I just did this an in case I still the bug, I will report this here.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 29, 2021, 03:41:53 pm
- the old: if you really did just want to "run without debugger", you could ignore that there was a debugger present. In *most* cases it was unnoticeable.
- the new: if you do want to debug, its nice to know that you need to fix the settings.

Thanks for explanation. I  only did not expect such a change between two RC releases.

However, since I saw some debugger-related commits to the 2_2 branch, I upgraded my Laz to this (using FCUPDeluxe). But also with
Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-63-gc29da8f0d8)
FPC 3.2.3 x86_64-win64-win32/win64
I have an issue:

- In the debug settings I set the debug info type to Automatic, see screenshot attached.
- When I now run in debug mode I get a dialog in which I must specify the debug info type. When I cancel this dialog, the debugging is not started.

But isn't the Automatic setting thought to select automatically an appropriate debug info?
This issue appears for both possible debuggers (FPDebug and IDE default)

Besides this, where can I find kind on a comparison table
- between the "IDE default debugger" and "FPDebug"
- the different debug info type settings (Dwarf1, 2, 3 and Stabs)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 29, 2021, 04:01:39 pm
I should also mention that the dialog on starting a debug session speaks about the FPDebug debugger, see attached. But I get this also when I use the "IDE default" debugger.

Is the "IDE default" debugger the same as the FPDebug debugger?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 29, 2021, 05:16:33 pm
I should also mention that the dialog on starting a debug session speaks about the FPDebug debugger, see attached. But I get this also when I use the "IDE default" debugger.

Is the "IDE default" debugger the same as the FPDebug debugger?
Yes. Well the default depends on your OS. On Linux and Windows that is FpDebug (Since Laz 2.2RC - and already for some time in git)

More to the point: The default debugger is set under Tools > Options > Debugger Backend.
Whatever is selected there is the default.
In the project, you can then set a diff debugger for each project. E.g. if you have a project that you run on a remote machine, and you need a remote debugger, then you can (if you install it) set the gdb-remote debugger.

Also, this default is for new installations.
If you upgrade an existing config, it will keep your settings (which would be gdb, unless you never made any change, that saved any debugger specific config).


Thanks for explanation. I  only did not expect such a change between two RC releases.
This was already the case for RC1.

If indeed it did not happen to you, then maybe it used an old config of yours, that pointed to gdb?

Quote
I have an issue:

- In the debug settings I set the debug info type to Automatic, see screenshot attached.
- When I now run in debug mode I get a dialog in which I must specify the debug info type. When I cancel this dialog, the debugging is not started.

But isn't the Automatic setting thought to select automatically an appropriate debug info?
This issue appears for both possible debuggers (FPDebug and IDE default)
Ideally yes... But depends on who defines "appropriate"....

Automatic, just means that the IDE leaves the decision to FPC. So it means "use fpc default".
The fpc default depends on the target (OS, bitness, ...).

The IDE does not have a list of all the fpc-defaults. So it can't be sure if "automatic" resulted in use-able debug info (for gdb that did not matter, as all the types of debug info can be read by gdb / though some lead to more errors in gdb....).

Since FpDebug only read DWARF, but not stabs, it now needs one of the dwarf settings explicitly selected.

The fact that this leads to extra user-interaction (instead of having some default) is not great. But keeping gdb instead of FpDebug is not better.
Hopefully that can be improved..... But not sure when...

Quote
Besides this, where can I find kind on a comparison table
- between the "IDE default debugger" and "FPDebug"
- the different debug info type settings (Dwarf1, 2, 3 and Stabs)
The "default debugger" is not a specific type. See above.

But info on the different debuggers:  https://wiki.lazarus.freepascal.org/Debugger_Status

That does not list every single issue, every debugger has....
There is some background here (some is really related to GDB, other relates to all debuggers or the way FPC encodes debug info, or the debug info itself....)
https://wiki.lazarus.freepascal.org/GDB_Debugger_Tips

GDB has lots of issues with various Pascal data types and structures. Depending on the gdb version this leads from data not shown to crashes.
And we can't fix GDB.

FpDebug is not bug free either. But we can fix it, and it does deal with a lot more of the data types.

Stabs and Dwarf are how the compiler tells the debugger how the machine code relates to the Pascal source, and where/what/which variables, types, .... are to be found.
I don't have a list of all the diffs.
Also that would include what FPC actually uses of each feature set. And what the debugger can read of it.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 29, 2021, 06:33:21 pm
GDB has lots of issues with various Pascal data types and structures. Depending on the gdb version this leads from data not shown to crashes.

many thanks for all your info. That helped me a lot!

My mistake was to use the FPCUPDeluxe version and leaving the official RC2 installed version aside. With FpCUPdeluxe one has to setup GDB on its own when necessary.

The last days then I debugged with FPDebug and I noticed that in some data structures I could not read out the values while this worked with GDB. I also got crashes with GDB in the past, but not often. For me the info about the actual values is more important that I will stay a while now with GDB.

You also helped me to understand the different debugger options, so I will now try out dwarf3 and see if this is a benefit.

I will not go back to the official RC2 release to not report here things that are actually not in RC2.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 29, 2021, 06:49:50 pm
The last days then I debugged with FPDebug and I noticed that in some data structures I could not read out the values while this worked with GDB. I also got crashes with GDB in the past, but not often. For me the info about the actual values is more important that I will stay a while now with GDB.

Do you have examples for the missing fields?
(and your OS / and which debug info type)

I know of the following (some only from having been told...)

- "file of FOO"
If (and only if) compiled with stabs, then a lot of details (like the file handle) will be visible.
Since it is stabs, it is gdb only.

- variant (and maybe records with "case" section)
FpDebug does not show the data, if dwarf-3 is used. Should work with Dwarf-2.

- type foo = interface
does not work, because there is no data in the interface (and the debug info does not contain anything about it => so not debugger specific)

- mode delphi - automatic dereferencing
   Type foo = ^record a: integer; end;
I have no idea if (by mere accident) "FooData.a" will work in gdb. (Since gdb itself has issues with getting Pascal data with (hidden) pointers in some cases, the IDE does a lot of trickery to get the data => it might just solve this, without intend / never tested)
FpDebug will not resolve "FooData.a" => there is a {$DEFINE } that can be set to compile the IDE, and then it will work.


Also make sure that packages are compiled with Dwarf. They are often set to automatic. Afaik that only matters for some 32bit targets, on 64 bit major targets the fpc default should be dwarf anyway.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on November 29, 2021, 07:26:40 pm
Do you have examples for the missing fields?
(and your OS / and which debug info type)

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-63-gc29da8f0d8)
FPC 3.2.3 x86_64-win64-win32/win64
Windows 10 21H2, 64bit

I tested with dwarf with sets, dwarf2 and dwarf3.

In the attached image is my test case.

This is a simple int and I don't understand why I don't see its value. Here is the source code: https://github.com/JobstTechnologies/JT-Driver-Sensing/blob/master/SIXControlUnit.pas#L71

(I tried to set up gdb for comparison but failed since GDB crashes now all the time -> I really need t go away from the FCUPDeluxe build.)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on November 29, 2021, 10:48:07 pm
I tested with gdb, and did also not get them with gdb (9.2).

Those are "class var" => basically global, but scoped. So to avoid naming conflicts, fpc renames them and tells the debugger they are called
dwarf2:  _static_tsixcontrol_NUMCHANNELS
dwarf3:  $_static_tsixcontrol_NUMCHANNELS

At least, fpc kept the var name uppercase even in Dwarf3 (were it normally uses the case as in the source).

So it should be (almost) possible to find them.

Only issues would be

1)
with dwarf2
Code: Pascal  [Select][+][-]
  1. var _static_tsixcontrol_NUMCHANNELS: integer;
would be detected as static var, but is not.

2)
Code: Pascal  [Select][+][-]
  1. type
  2.   TFoo_ = class
  3.     class var
  4.     bar: integer;
  5.   end;
  6.  
  7.   TFoo = class
  8.     class var
  9.     _bar: integer;
  10.   end;
  11.  
But that fails to compile: project1.lpr(25,3) Error: Duplicate identifier "$_static_tfoo__BAR"

Need to see how soon I can get to this....
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Bart on November 29, 2021, 11:06:39 pm
Code: Pascal  [Select][+][-]
  1. type
  2.   TFoo_ = class
  3.     class var
  4.     bar: integer;
  5.   end;
  6.  
  7.   TFoo = class
  8.     class var
  9.     _bar: integer;
  10.   end;
  11.  
But that fails to compile: project1.lpr(25,3) Error: Duplicate identifier "$_static_tfoo__BAR"

That's a real nice bug if I may say so  O:-)

Bart
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 01, 2021, 10:09:40 pm
I tested with gdb, and did also not get them with gdb (9.2).

Those are "class var" => basically global, but scoped. So to avoid naming conflicts, fpc renames them and tells the debugger they are called

Partly fixed (main and fixes branch).

Evaluating (watch or hint) "NUMCHANNELS" while in a method of the class should work.

TClass.NUMCHANNELS  will not yet work, neither inside any method of the class, nor from code outside.  (same for instance.NUMCHANNELS)

I also have yet to test, if it works across unit bounds, if the var is in an ancestor in a diff unit.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: avra on December 01, 2021, 10:24:38 pm
FpDebug will not resolve "FooData.a" => there is a {$DEFINE } that can be set to compile the IDE, and then it will work.
Could you remember which exact define it is, and why it is not switched on by default?
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 01, 2021, 10:32:01 pm
FpDebug will not resolve "FooData.a" => there is a {$DEFINE } that can be set to compile the IDE, and then it will work.
Could you remember which exact define it is, and why it is not switched on by default?
FpDebugAutoDerefMember

Commandline:
-dFpDebugAutoDerefMember

Afaik in mode objfpc that behaviour is also off.
I haven't checked if it is in any way possible that an expression could be ambiguous with this on.
I don't use it myself for writing code. So the first thing I would not know is
Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArr = array of integer;
  3.   PIntArr = ^TIntArr;
  4. var
  5.   a: PIntArr;
  6. begin
  7.   if PtrUInt(a[1]) <> 0 then
  8.  
Would that access the first element in TIntArray?
Or would that use pointer math, and mean (a+1)^ the pointer to the 2nd (index 1) of many TIntArray stored at the address to which a points?

IIRC, fpdebug currently checks first if the expression is valid without auto-deref, and then falls back. So IIRC it would go for the 2nd answer. But not sure.

Also since I don't use the feature in coding, and I haven't yet spent time on reading up on all the possibilities how it could be used, I don't know if fpdebug covers every case, or just some.


---

The idea is to make it a configurable option in the IDE options. But I haven't gotten to that yet.

And no: the debugger does not know what mode switches were given. Not part of the debug info.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: PascalDragon on December 02, 2021, 09:06:21 am
I don't use it myself for writing code. So the first thing I would not know is
Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArr = array of integer;
  3.   PIntArr = ^TIntArr;
  4. var
  5.   a: PIntArr;
  6. begin
  7.   if PtrUInt(a[1]) <> 0 then
  8.  
Would that access the first element in TIntArray?
Or would that use pointer math, and mean (a+1)^ the pointer to the 2nd (index 1) of many TIntArray stored at the address to which a points?

As auto dereferentiation comes from Delphi one point to keep in mind is that Delphi does not support indexing pointers using the array syntax. So without auto dereferentiation (which can't be switched off in Delphi) a[1] would be invalid code. So the only valid case is that it is essentially a^[1]. And lo and behold, that's how it's implemented in FPC.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 02, 2021, 01:10:05 pm

As auto dereferentiation comes from Delphi one point to keep in mind is that Delphi does not support indexing pointers using the array syntax. So without auto dereferentiation (which can't be switched off in Delphi) a[1] would be invalid code. So the only valid case is that it is essentially a^[1]. And lo and behold, that's how it's implemented in FPC.

And so, autoderef in FpDebug must be off by default.

Because then

Code: Pascal  [Select][+][-]
  1. type
  2.   TIntArr = array of integer;
  3.   PIntArr = ^TIntArr;
  4. var
  5.   b: array of TIntArr;
  6.   a: PIntArr;
  7. begin
  8.   SetLength(b, 2);
  9.   a := @b[0];
  10.  
  11.   a[1] ....
  12.  

"a[1]" returns the value of b[1]

While with autoderef it returns b^[1] => which is b[0][1]

---
All that, once it is fully and correctly implemented in FpDebug.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on December 06, 2021, 03:51:12 am
Partly fixed (main and fixes branch).
Evaluating (watch or hint) "NUMCHANNELS" while in a method of the class should work.

I got the latest 2_2 fixes branch and tested it. It works fine for me.  :)
Many thanks!
(I am also impressed how quick you implemented this.)
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on December 06, 2021, 06:49:20 pm
@martin_fr I see now another debugger issue that should be improved for the final release

- in the Project Options I set to use FPDebug, see the attached screenshot
- this results in this change in the *.lpi file

Code: Pascal  [Select][+][-]
  1. <Debugger>
  2.       <Backend Value="{9983401B-BBC1-4101-B04B-D600E4AB6D20}"/>
  3. </Debugger>
  4.  

OK, but when I now open the *.lpi file on another PC, I get a warning that the debugger was not found.
When I set on this PC FPDebug and transfer it back to the initial PC, I get the same warning. So I think the Backend Value should maybe simply be "FPDebug" and no number that might not exist on another PC.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 06, 2021, 07:37:26 pm
Please report on the bug tracker. That should probably be stored in the session.

It needs to be an UUID reference.

For example in my IDE, I hav many "gdb" debuggers defined. For testing diff gdb versions.
If FpDebug will have more options, maybe some people want several configs.

So just "FpDebug" is not possible. Which of the many configs would that be?

---
There is more that needs to be added  to the abilities of setting and choosing debuggers. But all in good time.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on December 07, 2021, 06:53:05 pm
I think this is a regression since this did not appear with RC1:

- set a breakpoint somewhere in your code
- sun the program in Release mode
result: the breakpoint becomes invalid.

This is new but might be OK, since it is no debug run.
But now
- stop the program
result: the breakpoint stays invalid, also when you changed the build mode to "Debug"

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-73-g0bf8dc1256)
FPC 3.2.3 x86_64-win64-win32/win64

I think the breakpoint should become valid again when the program is not executed like it was before.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on December 07, 2021, 07:01:28 pm
For example in my IDE, I hav many "gdb" debuggers defined. For testing diff gdb versions.
If FpDebug will have more options, maybe some people want several configs.

So just "FpDebug" is not possible. Which of the many configs would that be?

I will create the bug report as you requested.

Concerning the feature, this is my use case:

- PC A has 2 debuggers defined, FPDebug,
 and GDB
- PC B has no explicit debuggers defined (thus it has by default only FPdebug)

In the project options, I set on PC A to use the FPDebug. Fine, but now I open the project on PC B. There is no explicit debugger and I get a warning about the missing debugger despite the desired FPDebug is available.

So for example in my case several persons work on a project on different PCs. The idea is that there is a debugger defined for the project so that all programmers use this. Therefore it is of importance if the debugger is GDB or FPDebug. As the feature is currently, I cannot achieve this.
But OK, this is maybe a wish for the future.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 07, 2021, 07:54:09 pm
I think this is a regression since this did not appear with RC1:

- set a breakpoint somewhere in your code
- sun the program in Release mode
result: the breakpoint becomes invalid.

This is new but might be OK, since it is no debug run.
But now
- stop the program
result: the breakpoint stays invalid, also when you changed the build mode to "Debug"

Lazarus 2.2.0RC3 (rev lazarus_2_2_0_RC2-73-g0bf8dc1256)
FPC 3.2.3 x86_64-win64-win32/win64

I think the breakpoint should become valid again when the program is not executed like it was before.

Actually, while the debugger is not running, technically it should be unknown.

This is not about changing the debug info. This should (afaik) be triggered when the debugger stops.

Merely changing the debug info, does not, will not, and should not change the state (other than potentially unknown). Since without the debugger the IDE can not know if the breakpoint is then valid. It might be on an empty line, or even a unit not included in the exe.

IIRC:
unknown: red with no further mark
good/valid: red witch check-mark
bad: orange
disabled: green

So what you mean is actually unknown.

and gdb has red with pause-bars for "not yet valid, lets see if a library gets loaded where it can be set". That one does not yet exist in FpDebug.

----------------
I have to check your above report when I have time.

Please report it on the bugtracker, so it will not be forgotten.





About empty lines:
yes gdb accepted empty lines for the next line. With the effect that people did not know why the debugger stopped at line 500 => which was the first line of code in the unit. And the answer was, because at line 20 of that unit a breakpoint was set.
Neither "not at all" nor "at all costs" is good. But that is a different topic, and currently not high prior.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 07, 2021, 07:56:40 pm
- PC A has 2 debuggers defined, FPDebug,
 and GDB
- PC B has no explicit debuggers defined (thus it has by default only FPdebug)

In the project options, I set on PC A to use the FPDebug. Fine, but now I open the project on PC B. There is no explicit debugger and I get a warning about the missing debugger despite the desired FPDebug is available.

So for example in my case several persons work on a project on different PCs. The idea is that there is a debugger defined for the project so that all programmers use this. Therefore it is of importance if the debugger is GDB or FPDebug. As the feature is currently, I cannot achieve this.
But OK, this is maybe a wish for the future.

I understand it is annoying that it goes into the lpi. It should be the lps.

lps, session files are usually not shared. Nor should they be. => so then the setting would not be an issue for others.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on December 07, 2021, 09:43:23 pm
unknown: red with no further mark
good/valid: red witch check-mark
bad: orange
disabled: green

After setting the breakpoint it is red and unknown, see the attached screenshot
Then I run the program in Release mode and stop it subsequently.
result: the breakpoint became green and the context menu says invalid, see the second screenshot
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 07, 2021, 10:34:26 pm
Noted, please report the breakpoint issue.

I have to check what is supposed to happen, but got other more pressing issues now.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Muso on December 07, 2021, 11:42:55 pm
Noted, please report the breakpoint issue.

Done: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39505

The debugger UUID issue is now: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39504
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on December 07, 2021, 11:59:23 pm
ok, a few words on the uuid.

Moving it to lps, is obviously the important bit.

Storing "FpDebug" or "Gdb" in the LPI is not helpful.

For starters, you could install LazDebuggerFpGdbmi, which mixes both. But if the lpi has "FpGdb" then that gives an error for anyone that has not got it installed. (Yet actually, that scenario will happen....)

More important:
- If you want specific setting for a debugger stored with the project, then the class is not enough.
- You only ever need, to force everyone on the team to a specified debugger, If there is a problem with other debuggers.

But that problem, may not be solved by the class. Some debuggers on some OS have an option to force a console. If that is needed for the debugging, then the option must be included too.

The *long* time plan therefore is, that you should be able to chose from:
- UUID in lps
- a complete config (class, and options) in lps
- a complete config (class, and options) in lpi

Maybe even more than one complete conf, and then the ability to select (that selection going into the session).

But that will take some time to do.

Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zhuyl on December 11, 2021, 06:27:22 am
I found this problem: in the child form inherited by the form, if an event exists in the parent form, double-clicking the event in the child window is used to overwrite, and sometimes the procedure existing in the form is regenerated. There is a test case in the attachment. When in the uGoodsDetail form, double-click Createt and other events (the parent form has), and select Create Override will repeatedly generate InitStock and SaveCombineOrSplit.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: JuhaManninen on December 11, 2021, 10:56:10 pm
@zhuyl, please report the bug, but make a minimal simple example to reproduce it.
The project you uploaded requires extra packages and is big.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: AlexTP on December 16, 2021, 12:35:09 pm
Juha, let's apply this fix for gtk2?
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39422
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: zhuyl on December 18, 2021, 12:12:37 pm
I found this problem: in the child form inherited by the form, if an event exists in the parent form, double-clicking the event in the child window is used to overwrite, and sometimes the procedure existing in the form is regenerated. There is a test case in the attachment. When in the uPrintBarCode form, double-click Createt and other events (the parent form has), and select Create Override will repeatedly generate InitPrint()
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: ChrisR on December 25, 2021, 08:27:34 pm
I do think this Lazarus 2.2 milestone issue can be resolved by changing a single line of code
  https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39293
specifically, `lclplatformdef.pas` should be modified to that

{$IFDEF darwin}{$DEFINE WidgetSetDefined}
lpCarbon;
{$ENDIF}

should read

{$IFDEF darwin}{$DEFINE WidgetSetDefined}
lpCocoa;
{$ENDIF}

This would make lazbuild consistent with the Lazarus IDE, would use a supported widgetset, and would simplify documentation describing how to build cross platform projects.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: 0kulist on December 30, 2021, 11:09:37 pm
Hello,
Just an annoying unexpected behavior of TFloatSpinEditEx component from LazControls on Mac OS 10.14. When clicking Up button - value decreases, with Down button - increasing. Somehow vice versa. On Windows - working as normal TFloatSpinEdit.

Why not TFloatSpinEdit ? Because of FocusOnBuddyClick.

Same behavior with Lazarus 2.0.12 on Mac, with fpc-3.2.0 and fpc-3.2.2.

P.S. Same for TSpinEditEx.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: VTwin on January 01, 2022, 11:29:44 pm
Hello,
Just an annoying unexpected behavior of TFloatSpinEditEx component from LazControls on Mac OS 10.14. When clicking Up button - value decreases, with Down button - increasing. Somehow vice versa. On Windows - working as normal TFloatSpinEdit.

Why not TFloatSpinEdit ? Because of FocusOnBuddyClick.

Same behavior with Lazarus 2.0.12 on Mac, with fpc-3.2.0 and fpc-3.2.2.

P.S. Same for TSpinEditEx.

Best to post this on the Cocoa Widgets board.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on January 03, 2022, 08:08:43 pm
I separated the TSpinEdit Min/Max discussion.

It is now at:
https://forum.lazarus.freepascal.org/index.php/topic,57722.0.html
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: BSaidus on January 04, 2022, 08:38:54 pm
Hello.
I have a suggestion about the system font used by the IDE
On Windows 7 is "Segoe UI 9", on XP "Tahoma 9",
So What if adding in the IDE Option a possibility to change the IDE default font ( Object inspector, Component Tab, .... ).
Currentely I recompile a whole IDE with changed font to make it correspond to my wishes.

Thanks.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on January 04, 2022, 09:06:59 pm
I have a suggestion about the system font used by the IDE

Please start a new thread, as this is not an issue about the RC or 2.2.
Title: Re: Lazarus Release Candidate 2 of 2.2.0
Post by: Martin_fr on January 04, 2022, 09:09:54 pm
Topic locked.

This topic was to identify last minute issues for 2.2.
As 2.2 has been tagged, no more issues can be addressed.

Any issues should be reported through the normal channels.
Other suggestions can be made in the appropriate places.
TinyPortal © 2005-2018