Re: [Lazarus] Stepping into the LCL with fpdebug

[Martin Frb via lazarus]

On 22/04/2024 11:13, Luca Olivetti via lazarus wrote:


That doesn't answer my question: then how is it possible that I can 
step into the lcl with gdb and -gl even if I don't specify "-gl"  in 
additions and overrides?


Because your LCL is probably build with STABS. And gdb can read stabs, 
but FpDebug can't.


The problem is -g => and that is also the reason for the "Chose DWARF" 
dialog that pops up when you haven't explicitly set your project to dwarf.



-g is decided by FPC, it can be stabs or dwarf. Depends on Target and 
fpc version. The IDE does not have a list, so (prior to compiling it 
does not know). Therefore when using FpDebug the IDE requires explicit 
set to Dwarf. (But only checks the project).


Ideally the IDE should have a setting "Use IDE default" or "Follow 
project" for packages. But you can't put that in Makefiles (which are 
still used), because it would need to be translated before handing it to 
fpc.
Still, if we accept that any "just installed" or "build with make" files 
get immediately rebuild by the IDE, then it could be added But it 
hasn't yet (and probably is major work)



For the record: it is *not* necessary to add -gw3 to "configure build 
lazarus", it's enough to put it in the "additions and overrides". 

Yes, it's either, or, or both.

Additions and Overrides (with *) will affect ALL packages, even 3rd 
party. As long as they are part of the project (except RTL, because the 
IDE does not rebuild RTL / or fpc packages dir).


"Configure build Lazarus" only affects (most) packages that came with 
Lazarus. => they have $(IDEBuildOptions) in their "custom options".
But once done, it is done for all projects (for the packages that follow 
it).


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Stepping into the LCL with fpdebug

[Martin Frb via lazarus]

On 22/04/2024 10:37, Luca Olivetti via lazarus wrote:


But if they have it would be super useful to have a setting "use the 
debug setting of the system unit", but there is not.


You can add the -gw3 flag depending on build mode:
https://wiki.lazarus.freepascal.org/IDE_Window:_Compiler_Options#Add_a_flag_to_project_and_all_packages 



Then why I can step into the LCL with gdb and -gl?
I'm already using the additions and overrides but I don't currently 
specify any debug option there.


packages (even if rebuild) have their own settings what debug info type 
they use.


This is in each package's options.

LCL and many packages also include the settings that you specify in 
"Tools > Configure build Lazarus". So you can specify the setting there.


Or you can specify in "Additions and Overrides" with Target packagname, or *
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Project.pp

[Martin Frb via lazarus]

On 09/04/2024 19:39, Gabriele Cappelletto via lazarus wrote:

Done, I'm missing this, I can't find how to do this in the handbook

BMOptions: TBuildMatrixOption;

  BMOptions := 
TProject(AProject).BuildModes.SharedMatrixOptions.Add(bmotIDEMacro);

  BMOptions.Modes := 'Default';
  BMOptions.MacroName := 'LCLWidgetType';
  BMOptions.Value := 'nogui';

 I think it needs to be transformed into

  CompOpts : TLazCompilerOptions;

Does anyone know how to do this or how to use projectintf?



Not my main area of expertise, but I did some digging and found

function TBaseCompilerOptions.GetEffectiveLCLWidgetType: string;
...
  Vars:=GetBuildMacroValues(Self,true);
  if Vars<>nil then
    Result:=Vars.Values['LCLWidgetType'];


BuildMacros are available via

TLazProject(project).LazBuildModes.LazBuildModes[n].LazCompilerOptions.BuildMacros

I hope that works...
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Project.pp

[Martin Frb via lazarus]

On 03/04/2024 16:41, Gabriele Cappelletto via lazarus wrote:

TProject(AProject).UseAppBundle := False;

Package BuildIntf
components\buildintf\projectintf.pas => LGPL with linking exception

TLazProject(AProject).UseAppBundle := False;



TProject(AProject).ProjResources.XPManifest.UseManifest := False;

TLazProject(AProject).UseManifest := False;


TProject(AProject).ProjResources.ProjectIcon.SetStream(nil);


This may be a problem. At least I haven't found it...
You can get resources...
   TLazProject(AProject).Resources
But the class TProjectIcon isn't available.

Maybe someone else knows.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Project.pp

[Martin Frb via lazarus]

On 09/04/2024 17:45, Gabriele Cappelletto wrote:




It is not meant to work.
That is the unit "project" is part of the IDE, and only meant to be 
used by the IDE. From a license point of few, it is GPL (not LGPL), 
so if your code is GPL, then you are permitted to use it, but


If even the code was gpl then there would be no commercial product for 
lazarus. neither tms nor anything else.


IdeIntf is LGPL with linking exception

IDE is GPL
and the packages in the folder ide (IdeConfig, IdeDebugger) are GPL, 
because they used to be part of the IDE.


Commercial packages are build against the IdeIntf.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Project.pp

[Martin Frb via lazarus]

On 03/04/2024 18:49, Gabriele Cappelletto via lazarus wrote:

The code is this

function TExtPApplicationDescriptor.InitProject(AProject: 
TLazProject): TModalResult;


  TProject(AProject).UseAppBundle := False;
  TProject(AProject).ProjResources.XPManifest.UseManifest := False;
TProject(AProject).ProjResources.ProjectIcon.SetStream(nil);

TProject(AProject).CompilerOptions.ExecuteBefore.Command :=

We need the reference to TProject, how do I remove this reference?




Mind that getting this to work is only "being lucky".

It is not meant to work.
That is the unit "project" is part of the IDE, and only meant to be used 
by the IDE. From a license point of few, it is GPL (not LGPL), so if 
your code is GPL, then you are permitted to use it, but


The unit comes with no warranties on it's interface. It could change in 
any way, and such changes would not be announced. (so long as the IDE 
and lazbuild themself are still working).


The same is true for any file inside the ide folder. And that does 
include files in packages inside the ide folder.


--

Also further more, it may (maybe) fail even if it compiles (at least I 
think it may). If either your code or the IDE is build with -O4 but not 
the other. Then FPC may produce different memory layout for the 2 
equally named classes (it's only "equally name classes", it is not 
"equal classes"). And in future fpc could produce differences in other 
situations.


You best get in a feature request, so that functionality that is 
required can be (considered for) included in the IdeIntf.-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] I can't exit this component

[Martin Frb via lazarus]

On 29/03/2024 13:25, Martin Frb via lazarus wrote:

FIn_tedtNomArqMicEnter then exit;
  FIn_tedtNomArqMicEnter := true;


Field in TFrmGeraString.

TFrmGeraString = class(TForm)
private
  FIn_tedtNomArqMicEnter : Boolean;

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] I can't exit this component

[Martin Frb via lazarus]

On 29/03/2024 13:03, Werner Pamler via lazarus wrote:

Am 29.03.2024 um 12:09 schrieb Arí Ricardo Ody via lazarus:

procedure TfrmGeraString.tedtNomArqMicEnter(Sender: TObject);
The "Enter" in this method name indicates that you assigned the event 
handler to the OnEnter event of something (a button maybe). This means 
that whenever the mouse is moved over this button ("enter") the event 
fires. Usuall dialogs are displayed only when a "click" occurs, and 
this responsibility is in the OnClick event of the button.


Actually that would be "MouseEnter".
But good catch.

"TEdtEnter" => The "OnEnter" of an "TEdit" ?

So, you want the dialog to open when the user "enters" the edit:
- clicks in the edit
- uses Tab-key to go to the edit

Once the dialog closes, you fill the edit with the selected file:
   tedtNomArqMic.Text := opdArqmicro.FileName

I have not tested all of the below:
- When the dialog is closed, then focus would return to the form
- this focuses/enters the edit again => and the dialog opens again

I can see, you want to avoid that, because you set focus away from the edit:
   btnAvanca.SetFocus;


But that is (probably) to late.

If I am right (not tested, just a guess)...

begin
  if rbTransMainframe.checked then
     if opdArqmicro.Execute then
        tedtNomArqMic.Text := opdArqmicro.FileName

// ### Here the dialog close, and the edit is focused again
// ### tedtNomArqMicEnter is called from here (recursive)


// The below line is not reached in time.

  btnAvanca.SetFocus;
end;


===
If that is the case:

procedure TfrmGeraString.tedtNomArqMicEnter(Sender: TObject);
var auxstr : TFileName;
begin
  FIn_tedtNomArqMicEnter then exit;
  FIn_tedtNomArqMicEnter := true;
  try
 /// all your code
  finally
    FIn_tedtNomArqMicEnter := False;
  end;
end;

That way you stop the recursion, and the code to focus the btn should work.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] What happened to code templates?

[Martin Frb via lazarus]

On 28/02/2024 22:00, John Landmesser via lazarus wrote:

Am 28.02.24 um 10:10 schrieb Juha Manninen via lazarus:


Renaming "lazarus_dci_file.dci" to "codetemplates.dci" should not 
affect a file named "lazarus.dci".
I searched in my home dir if I have "lazarus.dci". It is found in a 
config dir for Lazarus 2.0. I don't remember creating such a file. 
How did it get there? I guess I don't know everything about the 
templates and their history.


Juha



Wondering about filenames you are talking about:


if i start my lazarus with new --pcp

lazarus --pcp=/home/john1/.lazarus-juha

I get these new config files including lazarus.dci


-rw-r--r--  1 john1 john1 6,9K 28. Feb 21:40 lazarus.dci


No codetemplates.dci ???



Afaik (from what I heard) the change only affects the file in the folder 
ide in your laz install. That was renamed.


The one in your PCP is as it always was => and that is where your own 
templates should also be stored.


For your original lazarus look into menu view > ide internals > about 
ide >> that should tell you where it has its pcp (usually ~/.lazarus)


-
So then, the question is: are there entries in such a lazarus.dci file 
(in the pcp), that are not available in the IDE (not via ctrl-j / not in 
the codetemplate editor from the tool menu)?


If so, then report a bug, with a copy of the lazarus.dci attached.-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] What happened to code templates?

[Martin Frb via lazarus]

On 28/02/2024 09:09, Juha Manninen via lazarus wrote:
On Tue, Feb 27, 2024 at 7:45 PM John Landmesser via lazarus 
 wrote:


Now i have in lazarus.dci

> [sm | showmessage]
> [todo | ToDo item creator]
.. and there is no way how i can use that?!!


First, "lazarus_dci_file.dci" was renamed to "codetemplates.dci". See
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40657.
I guess this is not related to your issue.


Just to be sure, did you directly edit the lazarus.dci inside the ide 
folder in the lazarus install dir?


Because then, it would have stopped working.
If you edit via the IDE, then the modified file is saved in your PCP.

If the above is your issue copy the modified file to the PCP.-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Testers needed for new configurable Highlighter in IDE (textmate based)

[Martin Frb via lazarus]

The IDE can now load highlighter definition files containing textmate 
grammar. (mostly).


There are some items still missing
- nested grammar/language (include using a 2nd grammar) (todo)
- folding (todo)
- There is also no support for "injections" (just edit the grammar and 
copy the injection into the final place).


Known differences:
- The regex engine does not support the full range of operations. So 
some existing grammars may fail on that (or behave different).
- SynEdit does not store newlines chars => patterns matching "\n" must 
be changed to match "$" instead.


--
Installation:

- Add the json file to PCP/usersessions/tml/
  Files will be loaded at IDE startup. IDE must be restarted to load 
new files.

- The IDE will show it in the highlighter list
  Or it will show it on the "color tml" page, if there is an error in 
the file



It is recommanded to edit/amend the files (if you copy existing grammars).
- to get text in the preview of the options, add (top level) either
  "sampleText": "foo bar some text"
  "sampleTextFile": "/foo/bar/file"
- simplify the naming. Existing files contain name like
  "name": "comment.block.pascal",
  "name": "comment.line.pascal",
  You may want to replace them, with one name for all comments (keep 
one dot, as it will detect "comment.*" for default colors).

  "name": "comment.pascal",

--

Please test (if interested in the feature). Thanks

https://forum.lazarus.freepascal.org/index.php?topic=64590.new#new

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] LazGitGui a git tool.

[Martin Frb via lazarus]

On 29/07/2023 12:55, Juha Manninen via lazarus wrote:
An IDE plugin that runs "git blame" for an active editor source file 
and shows a HashID for each line. The associated commit is shown in 
another window when the HashID is clicked. All that using a local Git 
repo history, no network access is needed.


That kind of IDE integration would make sense. I never understood the 
traditional revision control plugins that allow commits from the IDE. 
What is the benefit? I have anyways saved and tested all my changes 
when I want to commit. I can as well start a proper commit tool from 
outside the IDE. There is no true integration, the IDE plugin is only 
started from a different place.




Well, log for the current file would be useful too, and easier.


But what I really fancy is an integrated "git diff" => where the 
SourceEditor/SynEdit shows chages inline.


Could be different detail levels

- just line markers /like the current changed/save marker (yellow/green)

- diff show at bottom (like winmerge)

- maybe side by side split editor (though external tools to that well)

- inline markup, like MS-word capturing changes: red/strikethrough for 
stuff deleted by current diff, green for stuff added.


This could work, as you type.


It would work without gif, against the saved file, or a backup.

With git, against HEAD or index (or both / 3 color)


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 1 of 3.0

[Martin Frb via lazarus]

On 26/07/2023 17:58, Luca Olivetti via lazarus wrote:

El 26/7/23 a les 17:42, Martin Frb via lazarus ha escrit:


So FpDebug did not find the source file.

I found the issue: it's the -Xg (use external debug symbols file) option.
I wonder why it doesn't work under windows but it does under linux.


I would still like to see that sample project, if possible. Maybe there 
is an easy fix.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 1 of 3.0

[Martin Frb via lazarus]

On 26/07/2023 17:26, Luca Olivetti via lazarus wrote:

El 26/7/23 a les 17:18, Luca Olivetti via lazarus ha escrit:


Are there ways to reproduce it ?
Could sources be shared?


The projects I tested no, I'll see if I can find a simpler project 
with the same issue.


I found a simple project that I can share but I'm not sure it's a good 
idea to send it here (the zip file is 143K).




You can send it directly to my mail  lazarus as name, and the 2nd part 
is mfriebe.de


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 1 of 3.0

[Martin Frb via lazarus]

On 26/07/2023 17:18, Luca Olivetti via lazarus wrote:

El 26/7/23 a les 16:50, Martin Frb via lazarus ha escrit:


What happens to the breakpoint icon when you start the debugger?

Before you start the debugger, it should have a "?".


Yes, state "?(On)"


When you start it, what happens.


A pause simbol (two vertical white bars in a red circle), state 
"Pending (On)" (under linux the state is just "Enabled").


So FpDebug did not find the source file.

The pause is used, because this can happen with DLL. And then the break 
may get set when the dll is loaded.

I assume that is not the case?

Anything about the filename? special chars? sym links?






--
If you remove the breakpoint (can be done while the app is running / 
after you checked the above), is there a "small blue dot" in the 
gutter? On the very same line as the breakpoint had been?


No, not even under linux
Then there are probably 2 files with that name => and the breakpoint is 
in the other file.


Could that be?

Or could the IDE know the file with a different directory than FPC does 
? (though that should still work)


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release Candidate 1 of 3.0

[Martin Frb via lazarus]

On 26/07/2023 16:05, Luca Olivetti via lazarus wrote:

El 3/7/23 a les 13:33, Mattias Gaertner via lazarus ha escrit:


- Compile, debug and run


I don't remember the exact wording but, when converting the settings 
from lazarus 2.2 (which I copied in a different directory), it offered 
to use the fpdebug backend.


Then, when compiling a *existing* project, it tells me to use a 
suitable debugging format (with -gw3 selected, previously I used gdb 
with -g).

I accept but the breakpoints don't work.
I tried the other two options with the same result.
With gdb backend and -g the breakpoints work.

With a *new* project the breakpoints work even with the fpdebug backend.

This is under win32, under linux (64 bits), the breakpoints work even 
in the old project (the same one I used to test under win32).


What happens to the breakpoint icon when you start the debugger?

Before you start the debugger, it should have a "?".
When you start it, what happens.
You can also check in the breakpoint-windows, if you make the first 
column wide enough there is some text.


--
If you remove the breakpoint (can be done while the app is running / 
after you checked the above), is there a "small blue dot" in the gutter? 
On the very same line as the breakpoint had been?


Gdb would accept breakpoints at non-code lines.
FpDebug needs the breakpoint on a code line.

Note that
   if condition then
 exit;  /// this exit is only a codeline in -O- // with -O1 its 
optimized away


--
Are there ways to reproduce it ?
Could sources be shared?

Otherwise I'll send instructions to produce log files.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus trunk version number

[Martin Frb via lazarus]

On 30/06/2023 14:04, Michael Van Canneyt via lazarus wrote:


So basically you did a shift left of the version number ?


Not exactly, that would mean that major releases would be 4.0 and 6.0. 
Leaving 3 and 5 for development versions.


- We combined the first 2 digits into one. (because there separation had 
no meaning)

- Except for "trunk" development, which now got the .99 minor.
- for fixes releases and fixes development, the "patch" moved left to 
the "minor"


Or, yes: A shift left, the unallocated the odd trunk-developments, and 
reassigned them a .99.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus trunk version number

