Lazarus Release Candidate 1 of 3.0

[d7_2_laz]

Welcome to the new release / RC1!
I'm happy to say that a very long story of issues dealing with Listview in virtual mode (Windows),
annoying since approx. 2 years, has come to a good end now!
https://forum.lazarus.freepascal.org/index.php/topic,59393.msg442723.html#msg442723

It appears to me that – regarding those matters – the virtual listview now is back on board of an official release 

[JuhaManninen]

May be a new revizion 3.x must be with FPC 3.x?

Yes. Just use the latest FPC 3.2.2 which also is old because FPC project has a very slow release cycle.

[wp]

Can you fix this please?

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

Re: Change of property BorderSpacing.Left for an inherited control is not save in the .lfm file

Please see the comment that I added to your report. Short answer: You are replacing the property value by its default value, and thus it is not written to the lfm - this is unavoidable.  Set the BorderSpacing.Left to 1, and it will work. Or, if you absolutely need the 0 value, reset it at runtime after creation.

[bpranoto]

Can you fix this please?

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

Re: Change of property BorderSpacing.Left for an inherited control is not save in the .lfm file

Please see the comment that I added to your report. Short answer: You are replacing the property value by its default value, and thus it is not written to the lfm - this is unavoidable.  Set the BorderSpacing.Left to 1, and it will work. Or, if you absolutely need the 0 value, reset it at runtime after creation.

Thanks wp and martin for the explanation, I never thought this is quite complicated.

[JuhaManninen]

Thanks wp and martin for the explanation, I never thought this is quite complicated.

Which means you did not try to fix it yourself.
In a FOSS (Free and Open Source Software) project the best way to get thing done is to do it yourself and provide a patch.
Some issues are easy to fix. They just had low priority for the core developers.
Some issues are difficult.
Issues dealing with inherited forms and frames usually belong to the latter category.

[jonyrh]

Hello aweryone! 
Reporting a new issues in 3.0 RC1:

Using: TAChart + TAChartFPVectorial + FPVectorialPkg + LCLWidgetType=nogui
Error in Lazarus 3.0 RC1 only + FPC 3.2.2
In Lazarus 2.2.6 + FPC 3.2.2 = OK !
vfWindowsMetafileWMF - not work anymore

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

[dbannon]

On Linux (at least) the way Lazarus treats a tilde, '~' in a lazarus.cfg file has changed. It does not seem to be expanded correctly, now used as a relative path to current dir. For example, this config gives expected result in lazarus 2.2.6 but in Fixes does not -

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

1. dbannon@u2004-build:~/bin/Lazarus/lazarus-fixes_3_0$ cat lazarus.cfg
2. --pcp=~/bin/Lazarus/Configs/lazarus-fixes_3_0
3.  

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

1. dbannon@u2004-build:~/bin/Lazarus/lazarus-fixes_3_0$ ./lazarus
2. using config file /home/dbannon/bin/Lazarus/lazarus-fixes_3_0/lazarus.cfg
3. SetPrimaryConfigPath NewValue="/home/dbannon/bin/Lazarus/lazarus-fixes_3_0/~/bin/Lazarus/Configs/lazarus-fixes_3_0"
4. Hint: (lazarus) [TMainIDE.ParseCmdLineOptions] PrimaryConfigPath="/home/dbannon/bin/Lazarus/lazarus-fixes_3_0/~/bin/Lazarus/Configs/lazarus-fixes_3_0"

And sure enough, it creates a config dir in the current directory starting with the '~' character. Not nice.

I see no reference to no longer expanding out the tilde but even if that is deliberate, I suggest lazarus should, on *nix at least, object to finding a '~' in a path. What it does now is almost certainly NOT what the user expects.

This is, in my opinion, a bug, but is the change intended ?  Not sure how to word a bug report ?

Davo

[dbannon]

Another questionable "issue", really a doc issue. The Release Notes mention that the Qt5 c binding have been updated. But I think this is one point that needs to be labored !  Most people depend on the libqt5pas library in their Linux distro, not now for some time !

In fact they need to build a new library from the C source provided in the Lazarus Source or use the one from  https://github.com/davidbannon/libqt5pas.

