Recent

Recent Posts

Pages: 1 2 [3] 4 5 ... 10
21
Debugger / Re: FpDebug breakpoint on "begin"
« Last post by 440bx on April 19, 2024, 11:28:09 pm »
Please report an issue (not fpdebug related) that the editor unnecessarily overlaps gutter icons.
Done.  Issue: 40914 link: https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/40914

Breakpoint on "begin" => I assume when you remove the breakpoint, then there is no blue dot on that line?    So the issue is that FPC does not generate code for that line.
You're right.  There is no blue dot on the line.

The reason why this works in gdb is, that gdb when given a line number will set the breakpoint at the next linenumber that has code (and stops at that next line...).
That's quite handy in the case of a breakpoint placed on a "begin".

GDB does that even if it is 1000 lines below.
I think that's way too many lines below.  IMO, if the line is not visible in the current editor window then it shouldn't be set.  That way there are no "surprise breakpoints".

Eventually FpDebug should have some smart way....
- a limit how many lines to look down
- determining if it is within the same function (though that will not work for the first line of a function)

For now, it has to be a line with code (actual asm statements attributed to the pascal statement on that line) in it (blue dot).
Actually, if possible, I think placing a breakpoint on a non-code line should be limited to the breakpoint being placed on a "begin" line.  In most cases, there will be a statement soon after the "begin".  The only thing that is a potential "gotcha" is a "begin end" function/procedure.  I suppose in that case the breakpoint can go on the "end" line (FPC does seem to put a blue dot for those lines.)
22
Debugger / Re: FpDebug breakpoint on "begin"
« Last post by Martin_fr on April 19, 2024, 10:57:37 pm »
Talking about begin statements (and end)...

The "begin" of a procedure/function has code, the so called "prologue" => in this code the stack frame (storage for locals) is set up. So when paused on that line, locals (and params) contain trash.

Fpc currently does not mark this line as epilogue (though fpdebug is missing the interpretation of this mark too, but given its absence...).

So the debugger gives no notice that those values are not yet initialized.

Some versions of gdb detect "popular prologue asm", and internally stop only after the prologue., when the begin line is 99% done. Then the values are correct, but you aren't really a the start of "begin".
23
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by Wallaby on April 19, 2024, 10:52:25 pm »
Was there a pre-set dollar value attached to those bounties?

If there's a value where this would make sense and justify the - I'm sure excruciatingly painful - work involved, I could take it up with my employer, too.

I think last time, a year ago, I offered $300 US for each with a possibility of increase if it's difficult and takes a lot of time. Yet, it seems no one is interested.
24
Debugger / Re: FpDebug breakpoint on "begin"
« Last post by Martin_fr on April 19, 2024, 10:50:39 pm »
The 2 icons being drawn in the same column is entirely an issue in the IDE (either SynEdit, or somewhere SourceEditor). Please report an issue (not fpdebug related) that the editor unnecessarily overlaps gutter icons.




Breakpoint on "begin" => I assume when you remove the breakpoint, then there is no blue dot on that line?  So the issue is that FPC does not generate code for that line.

Btw, with -O1 that can even happen for lines containing break or exit statements.

The reason why this works in gdb is, that gdb when given a line number will set the breakpoint at the next linenumber that has code (and stops at that next line...).
GDB does that even if it is 1000 lines below. The curious I can't find the breakpoint, but it stops on the first line of the first routine in the unit => because the breakpoint is on line 1 "unit foo;" so the next line with code...


Eventually FpDebug should have some smart way....
- a limit how many lines to look down
- determining if it is within the same function (though that will not work for the first line of a function)

