Lazarus Release 3.0

[calebs]

Dont know if it helps, i downloaded with fpcupdeluxe lazarus fixes (3.1) with fpc 3.2.2 and opened the same project, added a form just the same way i did last time and happens exactly the same. it adds to lpr uses, it adds to the create event but when i run it it gives me sigsev error.
If i close lazzarus and reopen, the unit is added in the project but still missing in the uses in lpr and the code for create the form.
And if i do the ctrl+shift+f11 it gives me this screen

Hey calebs,

then i go to lpr file and add to uses section and add a line to create the form like the others.

Instead of adding stuff manually, can you please use the Projects Options(Ctrl-Shift-F11) and add the new form under the Forms tree item?

This will also alter the *.lpi, making all things project be in synch.

Hope this helps!!

Cheers,
Gus

*edit
using the window with shift+ctrl+f11 added the availableform  from right list to left list, and deleted the malformed form12-13 line and then tried to run again and gives me again sigsev.
then i go to the lpr file and find that this was writed on it

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

1. ... previous similar sentences
2.  Application.CreateForm(TForm9, Form9);
3.   Application.CreateForm(TForm10, Form10);
4.   Application.CreateForm(TForm11, Form11);
5.   Application.CreateForm(TForm12, Form12);
6.   Application.CreateForm(TForm13, Form12);  
7.  

when last line should be form13... corrected manually, save, and runed fine
it seems there is a bug ? I'll try with different project or new to see if happens too.

[calebs]

its me again.
fired lazarus fixes with 3.2.2 installed with fcupdeluxe.
fille New aplication
saved project1 and unit 1
add a button
then go to file >> new form
added unit 2
it adds automatically to lpr in uses and application.createform(tform2,form2).
added code to show form2 with click of the button
added unit2 in the uses section of unit 1
then run (f9)
then sigsev when i click on the button
if i restart lazarus, is missing again unit2 in uses section and the procedure application.createform below is missing to.
if add manually sigsev again, and restart and is gone again those lines.
attach the project to this post

[Gustavo 'Gus' Carreno]

Hey calebs,

its me again.
fired lazarus fixes with 3.2.2 installed with fcupdeluxe.
fille New aplication
saved project1 and unit 1
add a button
then go to file >> new form
added unit 2
it adds automatically to lpr in uses and application.createform(tform2,form2).
added code to show form2 with click of the button
added unit2 in the uses section of unit 1
then run (f9)
then sigsev when i click on the button
if i restart lazarus, is missing again unit2 in uses section and the procedure application.createform below is missing to.
if add manually sigsev again, and restart and is gone again those lines.
attach the project to this post

After your image and explanation, this does seem like an error.

I think you should report it on the GitLab issue section.

Cheers,
Gus

[EganSolo]

I just installed 3.0.
Wow!
I don't know if it's me or what, but on my system, it's noticeably faster than 2.2.6. Starting my program in debug mode in 3.0 is nearly instantaneous whereas 2.2.6 was, shall we say, slumberous?  I'm truly impressed.

The ability to drill down on complex structures in the local variable window is a God sent!

Thank you!

Truly appreciate your work and effort.

[dbannon]

......
then sigsev when i click on the button
if i restart lazarus, is missing again unit2 in uses section and the procedure application.createform below is missing to.
if add manually sigsev again, and restart and is gone again those lines.
attach the project to this post

Calebs, I am using Linux so, very slight chance that makes a difference. But lets assume not. As I am sure you are aware, its giving you a sigV because you call Form2.show without creating Form2 (in the attached project). I stepped through your recipe and it worked for me exactly as I would expect. I cannot imagine just what you are doing differently to cause the lpr to initially show that create() line but somehow not save it at compile time. But thats sure what is happening.

I am not certain a bug report is going to be very effective, I'd expect the devs will also fail to replicate your problem. There is something unusual with your setup or what you are doing and I suggest you might be the only one who can find out what that something is. So, you need to dig deeper !

