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.It works here.
There is many things not working ( jumping) from code explorer to editor.
It works here.Frankly,I tested a new non saved project.
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.
It works well, the code explorer synchronize well with the code.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.
Tested on saved project.
grep -rw occured lazarus-lazarus_2_2_0_RC2 [enter]
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.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.
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.
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.
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.
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.
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.
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?
and build IDE with "Optimized IDE" profile.
It should be fixed in 3.2.4Just curious, any reasonable guesstimate as to when 3.2.4 might be released ?
It should be fixed in 3.2.4Just curious, any reasonable guesstimate as to when 3.2.4 might be released ?
I found in lazstringutils unit: https://gitlab.com/freepascal.org/lazarus/lazarus/-/blob/fixes_2_2/components/lazutils/lazstringutils.pas#L103
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.
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.This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?) :-[
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.This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.
(Actually I accidentally installed RC3 from fpcupdeluxe, should I downgrade?) :-[
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.
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.
This is Lazarus, not KDevelop. Try Ctrl-Shift-V and Ctrl-Shift-U. See Source menu.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?".
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:It's already mapped to Ctrl + / though but Ctrl + Shift + V is working normal.
Toggle Comment in Selection is mapped to Ctrl + /.
Works as expected on Windows.
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?)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.
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.
If you check Tools > Options > Editor > Key Mappings > Text Selection commands:It's already mapped to Ctrl + / though but Ctrl + Shift + V is working normal.
Toggle Comment in Selection is mapped to Ctrl + /.
Works as expected on Windows.
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.
As I said, it's about the key (the physical key), not the char that it produces.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. :)
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.
in the example file:
/usr/share/lazarus/2.0.12/examples/fontenum.pas
line 375 reads:ie, is missing the letter 'g'. it should be:
L.Add('abcdefhijklmnopqrstuvwxyz');
L.Add('abcdefghijklmnopqrstuvwxyz');
a minor cosmetic, but it left me puzzled why upper and lower case lines were different lengths.
cheers,
rob :-)
drwxr-xr-x 35 503 admin 1120 31 Oct 19:26 Lazarus
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
editoroptions.xml:20: <ahaGutter Background="clInactiveCaption"/>
editoroptions.xml:21: <ahaOverviewGutter Background="clSilver" Foreground="clGray" FrameColor="clSkyBlue"/>
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.xmlQuoteeditoroptions.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.
Attached is the editoroptions.xml for RC2 (cant attach .xml, so renamed it to .xml.pas).
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.
Version="13"from the "LangObjectPascal" section then the fault shows ( i.e. the gutter is black ); put it back in and it works correctly.
Exec=/home/tim/misc/laztest/startlazarus --pcp=/home/tim/.config/laztest
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'
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.
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?
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.
- 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.
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.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)
Is the "IDE default" debugger the same as the FPDebug debugger?
Thanks for explanation. I only did not expect such a change between two RC releases.This was already the case for RC1.
I have an issue:Ideally yes... But depends on who defines "appropriate"....
- 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 tableThe "default debugger" is not a specific type. See above.
- between the "IDE default debugger" and "FPDebug"
- the different debug info type settings (Dwarf1, 2, 3 and Stabs)
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.
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)
But that fails to compile: project1.lpr(25,3) Error: Duplicate identifier "$_static_tfoo__BAR"
type TFoo_ = class class var bar: integer; end; TFoo = class class var _bar: integer; end;
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
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?
FpDebugAutoDerefMemberFpDebug 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?
I don't use it myself for writing code. So the first thing I would not know isWould that access the first element in TIntArray?
type TIntArr = array of integer; PIntArr = ^TIntArr; var a: PIntArr; begin if PtrUInt(a[1]) <> 0 then
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.
Partly fixed (main and fixes branch).
Evaluating (watch or hint) "NUMCHANNELS" while in a method of the class should work.
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 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.
- 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.
unknown: red with no further mark
good/valid: red witch check-mark
bad: orange
disabled: green
Noted, please report the breakpoint issue.
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.
I have a suggestion about the system font used by the IDE