[Martin Frb via lazarus]

On 30/06/2023 13:27, Martin Frb via lazarus wrote:


But, there was no need (anymore) to reserve 2 digits for major 
releases. When 1.0 was released there was no need for further major 
releases to be 1.2 instead of 2.0.


I forgot to add the explanation for "anymore"

Prior to 1.0 the minor and patch numbers were used: 0.minor.patch
But therefore the "major" number was not used (always 0).

Since Lazarus became stable, the major number became 1 and it became 
available for use. Yet - without perceivable need - minor and patch were 
kept in used too. Making it 3 digits to be used. When only 2 were needed.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus trunk version number

[Martin Frb via lazarus]

On 30/06/2023 12:51, Michael Van Canneyt via lazarus wrote:



On Fri, 30 Jun 2023, Juha Manninen via lazarus wrote:


On Friday, June 30, 2023, John Landmesser via lazarus <
lazarus@lists.lazarus-ide.org> wrote:


perhaps that should have become 3.00 ?

Lazarus *3.99* (rev main_3_99-41-g3d8dd85474) FPC 3.2.2 
x86_64-linux-gtk2


You are looking at trunk, the development version. See :

https://wiki.freepascal.org/Version_Numbering#Lazarus_3.0_and_newer


You might want to add some explanation for this new versioning scheme 
to that page. 


Added.


The graph does not help.

From what is currently there, I don't understand neither the logic nor 
the need of this change.
"Need"... Well, in terms of "because it solved the issue xyz" => then 
there is no need.


But, there was no need (anymore) to reserve 2 digits for major releases. 
When 1.0 was released there was no need for further major releases to be 
1.2 instead of 2.0.
So simple said a non-needed feature was abandoned, subjectively 
simplifying the process.





Also, how come trunk is 3.99 (indicating development for 4.0, if I 
understand
the page correctly) if 3.0 is not yet out ? Based on the graph, I 
would think trunk should be at 2.99 now.


The fixes_3 branch does exist. So the features for 3.0 have been 
finalized. Trunk therefore from this point prepares for 4.0.




--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Who uses "caret past EOL"?

[Martin Frb via lazarus]

On 02/06/2023 15:07, Michael Van Canneyt via lazarus wrote:



On Fri, 2 Jun 2023, Martin Frb via lazarus wrote:


If you do, do you use it within the range of the "longest line" only?



What if I want to add a comment at column 60 (think explanation about
enumerated value) but the max line length is 40 ?

Now I click at col 60 and add the comment. Will this still be possible ?


Yes, it will.
The question is how far should it allow by default?

---
Background:
Currently the scroll always goes to 1024. Except when the longest line 
is longer, then it goes (on any line) to the max = longest line. But 
never behind that.


In future, if you hold cursor-right, it will go further (like notepad 
++, if "virtual space" is enabled).

Of course that covers the range for cursor keys.

About the range for mouse. The current limit is quite big. But if you 
really have lines that long => it's not enough.
So instead you will (optional) be able to scroll (scrollbar / mouse) up 
to "longest line" + "width of screen".
If your Window shows 85 chars, and your longest line is 20 chars, you 
can mouse move the caret up to 105 (and right cursor will go behind).


Those options are already there in the main branch:
- no extra scroll, just cursor keys  (well on shorter lines, the mouse 
can go up to "longest line", but that is placement, not scroll range)

- add one page to longest line
- Max(1024, longest line)

Currently the last is default.
Maybe "add one page" is a better default.
Unless, there are use cases that require to place the caret more than 
"one page" past the end of (the longest) line.


Since I don't use "caret past eol" at all, this is hard for me to judge. 
But my experience is, when ever I think there would be no such use case, 
there is at least one.

https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40282
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Who uses "caret past EOL"?

[Martin Frb via lazarus]

If you do, do you use it within the range of the "longest line" only?

That is, currently caret-past-eol additionally allows you to scroll up 
to over 1000 columns, even if you don't have any line that long. Do you 
use that scroll range?


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Some source editor context menu items broken

[Martin Frb via lazarus]

On 21/05/2023 11:38, Mattias Gaertner via lazarus wrote:

On Sun, 21 May 2023 10:48:30 +0200 (CEST)
Michael Van Canneyt via lazarus  wrote:


[...]
I saw a remark in main.pp that this is supposed to be faster than
using the codetools:

  CurWordAtCursor := ASrcEdit.GetWordAtCurrentCaret;
  //it is faster to get information from SynEdit than from
CodeTools
ASrcEdit.EditorComponent.CaretAtIdentOrString(ASrcEdit.EditorComponent.CaretXY,
IdentFound, StringFound);

Faster? Probably. Correct? clearly not (yet).

Problem is that this function checks:
   AtIdent := Attri = Highlighter.IdentifierAttribute;
But TSynPasSyn has its own attribute
   ProcedureHeaderName: TSynHighlighterAttributesModifier



Yes that is broken in SynEdit.

This is related to procedure names having a color of their own.

Same probably happens for case-labels
  "case enum of" and then the named enum-members as labels.
Yet in that case there is no easy way to differentiate between 
identifier (enum member name) and else/otherwise (keyword).


That should be reported as a bug. (It may need a more substantial fix to 
be future-safe / a dedicated function in the HL maybe)


---
Using CaretAtIdentOrString is questionable anyway.

Afaik codetools also works on comments.
At least "find identifier references" (if invoked via key combo) works 
on idents in comments.


Yet CaretAtIdentOrString does by design not return true for comments.

So "git blame" the source editor, and see what was used before 
CaretAtIdentOrString.





--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] dbg file on smb share hangs IDE

[Martin Frb via lazarus]

On 12/05/2023 13:55, Mattias Gaertner via lazarus wrote:

Hi,

When debugging a project on Windows with external debug info (.dbg)
the IDE hangs.
It works on the local C partition, but it hangs the IDE when the project
is on a smb share. I have to kill lazarus.exe.

Is this known?



I don't think it is known.

Gdb or FpDebug?
Any size of dbg file?


FpDebug (on win) lets the OS do the loading by creating a memory map for 
the file. Maybe WIndows has an issues there.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Cannot use bookmarks in code window - why?

[Martin Frb via lazarus]

On 23/04/2023 19:39, Bo Berglund via lazarus wrote:

I have started a new project in Lazarus 2.2.6/Fpc3.2.2 on a Linux machine

...

I have looked at the same version of Lazarus on my Windows workstation and there
when I right-click the gutter to the left of the code there is a popup menu with
"Goto Bookmark" and "Toggle Bookmark" and when I click one of these a secondary
menu pops up with further alternative of where to go etc.

But on the RPi4 (via VNC) there is *nothing* happening if I click on any of the
two bookmark related lines in the first pop-up menu
No secondary menu shows up at all...




There was an issue that has been fixed for Lazarus 2.4 (i.e. in 2.3).
It is possible that the fix wasn't backported for some reason.

Though currently we have reports  that there may be individual cases 
were the problem persists in 2.3.
However despite lots of testing, this has not been reproducible. So the 
status is unknown.


You can set bookmarks using
   shift-ctrl-1  .. 0
and go to them
   ctrl-1  .. 0

Assuming your OS/Desktop has no shortcuts on those combos.
If there is a conflict, you can change the Desktop, or Lazarus.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Code editor column mode does not work...

[Martin Frb via lazarus]

On 19/04/2023 18:29, Bo Berglund via lazarus wrote:

How can I enable column selection with the mouse?

If I use the Alt key and click where I want to start the selection then when I
move the mouse the whole editor window moves instead of creating a vertical
selection...

Is there someone here who has done this and can share the solution?


Sounds like the OS / desktop manager grabs the mouse first.

2 possibilities.

1) change the OS config (if possible / I don't know)

2) Tools > Options > Editor > Mouse: assign another combo for the column 
selection

Either diff modifier keys; or diff button.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Is there a setting to include debug symbols when starting from Lazarus only?

[Martin Frb via lazarus]

On 16/04/2023 11:15, Bo Berglund via lazarus wrote:

- Use Run menu Build or Compile: no symbols should be included.
- Click the green run arrow button then the symbols will be included.



I think the closest you may get to this is build modes.


But all and any button/key/menu always use the current mode. you have to 
change it via the drop down on the toolbutton.



projectgroups may offer a direct "build mode xxx"

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus fails to build

[Martin Frb via lazarus]

On 19/03/2023 19:53, Sven Barth via lazarus wrote:
 If it *would* work however you could simply do {$if not 
declared(name_of_the_unit)}, because the unit name is also a valid 
symbol.


ooohh nooo. That would be like C header files Don't wont that. ;)
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus fails to build

[Martin Frb via lazarus]

On 19/03/2023 00:00, Michael Van Canneyt via lazarus wrote:


On Sat, 18 Mar 2023, Mattias Gaertner via lazarus wrote:



As this happens seldom there is no detection built in (yet) to handle
this automatically.


If possible, might be a good idea.


Afaik there are 2 scenarios.

1) The duplicate.
The user has the package installed, that now became a base package. So 
units are used twice.


For this there may be a very simple solution.
- staticpackes is used by lazarus.pp
- So we could add new core-packackage-units to a different unit's use 
clause. Then they don't appear twice in the same uses clause.
E.g. we could add a unit LazCorePackages, and that just contains a uses 
clause.  It would be used first in the uses of lazarus.pp.


It may also be able to do some trickery with IFDEF.
If core packages are in the lazarus.pp uses clause, appearing only after 
staticpackages, then there could be {$IF not 
defined(symbol_from_new_core_unit)}.

Haven't tested that, don't know if it would actually work.


2) The "unit not found"
The user does not have the package installed, yet.
Say when we added IdeDebugger package. This would have added units to 
the "core" uses clause.

But not only. Units of IdeDebugger are used throughout the entire IDE code.
And if you do not have that package installed (and use an old IDE, that 
does not have it as core yet), then the package's path is not in the 
list of unit-search paths.

So you will get "unit not found" errors.
To rebuild, you must first install the package that will become core.

Not sure how an old IDE can learn about that.

(The point (2) does not happen with every package. If the package is 
just used, so it can register itself, then that will be fine.)

E.g.
- LazDebuggerFpLldb => core, but only registration
- SynEdit => core, and units get used

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus fails to build

[Martin Frb via lazarus]

On 18/03/2023 22:55, Michael Van Canneyt via lazarus wrote:


Hi,

I did a git pull of latest lazarus sources.

Someone added laz.virtualtreeview and fpdebuggerfp to the IDE uses 
clause.


This caused the compilation to fail, since these units are also in the
installed packages.

For instance the online packagemanager also used laz.virtualtreeview, 
so laz.virtualtreeview was added to staticpackages.inc, which is 
included in the uses clause and leading to duplicate units in the uses 
clause.


If some functionality of the IDE uses laz.virtualtreeview then the IDE
should properly list a depencency on that package, instead of adding 
it hardcoded in the IDE uses clause. As soon as a user installs the 
package in

question (s)he will have the same error as I did.

I removed the duplicates and pushed the change.

Michael.



They werent duplicates.
Those units (or their packages) are now hardcoded included.

This error happens everytime, when packages become part of the core list.
Because older IDE are not forward compatible with that sort of change.

With then removed, the IDE will fail to build, when those packages are 
not installed manually.


==
To work around:

Build once via
  make clean bigide
and after that all should work.

Or remove the 3 units from lazarus.pp / rebuild / add them again

Once you have a new IDE, it wont add them to staticpackages anymore.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 2.2.6

[Martin Frb via lazarus]

On 16/03/2023 18:46, Bo Berglund via lazarus wrote:


But it also seems like on each system there is only one version of fpc that can
be "active" (at least on Linux) because its config is stored outside of the pcp
dir in a user global fashion.
How can I make the fpc compiler versions co-exist and be recognized by the
respecive versions of Lazarus?



As for Lazarus:
Lazarus takes an argument --pcp=
So each version can be pointed to its own config.

That option can be put into a file called lazarus.cfg which is to reside 
in the directory of your lazarus exe file
(or the startlazarus file if you use that / you only need that if you 
have non-writable root installs, and/or for restarting after build)
Mind that if you have root installs, then the lazarus exe eventually 
ends up in the pcp, and the lazarus.cfg must be with the startlazarus 
that would start the lazarus.



As for FPC:
Either use scripts to start lazarus and set the $PATH for each fpc.

Or start the ppc directly // configure lazarus to use the ppc.

Mind that you also need the fpc.cfg to be found (so that can have ifdefs 
based on the version)



---
From my setup script

this sets a folder for each fpc, and creates some symlinks
- The IDE must be pointed to use the ppc in the lib/fpc/3.2.2/ folder.
- there must be no global fpc.cfg (/etc or /home/name/.fpc or the like)

compiling with -va allows to check what is used.

$INSTPATH can be whatever.

-

mkdir -p /home/m/fpc/$INSTPATH/
mkdir -p /home/m/fpc/$INSTPATH/gl
mkdir -p /home/m/fpc/$INSTPATH/gw
mkdir -p /home/m/fpc/$INSTPATH/def
mkdir -p /home/m/fpc/$INSTPATH/o4


cd /home/m/fpc/$INSTSRC/source

make clean
make all    OPT="-gw -O-1  "
make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/gw

mkdir -p /home/m/fpc/$INSTPATH/gw/lib/fpc/etc
mkdir -p /home/m/fpc/$INSTPATH/gw/etc

cd /home/m/fpc/$INSTPATH
gw/bin/fpcmkcfg -d basepath=/home/m/fpc/$INSTPATH/gw/lib/fpc/$INSTVERS > 
gw/lib/fpc/etc/fpc.cfg
gw/bin/fpcmkcfg -d basepath=/home/m/fpc/$INSTPATH/gw/lib/fpc/$INSTVERS > 
gw/etc/fpc.cfg


ln -s /home/m/fpc/$INSTPATH/gw/lib/fpc/$INSTVERS/ppcx64 
/home/m/fpc/$INSTPATH/gw/bin/ppcx64


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 2.2.6

[Martin Frb via lazarus]

On 16/03/2023 07:53, Bo Berglund via lazarus wrote:
The install seems to have worked, but seeing this release comment I 
now have to

ask if 3.2.2 is a *requirement* for proper operation or if it just happens to be
what you used when building?

Do I have to change my fpc installed version and rebuild Lazarus to have it work
properly?


No, its not. Currently 3.2.0 is the minimum supported. (All else before 
is your own good luck, or the absence thereof).


We usually support:
- the current fcp release (at the moment 3.2.2)
- the previous release (3.2.0)
- fixes branch and main branch / for both support may lack a few days, 
if there are breaking changes.


Though, we do more/most testing with the current release. Issues that 
are 3.2.0 only usually only get attention when reported.
On the other hand, issues that are only 3.2.0 are usually "doesn't 
compile at all" (and IIRC we have a CI task for that now).

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] strange focus behaviour on source editor window

[Martin Frb via lazarus]

It does not happen to me, tested Win 10 and Win 11.
For me focus goes back to the source editor.

I switched back to the IDE with Alt-Tab. Maybe you use some other way? I 
also tried by clicking the icon in the taskbar, and that worked (tested 
Win 10 only).


Do you have any packages installed? (Maybe Anchor-Docking?)


On 27/02/2023 18:51, Mgr. Janusz Chmiel via lazarus wrote:


Dear Lazarus developers,

   I have found out very interesting and strange focus 
behaviour in Lazarus IDE.


When I edit The source code in The source editor Editable field. And 
when I switch window to desktop and when I switch back to Lazarus IDE, 
focus is not located at source editor editable field.


Focus jump automatically to The TAB with components list. The object 
class name is


Does this behaviour have a good thinked intention for developers? Or 
it should not appear?


I must always press F12 twice to have source editor Edit box on focus.

Thank you for your explanation.




-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus and FreePascal version relations on Linux and Windows?

[Martin Frb via lazarus]

On 22/02/2023 10:00, Bo Berglund via lazarus wrote:

Now I am having problems installing Lazarus 2.2.4 on Linux systems where older
Lazarus version exist because they use an older FPC which the new Lazarus cannot
use (3.0.4 vs 3.2.2).

You can install several fpc on Linux.

** But you need to remove the global /etc/fpc.cfg and have it local to 
the install. **

You can look at the output of
    fpc -va  empty_project.pas | grep fpc.cfg
to find the locations were fpc looks for it.