Firstly, can you be sure that the TForm2.Create() line is shown in lpr file at some stage, you can see it in the editor ?   If so, is that content visible in the actual file, have a look at it from the command line please.  Is it still there after the compile cycle ?  If it never gets to the disk file, thats important information, if its make it to the disk but is subsequently overwritten, even more interesting ! Remember, the compiler reads the disk file, not the content shown in the editor.

Davo

[Martin_fr]

its me again.
fired lazarus fixes with 3.2.2 installed with fcupdeluxe.
fille New aplication
saved project1 and unit 1
add a button
then go to file >> new form
added unit 2
it adds automatically to lpr in uses and application.createform(tform2,form2).
added code to show form2 with click of the button
added unit2 in the uses section of unit 1
then run (f9)
then sigsev when i click on the button
if i restart lazarus, is missing again unit2 in uses section and the procedure application.createform below is missing to.
if add manually sigsev again, and restart and is gone again those lines.
attach the project to this post

I tried (with a default windows install, all as the installer provides).

Couldn't reproduce, but maybe found something that will help narrowing down the steps to reproduce.

You don't specify if/when you save unit2. If you don't, it will be saved when you compile.

What I noted is, that when I
- save unit1
- add unit2 with form
- add unit2 to uses of unit1
- try to write "form2.sh" and autocomplete => it complains that it can't find unit2.

Apparently there are issues when a project is saved but some units are not (and that is not saved = file does not exist yet).

However, in my case all else remained ok.
project run ok, and all code remained as it was. Reloading the project did not change anything.

In your attached project, unit2/form2 is not (no longer?) in the auto-create list for forms (in project options), and the "Application.CreateForm" for form2 is also missing.

If you got a crash, then that must have already been removed at the time of compilation (i.e. either when you saved before, or when the IDE autosaved).

Quest remains to find the exact steps.

[petevick]

I've just updated to Lazarus 3.0 in Linux Mint Cinnamon 21.2 and I'm experiencing the jitters !!. It's mainly the main window with all the drop down menus and components, and any Form that has a lot of components on it. If I pick the title bar to move it, the window jumps all over the place, the only way I can place it properly is to use Alt+F7. I didn't have this problem with Lazarus 2.2.0.

EDIT The compiled app also has the jitters as well. 

[Bloodbat]

This behavior was modified in the Lazarus 3.0 and breaks the backward compatibility. So now, if you need to use relative paths in the program and be able to run/debug your program using IDE, just go to the Run Parameters window and set the $Path($(OutputFile)) string in the Working directory field (see attachment).

Thanks to the team for the new release

That said...

Thanks to Furious Programming for clearing that up. The solution works; but I still wonder why that change was made. It makes testing sources meant for distribution painful. There should, at least, exist an option to disable this, honestly, insane and regressive behavior, or a way to either auto-fill that field for every project by default or a field in, say, the project options to set the default "Working directory". This wasn't needed before because the "Target filename" was used for the "Working directory" automatically... that worked just fine.
If the issue is relative paths... it's not like there's not a built in solution in FPC: "ExpandFileName" in SysUtils.

I love the bug fixes in the release; but some user facing changes are IMO plain nonsensical or undercooked.

[Martin_fr]

This behavior was modified in the Lazarus 3.0 and breaks the backward compatibility. So now, if you need to use relative paths in the program and be able to run/debug your program using IDE, just go to the Run Parameters window and set the $Path($(OutputFile)) string in the Working directory field (see attachment).

but I still wonder why that change was made. It makes testing sources meant for distribution painful. There should, at least, exist an option to disable this, honestly, insane and regressive behavior

I would have to go back to the commit and debug the behaviour before...

But from memory: The working directory had different defaults, depending on the app started with
- run (debugger)
- run without debugging

IIRC, the current 3.0 behaviour is what used to be "run without debugging" ... IIRC. I may be wrong, but something of that kind was going on.

The reason for the change was to unify the behaviour of the different run methods => if the user did not specify anything, then it should always be the same.

I guess few people do "run without debugging", so that behaviour was rarely/never inspected.

One had to be picked, and I went for one that would not change => so it would be possible to have ini files and other data in one place.
Also by default the exe is generated there.


Happy with the idea to add some sort of option or preset.

Please open an issue for it.