For now, it has to be a line with code (actual asm statements attributed to the pascal statement on that line) in it (blue dot).
25
Graphics / Re: Demoscene The Champs Cracktro
« Last post by KodeZwerg on April 19, 2024, 10:36:21 pm »
Copperbars -> Shadowbars!
Switched to the BGRA version for easier bitmap manipulation.
Switched to a fixed autocolored version with a nice shadow effect (gradient color switching)
Hope its useful to someone.
Heres the code, in attachment a full working demo project.
Code: Pascal  [Select][+][-]
  1. unit uMain;
  2.  
  3. {$mode objfpc}{$H+}
  4.  
  5. interface
  6.  
  7. uses
  8.   Classes, SysUtils, Forms, Controls, Graphics, Dialogs, ExtCtrls, Spin,
  9.   StdCtrls, BGRABitmap, BGRABitmapTypes,
  10.   BGRAGradientScanner, BGRAVirtualScreen, BCTypes;
  11.  
  12. type
  13.   TCopperBar = packed record
  14.     Gradient: TBGRACustomGradient;
  15.     Y: Integer;
  16.     Size: Integer;
  17.     IsAdd: Boolean;
  18.   end;
  19.   TCopperBars = array of TCopperBar;
  20.  
  21. type
  22.  
  23.   { TForm1 }
  24.  
  25.   TForm1 = class(TForm)
  26.     BGRAVirtualScreen1: TBGRAVirtualScreen;
  27.     Label1: TLabel;
  28.     Label2: TLabel;
  29.     Label3: TLabel;
  30.     Panel1: TPanel;
  31.     SpinEdit1: TSpinEdit;
  32.     SpinEdit2: TSpinEdit;
  33.     SpinEdit3: TSpinEdit;
  34.     Timer1: TTimer;
  35.     procedure BGRAVirtualScreen1Redraw(Sender: TObject; Bitmap: TBGRABitmap);
  36.     procedure BGRAVirtualScreen1Resize(Sender: TObject);
  37.     procedure FormClose(Sender: TObject; var CloseAction: TCloseAction);
  38.     procedure FormShow(Sender: TObject);
  39.     procedure SpinEdit1Change(Sender: TObject);
  40.     procedure SpinEdit2Change(Sender: TObject);
  41.     procedure SpinEdit3Change(Sender: TObject);
  42.     procedure Timer1Timer(Sender: TObject);
  43.   strict private
  44.     FCB: TCopperBars;
  45.     FMaxBars: Integer;
  46.   private
  47.     procedure ReleaseCB;
  48.     procedure GenerateCB;
  49.   public
  50.   end;
  51.  
  52. var
  53.   Form1: TForm1;
  54.  
  55. implementation
  56.  
  57. {$R *.lfm}
  58.  
  59. { TForm1 }
  60.  
  61. procedure TForm1.BGRAVirtualScreen1Redraw(Sender: TObject; Bitmap: TBGRABitmap);
  62. var
  63.   i: Integer;
  64.   sy: Integer;
  65.   bmp: TBGRABitmap;
  66. begin
  67.   bmp := TBGRABitmap.Create(BGRAVirtualScreen1.Width, BGRAVirtualScreen1.Height);
  68.   bmp.Canvas.Brush.Color := BGRAVirtualScreen1.Color;
  69.   bmp.Canvas.FillRect(bmp.Canvas.ClipRect);
  70.   try
  71.     for i := High(FCB) downto Low(FCB) do
  72.       begin
  73.         for sy := 0 to FCB[i].Size do
  74.           begin
  75.             if FCB[i].IsAdd then
  76.               Inc(FCB[i].Y)
  77.             else
  78.               Dec(FCB[i].Y);
  79.             if (FCB[i].Y < (bmp.Canvas.ClipRect.Top - FCB[i].Size)) then
  80.               FCB[i].IsAdd := True;
  81.             if (FCB[i].Y > (bmp.Canvas.ClipRect.Height + FCB[i].Size)) then
  82.               FCB[i].IsAdd := False;
  83.             bmp.Canvas.Brush.Color := FCB[i].Gradient.GetColorAtF(sy);
  84.             bmp.Canvas.FillRect(bmp.Canvas.ClipRect.Left, FCB[i].Y, bmp.Canvas.ClipRect.Width, Succ(FCB[i].Y));
  85.             bmp.Canvas.Brush.Color := FCB[i].Gradient.GetColorAtF(FCB[i].Size - sy);
  86.             if FCB[i].IsAdd then
  87.               bmp.Canvas.FillRect(bmp.Canvas.ClipRect.Left, FCB[i].Y - FCB[i].Size, bmp.Canvas.ClipRect.Width, Succ(FCB[i].Y - FCB[i].Size))
  88.             else
  89.               bmp.Canvas.FillRect(bmp.Canvas.ClipRect.Left, FCB[i].Y + FCB[i].Size, bmp.Canvas.ClipRect.Width, Succ(FCB[i].Y + FCB[i].Size));
  90.           end;
  91.       end;
  92.     Bitmap.Assign(bmp);
  93.   finally
  94.     bmp.Free;
  95.   end;
  96. end;
  97.  
  98. procedure TForm1.BGRAVirtualScreen1Resize(Sender: TObject);
  99. begin
  100.   Timer1.Enabled := False;
  101.   ReleaseCB;
  102.   GenerateCB;
  103.   Timer1.Enabled := True;
  104. end;
  105.  
  106.  
  107. procedure TForm1.FormClose(Sender: TObject; var CloseAction: TCloseAction);
  108. begin
  109.   Timer1.Enabled := False;
  110.   ReleaseCB;
  111.   CloseAction := caFree;
  112. end;
  113.  
  114. procedure TForm1.FormShow(Sender: TObject);
  115. begin
  116.   Randomize;
  117.   GenerateCB;
  118.   Timer1.Interval := SpinEdit3.Value;
  119.   Timer1.Enabled := True;
  120. end;
  121.  
  122. procedure TForm1.SpinEdit1Change(Sender: TObject);
  123. begin
  124.   Timer1.Enabled := False;
  125.   ReleaseCB;
  126.   GenerateCB;
  127.   Timer1.Enabled := True;
  128. end;
  129.  
  130. procedure TForm1.SpinEdit2Change(Sender: TObject);
  131. begin
  132.   Timer1.Enabled := False;
  133.   ReleaseCB;
  134.   GenerateCB;
  135.   Timer1.Enabled := True;
  136. end;
  137.  
  138. procedure TForm1.SpinEdit3Change(Sender: TObject);
  139. begin
  140.   Timer1.Interval := SpinEdit3.Value;
  141. end;
  142.  
  143. procedure TForm1.Timer1Timer(Sender: TObject);
  144. begin
  145.   BGRAVirtualScreen1.RedrawBitmap;
  146. end;
  147.  
  148. procedure TForm1.ReleaseCB;
  149. var
  150.   i: Integer;
  151. begin
  152.   for i := High(FCB) downto Low(FCB) do
  153.     begin
  154.       FCB[i].Size := 0;
  155.       FCB[i].Y := 0;
  156.       FCB[i].IsAdd := False;
  157.       FCB[i].Gradient.Free;
  158.       FCB[i].Gradient := nil;
  159.     end;
  160.   SetLength(FCB, 0);
  161.   FCB := nil;
  162. end;
  163.  
  164. procedure TForm1.GenerateCB;
  165. var
  166.   i: Integer;
  167.   Y: Integer;
  168.   Gradient: TBGRACustomGradient;
  169. begin
  170.   Y := BGRAVirtualScreen1.Height;
  171.   FMaxBars := Succ(Round(Y / SpinEdit2.Value) * 2);
  172.   SpinEdit1.Value := FMaxBars;
  173.   SetLength(FCB, FMaxBars);
  174.   Gradient := TBGRAMultiGradient.Create([RGBToColor(Random(High(Byte)), Random(High(Byte)), Random(High(Byte))), clBlackOpaque], [0, FMaxBars], True, False);
  175.   try
  176.     for i := Low(FCB) to High(FCB) do
  177.       begin
  178.         FCB[i].Size := SpinEdit2.Value;
  179.         Y := Y - (FCB[i].Size);
  180.         FCB[i].Y := Y;
  181.         FCB[i].Gradient := TBGRAMultiGradient.Create([Gradient.GetColorAtF(i), clBlackOpaque], [0, FCB[i].Size], True, False);
  182.         FCB[i].IsAdd := True;
  183.       end;
  184.   finally
  185.     Gradient.Free;
  186.   end;
  187. end;
  188.  
  189. end.