There may also be a way (I don't know) to have the IDE pass a param to 
fpc telling fpc which fpc.cfg to use



And you either need to start the IDE via a script, setting a suitable 
%PATH env, so the correct fpc can be found. And fpc can find the correct 
ppc.

Or if you don't cross compile, you can invoke ppc directly .

I use the below. It allows several builds, even of the same version 
(debug / opt)


#!/bin/sh

mkdir -p /home/m/fpc/$INSTSRC
mkdir -p /home/m/fpc/$INSTSRC/source
cd /home/m/fpc/$INSTSRC/source

git -C  /home/m/fpc/svn/source --work-tree=/home/m/fpc/$INSTSRC/source 
restore .


### have a full working fpc in path to start the build

mkdir -p /home/m/fpc/$INSTPATH/
mkdir -p /home/m/fpc/$INSTPATH/def

cd /home/m/fpc/$INSTSRC/source

make clean
make all  OPT="-g- -gl -O-2  "
make install INSTALL_PREFIX=/home/m/fpc/$INSTPATH/def

mkdir -p /home/m/fpc/$INSTPATH/def/lib/fpc/etc
mkdir -p /home/m/fpc/$INSTPATH/def/etc

cd /home/m/fpc/$INSTPATH
def/bin/fpcmkcfg -d basepath=/home/m/fpc/$INSTPATH/def/lib/fpc/$INSTVERS 
> def/lib/fpc/etc/fpc.cfg
def/bin/fpcmkcfg -d basepath=/home/m/fpc/$INSTPATH/def/lib/fpc/$INSTVERS 
> def/etc/fpc.cfg


ln -s /home/m/fpc/$INSTPATH/def/lib/fpc/$INSTVERS/ppcx64 
/home/m/fpc/$INSTPATH/def/bin/ppcx64


## use in the IDE /home/m/fpc/$INSTPATH/def/lib/fpc/$INSTVERS/ppcx64



And another question:

How can I force Lazarus to show the initial configuration page, which is shown
on the very first start after installing Lazarus and later is skipped?

lazarus --setup

In the git main version of lazarus you can also force certain checks to 
be skipped (including fppkg)

lazarus --help

--skip-checks=LazarusDir,FpcExe,FpcSrc,Make,Debbugger,Fppkg,Setup,MissingPackageFile,InstallDir,SingleInstance,All
  Skip selected checks at startup.

You can put those into the
  lazarus.cfg
file (in the same directory as your lazarus exe // or your startlazarus 
exe, in case you use that and your lazarus is it the primary conf path)



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Conditional Debugger breakpoints not working ?

[Martin Frb via lazarus]

On 20/02/2023 15:14, Michael Van Canneyt via lazarus wrote:


On Mon, 20 Feb 2023, Martin Frb via lazarus wrote:



It is a problem on Mac, with LLDB. Though I am not even sure that 
conditional breakpoint are supported at all...
Just checked, conditions are set. But users must type them C-style. That 
is "a == 1".




They are:
https://stackoverflow.com/questions/37204551/lldb-setting-conditional-breakpoint-with-string-equality-as-condition 



That looks like it actually invokes strcmp() in the debugged exe. Which 
then depends on an fpc generated app having that function, and having 
sufficient debug info to have it found.


The GDB $_streq on the other hand is an gdb intrinsic.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Conditional Debugger breakpoints not working ?

[Martin Frb via lazarus]

On 20/02/2023 13:46, Michael Van Canneyt via lazarus wrote:



I suggest you adapt the wiki to clarify all this.

While you're at it, The link in the wiki page to the gdb convenience
functions is broken.

updated



In general, I don't think you can expect the user to know that he 
should use $_streq(myvar, "hello"), specially the cmem condition that 
seems necessary.


Ideally, the IDE could detect a string and transform the expression.


This always has been the issue with gdb.

If you had a watch with anything but just a plain variable name, then 
gdb may give you:

- an error,
- or an incorrect result,
- or the correct result

For watches, there is quite a lot of code in the IDE to try and fix 
those things.
There are testcases, that can be run with different debug-info, and diff 
gdb versions. (And they run for many hours / and unfortunately still 
have some errors, some false errors...).


But there is no way to get to 100%. In many cases gdb simple does not 
give enough info to detect the necessary information on the underlaying 
type. (And when trying to get this, one has to be carefully not to crash 
gdb).
Also it makes evaluating each individual watch a lot slower (at least 
factor 3 or 4). Though on that I have always pushed the point that a 
"correct result" is worth *any* wait time.


In any case, with conditional breakpoints it would be even more complex

It would be nice to have, but with the availability of FpDebug, it is 
very unlikely that will be fixed. (There are simply a lot of other 
things that (should) have more priority)


I may add a warning to the breakpoint dlg, that for non-fpdebug will 
display a red TLabel below the input, with some text that the condition 
may not work at all.


It is a problem on Mac, with LLDB. Though I am not even sure that 
conditional breakpoint are supported at all...
LLDB probably can do them (with restrictions like gdb). But the IDE has 
absolutely on code to translate "pascal to lldb" => because for watches 
it can evaluate with fpdebug.
But conditional breakpoints must be done by lldb, or they become very 
very slow. (That is if they need to pass lots of time before they match 
the condition, and each hit pass 1 second or more, you quickly get to 
several minutes of wait time)






--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Conditional Debugger breakpoints not working ?

[Martin Frb via lazarus]

On 20/02/2023 12:31, Michael Van Canneyt via lazarus wrote:


I'm trying to set a condition on a breakpoint.

I have a local variable aUnit, type string:

var
  aUnit : string;

I wish the breakpoint is only triggered when aUnit equals 'termio'.

So, in the breakpoint properties dialog, I enter the condition:

aUnit='termio'

It seems to have no effect whatsoever. The breakpoint is triggered 
always at

the first traversal of the line.

I tried variations (uppercase, lowercase) , but to no avail.

Looking at the debug internals window, I see that the expression is
only (correctly) evaluated by gdb when I move the mouse over the 
identifier

in the sources:

(gdb) 


gdb doesn't know pascal strings, or how do an "=" operation on them.

You can try to get  $_streq(myvar, "hello") to work
https://sourceware.org/gdb/onlinedocs/gdb/Convenience-Funs.html

Or use FpDebug. FpDebug can compare strings.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Folding ?

[Martin Frb via lazarus]

On 19/02/2023 21:49, Martin Frb via lazarus wrote:


On "Editor > Display" you can also change the "Gutter Separator index" 
from 3 to 4 => then the separator (a gray line /color can be changed) 
will be between the fold-tree and the text (and with that another 1 or 
2 pixels distance / not much, but)

(the preview in the options seems to be not showing the effect...)


There seems to be a bug. That needs an IDE restart (after changing the 
option) for the line to be painted...

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Folding ?

[Martin Frb via lazarus]

On 19/02/2023 21:12, Michael Van Canneyt wrote:

On Sun, 19 Feb 2023, Martin Frb wrote:

To entertain my lack of imagination: What is the issue, if e.g. 
Pascal shows fold indicators, and you just don't use them?


Secondly, I sometimes inadvertently click on the fold markers.

Ok, good reason.

That the thing, a lot of features are tested against my own usage 
patterns / experience. Simply because I don't know other people usage 
patterns.
I could imagine the accidental clicks to happen when trying to select 
text with the mouse (or set the caret). Neither of those 2 I usually do 
by mouse.




The above 2 reasons are why I disabled it. Also, I think that if you need
folding in Pascal, your code is not very well structured. As a general 
rule,

I think a procedure may not occupy more than 50 lines. If you adhere to
that, folding is simply not needed.
Actually there used to be another reason for folding (but that has been 
mitigated a decade ago).


And that other reason is why back then I spent the time to make it work...
=> Fold (several consecutive) entire procedures.

I occasionally find it useful while writing code in one procedure, to 
have another procedure in view for reference. (E.g. refactoring, moving 
code around)
If that was in the same unit (and back then one unit could only be open 
in one SourceEdit window), then I just folded all the procedures in between.

Now, I just open the unit in 2 windows, and have them side by side.

And in code that does have $IFDEF, it's sometimes nice to hide that.
As well as comments, including single line comments (hence hide/fold).


Btw, folding may not be the best way to check for correct html nesting.
IIRC, the highlighter tries to find a matching-name closing tag, even 
if that means to skip other tags.


No doubt. But there are other uses: in large html structures (HTML can be
very verbose in some CSS frameworks, there is no way around it) , it 
helps to be able to see the larger structure.


Ideally, the fold indicators are also not visible in HTML/XML, but I 
can simply right-click a div and ask to collapse/expand that div.


That could also be added.
There are keyboard shortcuts to fold at word at cursor (if that word is 
starting a fold).


Adding that to the menu should not be to hard.
And neither should it be hard to add an option to hide the fold outline.
But as usual it needs to be done.

I don't mind feature requests for those. But it's likely some time 
before I would get to it.


Hiding the fold-outline gutter (global / for all languages) is probably 
easy. So if folding by key works for you , and you don't mind that the 
keys work for pascal code too => that I can probably squeeze in.


Or, if it is just against accidental clicks => go to "Mouse advanced 
options"
Remove all (or at least left button) mouse actions for the fold-tree, 
and fold nodes. Then nothing happens if you click there.

Or change the clicks, so they only work with a modifier key (as protection)

On "Editor > Display" you can also change the "Gutter Separator index" 
from 3 to 4 => then the separator (a gray line /color can be changed) 
will be between the fold-tree and the text (and with that another 1 or 2 
pixels distance / not much, but)

(the preview in the options seems to be not showing the effect...)


Btw, If the caret is at a html tag, the matching tag is highlighted, so 
you can see those without needing the gutter outline.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Folding ?

[Martin Frb via lazarus]

On 19/02/2023 19:06, Michael Van Canneyt wrote:



On Sun, 19 Feb 2023, Martin Frb via lazarus wrote:


On 19/02/2023 12:28, Michael Van Canneyt via lazarus wrote:


Hi,

Is it possible to enable/disable code folding on a per-language 
basis  ?
No, or only in the way you described below. Or by changing the source 
in each highlighter, and make the pretend they don't fold.


That seems a strange way. Since folding can be globally switched on 
and off, it should also be

possible to switch it on/off on a language basis.


Well, it just hasn't been implemented. There is no reason not to add it, 
if someone wants to do it.


To entertain my lack of imagination: What is the issue, if e.g. Pascal 
shows fold indicators, and you just don't use them?






In any case, there also remains the "fold selected lines" folding.


That would defeat the purpose. I use the folding to see if the HTML 
tags are closed properly without having

to select them.


You don't have to select them.

If you do select text, the gutter will show an additional fold (actually 
"hide") symbol, allowing you to collapse whatever text is selected.


Btw, folding may not be the best way to check for correct html nesting.
IIRC, the highlighter tries to find a matching-name closing tag, even if 
that means to skip other tags.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Folding ?

[Martin Frb via lazarus]

On 19/02/2023 12:28, Michael Van Canneyt via lazarus wrote:


Hi,

Is it possible to enable/disable code folding on a per-language basis  ?
No, or only in the way you described below. Or by changing the source in 
each highlighter, and make the pretend they don't fold.


In any case, there also remains the "fold selected lines" folding.



Currently it seems you can only do this by enabling code folding 
globally,
and then disable it for all constructs in all languages except the 
ones you

want... But it can be that I missed the option somewhere...


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Porting Delphi (2007/XE5) application, how to handle ADODB?

[Martin Frb via lazarus]

On 11/02/2023 12:23, Bo Berglund via lazarus wrote:



Then rebuilt and tried to run, but I get an immediate fatal exception!
This happens both when starting within Lazarus and from the exe file itself.
Message:
  
  | Project AppManager raised exception class 'External: |
  | ACCESS VIOLATION' with message:  |
  | Access violation reading from address|
  | $0040|
  |  |
  | At adress 196AD  [OK]|
  

How can I find the cause of this exception?



Did the debugger jump to any source code?
What does the "Callstack" window show?

If neither shows anything, the error might be in the RTL or kernel. What 
does the assembler win show?


Give the data from the error message, I guess there is a nil pointer 
deref (e.g. access to a field in an object that is nil)


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fppkg reports RTL not installed - Lazarus 2.2.4/fpc 3.2.2 from sources on Ubuntu

[Martin Frb via lazarus]

On 09/02/2023 21:57, Bo Berglund via lazarus wrote:
And it seems to be looking for $HOME/.config/fppkg.cfg even though I 
am using

separate install dirs for Lazarus 2.0.12 and 2.2.4 and the launch file
lazarus_2.2.4.desktop contains --pcp=/home/bosse/.lazarus_2.2.4

So I would expect the location of the fppkg.cnf file to be inside that pcp dir,
but it is not.


According to what I gathered info wise, fppkg only supports one config 
dir. (it has some options, but not sure the IDE uses those)

So it does not work well for Lazarus multi install.

The IDE will work fine without it.
It' only needed if you need some of the few packages that are only avail 
via fppkg (though you can download them by hand anyway)



Try to delete the old config by hand.
Then -outside the IDE - use the latest (3.2.2) fppkg to create a new
config. (may or may not need the fpc install in PATH)

Exactly what do you suggest here?
- Which old config? File name and location please.

The one in your home folder (I don't have Linux path)...
On Windows it's in %APPDATA%\Local\FreePascal\fppkg

There are files like fppkg.cfg mirrors.xml packages.xml and some folders.


- How do I use the new fpc to recreate it? I don't even know what it is

there is an fppkg utility in the fpc folder. (fppkg is part of fpc)

If you just run it
fppkg
it should create a config file (if none exists).
It wont say that it did, it just prints the help.
(could be that fpc needs to be in path)



Note that I must be able to run my existing Lazarus 2.0.12 until everything with
2.2.4 has been checked to work..
It is a long time back since I last dealt with it (I now have it 
disabled...)


It is not about the lazarus version, but different fpc versions.
In my case (but maybe I was lucky) the older fpc didn't complain

Anyway that is about what I remember from when I last fought with it
Sorry, it's not much





--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fppkg reports RTL not installed - Lazarus 2.2.4/fpc 3.2.2 from sources on Ubuntu

[Martin Frb via lazarus]

On 09/02/2023 20:24, Bo Berglund via lazarus wrote:

On Thu, 09 Feb 2023 18:34:27 +0100, Bo Berglund via lazarus
 wrote:


What does this mean?

I have never seen this before in my many years of Lazarus usage...

And what should I do to rectify it?


I found this being discussed on gitlab:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/35254

and

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


Seems like there is no solution yet, am I right?

So, should I just disregard it completely?



In Lazarus trunk it can be disabled

But before that tuff.

Try to delete the old config by hand.
Then -outside the IDE - use the latest (3.2.2) fppkg to create a new 
config. (may or may not need the fpc install in PATH)



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] OFF-TOPIC: Naming of char [[[Re: Debugging the unicode RTL]]]

[Martin Frb via lazarus]

On 22/01/2023 13:12, Marco van de Voort via lazarus wrote:


On 22-1-2023 12:39, Martin Frb via lazarus wrote:


They should be called

AnsiCodepoint
UniCodeCodePoint


No, since in the case of a surrogate it is not a codepoint either. It 
is the unit of encoding granularity, nothing more.
Ouch, yes got me there. And in utf8 it is also not a codepoint. I should 
have use "CodeUnit".





I have some doubts about such simple nomenclature really explaining 
something as complex as unicode. It will never be intuitive and always 
need study.



Agreed.
But I couldn't resist.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] To be a string or not to be a string (bitness independent?) [[[Re: Debugging the unicode RTL]]]

[Martin Frb via lazarus]

On 22/01/2023 11:24, Martin Frb via lazarus wrote:

Though this relies on being able to detect
   PChar  <>  String  <>  array of char
which is a PITA.


Example:
  FPC 3.3.1 (but IIRC also 3.2.x)
  tested on Win, but similar on other OS
  dwarf-3

var
  s1: AnsiString;
  s2: array of char;


Both are encoded as
    DW_TAG_array_type

The name is not relevant, since the user could have done "type Foo = 
type AnsiString"


The debugger can only make the difference by looking at "current 
implementation in fpc"


For an array, FPC adds
- a stride
- a type for the subrange.

Both are not guaranteed, and could change any day.

If they do, a string may suddenly be shown as
  s1:   ('H','e','l','l','o',' ','W','o','r','l','d')


With DWARF-2  string are using the same dwarf as "PChar" (independent of 
its new name).


So for the watch "s1[2]" you get the value
PChar 'l'; String 'e'

Because the debugger simply can't tell if the index is 1 or 0 based.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] OFF-TOPIC: Naming of char [[[Re: Debugging the unicode RTL]]]

[Martin Frb via lazarus]

On 22/01/2023 11:53, Michael Van Canneyt via lazarus wrote:
Since the PChar/Char types are now an alias, logically the debug info 
should only have references to AnsiChar/UnicodeChar.


Well technically neither of them is (always) an actual character.

They should be called

AnsiCodepoint
UniCodeCodePoint

So people will be reminded that they do not contain characters (they may 
by coincidence, but software should not be build on coincidence)


But that is just my personal 2cent.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging the unicode RTL

[Martin Frb via lazarus]

On 22/01/2023 11:53, Michael Van Canneyt via lazarus wrote:


Since the PChar/Char types are now an alias, logically the debug info 
should only have references to AnsiChar/UnicodeChar.


But I have no idea how to test this assumption.


if adding a watch containing  "^char(x)" fails, then that will upset 
plenty of people. (including me)


That alias should always be encoded as type, if it is used in the user's 
code.




So, if I understand you correctly:

The problem is now to see if the debugger can determine from the
available debug info/rtti whether the RTL uses AnsiChar or UnicodeChar.


Not really.

Whenever the debugger accesses "char" or "sequence of char" data, it 
should have debug info for this.

If it has, this debug info will contain the size-of for that/those chars.
And that is enough to decide if that particular instance is utf8 or utf16.

If the RTL (or user code) would be partly AnsiChar, and partly 
UnicodeChar... => no problem.


The problem is, that the Exception.FMessage is not using dwarf info. 
(Because it is not always included)




Which still leaves the question: What to do if there is no debug info 
for the system unit ? By default, FPC distributes units without debug 
info.


Well if it is not possible to include
    type sysutils.Exception
in the dwarf info,
then some other kind of flag needs to be agreed that is on top of the 
normal dwarf.


The question is where to store this.
- It could be some $$$char  type declaration (to make sure it can't 
clash with user names). But then should be in a specific unit, so the 
debugger knows where to look.
- It could be an addition to the "producer" in the Compilation-unit (but 
that needs to be repeated in every CU)

- It could be a "linker symbol" like FPC_RAISEEXCEPTION",
  where the compiler either includes FPC_CHAR_IS_ANSI or FPC_CHAR_IS_UNI

Or, depending on how the whole stuff works with the linker
Even if sysutils.o does not have debug info, the compiler could write 
and include a dummy .o file that has debug info and gets included.

It may have to use a diff unit name for that: sysutils$$fpc.o


Those are just ideas, I don't know the compiler/linker well enough

Any "global" flag, will cause extra work when it comes to dll/libraries. 
Because then all FpDebug code needs to handle this per dll.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging the unicode RTL

[Martin Frb via lazarus]

I may have to double check some details, just going from memory

On 22/01/2023 11:46, Michael Van Canneyt wrote:

On Sun, 22 Jan 2023, Martin Frb via lazarus wrote:

On 12/01/2023 10:42, Michael Van Canneyt via lazarus wrote:


- Debugging programs works in general quite OK, except for 
displaying of

  some strings. Most notable, the exception message is affected:
  only the first character of the exception message is shown.


This is hardcoded, and may be change-able, if debug info is avail.

With a look at the next paragraph below
If
    Exception = class  end
 is available (ideally within the correct unit, so the debugger can 
distinguish it from some user declared type), then the debugger could 
use this.


Ideally it will by in unit system/sysutils.


Sorry, I don't understand at all what you are saying here.


1)
If you look at the current code getting the message, it just hardcoded. 
Get pointer to instance, add hardcoded offset to FMessage field. Assume 
it is an AnsiString. Read it.