There actually was more
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/32331

And the commit says

Code: Text  [Select][+][-]

1. SHA-1: a1b61028fa311b6cf12d01c6e78b3b4d7b3d3cc2, Branch RevNo: 63621
2.  
3. * IDE: Run/Debug, search for LaunchApp and HostApp in Project-dir and %Path. issue #32331
4. - Search in %PATH was done by "run without debug", but not by debug.
5. - Checking for an exe relative to the project-dir was added for both.
6. - A plain file-name will be first checked in the project-dir, and after that in %PATH
7.  

and

Code: Text  [Select][+][-]

1. SHA-1: 66bc8c9281b4a4f74278d1eb41a8a8e83c9df5bd, Branch RevNo: 63620
2.  
3. * IDE: Run/Debug, refactored getting the "working directory" for the project. Related to issue #32331
4. - "Debug" and "Run without Debug" now use the same steps to get the "working directory":
5. 1: BuildMode.RunParams "working directory" set by user (New, this can now be relative to project dir)
6. 2: Project Dir, if not virtual
7. 3: Directory from Host-App (RunParams), or if (and only if) Host-App is empty from Project.exe
8. (If host app is in %PATH, then there is no "working directory")
9.  
10. 1 and 2 are as before.
11. 3 was used before for "debugging", but "run without debug" did use: "Launch-App", "Host-App", Project.exe
12.  

According to the feedback 1 and 2 are not as before.
According to the complains, they were the PATH of the output-file.

[Bloodbat]

This behavior was modified in the Lazarus 3.0 and breaks the backward compatibility. So now, if you need to use relative paths in the program and be able to run/debug your program using IDE, just go to the Run Parameters window and set the $Path($(OutputFile)) string in the Working directory field (see attachment).

but I still wonder why that change was made. It makes testing sources meant for distribution painful. There should, at least, exist an option to disable this, honestly, insane and regressive behavior

I would have to go back to the commit and debug the behaviour before...

But from memory: The working directory had different defaults, depending on the app started with
- run (debugger)
- run without debugging

IIRC, the current 3.0 behaviour is what used to be "run without debugging" ... IIRC. I may be wrong, but something of that kind was going on.

The reason for the change was to unify the behaviour of the different run methods => if the user did not specify anything, then it should always be the same.

I guess few people do "run without debugging", so that behaviour was rarely/never inspected.

One had to be picked, and I went for one that would not change => so it would be possible to have ini files and other data in one place.
Also by default the exe is generated there.


Happy with the idea to add some sort of option or preset.

Please open an issue for it.

I do use "Run without debugging" some times .

I understand the desire to consolidate behavior for both buttons; but why was functionality removed (now for BOTH buttons, one of them, honestly, kind of hidden and apparently not used that much)? :S
Someone wanted the buttons to search in %PATH%, ok, weird; but fair... but, again, why remove already present functionality?

I opened an issue, as you requested with a suggestion to add a default work dir.

Thanks.

[Martin_fr]

I do use "Run without debugging" some times .

I understand the desire to consolidate behavior for both buttons; but why was functionality removed (now for BOTH buttons, one of them, honestly, kind of hidden and apparently not used that much)? :S
Someone wanted the buttons to search in %PATH%, ok, weird; but fair... but, again, why remove already present functionality?

I tried to explain, the only goal was to consolidate.

Anything that was changed (including removed) that had been present on both, was done in error. Otherwise the commit message wouldn't say that the behaviour had been kept.


I will go through the issue, maybe revert some of it, maybe add some extra default, maybe both.

[flowCRANE]

It would be good if the IDE worked as before, i.e. running the program with the working directory always set to the path of the executable file. This should be the default behavior if the working directory path has not been explicitly set in Run Parameters window. There should also be support for relative paths for the application (project), but also for host application and launching application.

This is the simplest solution, the most intuitive for the user.

[calebs]

......
then sigsev when i click on the button
if i restart lazarus, is missing again unit2 in uses section and the procedure application.createform below is missing to.
if add manually sigsev again, and restart and is gone again those lines.
attach the project to this post