That needs to be made clear on https://wiki.freepascal.org/Lazarus_3.0_release_notes - I seem to have edit access but would not go editing such a page with checking if I should first.

Davo

[Martin_fr]

And sure enough, it creates a config dir in the current directory starting with the '~' character. Not nice.

I see no reference to no longer expanding out the tilde but even if that is deliberate, I suggest lazarus should, on *nix at least, object to finding a '~' in a path. What it does now is almost certainly NOT what the user expects.

This is, in my opinion, a bug, but is the change intended ?  Not sure how to word a bug report ?

I don't know if it is intended, but I wouldn't guess.

I am surprised it used to work. ~ is expanded by the shell. I wasn't aware Lazarus did this on its own.

What about the   Tools > Options: lazarus directory? Did that take ~, does it still?

--------------------------------
Simple report it as
"Regression: Lazarus no longer expands ~ (tilde) on Linux in lazarus.cfg"

[TRon]

I am surprised it used to work. ~ is expanded by the shell. I wasn't aware Lazarus did this on its own.

I am not.

The Lazarus source-code is literally riddled with mentioning the tilde symbol. It would have been strange not to support it. And a closer look at 2.2.6 (lazbaseconf.inc) shows:

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

1. procedure InternalInit;
2. begin
3.   // For the Unix file functions only the slash is a directory separator.
4.   // The RTL defines AllowDirectorySeparators ['/','\'] for historical reasons.
5.   AllowDirectorySeparators:=['/'];
6.  
7.   PrimaryConfigPath:=ExpandFileNameUTF8('~/.lazarus');
8.   SecondaryConfigPath:='/etc/lazarus';
9. end;
10.  

So internally it is used as well (given that it does do the expand there).

edit: a closer look at SetPrimaryConfigPath, lazconf.pp

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

1. procedure SetPrimaryConfigPath(const NewValue: String);
2. var
3.   NewExpValue: String;
4. begin
5.   NewExpValue:=ChompPathDelim(ExpandFileNameUTF8(NewValue));
6.   if NewExpValue=PrimaryConfigPath then exit;
7.   if ConsoleVerbosity>=0 then
8.     debugln('SetPrimaryConfigPath NewValue="',UTF8ToConsole(NewValue),'" -> "',UTF8ToConsole(NewExpValue),'"');
9.   PrimaryConfigPath := NewExpValue;
10. end;
11.  

So, if it isn't working (anymore) the issue seem to originate from some(thing/where) else.

[dbannon]

Note: MyBad, this problem applies to Fixes_3_0 but not RC1. It seems RC1 was forked before the commit that causes the problem. Strangely, Fixes_3_0 identifies itself, Help->AboutLazarus as 3.0RC1 too ??