But if it could find (the correct) type "Exception" describing the 
class, then it could evaluate:

 Exception( instance_addr_from_reg ).FMessage

And thus get the dwarf info for FMessage which includes the size-of-char.

2)
However a user can define his own class name "Exception" that has 
nothing in common with the above.
So if LazDebuggerFp could relay on finding this class in unit system or 
sysutils => then that would make it more fool proof.


If the class is not found, the current behaviour can be used as fallback.

3)
Looking up "char" is possible. But there can be a "char" definition in 
each unit (On Windows there almost certainly is)






NOTE:
On Linux, such symbols are referenced cross units. But on Windows 
they are repeated in every unit using them. That again makes it 
harder to know if it is the correct type (since the user may have its 
own type by the name).


?
If I use TFooList from unit Foo, then a dwarf definition of TFooList is 
expected in unit Foo.


IIRC, on linux that is the case.
And on linux any other unit has a reference to that unit.

On Windows: There may be, if the type is actually used in unit Foo.
On Windows, every other unit in which it is used, will repeat the entire 
dwarf.


This may depend on the linker. ??




But for debugging this is not enough: I think the IDE debugger needs 
another mechanism to determine using whether a program uses a 
unicode RTL or not. The way this happens in code is {$IF 
SIZEOF(CHAR)=2}


I don't think the debugger should have or need such a "global" flag.

Currently if it looks at a string (and there is dwarf debug info), 
then the dwarf contains the size-of-char: 1 or 2.

And the debugger does utf8 or utf16 (the latter may be buggy).


I have meanwhile established that it has some problems: I have the 
impression that PChar is hardcoded in some places to mean UTF8.

Example? I did not find that " below"

Anyway, what you might have seen, is not that the name "PChar" maps to 
utf8, but that the dwarf description of:

      pointer > basic-dwarf-type(char with size =1)
Is interpreted as such.

For such a type it is not known what the encoding is. (Eventually the 
user should be able to chose in the watch-properties).
But in LCL apps, the above is most likely a PAnsiChar to a (sub-)string 
that is utf8 encoded.





Joost even added code to read the hidden encoding field of strings.

Though this relies on being able to detect
   PChar  <>  String  <>  array of char
which is a PITA.





But for such low-level things as a debugger, the use of "char" and 
"pchar" is IMO absolutely forbidden.


For the debugger the name of the type is irrelevant. It looks up the 
dwarf definition.


If the user's code contains a type name FooChar, then the debugger has 
no influence on that.

Equally if the user enters a watch: ^char(xy)^


2/ Where can I find the code that extracts the message from an 
exception

object ? So I can have a shot at trying to fix the display.


unit FpDebugDebugger;
procedure TFpDebugDebugger.HandleSoftwareException

// Get address of object

  if not 
FDbgController.DefaultContext.ReadUnsignedInt(FDbgController.CurrentProcess.CallParamDefaultLocation(0),
    SizeVal(SizeOf(AnExceptionObjectLocation)), 
AnExceptionObjectLocation)

  then


    ExceptionMessage := 
ReadAnsiString(AnExceptionObjectLocation+DBGPTRSIZE[FDbgController.CurrentProcess.Mode]);



That currently does not yet have the read of the "encoding" field.


From what I know, a unicode string does not have an encoding field. So 
this

code will need some changes.


This code IIRC only acts, if it finds:
    basic-dwarf-type(char with size =1)

So that should be ok.

It should be in the
  unit FpDbgDwarfFreePascal;

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging the unicode RTL

[Martin Frb via lazarus]

On 22/01/2023 11:24, Martin Frb via lazarus wrote:




2/ Where can I find the code that extracts the message from an exception
object ? So I can have a shot at trying to fix the display.


unit FpDebugDebugger;
procedure TFpDebugDebugger.HandleSoftwareException



Important:

If you make any change is the FpDebug package itself, and code that is 
FPC specific must go into

  unit FpDbgDwarfFreePascal;

All other units should be kept free from such knowledge (not 100% 
achieved yet, but...).
After all, FpDebug is meant to be a generic debugger for any app that 
has dwarf.


Exception may be semi-generic stuff like prologue detection based on 
fpc, but potentially working for other compilers too.


---
Of course
   LazDebuggerFp  (containing FpDebugDebugger)
is in a diff package.
And it can have as much FPC knowledge as it wants.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging the unicode RTL

[Martin Frb via lazarus]

On 12/01/2023 11:26, Michael Van Canneyt via lazarus wrote:


It needs to determine the definition of "string" which will be an 
array of
unicodechar or ansichar. Once it knows that, the rest will follow, 
since the definition of unicodechar or ansichar will have the correct 
size.




The big issues is still, that dwarf does not make any 
(official/documented) diff between PChar, string and array of char.

Except for internal encoding details 


I don't think this is a very reliable method. In moderately difficult 
code,
half of the time the codetools don't work properly, so relying on them 
to provide this info is a recipe for disaster. Hence my question...


The debugger does and should not relay on codetools.

Well, there is a  case where codetool helps preparing
If you add a watch (or hover for a hint), codetool will determine the 
boundaries of the expression.


So   "foo.bar"  will not just add bar, but the correct term.
Or  "foo.bar[x.y]"   if you hover on y, will get x.y, but if you hover 
on "]" will get the full term.


And codetool will resolve "with" at that time.

But that is it.
And it should be it.

Source can have changed in the mean time.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugging the unicode RTL

[Martin Frb via lazarus]

On 12/01/2023 10:42, Michael Van Canneyt via lazarus wrote:


- Debugging programs works in general quite OK, except for displaying of
  some strings. Most notable, the exception message is affected:
  only the first character of the exception message is shown.


This is hardcoded, and may be change-able, if debug info is avail.

With a look at the next paragraph below
If
    Exception = class  end
 is available (ideally within the correct unit, so the debugger can 
distinguish it from some user declared type), then the debugger could 
use this.


Ideally it will by in unit system/sysutils.


NOTE:
On Linux, such symbols are referenced cross units. But on Windows they 
are repeated in every unit using them. That again makes it harder to 
know if it is the correct type (since the user may have its own type by 
the name).





But for debugging this is not enough: I think the IDE debugger needs 
another mechanism to determine using whether a program uses a unicode 
RTL or not. The way this happens in code is {$IF SIZEOF(CHAR)=2}


I don't think the debugger should have or need such a "global" flag.

Currently if it looks at a string (and there is dwarf debug info), then 
the dwarf contains the size-of-char: 1 or 2.

And the debugger does utf8 or utf16 (the latter may be buggy).

Joost even added code to read the hidden encoding field of strings.

Though this relies on being able to detect
   PChar  <>  String  <>  array of char
which is a PITA.




1/ Should the compiler provide some symbol in - say - the system unit 
to deterine

whether the RTL is compiled in unicode mode, or is another mechanism
preferred to do this ?

I don't think that is useful.
Better find the individual places that go wrong, and fix them.

As I said, Exceptions are hardcoded (and IIRC not even in FpDebug, but 
in LazDebuggerFp).

They could/should first search for the type "Exception"




2/ Where can I find the code that extracts the message from an exception
object ? So I can have a shot at trying to fix the display.


unit FpDebugDebugger;
procedure TFpDebugDebugger.HandleSoftwareException

// Get address of object

  if not 
FDbgController.DefaultContext.ReadUnsignedInt(FDbgController.CurrentProcess.CallParamDefaultLocation(0),

    SizeVal(SizeOf(AnExceptionObjectLocation)), AnExceptionObjectLocation)
  then


    ExceptionMessage := 
ReadAnsiString(AnExceptionObjectLocation+DBGPTRSIZE[FDbgController.CurrentProcess.Mode]);



That currently does not yet have the read of the "encoding" field.



What about:
   TSomeClass.Classname

is that utf16 too?
Because the debugger reads it for automatic class casting

Any other changes in the RTTI where things switched to 16 bit?

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] make all compilation error after 319649fb (Attn: Martin)

[Martin Frb via lazarus]

On 09/01/2023 17:50, Marcus Sackrow via lazarus wrote:

Hi,

Am 08.01.23 um 23:11 schrieb Wayne Sherman:

make all for at least x86_64-linux does not compile since 319649fb

thanks it compiles again

About a week ago Lazarus was failing to build with "make useride".
Are these two build targets being run as part of the CI / CD tests?


these compilations (from this error report) are on m own Jenkins server
and atm it does only a "make all"

it's mainly focused on catching problems with latest FPC (because it
uses always the latest FPC, compiled some minutes before that)

and to check if the compilation for Amiga-style systems still work (and
with it the MUI widget set) in other jobs


Of course if there is interest in more tasks, it can be added, the
server still has some resources.


It needs to be discussed with other devs as well, what they think...

We do still have free minutes at GitLab. But the amount of combinations 
for testing is (near) infinite.


There is "make" (aka "make all" ?) and "make bigide".
Afaik "make useride" depends on what packages are configured, so that is 
not just a single setting?


But each of them may fail only for a specific OS/Arch, or for some other 
specific setting. (like compile time range check error for constant 
eval, with -Cr enabled).
We already have builds for win, gtk2, qt, iirc some with 32bit, and fpc 
3.2.2 and trunk. (not all variations though).


I personally currently don't have the time to look into it.
(I'll ping the others, if anyone wants to pick up)

If I should find time eventually, my interest will be much more in 
adding some of the tests we have to be run.





--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] make all compilation error after 319649fb (Attn: Martin)

[Martin Frb via lazarus]

On 08/01/2023 23:11, Wayne Sherman via lazarus wrote:

make all for at least x86_64-linux does not compile since 319649fb

thanks it compiles again

About a week ago Lazarus was failing to build with "make useride".
Are these two build targets being run as part of the CI / CD tests?


I don't know, it will need to be checked...
The CI config is part of the git repo. So it can be checked by anyone.

Not sure though if running all make targets is the best idea. IMHO more 
important to run diff OS/Arch targets and compiler versions.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] SynEdit highlighter for Markdown

[Martin Frb via lazarus]

Without yet having looked at it (currently got a bit of an incoming 
queue)...


But there is a tutorial on how HL work: 
https://wiki.freepascal.org/SynEdit_Highlighter



On 05/01/2023 23:59, Andrew Haines via lazarus wrote:
Hi, I attached a highlighter I made for Markdown. I like to use this 
in my projects to plan things.


It seems to work fine with any attribute that only requires a single 
line. I tried and failed to make multiline fenced code work. I'm sure 
there is just something I wasn't understanding.


```

multiline

code

block

```


Indenting works though.


If anyone has some clues I'd love to know what I did wrong :)


Regards,

Andrew Haines



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus IDE 'testall' program

[Martin Frb via lazarus]

On 24/11/2022 14:00, Aruna Hewapathirane wrote:
On Thu, Nov 24, 2022 at 7:16 AM Martin Frb via lazarus 
 wrote:


On 24/11/2022 12:53, Aruna Hewapathirane via lazarus wrote:


I found one repository on Gitlab:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/examples
<https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/examples>

And another repository on Sourceforge:
https://sourceforge.net/p/lazarus/laz.git/ci/main/tree/examples/
<https://sourceforge.net/p/lazarus/laz.git/ci/main/tree/examples/>


The correct repo is the one on Gitlab. The sourceforge is a mirror
(run by the team). There also is a mirror on Github.


Ah...  thank you for the clarification. So any fix'es I have to push 
to Gitlab then?


- Ideally as a "merge request" on Gitlab. (Fork, push to your fork, 
create merge-request)

- However Patches are accepted too.
- And some developers may accept pull requests (in which case your fork 
can be on any public accessible git).
  "some developers" => That is, if you interactively deal with a member 
of the team, who told you they would be the one to accept your changes.


Any change should ideally be against the "main" branch.
So in this case, that would be reintroducing the files.

If you plan any "larger" work, best to query (as actually - by 
coincidence - you do in this mail) if it would be accepted (or what 
implementation requirements their might be).
Ideally you will get response from some developer, who confirms that 
they will accept and merge/apply your changes.




In the "main" branch the example folder was re-ordered. During
this process the "testall" appears to have been removed. Not sure
of the reasons...

Oh-kay that explains why I was unable to find it and am sure the 
reasons were all good and valid :-)


Maybe oversight, maybe because it did not work. If the latter,
then likely a working version can be re-added.


Umm... well "testall" works on Windows I had zero issues but needs a 
few fixes when running under Linux. I have manged to get it to

work on my Debian system now.
If you plan to work on it, I would suggest to wait a day or two, for 
further details on this to emerge.
If it was removed because it did not work cross platform, then re-adding 
after fixing should be ok.


Maybe there were other reasons. Maybe it would be better to break it 
into a small number of projects, each dealing with a subset of the 
components.
A "all in one" might make it very hard to read and understand the code 
for a specific component.


If you look at the examples (and the IDE menu Tools > "Example projects" 
(in Lazarus 2.3), then you will find that many components have there own 
examples already.
Repeating them, may not make much sense (unless for example to have all 
buttons in one project, with settings/code explicitly showing their 
differences).


Of course, depending on the course of action, the wiki may need updates 
(it still is correct for the current release, but it wont be for 2.4 / 
and it might easily be overlooked when the time comes)
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus IDE 'testall' program

[Martin Frb via lazarus]

On 24/11/2022 12:53, Aruna Hewapathirane via lazarus wrote:


I found one repository on Gitlab:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/tree/main/examples 



And another repository on Sourceforge:
https://sourceforge.net/p/lazarus/laz.git/ci/main/tree/examples/ 



The correct repo is the one on Gitlab. The sourceforge is a mirror (run 
by the team). There also is a mirror on Github.




And now comes the interesting part, neither repository has a file 
called "testall" which was very confusing to me.
So I checked and then double-checked under the examples folder in both 
repositories and found nothing again.


Does anyone know why "testall" is not there in both Lazarus 
repositories? And where is the repo that contains
"testall" please? And which repo do I use when I want to submit a 
patch or fix?




The "testall" exists in the "fixes_2_2" branch. (Which is used for 
current releases).


In the "main" branch the example folder was re-ordered. During this 
process the "testall" appears to have been removed. Not sure of the 
reasons...
Maybe oversight, maybe because it did not work. If the latter, then 
likely a working version can be re-added. I did sent a query to the 
person behind the change, hopefully he can shine some light on this.


-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Message for Lazarus developers

[Martin Frb via lazarus]

I haven't got the answer at hand Also not sure which wiki page you 
refer too?


Have you looked into the image folder in the lazarus installation?
There is a copyright file that has info on the licenses (and creators) 
of the images. So if you got the filename you can check if it is listed 
there. And who the author is, if the current license is not permissive 
enough.


If the file is there, but not in the copyright list, then the git 
history might reveal who authored it. And hopefully under what license 
the lazarus project has received it.


I, myself, am not a gfx artist, and I don't know much about what 
licenses are used for gfx, and/or what they permit.
But it would be my guess, that at first it needs to be established, what 
rights the team has (i.e. under which license it was give to us). And, 
if the same license is in place for others.



On 11/10/2022 21:58, Tony Stone via lazarus wrote:

Hi,

My name is Tony Stone.  I am a long time user and fan of Lazarus. I am 
writing here to try and get permission of sorts for using the Lazarus 
logo as part of a online community a few IRC users have been setting 
up.  Our community is not trying to appear to be directly affiliated 
with Lazarus or FPC and we make it clear in our home page of our 
Rocket.Chat server.  But I do really want to replace the Rocket.Chat 
logo with something a little more friendly to our project and being as 
our chat community is a modern alternative to IRC and mailing lists I 
just want it to have a more modern appearance without third party 
branding.  I would like to use the "Blue gear head" logo as part of 
the chats logo... so basically what i asked a graphics designer to do 
is put it inside a chat bubble thing with our Lazarus chat URL 
wrapping around it. I see on the wiki page it says they are free to 
use for promoting Lazarus and FPC, which is what our rocket.chat 
community is doing.  The Wiki just is not very clear here on if 
modification is frowned upon.  Again I am trying to make sure our site 
doesn't look like it is trying to compete with any of Lazarus or FPC 
officially preferred communication platforms.  Thanks for your time.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] 131d1062 broke compilation "make all" on x86_64-linux