Calebs, I am using Linux so, very slight chance that makes a difference. But lets assume not. As I am sure you are aware, its giving you a sigV because you call Form2.show without creating Form2 (in the attached project). I stepped through your recipe and it worked for me exactly as I would expect. I cannot imagine just what you are doing differently to cause the lpr to initially show that create() line but somehow not save it at compile time. But thats sure what is happening.

I am not certain a bug report is going to be very effective, I'd expect the devs will also fail to replicate your problem. There is something unusual with your setup or what you are doing and I suggest you might be the only one who can find out what that something is. So, you need to dig deeper !

Firstly, can you be sure that the TForm2.Create() line is shown in lpr file at some stage, you can see it in the editor ?   If so, is that content visible in the actual file, have a look at it from the command line please.  Is it still there after the compile cycle ?  If it never gets to the disk file, thats important information, if its make it to the disk but is subsequently overwritten, even more interesting ! Remember, the compiler reads the disk file, not the content shown in the editor.

Davo

installed lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcupdeluxe (lazarus fixes + fpc 3.2.2) on x64 linux and tried all the process i've described and worked as expected.
Installed lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcdeluxe (lazarus fixes + stable fpc) on x86 windows and tried all the process also and it worked fine too.
finally
Installed lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcdeluxe (lazarus fixes + stable fpc) on x86 linux and tried all the process also and it worked fine again.
I will clean my fpcupdeluxe instalation folder and try again on winx64

[Martin_fr]

The reason for the change was to unify the behaviour of the different run methods => if the user did not specify anything, then it should always be the same.

I guess few people do "run without debugging", so that behaviour was rarely/never inspected.

I do use "Run without debugging" some times .

You are right. That worked in 2.2.n.
But I tested against the main-branch as it was before my change. And there the change had already been made.

So I don't actually know why that change had been made (to "run without debug"). I am currently trying to find out.

[calebs]

......
then sigsev when i click on the button
if i restart lazarus, is missing again unit2 in uses section and the procedure application.createform below is missing to.
if add manually sigsev again, and restart and is gone again those lines.
attach the project to this post

Calebs, I am using Linux so, very slight chance that makes a difference. But lets assume not. As I am sure you are aware, its giving you a sigV because you call Form2.show without creating Form2 (in the attached project). I stepped through your recipe and it worked for me exactly as I would expect. I cannot imagine just what you are doing differently to cause the lpr to initially show that create() line but somehow not save it at compile time. But thats sure what is happening.

I am not certain a bug report is going to be very effective, I'd expect the devs will also fail to replicate your problem. There is something unusual with your setup or what you are doing and I suggest you might be the only one who can find out what that something is. So, you need to dig deeper !

Firstly, can you be sure that the TForm2.Create() line is shown in lpr file at some stage, you can see it in the editor ?   If so, is that content visible in the actual file, have a look at it from the command line please.  Is it still there after the compile cycle ?  If it never gets to the disk file, thats important information, if its make it to the disk but is subsequently overwritten, even more interesting ! Remember, the compiler reads the disk file, not the content shown in the editor.

Davo

installed lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcupdeluxe (lazarus fixes + fpc 3.2.2) on x64 linux and tried all the process i've described and worked as expected.
Installed lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcdeluxe (lazarus fixes + stable fpc) on x86 windows and tried all the process also and it worked fine too.
finally
Installed lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcdeluxe (lazarus fixes + stable fpc) on x86 linux and tried all the process also and it worked fine again.
I will clean my fpcupdeluxe instalation folder and try again on winx64

installed fresh lazarus 3.1 2024-01-12 with fpc 3.2.2 with fpcupdeluxe (lazarus fixes + fpc 3.2.2) on x64 windows and all worked fine.
i started to think that this problem could be related to old project files... the programs im working in were started with earlier lazarus (like 1.6 or 0.9) in 32bits and later on migrated to newer versions of lazarus on 32 and 64 bits in windows and linux.
Maybe some garbage exists on those old project files that makes that behaviour appears when i add new form to a existing project.
The odd thing is that this never happened with any version prior at 3, always worked fine until 3.x
I'll try to check out.
Thanks for everything