Yes, the problem seem to have been introduced in idecmdline.pas where a new proc, ExpandCfgFileName has been introduced (#166) and called while cleaning up the parameters. Its not aware of how special *nix sees '~' apparently. I think its a mistake, not a deliberate change in behaviour, I'll put in a bug report and make a patch.

Davo

Edit : I think its as simple as deciding that a cmd line parameter (inc ones in cfg file) that start with a ~ should NOT be expanded. That way, the path is unchanged and eventually ends up in SetPrimaryConfigPath intact. But, I guess, maybe, Windows might not want that to happen ?  I am assuming whoever wrote ExpandCfgFileName() was a windows programmer and he/she expected it to behave as it is doing right now. Tilde in path names, sigh, who would that thats a good idea ?

Edit 2 : Yep, just don't expand a parameter that contains a tilde works fine, still unsure if I need to exclude Windows from that test, might contact the author of the original change ...

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

1. if pos('~', S) < 1 then
2. ExpandCfgFilename(s);

or

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

1. {$ifndef WINDOWS} if pos('~', S) < 1 then {$endif}
2. ExpandCfgFilename(s);

Davo

Edit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40363

[JuhaManninen]

Note: MyBad, this problem applies to Fixes_3_0 but not RC1. It seems RC1 was forked before the commit that causes the problem. Strangely, Fixes_3_0 identifies itself, Help->AboutLazarus as 3.0RC1 too ??

Actually RC1 was tagged in fixes_3_0 branch. I attach a screenshot of Gitk showing all commits in fixes_3_0 since RC1.

Yes, the problem seem to have been introduced in idecmdline.pas where a new proc, ExpandCfgFileName has been introduced (#166) and called while cleaning up the parameters. Its not aware of how special *nix sees '~' apparently. I think its a mistake, not a deliberate change in behaviour, I'll put in a bug report and make a patch.

Edit : I think its as simple as deciding that a cmd line parameter (inc ones in cfg file) that start with a ~ should NOT be expanded. That way, the path is unchanged and eventually ends up in SetPrimaryConfigPath intact. But, I guess, maybe, Windows might not want that to happen ?  I am assuming whoever wrote ExpandCfgFileName() was a windows programmer and he/she expected it to behave as it is doing right now. Tilde in path names, sigh, who would that thats a good idea ?

Why do you wonder who made it? You have Git revision control tools available like everybody else.
It was Mattias with commit msg :
 "IDE: fixed parsing long options case insensitive, fixed paths in lazarus.cfg are relative to the cfg not currentdir"
and indeed it was merged to fixes_3_0.

Edit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40363

Good.

[dbannon]

....
Actually RC1 was tagged in fixes_3_0 branch. I attach a screenshot of Gitk showing all commits in fixes_3_0 since RC1.

Yes, but the problem was committed to Fixes_3_0 after RC1 was tagged. I assume RC2 will be another, latter, tag in Fixes_3_0 and will therefore be subject to the problem I highlighted.

Why do you wonder who made it? You have Git revision control tools available like everybody else.
It was Mattias with commit msg :
 "IDE: fixed parsing long options case insensitive, fixed paths in lazarus.cfg are relative to the cfg not currentdir"
and indeed it was merged to fixes_3_0.

As I noted in the bug report.

I also noted the incorrect help message -

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

1. dbannon@dell:$> ./lazarus --help
2. ...
3. --primary-config-path= <path>
4. or --pcp= <path>

No spaces allowed in a long option after the '=' ! Wonder how long it has been like that ?  (I have git revision tools just like ....)   :-)

Davo

[JuhaManninen]

As I noted in the bug report.

Indeed you did. I didn't read it carefully.

No spaces allowed in a long option after the '=' ! Wonder how long it has been like that ?  (I have git revision tools just like ....)   :-)

I guess it has been like that from the beginning.

I use this opportunity to advertise "git bisect" command. It is a nice way to spot a guilty revision for a regression bug.
In this case the commit was so recent that no bisecting was needed, but what if a subtle regression happened a year ago but nobody noticed?
"git bisect" does a binary search with log2(n) iterations.
"git blame" is also very useful. It finds a guilty commit/person for a certain line in a certain source file. It does not show any further history nor details of those commits, and there Gitk comes handy. It can show commit history of a directory or a single source file.
I personally find Gitk superior to any other GUI frontends for Git. TortoiseGit is slow and clumsy and does not show all relevant information like Gitk does. SmartGit is OK but it concentrates more on eye-candy than functionality. And Java brings extra bloat there.

[alank]

I just tried building Lazarus 3.0.0 RC1 on my Fedora 38 workstation, using the repository versions of fpc, libQt5pas, etc.

Code: Bash  [Select][+][-]

1. > make bigide LCL_PLATFORM=qt5

It errors out at the linking stage with the following error message:

Code: Bash  [Select][+][-]

1. (9015) Linking ../lazarus
2. /usr/bin/ld: /home/alank/Lazarus/lcl/units/x86_64-linux/qt5/qtint.o: in function `CREATE':
3. /home/alank/Lazarus/lcl/interfaces/qt5//qtobject.inc:44: undefined reference to `QGuiApplication_setFallbackSessionManagementEnabled'
4. /home/alank/Lazarus/ide/lazarus.pp(171,1) Error: (9013) Error while linking
5. /home/alank/Lazarus/ide/lazarus.pp(171,1) Fatal: (10026) There were 1 errors compiling module, stopping

I'm guessing it may be a libQt5pas issue?

Alan