[Martin Frb via lazarus]

On 24/06/2022 22:16, Marcus Sackrow via lazarus wrote:


Hi,


the commit 131d1062 broke the Lazarus compilation on my Jenkins server 
(for x86_64-linux with latest Free Pascal a simple make all)


https://gitlab.com/freepascal.org/lazarus/lazarus/-/commit/131d1062dff2606d25ace6e031f0b65731cb19f6



could you test with this patch?

diff --git a/ide/Makefile b/ide/Makefile
index b6a553a776..c35f72c2bf 100644
--- a/ide/Makefile
+++ b/ide/Makefile
@@ -385,6 +385,7 @@ DEFAULT_IDE_OPTIONS= $(LAZARUS_LIBPATHS) \
-Fu../components/lazcontrols/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) 
\
-Fu../components/lazcontrols/design/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) 
\
-Fu../components/lazdebuggers/lazdebuggerintf/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
+ 
-Fu../components/lazdebuggers/lazdebuggerfp/lib/$(CPU_TARGET)-$(OS_TARGET) \
-Fu../components/lazdebuggers/cmdlinedebuggerbase/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
-Fu../components/lazdebuggergdbmi/units/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) 
\
-Fu../components/lclextensions/lib/$(CPU_TARGET)-$(OS_TARGET)-$(LCL_PLATFORM) 
\

@@ -407,7 +408,6 @@ BIG_IDE_OPTIONS=-dBigIDE $(DEFAULT_IDE_OPTIONS) \
   -Fu../components/fpdebug/lib/$(CPU_TARGET)-$(OS_TARGET) \
-Fu../components/lazdebuggers/lazdebuggerlldb/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
-Fu../components/lazdebuggers/lazdebuggerfplldb/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
- 
-Fu../components/lazdebuggers/lazdebuggerfp/lib/$(CPU_TARGET)-$(OS_TARGET) \

-Fu../components/leakview/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) \
-Fu../components/memds/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) \
-Fu../components/tachart/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) \
diff --git a/ide/Makefile.fpc b/ide/Makefile.fpc
index 18f485dd76..84e12f2b9f 100644
--- a/ide/Makefile.fpc
+++ b/ide/Makefile.fpc
@@ -97,6 +97,7 @@ DEFAULT_IDE_OPTIONS= $(LAZARUS_LIBPATHS) \
-Fu../components/lazcontrols/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) 
\
-Fu../components/lazcontrols/design/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) 
\
-Fu../components/lazdebuggers/lazdebuggerintf/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
+ 
-Fu../components/lazdebuggers/lazdebuggerfp/lib/$(CPU_TARGET)-$(OS_TARGET) \
-Fu../components/lazdebuggers/cmdlinedebuggerbase/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
-Fu../components/lazdebuggergdbmi/units/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) 
\
-Fu../components/lclextensions/lib/$(CPU_TARGET)-$(OS_TARGET)-$(LCL_PLATFORM) 
\

@@ -122,7 +123,6 @@ BIG_IDE_OPTIONS=-dBigIDE $(DEFAULT_IDE_OPTIONS) \
   -Fu../components/fpdebug/lib/$(CPU_TARGET)-$(OS_TARGET) \
-Fu../components/lazdebuggers/lazdebuggerlldb/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
-Fu../components/lazdebuggers/lazdebuggerfplldb/lib/$(CPU_TARGET)-$(OS_TARGET) 
\
- 
-Fu../components/lazdebuggers/lazdebuggerfp/lib/$(CPU_TARGET)-$(OS_TARGET) \

-Fu../components/leakview/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) \
-Fu../components/memds/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) \
-Fu../components/tachart/lib/$(CPU_TARGET)-$(OS_TARGET)/$(LCL_PLATFORM) \

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] I was just banned from the Lazarus Forum for no reason!

[Martin Frb via lazarus]

On 05/06/2022 12:28, Derek John Evans via lazarus wrote:
I don't have a copy. It was a quick post of the issues I had 
developing an app for my job as an egg collector. I thought people 
might find the project interesting and possibly ask questions about 
how I solved various problems.


I was just trying to give something back, but O well. It wasn't a 
product promo, since the app isn't for sale. Actually, if anything I 
was hoping to contact other developers so, the boss has contacts for 
future updates, since I'm retired. I collect eggs to keep fit. I don't 
work in IT anymore. Hence, we moved to the country.


Thanks for your time. If I'm banned, then so be it


I will for now give the benefit of the doubt. I reactivated your account.
I can't get the deleted message back

We have quite a few spam accounts each day signing up => so likely you 
were mistaken.
I contacted the moderator who was on duty last night. But he wont be 
responding till the this night.


Sorry about that.

Contact me if there are any issues. I am also on the forum as "martin_fr".
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] I was just banned from the Lazarus Forum for no reason!

[Martin Frb via lazarus]

On 05/06/2022 05:59, Derek John Evans via lazarus wrote:
My only feeling atm, is wtf. I just posted details on a project I've 
worked on for the last 6 months using Lazarus and pas2js on a farm 
environment, and then was banned!


Like really! In the past I've been an active contributor to helping 
people find solutions to their problems. And, yet, I post one message 
about a project I'm proud off, and I thanked the Lazarus/Freepascal 
team for their work, and I'm banned!


This is amazing selfishness on the part of the Lazarus team. I'm just 
shocked by the attitude of a forum moderator.


Wow. Ok. Anyway. I'm still thankful for the efforts of many talented 
coders whom made Lazarus a reality, but wow.


But, no words can express this insult.



I had a quick look, the moderator in question will likely only be online 
tonight (i.e. night-time in utc).


The post itself is gone unfortunately. So I can not judge why this 
happened. (Mind sending me a copy in the meantime?)



-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus Release 2.2.2

[Martin Frb via lazarus]

On 20/05/2022 11:47, Salvatore Coppola via lazarus wrote:

It seems that the list of changes is for 2.2.0

Ottieni BlueMail per Android 
Il giorno 19 Mag 2022, alle ore 09:21, Mattias Gaertner via lazarus 
 ha scritto:


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



2.2.2 is a "FIXES" release based on 2.2.0

So it has no new features over 2.2.0. Only bug fixes.

The "Release Notes" page are the feature announcement (and that hasn't 
changed)

Below that is the link to what was fixed.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debug Adaptor Protocol support

[Martin Frb via lazarus]

On 23/04/2022 13:00, Michael Van Canneyt via lazarus wrote:


Hello,

If memory serves me well, some time ago, the Debug Adaptor Protocol 
support was mentioned, I think in the context of fpDebug.


For pas2js, it would be beneficial to have DAP support in the IDE, as it
would allow to debug the pas2js programs from within Lazarus.

So, is my memory correct - is there a plan to support DAP ?


Joost has implemented a package for that: 
https://forum.lazarus.freepascal.org/index.php/topic,57737.0.html

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Adding unit automatically adds to uses clause

[Martin Frb via lazarus]

On 26/03/2022 18:00, Timothy Groves via lazarus wrote:
Good day.  When I click on "New Pascal Unit" on the toolbar, or select 
it from the menu, the new unit is automatically added to the uses 
clause of my main program.  Worse, the new unit is invariably added as 
"unit1", even after I change the name of the unit.  I cannot seem to 
find a way to suppress this behaviour. Can anyone tell me how to stop 
Lazarus from doing this?



I am not aware how to entirely to disable this.

About renaming.
If you do "Save Unit as" and enter a new name, then it should rename the 
unit in other units "uses" clauses.


IMHO, I consider it a bug that it does not update other units, if you 
change the name in source code before you save the unit for the very 
first time.


Obviously, once you saved the unit, you must do "save as" to rename it. 
Otherwise the name in the source, and the filename will not match.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] will fixes_2_2 be merged to trunk before next release?

[Martin Frb via lazarus]

Note:
- My below reply only answers part to the general workflow in git. (e.g. 
how we merge and release, etc).
- I am not working on the QT related parts of Lazarus. Therefore I can 
not give any answers on the specific plans for QT.


On 22/03/2022 12:09, John Landmesser via lazarus wrote:

Am 22.03.22 um 01:52 schrieb Martin Frb via lazarus:

Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:

I would like to know if the fixes for lazarus 2.2 will be merged to
trunk before next release? 

I don't know much about that particular issue, but from what I read:
There are no fixes in 2.2 that could be merged.


Your answer would fit to the answer  Alexey Torgashin gave me to my
question with title
"[Lazarus] IDE qt5 compile error" from  14.03.2022 18;15


Ok, that was a different mail thread, which I hadn't seen/read.


I am thinking about which is the base for next lazarus release if
fixes_2_2 is NOT merged back to main development branch.