26
Debugger / Re: FpDebug breakpoint on "begin"
« Last post by 440bx on April 19, 2024, 10:10:08 pm »
Hello,

This is not exactly an FpDebug thing but maybe FpDebug can mitigate the problem.  Please refer to the attachment.

In the attachment there is a breakpoint on line 3318 (dc := BeginPaint(...)) but the breakpoint is completely obscured by the Hint about "ps does not seem to be initialized".

At first sight it seems there is enough space to put the red breakpoint dot to the left of the little note bitmap.  Basically, if FpDebug could place its breakpoint indicator flush left there would be two (2) visible bitmaps at that location instead of just one.

Another possibility that does not entail moving the breakpoint indicator is to place the breakpoint indicator on top of of the Hint indicator (instead of having the Hint indicator on top as it is now.)  Personally, I think the breakpoint is a lot more important than the Hint. 
27
Debugger / FpDebug breakpoint on "begin"
« Last post by 440bx on April 19, 2024, 09:46:38 pm »
Hello,

Please refer to the attachment. 

FpDebug considers a breakpoint placed on a "begin" statement to be invalid.  This is unexpected, I believe a "begin" should be a valid "break" location.

Also, in the breakpoints list (on the right), the little breakpoint bitmap is a little chopped.
28
I'll keep all that in mind.