- "next release" => "next major release" = "2.4" (NOT: "next (minor) 
release" = "2.2.2")
- The base for Lazarus 2.4 will be whatever is in the current git "main" 
branch.


**AFAIK** (with regards to this QT issue) => As I said:
=> "fixes_2_2" does not contain anything that can be merged to fix your 
issue.

-  Something new (like a new feature) was added to "main" (aka trunk)
-  It was never added to "fixes_2_2"

So "fixes_2_2" does not have anything to "fix" your issue.
Rather "fixes_2_2" does not have the feature that doesn't work for you.

If you can't install (build yourself) the dependencies for that new 
feature, then your options are:
- wait for the dependencies to become available (as installable package 
/ as part of some installer)

- use "fixes_2_2"
- use "main", but revert (undo) the changes (aka: "the addition of the 
feature")
   => of course, over time that means to also revert/undo any 
change/addition that requires the new code



On 21/03/2022 11:49, John Landmesser via lazarus wrote:

I would like to know if the fixes for lazarus 2.2 will be merged to
trunk before next release?

And yes: i have a very poor knowledge about release models with git :-(


For the "release model", we use git (i.e., branches in git) exactly as 
we used branches in svn before.


- In SVN we had "trunk"   => Now, in GIT we have "main"
- In SVN we had "fixes_*_*" => Now, in GIT we have "fixes_*_*"

The only changes between how we use branches in GIT vs SVN is
- increased use of "feature branches" (we did once or twice in SVN)
- use of "merge-request branches"
Neither affects release management.
That is any  "feature branches" or "merge-request branches" eventually 
become part of "main" (or sometimes part of "fixes_*_*").
Before that, they don't account towards any future release. But once 
they are part of "main" (or "fixes"), they are simply seen as part of 
that branch.


For future releases, we have the same branches as we had in svn.
Exactly as we used to do with SVN, we now do in GIT:
=> New code goes into "main".
 - "Feature":   If it is a feature, then it goes to "main" only.
       It may get further changes, fixes, even part-undo And it 
will go into the next major release.
       (In rare cases, features that are not ready when the next major 
release happens, can be undone in the next "fixes" branch (i.e. for 
"2.4" that would be "fixes_2_4" once that has been branched).
 - "Bug-Fix":   If it is a bug-fix, then it will/should be merged to 
the fixes-branch.

      That is if the bug exists in the current "fixes" branch
=> Sometimes a bug only exists in "fixes":
  That is, something got broken in "fixes", but it was not broken in 
"main". Maybe a bug-fix that was merged had a side effect causing such a 
bug.
  Then the "code to fix this" will go directly into the "fixes" branch. 
And only there.

=> Sometimes an individual developer works in "reverse":
  That is, if there is a *bug* in "main" and in "fixes":
     - the developer adds his fix first in the "fixes" branch
     - then merges it to "main"
       (again, that actually also happened in SVN / IIRC, I haven't yet 
seen it happening in GIT)


**The issue you mentioned** belongs to (and only to):
"    => New code goes into "main".  "
"       - "Feature":    "

If you build your own IDE from a "cloned " git repo, then you can use 
"git revert" https://git-scm.com/docs/git-revert to undo any changes you 
don't want in your build.

- I do not know which commits that are
- you would need to learn more about git, if you want to keep updating 
after the revert





--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] will fixes_2_2 be merged to trunk before next release?

[Martin Frb via lazarus]

On 21/03/2022 17:32, John Landmesser via lazarus wrote:

Am 21.03.22 um 11:49 schrieb John Landmesser via lazarus:

I had an issue with qt5pas that was fixed in lazarus fixes_2_2.

Because i now use:

Lazarus 2.3.0 (rev main-2_3-996-ga94312373c) FPC 3.2.2 x86_64-linux-gtk2

I would like to know if the fixes for lazarus 2.2 will be merged to
trunk before next release?


I don't know much about that particular issue, but from what I read: 
There are no fixes in 2.2 that could be merged.


- 2.2 uses old code that works with the dependencies you have installed

- 2.3 has newer code and needs newer dependencies.
  On the issues it says, you may have to build them yourself. (I have 
no idea, when they will be avail pre-compiled)





Allready closed issue:

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



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] compile error for LazDebuggerGdbmi 0.1

[Martin Frb via lazarus]

On 01/02/2022 19:27, John Landmesser via lazarus wrote:

details:


Kompiliere Package LazDebuggerGdbmi 0.1: Exit code 1, Fehler: 1
gdbmidebugger.pp(14625,3) Error: Control flow statements are not
allowed in a finally block




Oh, well. The things FPC only supports on selected targets...

Please upgrade and try again.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] 867d12b4 breaks compilation on x86_64-linux Attn: Martin

[Martin Frb via lazarus]

Strange.
I have to check the Makefiles again. I thought the IDE had updated them.

Btw that revision has a 2nd bug, the 2nd bug is fixed in 947030b575f (I 
had some local defines enabled, so the 2nd bug did not trigger here)



On 25/01/2022 22:20, Marcus Sackrow via lazarus wrote:


Hi,


The commit  867d12b4 breaks the compilation at least on x86_64-linux

https://build.alb42.de:8081/job/LCL_off_x86_64-linux/9916/console


(3104) Compiling debuggertreeview.pas
/var/lib/jenkins/workspace/LCL_off_x86_64-linux/ide/packages/idedebugger/debuggertreeview.pas(8,22)
 Fatal: (10022) Can't find unit laz.VirtualTrees used by DebuggerTreeView
Fatal: (1018) Compilation aborted
make[1]: *** [Makefile:3294: idedebuggerpackage.ppu] Error 1
make[1]: Leaving directory 
'/var/lib/jenkins/workspace/LCL_off_x86_64-linux/ide/packages/idedebugger'
make: *** [Makefile:3764: lazbuild] Error 2


Could you please look into that?


Thanks.


Greetings,

Marcus



-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Lazarus compilation fail since 6d0ddd50bd2a76bb37830f068afe5828f4b06576

[Martin Frb via lazarus]

On 10/01/2022 23:08, Marcus Sackrow via lazarus wrote:


Hi,


my Jenkins compilation server fails since 
6d0ddd50bd2a76bb37830f068afe5828f4b06576


but the error message is a bit strange, anyone can explain it?



please git pull, and try again.

Somehow a file was generated with the wrong up/lower casing. Worked fine 
testing on windows.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Faster than popcnt [[Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]

[Martin Frb via lazarus]

On 30/12/2021 14:43, Marco van de Voort via lazarus wrote:
Compile with -O4 -Cpcoreavx2 , the others (non asm) will become 
faster, my guess is  "add" will be about double of asm.


Core I7 8700K

3.3.1 from Dec 10th
3.2.3 from Dec 9th

With fpc 3.3.1:
- fst is worse?
- add gets better

-O4 -Cpcoreavx2

fpc 3.2.3 /   fpc 3.3.1

fst 594   fst 688
fst 578   fst 703
fst 578   fst 687
fst 562   fst 688

pop 485   pop 485
pop 500   pop 500
pop 500   pop 484
pop 484   pop 500

add 594   add 422
add 578   add 438
add 578   add 437
add 594   add 453

asm 250   asm 250
asm 250   asm 250
asm 250   asm 250
asm 250   asm 266



fpc 3.2.3
-O4 -Cpcoreavx   -O4 -CpCOREI

fst 594  fst 593
fst 578  fst 579
fst 578  fst 562
fst 594  fst 578

pop 500  pop 500
pop 515  pop 500
pop 500  pop 500
pop 485  pop 485

add 593  add 593
add 579  add 578
add 578  add 594
add 593  add 594

asm 250  asm 250
asm 250  asm 250
asm 235  asm 250
asm 250  asm 250


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Faster than popcnt [[Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]

[Martin Frb via lazarus]

On 29/12/2021 13:42, Marco van de Voort via lazarus wrote:


On 29-12-2021 10:16, Martin Frb via lazarus wrote:


// Martin's routine that should be replaced by some punpkl magic, 
but it is too late now.


Why too late?


See datetime stamp.  02:10 AM. I don't know how it is with you Lazarus 
devels, but we FPC devels need our beauty sleep from time to time.

Oh, too late for the day.
I thought. Too late, that ship has sailed.




Could you post full source if you haven't already? For a bit of 
benchmarking. I just wrote it from the top of my head, and I assumed 5 
instructions for 16-byte would win any time, but haven't verified 
anything yet.
I had it attached on my last mail. Attached it again here. (3rd 
procedure / "Utf8LengthAdd")


It is only 64bit for now. (And not cleaned up in any way).

Also changing "bc >> 7" and "bc and 127"
to "moddiv(bc, 255, full, remain)" might save a few more ms. But 
probably needs larger data to benchmark.



If you do work on this, feel free to integrate my code as the baseline 
for cpu without SSE.

Otherwise, it might be a bit until I get to it.


Project1.pas
Description: application/unknown-content-type
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Faster than popcnt [[Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]

[Martin Frb via lazarus]

On 29/12/2021 02:10, Marco van de Voort via lazarus wrote:


On 28-12-2021 23:35, Martin Frb via lazarus wrote:



"nx" has a single "1" in each of the 8 bytes in a Qword (based on 
64bit).
If we regard each of this bytes as an entity of its own, then we can 
keep adding those "1".


I also was thinking in that direction, but more about how to optimize 
that loop using SSE2

good idea...



// Martin's routine that should be replaced by some punpkl magic, but 
it is too late now.


Why too late?

There is a place for both. My routine works fine for cpu. (soon as a 32 
bit (and maybe 16 bit) variant are added).


Then for known cpu, special handling can be added.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] fpc bug with M1 [[was: Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]

[Martin Frb via lazarus]

On 28/12/2021 23:18, Noel Duffy via lazarus wrote:


The assembler produced by 3.2.2 looks like this:

# [43] Result += (pn8^ shr 7) and ((not pn8^) shr 6);
ldr    x0,[sp]
ldrsb    w0,[x0]
mvn    w0,w0


mvn => bitwise not. And that applies to the whole register.

So I guess "eor    w0,w0,#255 " is meant to be some optimization, but 
comes with a bug.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Faster than popcnt [[Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]

[Martin Frb via lazarus]

On 28/12/2021 15:50, Bart via lazarus wrote:

On Tue, Dec 28, 2021 at 3:39 PM Marco van de Voort via lazarus
 wrote:


On what machine did you test? The settings if for the generated code,
but the actual processor determines the effective speed.

I have a Intel i5 7th generation on my Win10-64 laptop from approx.
2017 (so, it's really old for more modern folks than me).

Compiled for 32-bit:
With -CpCOREI
Unsigned version with multiplication: 1359
Unsigned version with PopCnt: 1282



I have a core I7-8600
The diff between the old code and popcnt is less significant.

old: 715
pop: 695

But there is a 3rd way, that is faster.
add: 610

"nx" has a single "1" in each of the 8 bytes in a Qword (based on 64bit).
If we regard each of this bytes as an entity of its own, then we can 
keep adding those "1".


We could add the 1 of up to 255 iteration, before an overflow can happen.
The example only does 128, as this avoids the "div" and "mod" operations.

The full routine / incl benchmark for all 3 versions is attached

For 64 bit:

  bc := (ByteCount-cnt) div sizeof(PtrInt);
  for j := 1 to bc >> 7 do begin
    nx := 0;
    for i := 0 to 127 do
    begin
  // Count bytes which are NOT the first byte of a character.
  nx += ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
  inc(pnx);
    end;
    nx := (nx and $00FF00FF00FF00FF) + ((nx >>  8) and $00FF00FF00FF00FF);
    nx := (nx and $) + ((nx >> 16) and $);
    nx := (nx and $) + ((nx >> 32) and $);
    Result := Result + nx;
  end;


  if (bc and 127) > 0 then begin
  nx := 0;
  for i := 1 to bc and 127 do
  begin
    // Count bytes which are NOT the first byte of a character.
    nx += ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
    inc(pnx);
  end;
    nx := (nx and $00FF00FF00FF00FF) + ((nx >>  8) and $00FF00FF00FF00FF);
    nx := (nx and $) + ((nx >> 16) and $);
    nx := (nx and $) + ((nx >> 32) and $);
    Result := Result + nx;
  end;

program Project1;
{$mode objfpc}{$H+}

uses SysUtils;

function UTF8LengthFast(p: PChar; ByteCount: PtrInt): PtrInt;
const
{$ifdef CPU32}
  ONEMASK   =$01010101;
  EIGHTYMASK=$80808080;
{$endif}
{$ifdef CPU64}
  ONEMASK   =$0101010101010101;
  EIGHTYMASK=$8080808080808080;
{$endif}
var
  pnx: PPtrInt absolute p; // To get contents of text in PtrInt blocks. x 
refers to 32 or 64 bits
  pn8: pint8 absolute pnx; // To read text as Int8 in the initial and final 
loops
  ix: PtrInt absolute pnx; // To read text as PtrInt in the block loop
  nx: PtrInt;  // values processed in block loop
  i,cnt,e: PtrInt;
begin
  Result := 0;
  e := ix+ByteCount; // End marker
  // Handle any initial misaligned bytes.
  cnt := (not (ix-1)) and (sizeof(PtrInt)-1);
  if cnt>ByteCount then
cnt := ByteCount;
  for i := 1 to cnt do
  begin
// Is this byte NOT the first byte of a character?
Result += (pn8^ shr 7) and ((not pn8^) shr 6);
inc(pn8);
  end;
  // Handle complete blocks
  for i := 1 to (ByteCount-cnt) div sizeof(PtrInt) do
  begin
// Count bytes which are NOT the first byte of a character.
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
{$push}{$overflowchecks off} // "nx * ONEMASK" causes an arithmetic 
overflow.
Result += (nx * ONEMASK) >> ((sizeof(PtrInt) - 1) * 8);
{$pop}
inc(pnx);
  end;
  // Take care of any left-over bytes.
  while ixByteCount then
cnt := ByteCount;
  for i := 1 to cnt do
  begin
// Is this byte NOT the first byte of a character?
Result += (pn8^ shr 7) and ((not pn8^) shr 6);
inc(pn8);
  end;
  // Handle complete blocks
  for i := 1 to (ByteCount-cnt) div sizeof(PtrInt) do
  begin
// Count bytes which are NOT the first byte of a character.
nx := ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
{$push}{$overflowchecks off} // "nx * ONEMASK" causes an arithmetic 
overflow.
//Result += (nx * ONEMASK) >> ((sizeof(PtrInt) - 1) * 8);
Result += PopCnt(qword(nx));
{$pop}
inc(pnx);
  end;
  // Take care of any left-over bytes.
  while ixByteCount then
cnt := ByteCount;
  for i := 1 to cnt do
  begin
// Is this byte NOT the first byte of a character?
Result += (pn8^ shr 7) and ((not pn8^) shr 6);
inc(pn8);
  end;
  // Handle complete blocks

  bc := (ByteCount-cnt) div sizeof(PtrInt);
  for j := 1 to bc >> 7 do begin
nx := 0;
for i := 0 to 127 do
begin
  // Count bytes which are NOT the first byte of a character.
  nx += ((pnx^ and EIGHTYMASK) shr 7) and ((not pnx^) shr 6);
  inc(pnx);
end;
nx := (nx and $00FF00FF00FF00FF) + ((nx >>  8) and $00FF00FF00FF00FF);
nx := (nx and $) + ((nx >> 16) and $);
nx := (nx and $) + ((nx >> 32) and $);
Result := Result + nx;
  end;


  if (bc and 127) > 0 then begin
  nx := 0;
  for i := 1 to bc 

[Lazarus] fpc bug with M1 [[was: Re: UTF8LengthFast returning incorrect results on AARCH64 (MacOS)]]

[Martin Frb via lazarus]

On 28/12/2021 22:05, Noel Duffy via lazarus wrote:

On 29/12/21 01:26, Bart via lazarus wrote:

fpc -al ulen.pas


> This will produce the file ulen.s
> You can attach or copy that here.

File is attached.


Thanks.
And I think there is a bug in FPC

This is the signed version

# [43] Result += (pn8^ shr 7) and ((not pn8^) shr 6);
    ldr    x0,[sp]
    ldrsb    w0,[x0] # < sign extend to a 32bit value 
(32bit register).
    eor    w0,w0,#255   # < But only "not" the lowest 8 bit. That 
is wrong. The calculation uses 32 bit at this point

    lsr    w0,w0,#6
    ldr    x2,[sp]
    ldrsb    w2,[x2]
    lsr    w2,w2,#7
    and    w0,w2,w0    # << here the full 32 bit are used.


Had the full 32 bits been "not"ed, the the upper 24 bit where 0 (because 
they had been sign extended to 1).

This would mask all the 1, that were sign extended in w2.

Had the char been < 128 (high bit = 0), then w0 would have the upper 24 
bit = 1 / but w2 would have them 0.


And that is why the code worked, even with signed values. (signed values 
were still a bad idea)




--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] UTF8LengthFast returning incorrect results on AARCH64 (MacOS)

[Martin Frb via lazarus]

On 28/12/2021 11:52, Juha Manninen via lazarus wrote:
On Tue, Dec 28, 2021 at 3:29 AM Noel Duffy via lazarus 
 wrote:


So it appears to me that an unsigned pointer type is required in
UTFLengthFast.


Can you please create a patch for UTFLengthFast. You can upload it 
here or create a merge request in GitLab or anything.




I would like to see the generates assembler on M1, if that is possible?  
(for code with optimization off, as well as code with whatever 
optimization was used so far)

Thanks

None the less, switching to "puint8" might be a good idea.-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Making fpdebug more cross-platform friendly

[Martin Frb via lazarus]

Ok, for now limiting this to a smaller audience, to get some 
brainstorming done.

=> Original mail at the bottom.

Some initial thoughts.

*** First, I would suggest, that all calls go to T[Foo]DbgProccess ***
T[Foo]DbgProccess can then forward them.
Outside classes should not have knowledge, nor access to the delegates.
(Better start restricted, so we have more flexibility for future changes)

--

I can currently see the following areas, that could be separated as needed.

API:  Calls to the OS => start/stop/mem-access/register/access
ABI:  Conventions about register usage, and stack layout
    (registers are known by either name or dwarf-index)
CPU: Identifying specific asm instructions  (Breakpoint / ret / call )

IHMO:
- API remains hardcoded in T[Foo]DbgProccess.
- The others are private delegate classes.


- Your idea about WOW64_CONTEXT / _ARM64_NT_CONTEXT is imho API.
   It can not be CPU or ABI. If it were, we would need to subclass them 
for each API.
- Identifying breakpoint is CPU (not necessarily the current asm class / 
could be a new class)
- unwinding stack => could be either. (there may be an API of the OS, 
otherwise ABI, maybe with help of CPU)


Only, question is, if we need the ABI?
- Do win64 and linux64 share the same ABI? (or win32 <> linux32)?
  Afaik SEH is win specific (and probably would be best of in the ABI?).
  But there could still be a base class that is shared between Win/Linux.

Similar about ABI vs CPU.
Only here we definitely have a shared base class for inter 32/64bit 
(currently it's only one class / no subclasses for the bitness).

So IMHO there is a point in splitting them.

---
Mind that, FPC specific units could provide specialized sub-classes of 
any of the delegate classes.

E.g. dealing with $fin$MyProcedure subroutines. (Win-SEH)
For some purposes, finally blocks need to look like they are part of the 
main-procedure, not sub-routines of their own.


---

With the above some of the issues can be solved by combining different 
subclasses of each.


And then we would end up with combinations like this:
(I am not sure, if the ABI for Win and Linux are actually different..., 
but there would be win-seh)


TDbgWinProcess with:    x64-win ABI /  x64 CPU
TDbgWinProcess with:    i386-win-ABI    /  x32 CPU
TDbgWinProcess with:    arm-ABI    /  arm CPU
TDbgLinuxProcess with:    x64-linux-ABI    /  x64 CPU
TDbgLinuxProcess with:    i386-linux-ABI    /  x32 CPU
...

There is potential for some re-usable code there.

Since all access would be through T[Foo]DbgProccess code can be moved 
gradually.


---

However, setting Breakpoints for example may be a bit more complex.
For example:
- if there is a limit to the amount, or only certain locations can be set.
- If breakpoints are not set to memory, but like watchpoints on intel.

In those cases, it needs to be decided how much power to give to the CPU 
class.


Should the CPU class be able to make calls to read/write mem and/or 
change registers?
(That is the point, where it would be a separate class from the asm 
class, which at most reads mem)


Even, if the CPU class can handle it all by itself, it may still end up 
needing support in the main class (T[Foo]DbgProccess).
- There can be errors due to restrictions (user watch points have been 
set to the register needed for the breakpoint).
- There may be different requirement on the relative timing of those 
actions and other actions outside the CPU class.
  Those timings are not known by the CPU class. So we end up with a 
tighter coupling than desired.


--

Comments?
Ideas?





On 16/12/2021 12:10, Christo Crause via lazarus wrote:
Currently there are a few instances where x86 specific 
assumptions/code are used [1] in what I consider as the target 
agnostic level of fpdebug.  My proposal is to move these instances to 
a hardware target specific unit so that these target specific handling 
is clearly separated.  One location for the target specific code is 
perhaps the fpdbgdisas* units, since it already provides a number of 
hardware specific concepts such as identifying call & return 
instructions and some stack frame analysis.  Adding for example 
IsSoftwareBreakInstruction seems like a logical addition.


These changes are hindering some functionality on AVR and Xtensa 
targets, e.g. some instructions are incorrectly disassembled because 
they start with $CC, which is incorrectly  interpreted as a software 
break.  Also the StepOut functionality currently assumes the x86 ABI 
to locate the return address, which obviously fails for other targets. 
While these methods could in principle be hidden by new target 
specific overrides, it is not aligned with proper OOP principles.  I 
will start with some concepts to address these soon.


Similarly, but possibly a bit more tricky, is to separate the OS code 
from the OS view of the hardware.  This would imply for example that 
the register handling in fpdbglinuxclasses needs to be 

Re: [Lazarus] Making fpdebug more cross-platform friendly

[Martin Frb via lazarus]

On 16/12/2021 12:10, Christo Crause via lazarus wrote:
  One location for the target specific code is perhaps the fpdbgdisas* 
units, since it already provides a number of hardware specific 
concepts such as identifying call & return instructions and some stack 
frame analysis.  Adding for example IsSoftwareBreakInstruction seems 
like a logical addition.

The current Frame-analysis is not really in good shape.

It is more likely that the central entry point for hardware and/or OS 
specifics will be the subclassed TDbgProcess (or potentially in some 
cases the subclassed Thread, but I can't think of a case for that).
The process class can then decide to use the asm class, or have other 
means...


Dividing this between hardware and OS will be a story of its own.



These changes are hindering some functionality on AVR and Xtensa 
targets, e.g. some instructions are incorrectly disassembled because 
they start with $CC, which is incorrectly  interpreted as a software 
break.

So that needs to be controlled by the process class then.


Also the StepOut functionality currently assumes the x86 ABI to locate 
the return address, which obviously fails for other targets.  While 
these methods could in principle be hidden by new target specific 
overrides, it is not aligned with proper OOP principles.  I will start 
with some concepts to address these soon.


Probably there will be some need for delegate classes

Btw, this is a big one, and I have some todo on this too.
Currently the entire handling of win SEH is in LazDebuggerFp => that 
should move. But it needs exactly the above ability of having target 
specific functions.
Even one step further: => those are not even default for win, because 
they assume fpc generated code [1]. So they need to be added, similar 
like the fpc additions for dwarf (separate unit, with detection of 
compiler)


So it's likely they will undergo a big rework.

[1] They should be fixed to be generic.



Similarly, but possibly a bit more tricky, is to separate the OS code 
from the OS view of the hardware.  This would imply for example that 
the register handling in fpdbglinuxclasses needs to be separated from 
the rest of the code so that one could re-use the Linux layer, but 
swap out the hardware specific layer x86_Linux.  Similarly for 
Windows, the WOW64_CONTEXT could be part of an x86_Windows unit, so 
that it is possible to also define and use _ARM64_NT_CONTEXT for 
Windows on ARM64.




[1] Examples of x86 specific code not in a x86 specific unit
fpdbgclasses.pas: checking for int3 and its x86 encoding in 
TDbgProcess, TDbgThread and TBreakLocationMap


The above will probably best go into a delegation class. But the extend 
needs to be evaluated.
The first 2 actually should allow to override (so that is not the 
desired solution)...


fpdbgcontroller.pas: TDbgControllerCallRoutineCmd uses x86 call 
specific encoding in InsertCallInstructionCode and 
RestoreInstructionPointer, StoreRoutineResult using x86 register 
specific assumptions,
TDbgControllerStepOutCmd.SetReturnAdressBreakpoint assumes return 
address is stored according to x86 stack frame layout.

As I said, there will have to be a big rework.
Until then, quickfix it by overriding it in the backend (like 
LazDebuggerFp does).



More later

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Source file license

[Martin Frb via lazarus]

On 15/12/2021 12:53, Juha Manninen via lazarus wrote:
On Wed, Dec 15, 2021 at 12:57 PM Dimitrios Chr. Ioannidis via lazarus 
 wrote:


what licenses are accepted by the Lazarus project ?
   MIT ? GPL v2 ? GPL v3 ?


The Lazarus IDE itself is GPL v2. Most packages are LGPL v2.
If your utility is to be installed into the IDE, LGPL v2 is the best.
Executables outside the IDE can have other licenses but GPL or LGPL is 
still recommended.



IMHO:

It is also acceptable to have a "mixed license". E.g.
   Licensed [L]GPL 2 [OR: "2 or later"] or MIT at the users choice.
   Anyone using/modifying this code must keep at least either one of 
the two Licenses, but is free to remove the other.


We inherited a case like this in SynEdit. You can check there how 
exactly it is described.


-
As Juha said:
- If it is an IDE plugin, to be compiled into the IDE
- and to be included in our repo / shipped with the installer
then it should really include/be [L]GPL at least including version 2.

If it is to be run from the IDE, lazbuild, our makefiles, or the like, 
then it should be permissive enough not to burden us with displaying 
special notes.
Of course a mention in the "about" dialog can be required. (not sure if 
Lazbuild currently has any provisions to print such things as 
"attribution notes".


-
As with all things that evolve over time, we already have to many 
Licenses, on different parts of the code.


This imposes extra work on users, who have to check what the can use in 
their projects.
By including [L]GPL 2 (with/without the LCL linking permission) a common 
base would be kept.

Additional/Optional Licenses should be no issue.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] FpDebug with aarch64-linux

[Martin Frb via lazarus]

On 06/12/2021 17:17, Gabor Boros via lazarus wrote:

Hi All,

FPC 3.3.1, Lazarus fixes_2_2, LazDebuggerFp installed and configured 
in Tools/Options.

If start the project got "Error starting process in debugger".
With gdb works as expected. Is FpDebug not supported on aarch64?



FpDebug only supports Intel/AMD 32/64 bit.

There is an remote "avr" extension (included, but must be installed), 
contributed (and currently worked on) by C. Crause.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Moved to DEV list // Re: TFrame improvements

[Martin Frb via lazarus]

On 30/11/2021 11:18, Juha Manninen via lazarus wrote:


Yes, at runtime it works on both a Form and a Frame.
At design time it works on a Form but crashes on a Frame which is 
clearly a bug. Agree?



No, at runtime it crashes too.

Of course, if you take the attached zip, you will not see this.

Because the Frame is not actually used in TForm1 => so at run time the 
frame is never loaded.


If you manage to get the frame on form1 then it crashes too.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 30/11/2021 00:27, Juha Manninen via lazarus wrote:
On Mon, Nov 29, 2021 at 11:14 PM Ondrej Pokorny via lazarus 
 wrote:


On 29.11.2021 17:18, Juha Manninen via lazarus wrote:

The commit message is not perfect but the committed code is, now
that I fully understand the issue.


That is nonsense. I reverted your change. The code user code is
just plain wrong and your change in TFrame doesn't change anything
about it.

No, the code is valid although not recommended. Accessing Canvas 
outside Paint works with some widgetsets and then an exception is wrong.




There are 2 (or 3) question.

1) Is the fix correct: Yes (if 2 or 3), otherwise "not applicable"

2) Is it a bug in first? (and therefore is a fix needed): No.
No (at least if it is at runtime) it is not a bug, because it is by 
design that a frame needs a form as parent.


3) Before the patch, ignoring the design time issues => did it work at 
runtime? (And is it indented to?)
When (without the patch) the stream is read at runtime, and the frame is 
embedded in a Form, does the example code then work?
Basically, will at runtime the parent be set, before any properties are 
loaded?

(Or, Is that documented that it should?)

=> *If* this works at runtime (and if this is by intention), then there 
is a bug in the designer, in that the designer fails to set the parent 
(parent = designer) in time.


I have not tested the example from the bug. But I did a quick debug of a 
TFrame being loaded, at runtime:
- The TFrame is loading twice from lfm (the frames own lfm, and the 
changeds stored in the form)

-- the first loading, there is no parent set => so it would/could fail.
-- the 2nd loading, there is a parent

The exact "expected" (not tested) behaviour for the app from the bug 
would be:
- If the offending property has a default, and is not changed from the 
default => all good, property is not set during TReader
- If the default is changed in the Frame's lfm => crash, because the 
property is set, when there is no parent.
- if the default is only changed for the frame's instance on the form 
(stored in the form's lfm) => ok


So IMHO it is save to say, that this is not supported at runtime either.
Should it be? IMHO not, see below.

---
This leaves improving the designer, to add a better error message, and 
handle it more gracefully.



---

Otherwise Ondrej is right that code accessing the handle (and that 
includes canvas) must do checks.

And TFrame is not the only place were it this is needed.

  b := TPanel.Create(Form1);
  a := TGraphicControl.Create(b);

  //a.Parent := b;
  //b.Parent := Form1;

  a.Canvas.Line(1,1,2,2);

You must set both parents, or it crashes.
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 21:20, Ondrej Pokorny via lazarus wrote:


Check TCustomLabel.CalculateSize in lcl\include\customlabel.inc for 
the solution how to solve this problem correctly in the component's 
code without any modifications needed in T(Custom)Form or T(Custom)Frame.


There, the GetDC(0) is used for Canvas.Handle, so that the label's 
parent's handle doesn't need to be created.


That raises another question: Why does it need that before/unless it is 
visible?


Does autosize run, for non-visible components?
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 17:18, Juha Manninen via lazarus wrote:


It allows a Frame to stand without a parent in the designer or even at 
runtime in some hypothetical situation(?).
Using Canvas outside Paint may not be recommended but it can be done 
in some widgetsets. The component's duty is to not crash in designer 
or anywhere else when it happens.




I suspect in the Designer it does not stand alone => The designer is the 
parent. But I have not checked.


As for "at runtime" and "stand alone" (which at design time may not be 
possible, if the designer forces itself as parent).

Is that now possible. Has anyone tested?
Just because it can get a handle does not mean it will work if you try 
to make the handle visible.


If it does fine.

If it does not, then we have a new problem.
We now provide a canvas, and let the user believe they painted on it. 
But its invisible. And if in order to make it visible, a parent is 
required, then that means a new Handle.
So then we throw away the users work. (and the user will forever wonder 
way his output is not drawn)


So can a frame be visible shown standalone? And do we want to support 
that. (fix bugs on it, make it work for all widgetsets, )-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 12:31, Ondrej Pokorny via lazarus wrote:
I didn't study the issue further but to me it looks strange that 
setting some parameters in CreateParams helps with it. Juha, your 
commit description "Somehow fixes issue ..." doesn't help to 
understand your change either.


"Setting" is actually "removing" => removing "WS_Child" allows the frame 
to be created as a top-level window.


So before this, while the frame was created (and did not have a parent), 
that "buggy component" accessed the canvas. => Handle creation failed.
=> Now handle creation works. (note, that the handle is probably never 
"shown" , set to visible=true)


So that is why the patch "works"


Actually, come to think of it, maybe it be different.
=> it just allows a temporary handle (that will be thrown away without 
ever being visible), only to support buggy code, and that should not 
happen


Yet:
- Afaik/IIRC if read from stream as part of a form in runtime => the 
parent is already set (the form).

  So at runtime such buggy code would work
- If indeed so, the IDE would have to make sure, that the "designer" is 
already set as a parent, when reading the stream.


Well, that is:
I guess, when the frame is show stand alone in the IDE it has the 
designer as parent (not verified, but must have something, as it can be 
shown -- and until now it could not be shown as top level window).


Then again, setting the designer as parent for reading the stream, may 
not be trivial at all.

In which case we may go with the "dummy handle" but for designtime only.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 12:05, Michael Van Canneyt via lazarus wrote:


What do you mean 'artificial restrictions' ?  The above is quite 
standard.


IMHO  "if csLoading" tests are also "quite standard"

"If HandleCreated" exist too, not sure how widespread

"accessing canvas"  outside paint, is discouraged. Though other uses of 
the "Handle" may exist outside paint.

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 11:36, Michael Van Canneyt wrote:



On Mon, 29 Nov 2021, Martin Frb via lazarus wrote:


On 29/11/2021 10:52, Juha Manninen via lazarus wrote:

Please everybody test issue:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/25124
Some components caused an error when placed on a Frame. Now it 
apparently works.

Can somebody please explain why it works. (See my comment there).



From reading the issue, and a peak at the code:

- When the frame is read from stream, the property is triggered, as 
it should (and as on a Form.
- The property accesses "canvas" => that triggers asking for a handle 
(which is created based on CreateParams)


A form does not need a parent (it can have one, if it is embedded).
Therefore CreateParam for TForm checks this and removes flags such as 
WS_CHILD (not sure if WS_TABSTOP would cause an issue, but it makes 
no sense...)


A frame, at least at design time, can display without parent too. (I 
guess: it acts as if it is a TForm in that case).

=> So for that IMHO your patch is correct (for design time).

Yet a TFrame at runtime IMHO should always have a parent.
No idea, if there is other code, that relies on that
So maybe your patch should be extended, to only do that, if the 
control is in "designtime" state?
Though, not sure if it is worth it. While it would be correct to fail 
at runtime if there is no parent, it would not bring any benefit. If 
other code in TFrame needs the parent, then it will fail in the other 
code, if not then it will work.
The question is, do we commit to it may work, and then maybe have to 
fix more later? Otherwise it may want to even throw an exception, if 
it does not have a parent at runtime?


I often create a frame in code (so no parent) which is then placed on 
a form.


Will this scenario still work ?


Well, if your code works now, then apparently it does not access the 
handle/canvas before setting a parent?

Which also means, you do not "show" the frame, before it has a parent.

1)
With Juha's current patch: Yes. => Afaik this adds no restrictions.
=> Except, if you are waiting for an Exception, because you expect it to 
fail. ;)


2)
If we add a "if designtime" around Juhas code, still nothing changes for 
your code. Since then runtime behaviour would be exactly as it currently is.


3)
If we add
   If (not designtime) and (ParentWindow = nil) then raise Exception();
afaik still nothing changes (except for the error message).
Because currently, without Parent/ParentWindow it will fail to create 
the Handle (Actually, may need to be tested for all WidgetSets).



If your code creates a Frame that during its creation (reading from lfm, 
or calls by other code) triggers any component to access the canvas, or 
otherwise needing a handle,

then your code would fail already (without Juha's Patch).

With the current Patch, such an "canvas" access would create a handle 
(it might not make it visible, but it could even do that).
If that handle is created, and you set a Parent, then the handle would 
have to be discarded.


So unless a frame should be able to be visible shown at runtime as if it 
was a Form of itself, any handle created without parent is created to be 
discarded again.
Such a handle would only serve the purpose to allow incorrect code to 
"get away" (I.e. to draw text on an invisible canvas, that will never 
become visible).


Question is:
- Should that be allowed?
- Should components access the canvas in "csLoading", or "if not 
HandleCreated"  (unless they indent for the Handle to be created at that 
time, and therefore are aware if that is possible)



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] TFrame improvements

[Martin Frb via lazarus]

On 29/11/2021 10:52, Juha Manninen via lazarus wrote:

Please everybody test issue:
https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/25124
Some components caused an error when placed on a Frame. Now it 
apparently works.

Can somebody please explain why it works. (See my comment there).



From reading the issue, and a peak at the code:

- When the frame is read from stream, the property is triggered, as it 
should (and as on a Form.
- The property accesses "canvas" => that triggers asking for a handle 
(which is created based on CreateParams)


A form does not need a parent (it can have one, if it is embedded).
Therefore CreateParam for TForm checks this and removes flags such as 
WS_CHILD (not sure if WS_TABSTOP would cause an issue, but it makes no 
sense...)


A frame, at least at design time, can display without parent too. (I 
guess: it acts as if it is a TForm in that case).

=> So for that IMHO your patch is correct (for design time).

Yet a TFrame at runtime IMHO should always have a parent.
No idea, if there is other code, that relies on that
So maybe your patch should be extended, to only do that, if the control 
is in "designtime" state?
Though, not sure if it is worth it. While it would be correct to fail at 
runtime if there is no parent, it would not bring any benefit. If other 
code in TFrame needs the parent, then it will fail in the other code, if 
not then it will work.
The question is, do we commit to it may work, and then maybe have to fix 
more later? Otherwise it may want to even throw an exception, if it does 
not have a parent at runtime?

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugger stops in c dll even when no breakpoint set

[Martin Frb via lazarus]

On 24/11/2021 13:41, Luca Olivetti via lazarus wrote:

El 3/11/21 a les 15:56, Luca Olivetti via lazarus ha escrit:

A quick follow up: I used the wrong size when mallocing data (size of 
the pointer variable instead of the size of the struct it pointed to, 
d'oh!).
I found it by running the program under windbg and there I saw a 
message saying that I wrote to a memory area beyond the 4 bytes 
allocated. I wondered why 4 bytes when my struct is bigger and then I 
found the stupid error 
https://github.com/olivluca/fpopen62541/commit/e5ec2cab8e97eeeba29e33b801de6e42a0084ca8


I don't know where that message came from, but is there a way to see 
it while debugging the application under lazarus?


I would guess this is based on 
https://docs.microsoft.com/de-de/windows-hardware/drivers/debugger/gflags-and-pageheap


Now there are 2 modes: "standard" and "full"
Note: this is only about mem on the heap. Local vars on the stack are 
not affected (except, if (like objects) they are pointers to the heap, 
then the heap part (and only that) will be affected)


"Standard" only detects, overruns when mem is freed.
If I understand this correctly, in FPC you can enable -gh heaptrc, and 
this will do something similar, but limited...

This is hardcoded in HeapTrc
      { add a small footprint at the end of memory blocks, this
        can check for memory overwrites at the end of a block }
  add_tail : boolean = true;
      tail_size : longint = sizeof(ptruint);
Additionally 
https://www.freepascal.org/docs-html/rtl/heaptrc/keepreleased.html


On Linux, you can also use valgrind memcheck => which is excellent at 
finding stuff like this.


"Full" (if I read it correctly) will get a separate mem-page for every 
(m)alloc.

As the doc says, that will strain your sys mem
This want work with default FPC, because FPC does not use its own mem 
manager. Fpc gets a whole page, and splits it without windows knowing.
So you need to see if there is an alternative mem manager that would 
work (maybe CMEM?).


If there is a mem manager, that works with "FULL", then gdb and fpdebug 
should stop with an access violation.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] triggered by the frontend / Representation of an "watch" [[was: Re: Playing with debuggers]]

[Martin Frb via lazarus]

On 21/11/2021 17:23, Martin Frb via lazarus wrote:


- Watches are stored in a list.
That is needed by the frontend. Because the History wants to know 
about the watches.

However, this may not be needed by the backend. That can be reviewed.

Actually, there only is a list for the frontend.

It is currently part of the DbgIntf. But it should not be. And should be 
easily fixable.


The backend site has (through a forward handler) access to it.
The only use that is made of it, is to invalidate all watch values, if 
they changed (actually this is only used, if the user modified a watch).


The debugger should in that case send an event (or call an abstract 
method in the base class). This can then clear the values.


And the entire TWatches list can move up, into the current frontend.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] triggered by the frontend / Representation of an "watch" [[was: Re: Playing with debuggers]]

[Martin Frb via lazarus]

1) Events to be more frontend centric.
2) Actions (eval watch) to be triggered by the frontend
3) Representation of an "watch"  (Should methods be on the Watch 
object, or the Debugger object)