I got one thing to finish before I can give this latest version a good workout.

But, I don't need to finish anything to thank you again for all that work.  FpDebug is getting to be a really nice debugger.  In many ways I find it more enjoyable than VS' debugger, that has been my "gold standard" for years and now I find FpDebug more responsive and intuitive.   Good stuff ... and getting better.

29
Just a note on the "char array to string" => It is limited by the overall length of the array.

The manual cast "^char(@arrardata[1])" => is a different expression sent to the backend, and the backend then figures out what data to sent based on that expression.

The "Value Formatter" does not change the expression. The backend does still evaluate that array, and returns that data. Like a "DisplayFormat" (e.g. hex/dec/bin for numbers) the "Value Formatter" merely changes how this data is displayed (and it omits some data, if it is told to stop at #0).

This also means that there is a difference for sparse arrays. (arrays with memory gaps between their elements). If an array of char for some reason had each element aligned to a 4 byte boundary, then there would be 3 empty bytes between the element. (Afaik no way to make that happen with fpc, but...). The array would show "'a','b','c'", the display-formatter "'abc'", but the "pchar" trick would show "'a'#1#2#3'b'#4#5#6'c'" (depending on what trash would be present in the gaps, or if it was #0 it would cut off).

However, the Value formatter does assemble the pascal "char" as code-units into an utf8 string. (Of course, setting a codepage could be added).


Internally that is owed to the strict differentiation between a frond and back end.

It is possible that (at extra cost), Value formatters off the future could evaluate extra data.
There also is a "backend converter" which can handle this in the backend.

A further difference between work done in the front or back end is, that data stored in debug history can not be updated by the backend (as the debug process is no longer in the state that it was). But front end formatting can still be done. (even if currently access to that is not yet implemented)
30
Windows / Re: Lazarus for Windows on aarch64 (ARM64) - Native Compiler
« Last post by msintle on April 19, 2024, 06:42:18 pm »
Nice to see everyone has plenty of love for their favorite operating systems ;)
Can we get back on track - what needs to be done to fix FPC so larger apps like Lazarus can be compiled successfully for aarch64 on Windows?

Indeed  :D From my experience with the trunk compiler, it works in principle for simple programs, but there are two showstopper bugs I have reported:

Win64 AArch64 optimizer bug and Win64 AArch64 exception handling

I already offered to pay anyone in the FPC team who is able to fix those issues (aka offer a bounty), but so far looks like no one is interested.

Was there a pre-set dollar value attached to those bounties?

If there's a value where this would make sense and justify the - I'm sure excruciatingly painful - work involved, I could take it up with my employer, too.
Pages: 1 2 [3] 4 5 ... 10

TinyPortal © 2005-2018