=> 2) Actions (eval watch) to be triggered by the frontend

The evaluation of a watch is triggered when the frontend attempts to 
access it. The backend then gets a call to

 TWatchesSupplier.InternalRequestData(AWatchValue: TWatchValue)
for that one watch.

For all I can see neither gdb, nor Fp backends will evaluate any watch, 
unless the frontend asks.



=> 3) Representation of an "watch"  (Should methods be on the Watch 
object, or the Debugger object)


You introduced a new method to get a watch value.
  Debugger.EvaluateExpression(S, Debugger.GetCurrentFrameID, 
FLatestRef, @EvaluateCallback)


and then in the callback the data is in an object: 
TLazDebugExtensionVariable
TLazDebugExtensionVariable has a reference, where the debugger can store 
any data it wants: integer or object



I am trying to see, what advantage this should bring over the current 
system:


* TIdeWatch / TCurrentWatch
  => those can nicely store all the data a frontend needs to store with 
the watch (any options the user did chose).
  => this also stores (as TWatchValue) the result returned from the 
debugger.

  => Each frontend can subclass it as it wants.
* The frontend decides when it wants the data. The backend then receives 
a single call for this/each watch.
* The backend then send a notification for the frontend, when the data 
is there.


Same flow? Main difference is that the methods to invoke the evaluation 
are on the TWatch.


--
So far so good.
- The TWatch class is currently quite big. It might benefit from some 
cut down, but that is not related to any of the things you implemented.


- An advantage is, that a watch eval can be aborted.
  Your concept is to discard unwanted results, but the backend still 
spends time on evaluating it. Of course you could add

 dbg.AbortEval(reference);
  In the end, I prefer to encapsulate this into the TWatch.

- Watches are stored in a list.
That is needed by the frontend. Because the History wants to know about 
the watches.

However, this may not be needed by the backend. That can be reviewed.

--
Collapsing / Expanding

Currently watches can only be added by the frontend. That may need to be 
changed.
Each watch needs a way to ask the debugger for the TWatchValue data of 
its children.

=> For that the Watch could call the backend
  dbg.GetChildren(self);
=>  The backend would then for each child call
  watch.GetChildWatch
and the backend would put the data in.

Something like that.

As for the TWatches list:
The watch window would know, which watches are visible (expanded) and 
evaluate them.
For the history, each watch could have a "parent" and/or 
"CurrentVisible" field. Or the watch has an "Owner" (the window), which 
can be asked.



On 14/09/2021 16:11, Joost van der Sluis via lazarus wrote:
The big advantage of the tree-view, is that you do not evaluate 
sub-watches, only when they have to be shown. So only those fields 
that need to be shown have to be evaluated by gdb. (It also solves the 
endless loop you sometimes have)
Well at latest when the debugger is idle, evaluation of watches "not 
scrolled in" should start.

So when the user starts scrolling, values can be shown immediately.






-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] Events to be more frontend centric [[was: Re: Playing with debuggers]]

[Martin Frb via lazarus]

1) Events to be more frontend centric.
2) Actions (eval watch) to be triggered by the frontend
3) Representation of an "watch"  (Should methods be on the Watch 
object, or the Debugger object)


=> 1) Events to be more frontend centric.

The current events and especially states are certainly in need of clean up.

I would not say that they are all backend centric.
States like: dsRun, dsPause, dsStop  are very valid and meaningful for 
the frontends too.


On the other hand states like
- dsDestroying is backend only, and should not be exposed.
- dsInit, dsInternalPause are not well defined at all.


Looking at your code, I do not agree with your new states.

  TLazExtEvaluationState = (
    esNone,  // No debugger available
    esEvaluationImpossible,  // Evaluation of variables is impossible 
(Maybe because there is nu debugee? (stopped))
    esEvaluationPaused,  // Evaluation of variables is temporarily 
disabled (Maybe because debugee is running?)
    esEvaluationPossible // Evaluation of variables is possible 
(Debugee is probably paused)

  );


1 - First of all,
The above are either
a- not enough
b- to many

a) There may be different extends of evaluation in the frontend. So more 
info than the above few states is needed.
=> Of course, the states may be sufficient, as further info could be 
maintained within the frontend.
* I quite often use breakpoints, that do not "break" (continue 
automatically), but take a history snapshot.
Currently when this happens the watch/stack/.. windows actually do 
update (and that is a workaround to missing options).

But ideally they should not. Only the history-snapshot should run.
* Or while viewing history => one can get existing values, but not 
evaluate new ones.


b) On the other hand, why differ between Paused and Impossible? They 
both mean "can't eval".
Your frontend may differ between the 2 reasons behind them. But other 
Frontends, relay on other factors.


After writing all the below, I realized that (probably) your frontend 
uses the 2 states to decide, if there should be a timeout before 
clearing the values?
But that is very specific to your frontend (well most frontends probably 
would benefit). But then this is just a duplication of the existing and 
further needed dsStop.


See idea on "CurrentCapacities" below.


2 - Second,
they already exist:
   WatchValue.Validity => ddsUnknown, ddsRequested, ddsEvaluating,  
ddsValid, ddsInvalid, ddsError

Though they are only set, once a value gets requested.
(Asking upfront, may be an idea, but one only need "function CanEval: 
boolean". / See idea on "CurrentCapacities" below.)


This falls partly under the topic (3) representation => should the state 
come via the watch or the debugger.


And then, if history is shown, there is no point of calling a function 
on the debugger. There is no data to be computed by the debugger.



3 - Third
Also, while your argument for a frontend-needs driven event system is 
compiling, we need to keep in mind, that the frontend (or plural 
frontends) may change/differ how they want to react to different backend 
states.
The backends can not actually know this. So the frontend still needs 
(most of) the DebuggerStates (dsPause, dsRun, dsStopped)


Yet, as mentioned above, (sub)states may need to be added for different 
"pause reasons".
This may be something (some/all) frontends can do on their own. But some 
may also belong into the backend. (Maybe such as, that the backend is 
going to continue the run/step)


If a breakpoint has "no break" or "auto-continue" (the latter differs 
from the first), then parts of the frontend may need to know.
This can to some extend be managed in the frontend itself, by examining 
the current breakpoint(s) [1].
But it can't be entirely taken from the backend, because if the backends 
state is "mid single step", then the frontend can not sent a "step over".
If maintaining some of the state info is moved to the frontend, this 
must avoid duplicating info that is bound to the backend. (to avoid them 
becoming out of sync).


[1] Btw, off topic, there may be more than one breakpoint on the same 
address, so there needs to be a list of breakpoints hit...



===> Going forward

It might be best to look at an actual list of new states and events.

- What do different parts of the frontend need to react to (events)?
  And can/should the backend(s) know about each of those "causes".

- What states are important, from a frontend/users view.
- What mapping, between abilities and state do we need, and where to 
compute them.



For example the debugger already has
    function  GetCommands: TDBGCommands; virtual; // property Commands
And this returns what is currently possible
    if dcEvaluate in Commands then {watches can be evaluated}
- Except, that may be returning wrong for dsInternalPause => so there is 
some fixing needed.

- The naming is bad, because its more than just commands. Maybe should be:
   ~ dcEvaluate in 

Re: [Lazarus] Playing with debuggers

[Martin Frb via lazarus]

On 14/09/2021 01:00, Joost van der Sluis via lazarus wrote:
I've created a new Lazarus-debugger LazDabDebugger that can work with 
FpdServer. It depends on a package (LazDebugExtensionIntf) that adds 
another way of showing debugging variables inside Lazarus.
I can write tons of texts about the background and possibilities. But 
for now I'm just curious at your input.


Ok, lets try to pick up on where we were.  / Going through the thread, 
picking out previous comments.


The main points seem to be:

1) Events to be more frontend centric.
2) Actions (eval watch) to be triggered by the frontend
3) Representation of an "watch"  (Should methods be on the Watch object, 
or the Debugger object)


I think, I will write individual mails on each of them.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Debugger stops in c dll even when no breakpoint set

[Martin Frb via lazarus]

On 28/10/2021 14:28, Christo Crause via lazarus wrote:


On Thu, Oct 28, 2021 at 2:01 PM Luca Olivetti via lazarus 
 wrote:



77045AC4 cc                       int3


The Int3 instruction means break, so this is the expected behaviour.  
If there is no debugger inserted break point for this location, it 
must be compiled into the dll code.  This means not stopping here will 
be problematic, unless you use some kind of script to step over this 
break instruction automatically.  I do not think it is possible from 
inside Lazarus, but haven't actually tried to work around something 
similar before.





FpDebug refers unknown "int3" back to the application, and lets the 
application handle them itself.


At least FpDebug does this by default. There is an option in the global 
settings to stop.
But if the dll expects the int3, and therefore wants to handle it 
itself.-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Command line program - CPU overused - do I need profiling?

[Martin Frb via lazarus]

On 04/10/2021 10:33, Bo Berglund via lazarus wrote:

Failed to post via Gmane so trying direct emailing instead:

I need to figure out why my program uses 10% CPU when it is essentially idle, 
waiting for a client connect via TCP or for the time for a new task start to 
arrive.
It is a command line program running as a service on Linux (Raspberry Pi4).
Developed on the RPi4 with Lazarus 2.0.12 and FPC 3.2.0

This is the main loop in the program following creatrion of the handler objects 
(which are idle):

   While not (bSTerm or bSInt or bsHup) do
   begin
 //Eternal loop to wait for system messages
 CheckSynchronize(5); //Timeout here instead of using sleep


I think "5" is too small a timeout. So this could keep your system busy. 
Even if it would be less than 10%, it will prevent your system from ever 
entering any idle/power saving state.


Ideally you should not need a timeout.
If any code (in a thread) sets any of the variables, it should sent a 
message to wake the CheckSyncronize.


If of course those vars are set in interrupts, then you can not send a 
wake up, because any work in interrupts is dangerous

In that case set the timeout to at least 50. Ideally even higher.

You can have any thread checking the vars, before they do any work (or 
even while the do work).

Threads can then abort, and send a wake up.
So a longer delay, would not mean any work being done in that time.
It would only mean the app shuts down a bit later.
IMHO in that a scenario, you could probably up the timeout to 100 or 
even 200 ms.
Well I don't know how urgent you need your app to exit or reload config, 
or...
(Assuming that no-one changes the config that should be loaded in that 
200ms, and no thread starts work on the old because they all check the 
flag then the delay should not hurt)


Also maybe there is a wait or select call, that would return if an 
interrupt was received. (IIRC select does that). Then your threads would 
have to use whatever you select on, in order to communicate with the 
main thread

--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Request for Gitlab access rights for Cocoa

[Martin Frb via lazarus]

On 29/09/2021 19:53, Alexey Tor. via lazarus wrote:


Thanks, here are 3 patches which I wanted to merge on start

1- TListItem.MakeVisible does not work on MacOS 



2- [Cocoa] TListView.GetItemAt returns wrong item when 
ShowColumnHeaders=true 



3- forum, patch by Zoe, Demo to benchmark TextOut on win64/gtk2/Cocoa 
- Cocoa is very slow 





If/Once they are in Dmitry's branch they will get merged.
My understanding (and that coincides with Dmitry's feedback yesterday) 
is that he is managing the Cocoa development.


From what I can see (issue comments) both issues have a fix in that 
branch. So they should get handled.


About the issue on the forum.
Forum posts get lost over time. And they do not always get noted by the 
core team member that could help.

Therefore
- if your/everyones intend is to wait for other forum members to help => 
all is fine.
- if you like the attention of a core team member, and currently no 
member has stated they are looking at it, you may have to reach out 
beyond the forum.
  Not all team members are all the time active on the forum. You may 
try to reach out on the mail list.


If you can't get anyones attention now, the report on the bugtracker, 
giving a link to the forum and a brief summary.

When and if a team member has time, they will have a look.
Notes about the nature of the post (proof of concept / only for testing 
/ intend to inspire) can be added on the forum and/or the issue.



-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Request for Gitlab access rights for Cocoa

[Martin Frb via lazarus]

On 28/09/2021 16:36, Alexey Tor. via lazarus wrote:

Hello. As you see on Gitlab comments:

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

Dmitry (Cocoa WS supporter) has no Gitlab rights and he wants to pass 
these rights to me - Gitlab account Alexey-T1. Please do so. Dmitry is 
busy and has no enough wish to talk here. But he continues his work in 
his public GitHUB fork.


Looking at the issue referred, this reads to me as "someone who will 
make individual merge requests of the work provided".


We (the team) are currently looking at the situation, and it looks like 
we found an internal solution to it, saving the extra step. Results of 
this should hopefully manifest in the coming days.


So thanks, but we think its easier if we can do it directly.
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] git diff enhancement

[Martin Frb via lazarus]

On 14/09/2021 21:28, Marco van de Voort via lazarus wrote:


Op 14-9-2021 om 17:55 schreef Martin Frb via lazarus:

On 14/09/2021 17:49, Marco van de Voort via lazarus wrote:


Op 14-9-2021 om 17:17 schreef Martin Frb via lazarus:

In order for git to show pascal function headers.

Add the following to your config

[diff "fpc"]
  xfuncname = "^(((class[ 
\\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ 


operator?



Yes, and you can also allow spaces at the begin of the line.

I did not, to try and get the outer procedure always. Because 
otherwise it finds nested procs, even if you are in the main body.




I meant "class operator" is also a method like declaration


yes,
When I wrote "Yes, and you can also allow spaces at the begin of the line."

The "yes" applied to "operator may be included too". And then I went on 
and talked about something else.
I do see, how this does not come across, if you don't have inside info 
from inside my head.



--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] Fpdebug merge request 6

[Martin Frb via lazarus]

On 05/09/2021 21:08, Martin Frb wrote:

On 05/09/2021 20:57, Christo Crause wrote:



1) adding to the IDE options. Looks that then every user using
fpdebug, will see options for host/port?
While really convenient for avr users, rather confusing for others?


I am starting to agree with this view. There are quite a few extra 
remote options that should eventually be implemented, so the IDE 
options will become more busy.  My simplistic view is that a new 
remote Lazarus debugger will inherit just about all its core 
functionality from the existing FpDebugDebugger, with added remote 
config options.

Ok, so on the topic of user config.

Step 1 is to decide, if  IDE-config  for avr debugging should be part of 
the generic FpDebug config.


At current, I see that as a remote debugger, and therefore would think 
it should be made a separate entry in the list of debuggers.
That would mean to subclass TFpDebugDebugger and add a new 
TFpRemoteDebugDebuggerProperties or TFpAvrDebugDebuggerProperties.


Of course, it may turn out in the future that the current config will 
get a bit of a mix. Lets say if support for Win on Arm would be added, 
and some options are arm/intel specific.
Or if some options are Windows/Linux specific. (Like loading debug 
symbols for Windows dll, that can be downloaded at MS / not planned by 
the way).


But I still think remote debugging is a step further. (To say, it could 
even be that we get an fpdebug remote / actually there also is Joost's 
DAB debugger)


Since it seems you agree, I will base below points on this



There are 2 ways here:

1) find a way to pass a custom config to whatever T[avr]DbgProcess.

2) Instantiate a process class, before starting the controller, and 
push that in.
That also has the advantage that it allows to choose between several 
process classes, if more than one can handle the target.


*** Option 1

Initially my thought was that once you have a TFpAvrDebugDebugger you 
could just instantiate the TDbgAvrProcess before starting the debugger, 
and pass the instance to the TDbgController.

Then you could set any config values to it, that you would want.

But the controller should keep control of calling either StartInstance 
or AttachToInstance => which currently call the constructor.


StartInstance/AttachToInstance  would become normal methods.
And the constructor would be called before them.

In that case you could
- create the instance of your TDbgAvrProcess outside of the controller,
- set host/port/... to the instance,
- and pass it to the controller before calling Run.

This also needs to ensure, that the OsDbgClasses are matching the instance
Some sample of how they can be set: 
https://gitlab.com/martin_frb/lazarus/-/tree/f-fpdebug-override-OsDbgClass-selection

That can be easily extended to pass the TDbgAvrProcess instance too.

The controller then just calls StartInstance/AttachToInstance .


*** Option 2

have a
    TDbgProcessConfig class and  a TDbgAvrProcessConfig  subclass.
That can be instantiated.
And host/port/... can be copied to it.

It can be passed to  the controller before calling Run, and it can then 
be passed to the constructor. Or to StartInstance/AttachToInstance as an 
optional argument.


Of course that also modifies StartInstance/AttachToInstance.
So it seems of little benefit to me.

*** Option 2a
If StartInstance/AttachToInstance  become normal methods, and the 
constructor is called before, then the controller could do:

  MainProcess := OSDbgClasses.DbgProcessClass.create;
  MainProcess.Options := 
  MainProcess.StartIntstance();

That would mean you would not need to pre-select the OSDbgClasses. (But 
still could)




IMHO 1 or 2a.

Your opinion?
-- 
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

Re: [Lazarus] git diff enhancement

[Martin Frb via lazarus]

On 14/09/2021 17:49, Marco van de Voort via lazarus wrote:


Op 14-9-2021 om 17:17 schreef Martin Frb via lazarus:

In order for git to show pascal function headers.

Add the following to your config

[diff "fpc"]
  xfuncname = "^(((class[ 
\\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ 


operator?



Yes, and you can also allow spaces at the begin of the line.

I did not, to try and get the outer procedure always. Because otherwise 
it finds nested procs, even if you are in the main body.


--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus

[Lazarus] git diff enhancement

[Martin Frb via lazarus]

In order for git to show pascal function headers.

Add the following to your config

[diff "fpc"]
  xfuncname = "^(((class[ 
\\t]+)?(procedure|function)|constructor|destructor|[ \\t].*[ \\t]*=[ 
\\t]*(class|interface|object|record)|initialization|finalization)[ 
\\t]*.*)$"



then create a file
    lazarus\.git\info\attributes
and add the following

*.pas diff=fpc
*.pp diff=fpc
*.lpr diff=fpc
*.inc diff=fpc


Diffs then look like (note the @@ line has the "function" header)

 components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas 
b/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas

index ea4fbee06a..8fd79d673d 100644
--- a/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
+++ b/components/lazdebuggers/lazdebuggerfp/fpdebugdebugger.pas
@@ -1745,7 +1745,8 @@ function TFPDBGDisassembler.PrepareEntries(AnAddr: 
TDbgPtr; ALinesBefore, ALines

   p: pointer;
   ADump,
   AStatement,
-  ASrcFileName: string;
+  ASrcFileName,
+  AFuncName: string;
   ASrcFileLine: integer;
   i,j, sz, bytesDisassembled, bufOffset: Integer;
   Sym: TFpSymbol;
--
___
lazarus mailing list
lazarus@lists.lazarus-ide.org
https://lists.lazarus-ide.org/listinfo/lazarus