Re: [fpc-pascal] Type-casting a class variable

[Martin Frb via fpc-pascal]

On 02/05/2024 08:32, Adriaan van Os via fpc-pascal wrote:

Martin Frb via fpc-pascal wrote:


Silly question, but did you assign the value to the variable?

myClass := TWindow;


That's what I did.


TWindow(myClass).CreateNewWindow;


And this is what crashes. I can report this, if the type-cast is 
supposed to work.


My example (2nd part of it) was actually wrong.

It was mentioned before

On 01/05/2024 19:43, Jean SUZINEAU via fpc-pascal wrote:

I didn't tested but I imagine it could be done with something like this ?

type
   TWindow_Class= class of TWindow;
begin
  ...
  (myClass as TWindow_Class).CreateNewWindow( );


It must be cast to another "class of"
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Type-casting a class variable

[Martin Frb via fpc-pascal]

On 01/05/2024 16:28, Adriaan van Os via fpc-pascal wrote:

Suppose I have a

var myClass: TClass

and (for example) a

class function TWindow.CreateNewWindow( )

Now I want to call CreateNewWindow for var myClass. Of course, 
depending on the class, CreateNewWindow will behave different. 
Type-casting myClass to TWindow crashes (in my setup). And even if it 
worked, wouldn't it loose the class information ?




Silly question, but did you assign the value to the variable?

myClass := TWindow;
TWindow(myClass).CreateNewWindow;

The cast is not always needed.

If you have

var myClass: TMyClass;

with
  TMyClass = class
   class  procedure  CreateNewWindow; virtual
  end;

And any inherited class correctly overrides this, then you don't need 
the typecast.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] "Unexpected end of file" when having an open comment after the final "end."

[Martin Wynne via fpc-pascal]

Hi Thomas,

The error is not the file content after "end.".

The error is not having the expected "end;" after "begin".

This works ok:

_

program test;

begin
end;

end.

abc 123

_____

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Strings greater than 255 characters

[Martin Frb via fpc-pascal]

On 19/12/2023 12:36, James Richters via fpc-pascal wrote:


I did notice that I cannot have a file of Ansistrings…

Myfile : File of Ansistring;

Causes a compiler error:

Error: Typed files cannot contain reference-counted types.




A "file of" must have a fixed size type.

"file of word", reads 2 byte (1 word) for each entry.

Shortstring always occupies 256 bytes
String[20] always 21 bytes
Even if such a string just contains "abc" it will have the full amount 
of bytes used in the file.


For ansistring that is not possible. It can have millions of chars, and 
you can't have each entry use 2^32 bytes.
If they don't have linebreaks, then you can just readln/writeln to/from 
a text file.


Mind: You can't replace just one string in the file by a different 
value, if the new string-value has a different length => then the entire 
rest of the file needs to be moved.___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] method-definition

[Martin Frb via fpc-pascal]

On 15/12/2023 14:56, Adriaan van Os via fpc-pascal wrote:
I am puzzled by the syntax rule  in Chapter 6. Classes of 
the FreePascal Language Reference (version 3.2.0)


Section 6.1 Class definitions has

method-definition = [ "CLASS" ] ( function-header | 
procedure-header | constructor-header | destructor-header ) ";" [ ( ( 
( "virtual" | "dynamic" ) [ ";" "abstract" ] ) | "override" | 
"message" ( integer-constant | string-constant ) ) ";" ] [ 
call-modifiers ";" ] .


Section 6.6.1 Declaration has:

method-definition = ( function-header | procedure-header | 
constructor-header | destructor-header ) ";" method-directives .


method-directives = ( ( "virtual" | "dynamic" ) [ ";" "abstract" ] 
| "reintroduce" ";" | "override" ";" | "message" constant-expression ) 
[ call-modifiers ";" ] .


2. "reintroduce" is in just one of the two definitions.


Another note: "reintroduce" is given as an alternative to "virtual; 
[abstract;]".


However, a method can be reintroduced, and be virtual/abstract.

program Project1;{$Mode objfpc}
type
  TFoo = class
    procedure Bar; virtual; abstract;
  end;

  TFoo2 = class(TFoo)
    procedure Bar; reintroduce; virtual; abstract;
  end;

begin
end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] case statement

[Martin Wynne via fpc-pascal]

I've been using ELSE in IF statements and in CASE statements for 25 
years without realising there was a problem. What a dim-wit I have been.


Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] operator := in mode delphi?

[Martin Frb via fpc-pascal]

Thanks, but that isn't the part of the answer I was looking for

I was looking for a global operaton :=

That could be used for an array (rather than just record/class).

But according to the docs that I found that is not possible


On 24/10/2023 23:51, Sven Barth via fpc-pascal wrote:
Martin Frb via fpc-pascal  schrieb am 
Di., 24. Okt. 2023, 23:30:


Is there a modeswitch to enable it?


Because currently I am getting an error in mode delphi.


In mode Delphi it's called "Implicit" as Delphi does not support 
symbolic operator overloads.


Regards,
Sven


___
fpc-pascal maillist  -fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] operator := in mode delphi?

[Martin Frb via fpc-pascal]

Is there a modeswitch to enable it?


Because currently I am getting an error in mode delphi.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] All methods vitrual ?

[Martin Frb via fpc-pascal]

On 11/10/2023 16:46, Adriaan van Os via fpc-pascal wrote:
I don't see any use in allowing or disallowing something. And with the 
current design, it is, as I said, impossible, without macros, to 
compile the same code with {$M+} and {$M-}.


Use $IfOpt instead of macros?

{$IfOpt M+} published {$Else} public {$EndIf}
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Parse unicode scalar

[Martin Frb via fpc-pascal]

On 02/07/2023 19:20, Nikolay Nikolov via fpc-pascal wrote:

On 7/2/23 16:30, Hairy Pixels via fpc-pascal wrote:
I'm interested in parsing unicode scalars (I think they're called) to 
byte sized values but I'm not sure where to start. First thing I did 
was choose the unicode scalar U+1F496 ().


There's no such thing as "unicode scalar" in Unicode terminology:

https://unicode.org/glossary/

There seems to be
https://www.unicode.org/versions/Unicode10.0.0/ch03.pdf#G7404






Next I cheated and ask ChatGPT. :) Amazingly from my question it was 
able to tell me the scaler is comprised of these 4 bytes:


  240 159 146 150


That is an utf-8 encoded representation of such a value.

You can find them on https://www.compart.com/en/unicode/U+0041
(using the hex for whatever codepoint interests you)




The question is, how was 1F496 decomposed into 4 bytes?



https://en.wikipedia.org/wiki/UTF-8#Encoding
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] 3123 inherited not supported inside inline

[Martin Frb via fpc-pascal]

On 24/06/2023 17:21, Hairy Pixels via fpc-pascal wrote:



On Jun 24, 2023, at 10:11 PM, Hairy Pixels  wrote:

Doesn't this mean the compiler can dictate the binary size by inlining 
everything even if the programmer doesn't want that?

and another thing, I have frequent problems with a crash which happens in an 
inlined function and it's now not possible to step into the code in the 
debugger. Now I can disable the inline and step in the function but if it was 
auto inlined that would be really bad. Maybe the debug info could fix this 
though? It's a general problem with inlined functions anyway.



-O-
also afaik -Si-

{$INLINE OFF}

And, the compiler could write debug info were inlined code is. (Which 
then the debugger would also need to be taught to read)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Legitimate use of for and break

[Martin Wynne via fpc-pascal]

On 17/06/2023 19:07, Travis Siegel via fpc-pascal wrote:
This is interesting, because it's the first time I've ever seen "break" 
as a valid command in pascal, and I've been using pascal since the 
mid/late 80s.  All kinds of dialects too, and I've never seen break as a 
keyword.  C, Python, Perl, sure, even shell scripts, but pascal? Never 
seen it used before.


I've been using break very often in Pascal loops for 25 years since 
Delphi 2. Also continue.


My code is littered with:

repeat

 do_something;

 if x then BREAK;

 if y then CONTINUE;

 do_something_else;

 Application.ProcessMessages;

 if key_clicked then EXIT;

until 0<>0;

ProcessMessages allows the user to stop the loop if it is running out of 
control.


Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] What is -CO ?

[Martin via fpc-pascal]

On 09/06/2023 12:03, Mattias Gaertner via fpc-pascal wrote:

Hi,

What is -CO?

In the docs I can only find this sentence:
"Check for possible overflow of integer operations"



Done some testing. -CO produces the below warning.

program Project1;
var a,b: Integer;
var c: integer;
begin
a := Random();
b := Random();
c := a +b;  // project1.lpr(7,3) Warning: Type size mismatch, possible 
loss of data / range check error

writeln(c);
end.


However it overdoes it.

make it
  var a,b: shortInt;

Then the ":=random" will warn => ok.
But the addition still warns, yet it can't ever fail. (even if the 
compiler internally uses int64)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error: Argument cannot be assigned to

[Martin Frb via fpc-pascal]

On 04/06/2023 17:49, Martin via fpc-pascal wrote:

On 04/06/2023 15:04, Juha Manninen via fpc-pascal wrote:

Why the following code fails to compile?
MyObj.RecInstance.ii := 123;
Technically you can modify the members of the temp record (just to 
have the work thrown away afterwards).


So I guess the compiler forbids it, because the only case it would 
ever be done is: by mistake.


Btw, this works (or actually not, it works wrong)

  with  MyObj.RecInstance do {begin} ii := 123; {end;}

Now you could do some work with the temp result, and have it trashed at 
the end of the "with" block.


However, fpc incorrectly changes the value in the original record.
Yet, don't use it. It will (likely) change, and stop working. (or work 
correctly, changing the temp value only).

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error: Argument cannot be assigned to

[Martin Frb via fpc-pascal]

On 04/06/2023 15:04, Juha Manninen via fpc-pascal wrote:

Why the following code fails to compile?

  TMyRec = record

...

property
    RecInstance: TMyRec read fRecInstance;// write fRecInstance;

...

MyObj.RecInstance.ii := 123;
Access through property seems to be the problem. Accessing 
fRecInstance directly works.




A property enforces that any code you write will work even if you change 
the property to a getter/setter.

Or in other words, it will fail any code that would not work.

If this was a getter, it would be
  function GetRec: TMyRec;

And that returns a *copy* in a temporary location of the record.
Technically you can modify the members of the temp record (just to have 
the work thrown away afterwards).


So I guess the compiler forbids it, because the only case it would ever 
be done is: by mistake.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Error: Argument cannot be assigned to

[Martin via fpc-pascal]

On 04/06/2023 15:04, Juha Manninen via fpc-pascal wrote:

Why the following code fails to compile?

  TMyRec = record

...

property
    RecInstance: TMyRec read fRecInstance;// write fRecInstance;

...

MyObj.RecInstance.ii := 123;
Access through property seems to be the problem. Accessing 
fRecInstance directly works.




A property enforces that any code you write will work even if you change 
the property to a getter/setter.

Or in other words, it will fail any code that would not work.

If this was a getter, it would be
  function GetRec: TMyRec;

And that returns a *copy* in a temporary location of the record.
Technically you can modify the members of the temp record (just to have 
the work thrown away afterwards).


So I guess the compiler forbids it, because the only case it would ever 
be done is: by mistake.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Forking the GitLab FPC Source repository

[Martin Frb via fpc-pascal]

On 01/05/2023 20:02, Norman Dunbar via fpc-pascal wrote:
On 1 May 2023 17:27:52 BST, Christo Crause via fpc-pascal 
 wrote:



> FWIW, there are currently 68 forks of
> the FPC source repository on GitLab. ...
I noticed that when I tried to fork it. Unfortunately I am not able to 
fork those now either.


At what time do you get the error?

I tested, first attempt I used a "project slug" I already had in use => 
immediate error.

(And you may also have to select the namespace)

2nd attempt went through. Took maybe half a minute at most.
The fork started about 1 second after the click. The moment it started, 
the repo was also listed in my projects.


And, well yes, my account for testing was my account also used for 
fpc/laz. So I have full rights there. But that should not make any diff.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pause Key

[Martin Wynne via fpc-pascal]

On 14/04/2023 01:31, James Richters via fpc-pascal wrote:

Does anyone know what's up with the Pause key in Windows?
Is there some way to tell if it was pushed?


Hi James,

//

Tform.FormKeyDown(Sender:TObject; var Key:Word; Shift:TShiftState);

begin

if Key=VK_PAUSE then
begin
 do_something;
 Key:=0;
end;

end;
//_

cheers,

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] pointer to char vs pchar

[Martin Frb via fpc-pascal]

On 24/03/2023 15:04, Benito van der Zander via fpc-pascal wrote:
why is a pointer to a char not a pchar (for type helpers)? 


My guess: For the same reason that "p2" fails in the below. Distinct type.
May be assignment compatible, but a type of it's own.

Imagine you had a different helper, with a different "toString" on 
pchar2, then which one should @char get?


program Project1;
{$Mode objfpc}{$H+} {$ModeSwitch typehelpers}
type
  pchar = ^char;
  pchar2 = ^char;

type TPcharHelper = type helper for pchar
  function toString(length: integer): string;
end;

function TPcharHelper.toString(length: integer): string;
begin
end;

var
  p: pchar;
  p2: pchar2;
begin
  p.toString(1);
  p2.toString(1);  // error
end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Downloaded cross-compiler from Sourceforge - wiki incorrect?

[Martin Frb via fpc-pascal]

On 24/03/2023 07:38, Bo Berglund via fpc-pascal wrote:

On Thu, 23 Mar 2023 09:47:36 +0100, Martin Frb via fpc-pascal
 wrote:


You need to change the CPU to i386 too

OK, I thought that the current processor could be used since it can run both
types of programs...


Well no, and probably for several reasons.

1) The compiler only cares about the cpu, you have both, so that would 
be ok.


2) the units (rtl/fcl) are only prebuild for the exact combination

3) I don't think a 64bit app can open the 32 bit dll/kernel.
One app has to be either all 64bit code. Or all 32 bit code. The CPU has 
to run either in one or the other mode. The same byte sequence of code 
has different meanings in either mode.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Downloaded cross-compiler from Sourceforge - wiki incorrect?

[Martin Frb via fpc-pascal]

On 23/03/2023 09:25, Bo Berglund via fpc-pascal wrote:


Then opened Lazarus 2.2.4 with my project and changed project options as
follows:

Compiler_Options/Config_and_Target/Target OS(-T): Win32

Everything else left as-is.

You need to change the CPU to i386 too


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Get highest element of a StringList

[Martin Wynne via fpc-pascal]

On 12/09/2022 15:37, James Richters via fpc-pascal wrote:

So I could just do this?

Index:= MyStringlist.IndexOfName(SearchName);
If Index >=0 then
MyValue := MyStringlist[Index].ValueFromIndex;



Hi James,

I would probably do

try
  with MyStringList do MyValue:=ValueFromIndex[IndexOfName(SearchName)];
except
  MyValue:='';
end;

cheers,

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Get highest element of a StringList

[Martin Wynne via fpc-pascal]

On 12/09/2022 14:16, James Richters via fpc-pascal wrote:

The problem with the for in loop is that I need the index.


Hi James,

You don't need a loop for that:

 index:=MyStringlist.IndexOfName;

see: 
https://www.freepascal.org/docs-html/rtl/classes/tstrings.indexofname.html


martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Get highest element of a StringList

[Martin Wynne via fpc-pascal]

On 10/09/2022 17:01, James Richters via fpc-pascal wrote:


For Loop := 0 to MyStringList.Count-1 do

It would be nice to not have the -1


I don't understand what is wrong with Count-1, but you can get the 
highest index like this if you wish:


high_index:=Length(Trim(MyStringList.Text))-Length(StringReplace(Trim(MyStringList.Text),#13,'',[rfReplaceAll]));

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Union followed by Property does not compile !

[Martin Frb via fpc-pascal]

On 03/08/2022 12:41, wkitty42--- via fpc-pascal wrote:

On 8/2/22 5:12 AM, Michael Van Canneyt via fpc-pascal wrote:

The variant part of a record must always come last.


FWIW: is this documented somewhere easily found?


google
free pascal language reference

https://www.freepascal.org/docs-html/ref/ref.html

and read up on "record"


The variant part must be last in the record. The optional identifier 
in the case statement serves to access the tag field value, which 
otherwise would be invisible to the programmer. It can be used to see 
which variant is active at a certain time^3 
. In 
effect, it introduces a new field in the record.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] "Is nested" vs "of object" compatibility with global functions

[Martin Frb via fpc-pascal]

On 29/05/2022 07:21, Michael Van Canneyt via fpc-pascal wrote:



On Sun, 29 May 2022, Hairy Pixels via fpc-pascal wrote:


I’ve been testing out all the different function pointer types in FPC to
test their compatibility with each other and I noticed that “is nested”
can accept a global function declaration but “of object” can not.  
What is

the reason for this exactly?  I wouldn’t expect nested function types to
accept global functions but since they do I wonder why “of object” is
different.


Because you're pushing a parameter which does not exist in the case of a
global function.


Actually afaik you push an extra param in for "is nested" as well as for 
"of object.


But for "of object" it is the first param, for "is nested" it is the last.

procedure TFoo.Bar(self: TBar; a: integer);
procedure NestedBar(a: integer; parentFp: pointer);

So in the code at the end of the mail, with a global function assigned 
to "p", it calls

  p(1, SomeValueForParentFp).
But the global "procedure f" just ignores the extra param.

If it was "of object", the "self" value would be first, and it would be 
in place of the parameter "a".



program Foo;
type TProc = procedure(a:integer) is nested;
var  p: TProc;

procedure f(a:integer);
begin
end;

begin
  p:= @f;
  p(1);
end.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Element type of set at compile time

[Martin Frb via fpc-pascal]

On 15/05/2022 15:07, Hairy Pixels via fpc-pascal wrote:

var
   I: ElementType(TMySet);
begin
   for i := low(TMySet) to high(TMySet) do
 ;


type
  TMySet = set of (one,two,three);
var
  I: low(TMySet) .. high(TMySet) ;
begin
  for i := low(TMySet) to high(TMySet) do
    ;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Martin Frb via fpc-pascal]

On 25/04/22 05:15, Hairy Pixels via fpc-pascal wrote:

generic function Add(left, right: T): T;

And the programmer intends to call it like:

Add(1,1);


Why should the programmer need to tell the compiler it’s dealing with Integer 
when it’s so obvious from the types being used?


Actually, it's dealing with SmallInt (or ShortInt). And if the 
programmer does not know that, then it might be an issue...


Imagine the generic code (something more complex than "Add") would 
somehow do something that differs for SmallInt and Integer. Like using 
"SizeOf(T)".


Sure it can be solved by explicit specialization "Add(1,1)".
But to solve it that way, the programmer needs to know... And he might 
not...


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Possible fpdebug issue

[Martin Frb via fpc-pascal]

Lazarus 2.2 or 2.3 ?
In 2.3 some work has been started to debug into dll...

Is there a way to reproduce this?
Also try:
lazarus.exe  --debug-log=c:\logfile.txt 
--debug-enable=DBG_EVENTS,DBG_VERBOSE,DBG_WARNINGS,DBG_ERRORS,DBG_VERBOSE_BRKPOINT,DBG_STATE,DBG_COMMAND_ECHO,DBG_DATA_MONITORS,DBG_LOCATION_INFO,DBG_BREAKPOINTS,DBG_FPDEBUG_VERBOSE,FPDBG_BREAKPOINT_ERRORS,FPDBG_BREAKPOINTS,FPDBG_COMMANDS,FPDBG_THREADS,FPDBG_QUEUE,FPDEBUG_THREAD_CHECK,FPDBG_WINDOWS



I am away for some days, so replies may take some time.

On 24/04/2022 02:15, Thomas Kurz via fpc-pascal wrote:

Dear all,

I'm not sure whether or not this is an issue with fpdebug, so I'd like to 
describe it here first:

I have a main program (Win32 GUI running on Win 8.1) which loads and unloads a 
DLL dynamically. I know that fpdebug is currently not able to debug DLLs, but 
imho I don't do so, but the issue might be related.

The program runs fine when being run without debugger or when using GDB. However, a crash 
occurs when fpdebug is active and the call to "FreeLibrary" is made. The error 
is:

Project raised exception class 'External: Unknown exception code
$E0465043'. At address 76EB56E8.

The DLL is my own and I tried to debug the Finalization section with GDB, but I cannot 
find an issue there. So imho unloading the DLL should not cause any trouble. As I said, 
I'm not trying to actually step into the DLL; I'm only using fpdebug in the main program 
and trying to step over the "FreeLibrary" line.

Kind regards,
Thomas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Martin Frb via fpc-pascal]

Possible one more / Though more of an optimization.

If the code has multiple
    Add(Int64(0), Int64(0));
then they will all use the same procedure (just break in the debugger 
and check the CRC).


But if  one specialization is explicit and the other implicit then 2 
identical (as far as I can tell with -al ) functions (with diff CRC) are 
created.


There is however a subtle difference in the generate asm.
The explicit specialization has comment for the source code
# [6] begin
...
# [7] Result := aArg1 + aArg2;
...

The implicit does not have those.
Actually I checked that a bit deeper. The comment occur in (and only in) 
the first specialization (implicit or explicit).

All other specialization are without comments for the source.



program Project1;
{$mode objfpc}
{$ModeSwitch ImplicitFunctionSpecialization }

generic function Add(aArg1, aArg2: T): T;
begin
  Result := aArg1 + aArg2;
end;

begin
  specialize Add(Int64(0), Int64(0));  // No Hint
  Add(Int64(0), Int64(0));
end.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Martin Frb via fpc-pascal]

On 22/04/2022 23:12, Sven Barth via fpc-pascal wrote:

Am 22.04.2022 um 20:51 schrieb Martin Frb via fpc-pascal:



So why does it generate "Add$1" if it does not use it? (Or rather why 
does it warn, if this is some internal details?)


Add$1 is the symbol of the generic itself, *not* the specialization. 
But please report it, cause that definitely shouldn't be the case 
anyway, as the generic is after all used by the specializations (and I 
should compile with -vh more often...)


=> Then you get an additional hint: "project1.lpr(81,41) Hint: Local 
proc "Add$1$crc9AB0BCED" is not used"
So then that very line generates a specialized version for the call, 
and then the compiler does not use it.


The compiler essentially works like this: it generates a suitable set 
of overloads. This includes the non-generic routines as well as all 
generic routines for which suitable type parameters can be found. Out 
of this set the compiler will then pick the function it will finally 
use with a preference for non-generic functions (even if parameters 
might be a worse, though not incompatible match).


That said: if the compiler does not pick one of the specializations it 
should totally discard them, so please report a bug for this as well.


Done
https://gitlab.com/freepascal.org/fpc/source/-/issues/39684
https://gitlab.com/freepascal.org/fpc/source/-/issues/39685
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Feature announcement: implicit generic function specializations

[Martin Frb via fpc-pascal]

On 20/04/2022 19:15, Sven Barth via fpc-pascal wrote:
This feature allows you to use generic routines (functions, 
procedures, methods) without explicitely specializing them (“<…>” in 
Delphi modes and “specialize …<…>” in non-Delphi modes) as long as the 
compiler can determine the correct parameter types for the generic.


This feature is enabled with the modeswitch 
ImplicitFunctionSpecialization and is for now not enabled by default 
as this has the potential to break existing code.




One more step by Delphi to remove type safety.
IMHO a good option would have been to allow specializing multiple 
overloads in a single statement. But since Embarcadero has decided 
otherwise


I did explore what happens if I throw different types at it, and see how 
the current implementation deals with this (what I call) lack of type 
safety.
And also asked the question, how should it act?  (Because the current 
behaviour is new, expected to need fixes, and can obviously be fixed).



Assume you have the following function:
  generic function Add(aArg1, aArg2: T): T;
...

Up to now you could only use this function as follows:

SomeStr := specialize Add('Hello', 'World');
SomeInt := specialize Add(2, 5);

However with implicit function specializations enabled you can also 
use it as follows:


SomeStr := Add('Hello', 'World');
SomeInt := Add(2, 5);


So what happens if:

var
  b: Byte;
  c: Cardinal;
begin
  Add(b, c);

Well, I tested: It uses the type of the first Param. So it calls a 
function for both param of type Byte. The cardinal argument is 
converted. (potentially truncated).


If you use numeric constants:
  writeln('   0', Add(0, 0) );  // ShortInt
  writeln('1000', Add(1000, 1000) );  // SmallInt
  writeln('100K', Add(10, 10) );  // Integer

So then, if you try to fix   " Add(b, c)" by checking that b and c have 
the same type => "Add(c, 0)" will fail => because 0 is ShortInt and not 
cardinal.




I created a little test program (see bottom of mail).

And it gives a strange warning:

Compile Project, Target: 
C:\Users\martin\AppData\Local\Temp\project1.exe: Success, Warnings: 1, 
Hints: 3
project1.lpr(67,52) Warning: Range check error while evaluating 
constants (10 must be between -128 and 127)

project1.lpr(41,18) Hint: Local proc "Add$1" is not used
72 lines compiled, 0.2 sec, 105136 bytes code, 5476 bytes data

Line 41 is the declaration of the generic
   generic function Add(aArg1, aArg2: T): T;

So why does it generate "Add$1" if it does not use it? (Or rather why 
does it warn, if this is some internal details?)



And if you add to the app (at the top)

function Add(aArg1, aArg2: Int64): Int64; overload;
begin
//  write(' Int64 overload ');
  Result := aArg1 + aArg2;
end;

Then the line  (Shortint, because the first param is ShortInt)
 writeln(' 1,CK = ',Add(0, 10) ); // ShortInt

Will no longer call the specialized function, but instead use the int64 
version.


If you comment all "Add(...)" calls, except that one
=> Then you get an additional hint: "project1.lpr(81,41) Hint: Local 
proc "Add$1$crc9AB0BCED" is not used"
So then that very line generates a specialized version for the call, and 
then the compiler does not use it.



Yet if INSTEAD of adding the hardcoded Int64 variant (as given above), I 
let the compile create a Int64 version by adding

    writeln(' 1,CK = ',Add(int64(0), 10) ); // ShortInt
before the line above... Well the line above will not use that int64 
version, but use its own specialization...




program Project1;
{$mode objfpc}
{$ModeSwitch ImplicitFunctionSpecialization }
{//$H+}

uses SysUtils;

Procedure Foo(a: Integer; out r: ShortInt);
begin
  write(' ShortInt ');
  r := a;
end;
Procedure Foo(a: Integer; out r: SmallInt);
begin
  write(' SmallInt ');
  r := a;
end;
Procedure Foo(a: Integer; out r: Byte);
begin
  write(' Byte ');
  r := a;
end;
Procedure Foo(a: Integer; out r: Word);
begin
  write(' Word ');
  r := a;
end;
Procedure Foo(a: Integer; out r: Cardinal);
begin
  write(' Cardinal ');
  r := a;
end;
Procedure Foo(a: Integer; out r: Integer);
begin
  write(' Integer ');
  r := a;
end;
Procedure Foo(a: Integer; out r: Int64);
begin
  write(' Int64 ');
  r := a;
end;
Procedure Foo(a: Integer; out r: AnsiString);
begin
  write(' Ansi ');
  r := ' _A:'+IntToStr(a);
end;
Procedure Foo(a: Integer; out r: ShortString);
begin
  write(' Short ');
  r := ' _S:'+IntToStr(a);
end;

generic function Add(aArg1, aArg2: T): T;
var x: T;
begin
  Foo(SizeOf(T), x);
  {$R-}
  Result := aArg1 + aArg2 + x;
end;

var
  b: byte;
  c: cardinal;
begin
  b := 0;
  c := 0;

  writeln('    B = ',Add(b, b) );
  writeln('    C = ',Add(c, c) );
  writeln('    0 = ',Add(0, 0) );  // ShortInt
  writeln(' 1000 = ',Add(1000, 1000) );  // SmallInt
  writeln(' 100K = ',Add(10, 10

Re: [fpc-pascal] RTLEventWaitFor

[Martin Frb via fpc-pascal]

On 05/04/2022 01:03, Mattias Gaertner via fpc-pascal wrote:

Under Linux a RTLEventWaitFor(e,1) usually waits at most 1ms. But under
Windows it usually waits at least 15ms. It seems to round to nearest
1/64 of a second.

Has anyone an idea if this is normal on Windows and if there is an
alternative?


As for the alternative bit Maybe

I have some code in  components\fpdebug\fpdbgutil.pp (e.g, one side in 
TFpThreadWorkerItem.WaitForFinish) doing the following. (simplified version)

- Thread T1 => Worker: sets event when ready
- Thread T2 => Controller: waits for event. (But could easily be 
extended to just check the state, without waiting)


Both threads use a variable via InterlockedExchange.
- The variable starts with TWSTATE_RUNNING => T1 is busy
- When T1 finished, and T2 does not yet wait (See below): It sets 
TWSTATE_DONE


- When T2 needs the result:
  ~ if the state is TWSTATE_DONE then it never needs to call RtlEventWait
 > not calling RtlEventWait => no timeout needed at all
  ~ Otherwise it sets TWSTATE_WAIT_WORKER, and calls RtlEventWait
 (In this case no timeout either, as it waits until the event comes)
    ==> But instead of calling RtlEventWait  it could return the state.

- When T1 finished, and T2 does wait (TWSTATE_WAIT_WORKER)
  then T1 sets the event to signal T2


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Inactive account on GitLab

[Martin Frb via fpc-pascal]

On 10/09/2021 10:42, Luca Olivetti via fpc-pascal wrote:


Not a biggie now that I know how to find my bugs, though I'd prefer to 
find them with the proper filter (the first one with author_username) 
and not with a full text search.


Still a full search, but more precise:
https://forum.lazarus.freepascal.org/index.php/topic,55532.msg413642.html#msg413642

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 22:08, Vojtěch Čihák via fpc-pascal wrote:


Hi,

my numbers of Lazarus on Linux, Qt (incl. binaries and *.ppu and *.o 
files)


SVN:

lazarus dir: 2.6 GB (4 files, 1300 dirs)

.svn subdir: 1.6 GB (25000 files, 260 dirs)

GIT:

lazarus dir: 1 GB (15000 files, 950 dirs)

.git subdir: 150 MB (60 files, 40 dirs)




The size of the .svn / .git dir will vary, dependent how often you 
"clean" it.


That is it will grow, when you work with the repro (svn update / git 
pull or commit )


So you can compare those either
1) immediately after your first checkout/clone

2) after cleaning
IIRC
in svn "svn cleanup  --vacuum-pristines " not sure
in git "git gc" (or git gc --aggressive)


IIRC, svn will end up a little bit smaller. But you lose that as soon as 
you stop running maintenance.


Not to say if you need to often switch between trunk and fixes.
(In git, I have 2 work dirs, one for main, one for fixes => but only ONE 
.git dir => so that saves space)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 15:30, Martin Frb via fpc-pascal wrote:

depth=1


gitlab also offers you a tar.gz (or zip, or...)

https://gitlab.com/freepascal.org/lazarus/lazarus/-/archive/main/lazarus-main.tar.gz
https://gitlab.com/freepascal.org/lazarus/lazarus/-/archive/lazarus_2_2_0_RC1/lazarus-lazarus_2_2_0_RC1.tar.gz

You can see where the branch/tag name goes.

It's approx the size of fetching with --depth=1

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 15:11, Bo Berglund via fpc-pascal wrote:

On Wed, 11 Aug 2021 23:13:28 +0200, Martin Frb via fpc-pascal
 wrote:


Well I don't know your script, and I am not sure how exactly you do that
in svn

It is not done in SVN, instead I visit the (now removed) page
  https://svn.freepascal.org/svn/lazarus/ (for lazarus)
or
  https://svn.freepascal.org/svn/fpc/ (for fpc)

and look at the tags list to find the most recent release tag.
I then use that as input to my script.

ok, so you could run
  git ls-remote
in your shell, and look at that.




Also I do not know, if this is for a once up setup (so you only wont to
download the one revision and nothing else), or if you don't mind.
(I have not measured the overhead..>)

It is for installation on a pristine RaspberryPi (or Ubuntu) machine and the
script does everything including setting up the folder tree for development and
adding the desktop shortcuts.
Of corse now it is unusable because it cannot retrieve the sources... :(

I want to download the complete source tree for the tagged revision I want to
install. I do not care if it is with metadata or not, I only ever use the files
as is and never modify them.


Well
On 12/08/2021 08:12, Christo Crause via fpc-pascal wrote:
git clone --depth=1 --branch fixes_3_2 --single-branch 
https://gitlab.com/freepascal.org/fpc/source.git 
<https://gitlab.com/freepascal.org/fpc/source.git> fpc-fixes_3_2

You need to test, if it works with tags too (my 3 step solution did).



Of course I do not want to get excessive overhead like the complete history of
all files for eternity...
No history at all would be fine.

depth=1

Only when you update, then you do get history.

with my "fetch" solution

git init .
git fetch --depth=1 
https://gitlab.com/freepascal.org/lazarus/lazarus.git 
refs/tags/lazarus_2_2_0_RC1

git switch -c my-branch FETCH_HEAD

you can then later do (may download entire 2.2.0, NOT just the diffs / 
if you are lucky it will reuse some of your local existing data / I 
don't know the internals well enough)


git fetch --depth=1 
https://gitlab.com/freepascal.org/lazarus/lazarus.git 
refs/tags/lazarus_2_2_0

git switch -c my-NEW-branch FETCH_HEAD
git branch -d my-branch
git reflog expire --expire=now --all
git gc --prune=now --aggressive

And then you should have just the new branch, and all old data gone. But 
you temp have both.
(git switch takes -f to overwrite changed file / there also is a merge 
option instead)


Afaik You only can get rid of the old data, once you switched to the 
new. So for a brief moment you do have both.


Or you delete the entire dir, and start from scratch.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 15:04, Michael Van Canneyt via fpc-pascal wrote:


If you do an update of an existing directory, instead of

git clone http://theurl/ thesourcedirectory

you must do

cd thesourcedirectory
git pull
cd ..

This will reduce the download size considerably.


If he stays on the same branch (assuming he is on a branch). Or if his 
"--depth" was deep enough to have common history with the new target branch.


An svn server (afaik) calculates the diff between any 2 revisions, even 
on diff branches...
But (afaik, really not sure) git will look for the nearest common 
history, and download all changes from that point.


This makes sense for git, because "--depth" is the exception, and not 
what the design is made for. So git would assume you want the commits in 
the middle, and it would assume you have common history.

(But again, not tested at all).

And if you "cloned" only a "tag" (depth 1), not a branch => then you may 
not have an upstream branch. So you can't "git pull".



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 11/08/2021 22:12, Bo Berglund via fpc-pascal wrote:

Please advice how to:
1) Find which is the latest release tag of fpc and lazarus



Well I don't know your script, and I am not sure how exactly you do that 
in svn


Also I do not know, if this is for a once up setup (so you only wont to 
download the one revision and nothing else), or if you don't mind.

(I have not measured the overhead..>)

Most replies will be to clone all, and then look at tags. (or branches)
But you can do ( -t => tags) https://git-scm.com/docs/git-ls-remote.html

git ls-remote -t https://gitlab.com/freepascal.org/lazarus/lazarus.git

However, there is no "svn serial rev number", nor a date. So you need to 
parse the "release version" number, and compare them.


If you have a complete clone, you can afaik sort them by "commit date" 
(see "git for-each-ref")



2) Retrieve the full sources for that tag on the command line from gitlab




If you do not want to clone

git init .
git fetch --depth=1 
https://gitlab.com/freepascal.org/lazarus/lazarus.git 
refs/tags/lazarus_2_2_0_RC1

git switch -c my-branch FETCH_HEAD

"my-branch" is your choice


*** the rest BELOW is completely UNTESTED / pure assumptions ***

I haven't tested how well updates work, if you go to other branches.
Since you have no history fetched (depth =1), I expect a full download 
of any other version (unless it is a direct child / same branch, NOT 
diverged)


Git is written for getting the full history once. I *guess* (but might 
be totally wrong) that not doing so, will make you pay later.

You could do a depth of 3000 or 1.
That is 2.2.0 (with the ending 0) is likely less that 3000 commits 
divirged from main. Then that gives you common history, and 2.4 can base 
on that.


2.0.18 is probably more revisions from main.

If you only want to stay in the same fixes branch (and are ok with a new 
download for major releases) go with a depth of 500. It is unlikely that 
a release tag will be further away from its fixes branch (usual are 0 to 
5 commits)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 06:26, Michael Van Canneyt via fpc-pascal wrote:


Well, sorry to say, but I don't understand this.

What's so hard about it ?

It's like switching car brands from a VW to an Audi or so.
Some buttons are in different places, your key will maybe look different,
but that's it. It's a car, it brings you from a to b.

A file version system manages versions of files. The actual commands 
differ a little, but that's it.


That comparison is a bit to simple
And the extend has also to be taken into account.

Lets say you switch from a European to a British car. In theory it is 
simple. The amount of time you try to find the hand/emergency break or 
gear stick and your hand goes down along the inside of the car's door.


If all you need to do is use git for download, then well it is simple in 
terms, that indeed you just need a "translation".
If you have size restrictions, and can't do a full clone, you need a 
special translation (which you have to find, somewhere in a large manual).
Still if you have time, that is indeed simple. "simple, but one off time 
consuming"


If you need to commit to, then its yet a bit more time consuming. And 
even if you read up, you will end up with a few surprises.
Like you may end up making a commit while detached. Or resetting your 
local tracking branch onto another remote branch.

It's all recoverable.
And for a lot of people at some point it may be worth it, because they 
have new knowledge. Be that only to be put on the CV, or be it that they 
actually benefit from it.


If you need to learn a platform like GitLab with it. Well, we have 
already examples for some pitfalls that it does have.
Example: In a merge-request, which the requestor rebased after making it 
(and before it got rebased) => there is a link, that shows the 
difference of the rebase. There is not much of an explanation there. It 
looks as if those commit between the 2 forkpoints (wrong name) are part 
of the merge request.


So every new set of features does add new pitfalls.

Still IMHO its more than worth it.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 10:53, Christo Crause via fpc-pascal wrote:


On Thu, Aug 12, 2021 at 7:34 AM LacaK via fpc-pascal 
> wrote:



I have related question: in SVN was possible to checkout specific
sub-directory (for example if I am interested in fcl-db package
only I checkedout only this sub-directory).
Is it possible with gitlab? Or I must clone whole
https://gitlab.com/freepascal.org/fpc/source
 ?


There is a relatively new git feature "sparse-checkout" that could 
potentially be used in this case (I haven't tested this).  See e.g. 
https://stackoverflow.com/a/60729017/13781629 




Afaik that is only checkout.
You still clone the entire set of files.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 02:02, Dennis Lee Bieber via fpc-pascal wrote:


And... the local repository will add files for each committed change...

https://www.dulwich.io/docs/tutorial/file-format.html
"""
If you change a single line, another blob will be generated by Git each
time you successfully run git add. This is how Git can fastly checkout any
version in time.
"""



1) Afaik the OT is looking at only checking out. He isn't planing on 
making any (local) commits.


2) yes, for every changed file you commit, a new blob is added (and new 
tree objects too).
From a users point of view, each blob contains the entire file (changed 
and unchanged parts).
But git compresses those blobs. 
https://git-scm.com/docs/git-repack#Documentation/git-repack.txt---windowltngt

So in the end, the disk space used is not that bad.
Still of course, it is significantly more, if you do a full clone, 
rather than just a shallow (depth=1).


I don't know how big your ".svn" folder is, if you checkout a current 
fpc/lazarus.
But as it was pointed out, cloning with depth=1 gives you about 50 MB of 
compressed data, for files worth over 300MB.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 06:26, Michael Van Canneyt via fpc-pascal wrote:


Well, sorry to say, but I don't understand this.

What's so hard about it ?

It's like switching car brands from a VW to an Audi or so.
Some buttons are in different places, your key will maybe look different,
but that's it. It's a car, it brings you from a to b.

A file version system manages versions of files. The actual commands 
differ a little, but that's it.


That comparison is a bit to simple
And the extend has also to be taken into account.

Lets say you switch from a European to a British car. In theory it is 
simple. The amount of time you try to find the hand/emergency break or 
gear stick and your hand goes down along the inside of the car's door.


If all you need to do is use git for download, then well it is simple in 
terms, that indeed you just need a "translation".
If you have size restrictions, and can't do a full clone, you need a 
special translation (which you have to find, somewhere in a large manual).
Still if you have time, that is indeed simple. "simple, but one off time 
consuming"


If you need to commit to, then its yet a bit more time consuming. And 
even if you read up, you will end up with a few surprises.
Like you may end up making a commit while detached. Or resetting your 
local tracking branch onto another remote branch.

It's all recoverable.
And for a lot of people at some point it may be worth it, because they 
have new knowledge. Be that only to be put on the CV, or be it that they 
actually benefit from it.


If you need to learn a platform like GitLab with it. Well, we have 
already examples for some pitfalls that it does have.
Example: In a merge-request, which the requestor rebased after making it 
(and before it got rebased) => there is a link, that shows the 
difference of the rebase. There is not much of an explanation there. It 
looks as if those commit between the 2 forkpoints (wrong name) are part 
of the merge request.


So every new set of features does add new pitfalls.

Still IMHO its more than worth it.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 11/08/2021 22:12, Bo Berglund via fpc-pascal wrote:

Please advice how to:
1) Find which is the latest release tag of fpc and lazarus



Well I don't know your script, and I am not sure how exactly you do that 
in svn


Also I do not know, if this is for a once up setup (so you only wont to 
download the one revision and nothing else), or if you don't mind.

(I have not measured the overhead..>)

Most replies will be to clone all, and then look at tags. (or branches)
But you can do ( -t => tags) https://git-scm.com/docs/git-ls-remote.html

git ls-remote -t https://gitlab.com/freepascal.org/lazarus/lazarus.git

However, there is no "svn serial rev number", nor a date. So you need to 
parse the "release version" number, and compare them.


If you have a complete clone, you can afaik sort them by "commit date" 
(see "git for-each-ref")



2) Retrieve the full sources for that tag on the command line from gitlab




If you do not want to clone

git init .
git fetch --depth=1 
https://gitlab.com/freepascal.org/lazarus/lazarus.git 
refs/tags/lazarus_2_2_0_RC1

git switch -c my-branch FETCH_HEAD

"my-branch" is your choice


*** the rest BELOW is completely UNTESTED / pure assumptions ***

I haven't tested how well updates work, if you go to other branches.
Since you have no history fetched (depth =1), I expect a full download 
of any other version (unless it is a direct child / same branch, NOT 
diverged)


Git is written for getting the full history once. I *guess* (but might 
be totally wrong) that not doing so, will make you pay later.

You could do a depth of 3000 or 1.
That is 2.2.0 (with the ending 0) is likely less that 3000 commits 
divirged from main. Then that gives you common history, and 2.4 can base 
on that.


2.0.18 is probably more revisions from main.

If you only want to stay in the same fixes branch (and are ok with a new 
download for major releases) go with a depth of 500. It is unlikely that 
a release tag will be further away from its fixes branch (usual are 0 to 
5 commits)



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to get fpc and lazarus sources when svn has shut down?

[Martin Frb via fpc-pascal]

On 12/08/2021 06:55, Dmitry Boyarintsev via fpc-pascal wrote:
On Thu, Aug 12, 2021 at 12:27 AM Michael Van Canneyt via fpc-pascal 
> wrote:


It's like switching car brands from a VW to an Audi or so.
Some buttons are in different places, your key will maybe look
different,
but that's it. It's a car, it brings you from a to b.

It's not switching brands, it's switching the type of the car.
from a passenger i.e. to a bus.
It's still a car, but the concept is a little different.



Ah, that is true for selected individuals, if looking at their own plate 
only...


There were issues for those who wanted to switch.

- the need to maintain the server on which it was hosted / to update 
server software.

- the absence of the feature the knew exist / and they knew would help them.

For those that "had to come along", well it's part of the group experience.
Many of them will probably at some point pick up some of the new 
features, and then they can look back and be glad to have learned it. 
(just like the pupil in later live might come to benefit from what they 
learned in school).


For those who will not have the luck of benefiting themself ever, well 
they came along for the "greater good".
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FPC & Lazarus moving to gitlab

[Martin Frb via fpc-pascal]

On 04/07/2021 21:25, Bo Berglund via fpc-pascal wrote:


Does this mean that the sources will disappear from SVN?

From the current svn => yes. afaik


I am using scripts to install FPC and Lazarus on new systems and these use svn
co commands towards:
https://svn.freepascal.org/svn/fpc/tags/
https://svn.freepascal.org/svn/lazarus/tags/

where I pick up the released code based on the tag value and build off of them.

Will that have to change to git now?


Can you spot the tag name in the below?
The rest of the url will change once it is no longer a "test conversion"

https://gitlab.com/freepascal.org/lazarus/lazarus_test_conversion_2/-/archive/lazarus_2_0_12/lazarus_test_conversion_2-lazarus_2_0_12.tar.gz
Also avail as zip.

No guarantees, but I expect that to keep working.
Of course you need to know the tag names.

There are 2 pages helping with using git.
Choose either one and stick with it. (if you try to use both, it will 
get confusing)

By the FPC team:  https://wiki.lazarus.freepascal.org/FPC_git
By me:  https://wiki.lazarus.freepascal.org/SVN_to_GIT_Cheatsheet

I recommend on the long run to switch to git.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Option type

[Martin Frb via fpc-pascal]

On 01/06/2021 22:40, Sven Barth via fpc-pascal wrote:

Am 01.06.2021 um 20:20 schrieb denisgolovan via fpc-pascal:


I am trying to implement Option type in FPC.

type
   generic TOption = record
 case IsSome:boolean of
 true: ( some: T );
 false: ();
   end;


Well as already discovered type like strings can not go into a "record case"

But... The above record is anyway of constant size. I.e. the memory for 
the field is always included, even if it is not used.


Since the "false" block is empty, you can do

type
   generic TOption = record
 IsSome:boolean;
 some: T;
   end;

It is not as expressive to the reader of the code. But it leads to the 
same data in memory.


There is only a diff, if the other blocks of the record (the false 
block) also has/have data.

With case the memory will overlap.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to find where my app consumes CPU?

[Martin Wynne via fpc-pascal]

On 18/05/2021 20:59, Bo Berglund via fpc-pascal wrote:

I have a pretty sizable console app written with Delphi 15 years ago but ported
to Linux using FreePascal (3.2.0) with Lazarus (2.0.12) as IDE.


I have the same problem with high CPU usage for a 20-year-old Delphi App 
compiled in Lazarus(2.0)


When run in debug mode within the Lazarus IDE it runs fine.

When run stand-alone as a Windows exe the CPU usage shoots up to 30% and 
stays there.


I found that the problem is in the Lazarus Application.OnIdle event, 
which fails to honour the Done parameter and runs continuously:



http://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Forms.TApplication.OnIdle

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to find where my app consumes CPU?

[Martin Frb via fpc-pascal]

On 19/05/2021 00:29, Bo Berglund via fpc-pascal wrote:


   While not (bSTerm or bSInt or bsHup) do
   begin
 //Here is where the server runs as defined elsewhere
 //Eternal loop to wait for system messages
 Sleep(1); //To not hog the CPU
 CheckSynchronize; //To get thread comm working
   end;

sleep 1 is not that much. How does it change if you increase it to 
sleep(50) / just for testing?


Also CheckSyncronize afaik takes a timeout.
So if you do not need to check the variables every millisecond, then do

  While not (bSTerm or bSInt or bsHup) do
  begin
//Here is where the server runs as defined elsewhere
//Eternal loop to wait for system messages
CheckSynchronize(50); //To get thread comm working
  end;


For all, else you can try
valgrind --tool callgrind
and  kcachegrind to view the result.

but not sure if that works on a service, maybe you can run your code in a 
foreground process under valgrind?
 


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] [fpc-devel] Nested function closures

[Martin Frb via fpc-pascal]

On 28/04/2021 18:43, Graeme Geldenhuys via fpc-pascal wrote:

Hello Sven,

On 28/04/2021 6:32 am, Sven Barth via fpc-pascal wrote:

Second: the syntax is required for Delphi compatibility anyway

Couldn't such verbose syntax be limited to {$mode delphi} behaviour,
and then leave {$mode objfpc} free to experiment and introduce new
less verbose syntax in the language.


Would omitting the type info not lead to issues with overloaded functions?

foo(function(a,b)

Foo could have lots of overloaded arguments, all taking a callback with 
2 params.

Or it does not have them yet, but later.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] lazarus ide space/dot display

[Martin Frb via fpc-pascal]

On 06/04/2021 18:26, jean-françois Jouvet via fpc-pascal wrote:

does anyone knows how avoid display dot point for space between 2 words?
Thanks in advance



Menu: Tools > Options
Page: Editor > General > Miscellaneous: Turn off "Show special characters"

That will turn off tabs and spaces anywhere.
There is no fine tuning.

However instead of turning them off, you can change the color.
Page: Editor > Display > Color:  In the color tree:  Text > Visualized 
special chars
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Pull request for fphttpclient.pp in git mirror repo

[Martin Frb via fpc-pascal]

On 16/03/2021 22:21, Graeme Geldenhuys via fpc-pascal wrote:


   https://github.com/graemeg/freepascal/pull/18


Review instructions:


For none git users, githup offers patch/diff

https://github.com/graemeg/freepascal/compare/master...billyeatcookies:patch-1.diff
https://github.com/graemeg/freepascal/compare/master...billyeatcookies:patch-1.patch
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicode chars losing information

[Martin Frb via fpc-pascal]

On 08/03/2021 23:26, Tomas Hajny via fpc-pascal wrote:

On 2021-03-08 21:36, Martin Frb via fpc-pascal wrote:



I can think of 2 groups already.
1) Conversion due to explicit declared different encoding.
   AnAnsiString := SomeWideString;
  AnAsciiString := AnUtf8String; // declared as "type
AnsiString(CP_ASCII);" and "type AnsiString(CP_UTF8);"


Do you mean a compile-time warning? The trouble is that the compiler 
wouldn't know whether a real widestring manager would get included in 
the final binary when such conversions are encountered. And remember 
that the final binary may be compiled at a different time from the 
moment when the unit containing such conversions is compiled. In other 
words, compile-time warnings would be rather difficult to implement.

Yes, I mean a compile time warning.
But, not in the above case. In the above case the users could kind of 
reasonably be expected to know a widestring manager is needed.


However, IMHO that differs in the below case:


2) Conversion where at least one string is not explicitly declared for
a certain codepage.
   This should include indirection via $codepage


No, this is not the case. $codepage defines the source file encoding. 
The compiler translates the string constants declared this way to a 
UTF-16 constant stored within the compiled binary. Specifying 
$codepage has no implications on runtime conversions by itself.

So "const Foo = 'abäö';" is always stored as utf-16?
That is something IMHO unexpected.

But more to the point
  var s: AnsiString
  var s2: UnicodeString
  var s3: WideString
  s := Foo;
  s := 'abäö';
  s2 := Foo;
  s2 := 'abäö';
  s3 := Foo;
  s3 := 'abäö';

Does any of the assignments  "s:=" or "s2:=", "s3:=" cause a conversion?
(For this it does not matter if this depends or does not depend on a 
$Codepage / all that matters is, if there is some case in which it 
causes conversion)


If it never causes a conversion, then I misread/misunderstood something.

If it does, it is IMHO very unexpected. After all why include a constant 
in a way that it must still be computed before it can be used?
I do not include pi as a formula to be computed at runtime, I define it 
to the precision I will need (and/or can store) as pre-computed constant 
of 3.14159


So if that causes a conversion, then that is worth a warning/note.
And IMHO it is worth a warning, even if a widestring manager is present. 
Because that conversion which it causes is most likely not wanted by the 
user.




- This could be given, even if the presence/absence of a widestring
manager is not known. Because


Because what?

Reason above.
I hit send accidentality. I then decided to wait, and answer it with the 
next response (i.e. now)




Obviously knowing the presence/absence of a widestring manager allows
to refine warnings.
But I guess that comes at a higher price, as each unit when compiled
could only set flags in the ppu (including forwarding flags from used
units).
And the compiling the final program would read which warning flags are
present, and if any unit flagged the inclusion of a widestring
manager.


Yes, this would be indeed the only possibility.


On 08/03/2021 23:23, Michael Van Canneyt via fpc-pascal wrote:

The compiler has no way to know if the widestring manager actually does a
complete or even a good job. Maybe it just does logging


Even then, the mere fact that the user added a W.M. other than default, 
would indicate that the user is aware, and hence does not need a 
hint/warning.
Sure the user might not be aware..., but it's to catch common problems, 
not every border/edge case.


Still, I agree that the "unit flag" solution is too costly to 
implement/maintain.









___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Unicode chars losing information

[Martin Frb via fpc-pascal]

On 08/03/2021 20:49, Jonas Maebe via fpc-pascal wrote:

On 08/03/2021 19:16, Ryan Joseph via fpc-pascal wrote:

I agree it would be nice to have some warning that indexing the unicodeString 
wouldn't work as expected.

Then the compiler would have to give a warning for any indexing of
unicodestring. That would render it useless, because everyone would just
turn it off. It's not possible to safely use unicodestring without
knowing how 16bit unicode works. The compiler can't solve that.




Indexed access to a string, is different from implicitly inserted call 
to encoding conversions.


In the example the index access should have returned a single codeunit, 
which was known to be a complete codepoint.
As far as I understand the unexpected part was, that the unicode string 
did not contain the content of the string constant, because the 
assignment had caused an encoding conversion to be inserted.

That conversion caused the need for a widestring manager.

Maybe to help the search when/where and whatfor notes/warnings 
should/could be produced, those implicit conversions can be broken down 
into groups.

I can think of 2 groups already.
1) Conversion due to explicit declared different encoding.
   AnAnsiString := SomeWideString;
  AnAsciiString := AnUtf8String; // declared as "type 
AnsiString(CP_ASCII);" and "type AnsiString(CP_UTF8);"
2) Conversion where at least one string is not explicitly declared for a 
certain codepage.

   This should include indirection via $codepage


Then maybe as a first step, a note/warning could be given, if a constant 
string is assigned to a variable, and a change of encoding is needed for 
this.
- "constant string" here would be any string that does not have a direct 
explicit declared encoding.
- This could be given, even if the presence/absence of a widestring 
manager is not known. Because




Obviously knowing the presence/absence of a widestring manager allows to 
refine warnings.
But I guess that comes at a higher price, as each unit when compiled 
could only set flags in the ppu (including forwarding flags from used 
units).
And the compiling the final program would read which warning flags are 
present, and if any unit flagged the inclusion of a widestring manager.





___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 18/02/2021 23:47, Ryan Joseph via fpc-pascal wrote:



On Feb 18, 2021, at 12:33 PM, Martin Frb via fpc-pascal 
 wrote:

   TMyFoo = class(specialize TTrait)
  procedure Foo;
   end;

Of course that can get out of hand, if you want to include many traits.

I'm not really understand this at all. You're still using subclassing, which is 
the thing we're trying to avoid.


Yes and Yes, and maybe Why?

I agree that a dedicated traits solution would be cleaner, and may have 
advances.
For example in the above, the trait can not have a base-trait. (Well it 
can, but it get messy, really messy).

Multiple traits via generic => messy.
And also the conflict resolution behaviour differs.
...


However what is the problem of the subclassing?

1) From the user of the class (the person using the class in their code) 
all methods are in the desired namespace.


2) There is (almost) no performance penality.
Well perfomance:
  SomeFoo is T will need to step the extra classes inbetween.
  And so will  fpc assert objec checks, if enbled. (but thats debugging)

But otherwise I can't think were the resulting class would even need one 
CPU tick more. Calling a method (with the exact same signature) should 
generate the exact same code, independent if it was declared in the 
current or in the base class. (at least if it is not 
overriden/reintroduced in the current, but then you would need to call 
it with the "inherited" keyword, so that would be different.)

none virtual method => known address, just call
virtual method => address from know offset in the VMT. In both cases the 
VMT of the current class. Same thing.



And yes, their is memory. Their is one single block of memory for the 
class data. (It is only once, even if you have 1000 instances). So what?


One could have a WPO optimization, to remove classes from the tree, if 
they are not needed.
- no reference to the class itself: casting, ".. is .." (not possible 
here, since anonymous)

- access via ClassType, ParentClassType etc
- no difference in the VMT compared to the next higher class
- not sure maybe others
But its a lot of work in order to save a few bytes in the exe.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 18/02/2021 22:42, Sven Barth wrote:


You need to constrain T as a TObject, then it works.


Ah that works. With 2 restrictions

TBase can be any class, since a trait can be applied to any class.
So the only known common base is TObject.

(restriction 1)
But "TBase: TObject" means that the trait can not access Self.Base, even 
if the latter passed in type has such a method.

Same with (note the "class" keyword)
 generic TTrait = class(TBase)


Normally if the param to a generic is not restricted you can write 
T.anything, and during specialization this will be resolved or fail.

So that ability is lost.

As a workaround THost can be passed in.
(restriction 2)
That requires a forward declaration of TFoo. Otherwise it fails.


type
  TFooBase = class
    procedure Base;
  end;

  generic TTrait = class(TBase)
    procedure Bar;
  end;

  TMyFoo = class;
  TMyFoo = class(specialize TTrait)
 procedure Foo;
  end;


procedure TTrait.Bar;
begin
  //Self.Base; // fails
  THost(Self).Base;
  THost(Self).Foo;
end;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 18/02/2021 18:46, Ryan Joseph via fpc-pascal wrote:



On Feb 18, 2021, at 10:40 AM, Benito van der Zander via fpc-pascal 
 wrote:

Traits are like reverse type helpers. With the type helper you first declare 
the class and then the extending helper.

Indeed, but with the crucial distinction that helpers don't allow fields, only 
methods.


And they are differently scoped.


There is another approach, but generics do not yet support that

type
  TFooBase = class
  end;

  TTrait = trait
    procedure Bar;
  end;

  TFoo = class(TFooBase)
    _trait: TTrait;
 procedure Foo;
  end;

could be written as

  generic TTrait = class(T)
    procedure Bar;
  end;

  TMyFoo = class(specialize TTrait)
 procedure Foo;
  end;

Of course that can get out of hand, if you want to include many traits.

-

On the other hand, it even would allow support for the Trait to access 
methods from TFoo...


  generic TTrait = class(TBase)
    procedure Bar; // can do    THost(self).Foo()
  end;

  TMyFoo = class(specialize TTrait)
 procedure Foo;  // can call Bar()
  end;

Of course assuming that TMyFoo can already be passed during specialization.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 14/02/2021 18:20, Sven Barth via fpc-pascal wrote:




   TTest = class(TObject, ITest)
   private
 fTest: TTestImpl;
   public
 property Test: TTestImpl read fTest implements ITest; default;
   end;


Well there is a difference there.

Interfaces are essentially inheritance. One can access TTest via "TTest 
as ITest".


A trait (in any of the proposed forms) would not allow that. (Hence a 
trait should probably also not be it the  TFoo=class(...) part).


So that makes 2 differences for trait vs interface
- The result of the composition can not be cast to either of the parts 
making it up

  That is a functional difference
- Traits remove the need to declare all methods twice (once in the 
interface, once in the class (or whatever implementing struct))
  That can be considered syntactic sugar (though it might have a quite 
impacting effect)



Further, IIRC it was said that:
For interfaces the syntax is already fully available. But some features 
are not yet supported by fpc.

Though Delphi has them, so the might come anyway.
However for traits as "default property" the syntax also already exists.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Windows Defender considers fp.exe a malicious program

[Martin Frb via fpc-pascal]

On 13/02/2021 16:52, Ched via fpc-pascal wrote:

Hello,

For one software I compile with fpc, Avast always complained. But only 
when compiled for debugging.
That exe was sent to the false positive departement, and it toke about 
_one mounth_ to have a corrected version of the AV. Afterwhat, he 
never complained even with reworked source code.


I've seen a few false positives on debug info. To be fair, the AV can't 
really tell its not code. It could be used like a resource, later to be 
loaded from the file and then somehow be executed. So if debuginfo 
happens to look like malicious code

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Windows Defender considers fp.exe a malicious program

[Martin Frb via fpc-pascal]

On 13/02/2021 03:55, Travis Siegel via fpc-pascal wrote:
that if you have any timing routines in your code, it tends to get 
flagged by virus scanners.  No clue why, but I've run afoul of that 
issue more than once.


I read somewhere that some viruses have a build in wait, to evade 
sandbox detection. AV companies let unknown exe run in a sandbox, and 
wait if they behave bad.

Viruses evade that by being dormant for a while.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Windows Defender considers fp.exe a malicious program

[Martin Frb via fpc-pascal]

On 12/02/2021 22:48, James Richters via fpc-pascal wrote:

I have no idea how to register a legitimate program as not having a virus.  
I've had this issue before but managed to track down the section of code that 
caused it... after a completely exhaustive search.

Anti virus providers normally have page where you can submit false 
positives.


For windows defender it seems to be here. (unlike most other AV 
companies, you need to sign in)

https://www.microsoft.com/en-us/wdsi/filesubmission

Of course that needs the exe to be detected (well I don't know if AV 
companies accept submissions that are not detected). If you release 
today, your exe can still be detected as avirus in a few month. Once it 
is detected, you can submit it.


That may not solve the issue for self build fp.exe .
If the AV whitelists the exact exe, it will fail the next time you 
build, because fpc includes a timestamp (afaik)

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 11/02/2021 04:13, Ryan Joseph via fpc-pascal wrote:



On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal 
 wrote:

In that case IIRC, it was said traits are not allowed constructors. Why?

Traits are meant to be a way to import fields/methods and is based off of 
"object" (so it's on the stack). This is also important for using properties to 
alias the imported fields. It's the same with subclassing, you don't need to manually 
allocate the super class because it's all one structure with a shared memory space. The 
idea is to make a viable alternative to inheritance in the simplest way possible.

"don't need to manually allocate"
I know, I am using old "object" for that already. So that is not new 
when traits come.


Hence I concluded, the "trait" feature is exactly and only an automated 
generation of forwarder-methods (well exactly they are no longer 
forwarders, but imported / to the user that writes a call to them that 
is the same in the end)


But if the above conclusion is correct (no more, no less that replacing 
the need for forwarders ), then it is reasonable to want the same 
concept for other types... I do not actually advocate it. I simple point 
out what would logically follow (rather than what may or may not be good)



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 11/02/2021 04:20, Ryan Joseph via fpc-pascal wrote:



On Feb 10, 2021, at 7:47 PM, Martin Frb via fpc-pascal 
 wrote:

I understand it is for conflict resolution only. But see my example => as soon 
as you need to repeat a trait with just a change in name, you always need conflict 
resolution.

Please post the code snippet again. I'm not sure I understand what you're 
saying.


TEmployeList = trait
  function  FindByUnallocateWorkTime: TEmploye;
  // other functions/members
end;

TCompany = class
end;

Now the company could have Engineers and Designers. It needs to lists
But the trait can obviously only be added once.
Yet no-one wants to copy and paste the trait to create a 2nd verson

Maybe Something like  (aliasing / no need to copy implementation)
TDesignerList = trait(TEmployeList)
  function  FindDesigerByUnallocateWorkTime: TEmploye; aliases 
FindByUnallocateWorkTime;  // no body /just a name replacement

  // and the others
end;

===>
TCompany = class
  _TraitDesigner: TDesignerList ;
  _TraitEngeneers: TEmployeList;
end;


This is clearly something that can be done later. **IF** the design is 
chosen to allow for it.



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 11/02/2021 03:07, Ryan Joseph via fpc-pascal wrote:

We get the shared namespace
So basically, we get the compiler to automatically create forwarder 
methods for us (or at least that behaviour). And that is all there is. 
right?


In that case IIRC, it was said traits are not allowed constructors. Why?
Now a constructor would and should not have a forwarding method, but 
that the compiler can skip.

Yet, in my code, in the constructor of the TMyClass, I could add
  _traitA.Create
even
  _traitA := TTraitA.Create; // if the trait was not an object, but 
another class.


The compiler can with no doubt create the forwarder methods. And if I 
understand right, then that is all the compiler should do?

(Not that I advertise a trait should be a class / IMHO better not)



procedure TMyClass.DoThis;
begin
   // resolve the conflict by directly referencing the trait
   traitA.DoThis;
end;


This we already can do. Write our own forwarder method.
I understand it is for conflict resolution only. But see my example => 
as soon as you need to repeat a trait with just a change in name, you 
always need conflict resolution.

IMHO, there are many traits that a class could need more than once.

Also that only works, if a trait is included as a field.
There was at least one message in this mail-thread that suggested
  TMyClass = class(TObject, TTraitA);

The solution is on 
https://en.wikipedia.org/wiki/Trait_(computer_programming)
/alias/: an operation that creates a new trait by adding a new name 
for an existing method
Doing that for all methods, means having 2 identical traits, but with 
different names. => no conflict.




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 10/02/2021 21:17, Ryan Joseph via fpc-pascal wrote:



On Feb 10, 2021, at 12:40 PM, Martin Frb via fpc-pascal 
 wrote:

type
   TSomeTrait = trait
   public
 procedure DoTraitFoo;
   end;

   TSomeClass = class(TObject)
   private
 trait: TSomeTrait; // whatever syntax is used so that the trait is added
   public
 SomeVal: Integer;
 procedure DoSome;
 procedure Dispatch(var message); override;
   end;

if it's the simple then just set a reference to TSomeClass inside of 
TSomeTrait. If the trait doesn't know anything about the implementor then you 
indeed need to use a dispatch table or something. Can't this be solved with 
existing features?

btw, I don't think we should model this based on PHP, I just gave that as an 
example. The Swift model is much more simple and does 99% of what you want. I 
think that's what we should do for Pascal also.

I don't have a pro/contra agenda on whether that feature should be part 
of the fpc trait or not.

I just saw it, and thought I raise it.

But also, if any option should be reserved for the future, then it 
matters. Because re-using "sometrait = object end" makes it less likely 
that an "implements" clause will be added (because "object" does already 
have a fully defined syntax).

So I felled it might be worth being noted.

--
Another option would be

  TSomeTrait = trait (basetrait) for (someclass_as_minimum_base_class)

for (someclass) is of course  optional (or rather default to TObject).
So sometrait then can access
   self.any_trait_identifier
   self.someclass_ident

This is a bit limiting at first, but bring in genericts
  generic TSomeTrait = trait (basetrait) for ()
Since it is a generic the compiler will not complain about unknown 
identifiers.


It can automatically specialise, when applying a trait.

Then again the "implements" clause from above could internally create a 
generic too.


--
Btw, next question that just came up

Will traits only apply to classes?

or could a record / advanced record / old object also receive traits ?


And one more thing that may at least be considered for design in case of 
future use.


Consider a Trait
TEmployeList = trait
  function  FindByUnallocateWorkTime: TEmploye;
end;

TCompany = class
end;

Now the company could have Engineers and Designers. It needs to lists
But the trait can obviously only be added once.
Yet no-one wants to copy and paste the trait to create a 2nd verson

Maybe Something like
TDesignerList = trait(TEmployeList)
  function  FindDesigerByUnallocateWorkTime: TEmploye; aliases 
FindByUnallocateWorkTime;

end;

--
Again, none of those are needed. But if they are found interesting
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 10/02/2021 20:17, Ryan Joseph via fpc-pascal wrote:



On Feb 10, 2021, at 11:09 AM, Ryan Joseph  wrote:

type
TSomeTrait = trait
   public
 parent: TObject;
 procedure DoThis;
end;

procedure TSomeTrait .DoThis;
begin
// ??? here is our issue. Is this good enough to call the TBaseClass.DoThis?
TBaseClass(parent).DoThis;
end;

Thinking about this more I don't think there's even a reason for it since Object Pascal 
doesn't let you do stuff like this anyways. If you want to call the super class you need 
to use "inherited" from within the class body.  The example I posted only works 
if there is no virtual/override involved.



Its not about the keyword to be used.
Its not even about the inheritance.

In the example from https://www.php.net/manual/en/language.oop5.traits.php
The trait accesses a method defined in the class to which the trait is 
applied. (It happens to be from the base class, but that does not matter)


In Pascal that would look like

type
  TSomeTrait = trait
  public
    procedure DoTraitFoo;
  end;

  TSomeClass = class(TObject)
  private
    trait: TSomeTrait; // whatever syntax is used so that the trait is 
added

  public
    SomeVal: Integer;
    procedure DoSome;
    procedure Dispatch(var message); override;
  end;

procedure TSomeTrait.DoTraitFoo;
begin
  inherited Dispatch(nil); // from TObject
  DispatchStr('');  // from TObject
  DoSome;  // from SomeClass
  SomeVal := 1;  // if we can access methods, then why not data
end;

In the example
|  parent::sayHello();|
"parent" does not refer to the class containing the trait. "parent" = 
"inherited"


The php example tait's sayHello hides the inherited sayHello => so 
parent is needed.


So in the example this/self of the embedded trait is the entire object 
into which it is embedded.


That means also: the trait and the class must be conflictfree even for  
private variables. (except where maybe cross unit scoping hides them???)


-
Leaving scoping/conflicts aside.

In Pascal TSomeTrait as it is given above can not compile, as it does 
not know what DoSome,SomeVal,Dispatch are. Not until it is embedded.

Well it could compile as a generic...

So, if a trait should have such access, then how to make sure the trait 
can compile?

Maybe:

  TSomeTrait = trait
  imports
// Those must be implement/provided by classes to which the trait is added.
    procedure DoSome;
    SomeVal : integer;
  public
    procedure DoTraitFoo;
  end;

Or (less flexible)
  TSomeTrait = trait
  extends(TSomeClass)  // can extend anything that is inherited from 
TSomeClass (i.e can access anything that a TSomeClass has)

  public
    procedure DoTraitFoo;
  end;
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Traits Proposal

[Martin Frb via fpc-pascal]

On 10/02/2021 16:59, Ryan Joseph via fpc-pascal wrote:

• PHP (trait): https://www.php.net/manual/en/language.oop5.traits.php



The example exposes another aspect:


|trait SayWorld {
public function sayHello() {
parent::sayHello();|


|In this case the trait has access to the object/class into which it is 
embedded. (otherwise it could not call the inherited method of the outer 
class).


Is that wanted?
(methods and fields?)

If that is wanted
- If it will be using the existing "object" (or advanced record), then 
such code is not possible.

- One might have to think about how to declare what a trait can access?
   Just allow anything in the code, and attempt to resolve when the 
trait is embedded? IMHO maybe not?


|
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GetClipboardFormatName causing an Error 216

[Martin Frb via fpc-pascal]

On 31/12/2020 18:11, James Richters via fpc-pascal wrote:

Thanks for the info on SynEdit.  Where can I find the synedit source related to 
the clipboard?
I think the link you indtended ater 'See the code at.' Didn't come though, can 
you pleaese send it again?



Sorry, I assumed SynEdit would be recognized as part of Lazarus (yes its 
the fpc list, but the name may still be known). So I simply gave a file 
location in the Lazarus source.


It can be found here: 
https://github.com/User4martin/lazarus/blob/master/components/synedit/syneditmiscclasses.pp#L1674


Some of the code is specific to SynEdit (E.g. information on code-folding).

But ReadFromClipboard 
https://github.com/User4martin/lazarus/blob/master/components/synedit/syneditmiscclasses.pp#L1699 

checks for either flag being present, and that is all you need. => Then 
the normal text, and line-ends in the text mark where each column ends.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GetClipboardFormatName causing an Error 216

[Martin Frb via fpc-pascal]

I missed you have
FN:=StrAlloc (255);

in that case see Alexanders response.

On 31/12/2020 02:00, Martin Frb via fpc-pascal wrote:


FN must point to an existing buffer (allocated mem) that receives the 
result.


FN : Array [0..255]of Byte;
GotLen := GetClipboardFormatName(Format_Id, LPTSTR(@FN[0]),250);

then "move()" the received bytes into a string, make sure to use 
UniqueString() or similar


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GetClipboardFormatName causing an Error 216

[Martin Frb via fpc-pascal]

On 31/12/2020 01:09, James Richters via fpc-pascal wrote:

Var
FN : LPTSTR;

Begin

FN:='';
Writeln(Format_ID);
GetClipboardFormatName(Format_Id,FN,250);



Check the msdn help.
https://docs.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-getclipboardformatnamea

FN must point to an existing buffer (allocated mem) that receives the 
result.


FN : Array [0..255]of Byte;
GotLen := GetClipboardFormatName(Format_Id, LPTSTR(@FN[0]),250);

then "move()" the received bytes into a string, make sure to use 
UniqueString() or similar


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GetClipboardFormatName causing an Error 216

[Martin Frb via fpc-pascal]

On 31/12/2020 01:09, James Richters via fpc-pascal wrote:

I'm trying to write a programs to get data from the windows clipboard that
was put into it with Notepad++ using vertical editing.


Just for Info, SynEdit (trunk) can handle notepad++ column selection

See the code at.
There are 2 common formats (and as a 3rd the one used by SynEdit).
NP++ uses one of them, not sure which.

components\synedit\syneditmiscclasses.pp
 TSynClipboardStream = class
    class function ClipboardFormatMSDEVColumnSelect: TClipboardFormat;
    class function ClipboardFormatBorlandIDEBlockType: TClipboardFormat;

IIRC in both cases the text is in the normal ClipBoard.AsText. Each line 
is one column segment.


'MSDEVColumnSelect' acts as a flag if present.
'Borland IDE Block Type' has a single byte. the value $02 indicates 
column mode.


Register the format, to get the ID, then check if it is on the clipboard.

Either check the synEdit source, or google the 2 format names
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Off topic Re: TurboVision is reborn as FOSS (again)

[Martin Frb via fpc-pascal]

On 21/12/2020 10:26, Markus Greim via fpc-pascal wrote:

Hello Nikolay,

I am a German - so may be we are both "lost in translation"
Sent from Front

English and German tenses are very much alike. Except for English having 
the progressive forms, which do not exist in German (...ing form)


past perfect (started before the past, and usually either continuing 
into the past or having an effect lasting into the past / used with some 
other event in the past)   // Plusquamperfekt

had had  (had + verb in past)    //  hatte gehabt

past
had  // hatte

perfect (started in the past, still going on or having an effect still 
lasting)


have had  //  habe gehabt
has had (3rd person)

present
have // habe

and for a bit of fun (future perfect / future 2) conjunctive/subjunctive 
mood

causative

I would have had had it done
Würde es getan lassen haben

And if I - in a none nonsensical form - have somebody else possess a hat 
for me (future 2 / conjunctive):

I would have had had the hat had.

Now please, nobody is going to not tell me they didn't have no fun at 
all with this.





On 12/21/20 10:42 AM, Markus Greim wrote:

FPC has had a Turbo Pascal-like console IDE for many years...

"has had" ?

AKAIK "has"

I still used it yesterday.


English is not my native language, but I think "has had" means it 
still has it. If I had said "had" instead of "has had", it would mean 
it had it in the past, but no longer has it. Please correct me if I'm 
wrong.





___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to implement a circular buffer object in pascal?

[Martin Frb via fpc-pascal]

On 03/09/2020 17:44, Martin Frb via fpc-pascal wrote:

type
  TMyData = class
      FData: array of byte;
   end;
  TMyThreadedQueue = specialize TLazThreadedQueue;

Of course you can do
  TMyData = array of byte;  // or record  end if you want
  TMyThreadedQueue = specialize TLazThreadedQueue;


Keep in mind, that if you push an array (or anything containing an 
array), you push a reference.


That is any modification you make to the array content after you pushed, 
will modify the date in the queue. (reference to the same data)


To prevent that you must ensure the data has only one reference holder.
See SetLength
https://www.freepascal.org/docs-html/rtl/system/setlength.html
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to implement a circular buffer object in pascal?

[Martin Frb via fpc-pascal]

On 03/09/2020 16:36, Bo Berglund via fpc-pascal wrote:
A "simplest case" usage example would be nice to have. 

True. Once you got enough info from this thread, please write one.


I still when looking at the sources have no clue as to how it would be
used...

It seems to me like at the very least one should define what type of
data will be stored in the buffer...
Is this how you use it?

var
   MyFifoBuffer: TLazThreadedQueue;  77Whgat do I do about the ???


Ok, I see. It's a generic, so this question is not directly related to 
the TLazThreadedQueue


type
  TMyData = class
      FData: array of byte;
   end;
  TMyThreadedQueue = specialize TLazThreadedQueue;

var
  a: TMyData
  q: TMyThreadedQueue

q := TMyThreadedQueue.create($8000);
a := TMyData.Create;
q.PushItem(a);


Of course you can do
  TMyData = array of byte;  // or record  end if you want
  TMyThreadedQueue = specialize TLazThreadedQueue;

or even
  TMyThreadedQueue = specialize TLazThreadedQueue;

Pushing arrays (dyn ar stat) is fine.

Pushing individual bytes => works. And if you get a byte once or twice 
in a second then it is ok.


If you get bytes every few milliseconds or faster, then pushing bytes 
may be too expensive (I don't know, but I would expect at some point).
In order to push (or pop) the queue has to obtain a lock. You have to 
make sure your computer can handle that fast enough. (maybe it can)






And how do you use ShutDown, DoShutDown, QueSize and Grow?

Very confused.


Grow gives a positive/negative delta. It is added to the current size.
But as I said, for this to work you need the patches.
Also "grow" on a live queue, requires to get the lock yourself. This is 
not automated. (Might be an idea to add that)


- If the queue is full then PushItem will wait until timeout, or until 
something is popped.

- if the queue is empty PopItem will wait in that manner.
If threads are waiting, and ShutDown is called, then Push/PopItem return 
wrAbondoned. (So you need to check for this)


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to implement a circular buffer object in pascal?

[Martin Frb via fpc-pascal]

On 03/09/2020 14:54, Bo Berglund via fpc-pascal wrote:

Now to my question:
Is there some *example* around for using TLazThreadedQueue as a
circular buffer?
In the examples dir are only examples for LazUnicode and
LookUpStringList...
And when reading the sources I cannot really say I understand what it
does or how it works.

Is it even applicable for storing data such as a sequence of bytes
arriving via a serial port?
The names PushItem and PopItem really suggest it works like a LIFO
buffer rather than a FIFO buffer, which is what I need...

LIFO: Last In First Out, like how a stack works
FIFO: First In First Out, like a tube where the items reside for a
while but come out in orderly sequence.



It is FIFO. Its a queue, not a stack.

Look at my latest commits in Trunk to fpdebug > FpDbgUtil
I use the queue there.

Note:
- Calling "grow" when the buffer is NOT empty, works in latest trunk only.
Actually you want that fix anyway, because on Win there is a race 
condition, that could starve individual threads.

r 63811 and 63833 (must take both / I introduced a silly type in the first)

- Calling shutdown (to stop all threads from waiting), may also not 
work, if there are many threads (at least on win). But the fix is in 
trunk, and easy to port. r 63860


You need a type (e.g. class, or array, or pointer) that you can then push.
So if you get bytes from an input, I suggest you push collected chunks 
of them (fixed or dynamic size).



___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] How to implement a circular buffer object in pascal?

[Martin Frb via fpc-pascal]

On 03/09/2020 10:09, Bo Berglund via fpc-pascal wrote:

I would like to create a buffer into which a thread can push incoming
data and the main thread can extract it for processing.
Data are coming from the serial port in a worker thread and should be
consumed by the main thread. The data is a byte stream.

Are there any good examples available?
I have only implemented such systems in C on embedded platforms so it
is not pascal enough to easily port.



Packager LazUtils
unit LazCollectionss

TLazThreadedQueue


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] properties // Re: fpDebug function-call proof-of-concept

[Martin Frb]

On 07/07/2020 15:04, Joost van der Sluis wrote:


Op 07-07-2020 om 12:41 schreef Christo Crause via fpc-pascal:


Great news! I guess this is a step towards evaluating object 
properties via get methods?


That is the final goal, yes.


For this, we will need to start looking at improving the DWARF info.
And most probably adding some vendor specific info.

Afaik, even Dwarf 5 does not supply those

We should probably start a wiki on this

1) Encoding a property. This could be done by:
- Currently properties already point to the Field.
  That could in future be: point to either the field or the getter. => 
Thus any debugger could read the info.
  The type of the property might point to a function declaration (for 
other debuggers)


- Adding a DW_AT_fpc_type_property attribute to the type, so FpDebug 
knows it is a property
  This would be added to DW_Tag_Member  Or for global properties to 
DW_Tag_Variable.
  => FpDebug would (in case of a function) show the property as the 
result type of the function.    (that does not apply for function refs)


- Adding a sub tag    DW_TAG_fpc_setter
  This contains the description of the setter/or the field
  It could be left empty, if the outer TAG describes a field, and the 
setter is direct field access.


The absence of the DW_TAG_fpc_setter would mean a read-only property
Alternatively the outer tag can have DW_AT_fpc_type_property_readable 
DW_AT_fpc_type_property_writeable



2) Extra info for managed data (ansistring, dyn array, smart pointer)
Managed data needs to be marked with DW_AT_fpc_managed
Also maybe DW_AT_fpc_managed_copy_on_write
- This would also make ansistrings distinguishable from 
pchar/array-of-char. Though for that ansistring could also have 
DW_AT_fpc_longstring.


There would also need to be info on
- initial default value: nil
- incref / decref
- alloc mem, for initializing/changing with a value that the user 
specified in the debugger

  Foo('abc') needs to create a string 'abc'.
  Modifying the value of an existing string, also needs this.

3) calling convention?
Not sure what information already exists.



Outside the scope of function calling:

- the dwarf info for nested procedures, and the outer variables that 
they can access, could be improved.

Currently there is some scope info lacking.

- Each unit should have a list of other units, in correct search order.
So global symbols can be found according to pascal scope.

- file of text /file of record
I still haven't figured out what the dwar specs try to archive with 
their definition.

It defines a type, but there is no data to be viewed.
Some users have pointed to what "stabs" did => exposing the internal 
filehandle, so one can see if the file is open. Not exactly "correct" 
but more useful than what dwarf offers.

I have no idea/preference what should happen on this. Just throwing it in.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FpDebug hands-on: AnsiStrings

[Martin Frb]

On 21/05/2020 20:19, Joost van der Sluis wrote:
Might be, you could see this as a saveguard. But my goal is to cut-out 
the middle part of the string. That's formatting

Well, we should have the safeguard. And make it configurable.
... See below

Part 2 is formatting related  In most cases the user does not 
need a 10kb string, the user may want offset 1500 len 500. Ideally 
then the debugger only reads that part. That part may move to the 
formatter. But also may need an extension to target reading the 
correct subset of the data.

Indeed


Now for your goal. That does not conflict with the safeguard. When 
"getting the middle of a string" is added, then the safeguard still 
applies. (Well maybe).


If the user says get me SomeString[1000..1999] (1000 chars) => 
technically the safeguard should apply (no problem if user configurable.
This may sound nonesense, when the user gives hardcode dimensions. But 
what if

   SomeString[1000..1000+i]

Btw, It may be a good idea to teach pascal parser that syntax. (also for 
arrays)


Anyway: A formatter can temp increase the safeguard. So there is no 
problem with keeping it on this level.


To get substrings, one needs to be able to read the length, without 
actually starting to retrieve the text. (would be a waste, to retrieve 
text that will not be needed).

So maybe implement
  GetMemberCount
to return the amount of "char"s (bytes / words for widestring)

And then one new method is needed to get the substring.
Need to check which other dwarf types could benefit. (For arrays members 
are retrieved individually, but maybe target mem could be read and 
cached (like for structures)





If needed I would rather add the 2 new functions. Though it seems the 
data is actually returned as part of the longstring?


No, it is not, because the result is assigned to an AnsiString, and 
therefor the compiler could decide to change it's codepage. In this 
function or somewhere further down the line.

Then the result type should be changed to rawbytestring or whatever is safe?
At least so that the formatter can get it correct. Other calling code 
may assign it to whatever that code wants




What you are saying is that the TFpValue doesn't do the formatting. 
But it retrieves the data. And indeed it's very suitable for that.

Should be that way.



But then, we should be consistent. And do not let any other classes 
(The formatter I was talking about, but also the PrettyPrinter and 
such) retrieve data. Such a class could always create a TFpValue for 
their own use

Have to look at it case by case. Ideally yes.

It may have to be judged for performance:
Array members are gotten by re-using the same TFpValue. Otherwise 
retrieving a large array would be expensive...
If the formatter would all the sudden need to create extra object for 
each array value


Anyway case by case.







___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FpDebug hands-on: AnsiStrings

[Martin Frb]

On 21/05/2020 17:29, Joost van der Sluis wrote:
I've added codepage-support for ansistrings, compiled with -gw3. This 
is done in the TFpValueDwarfV3FreePascalString class, which does the 
heavy work regarding the formatting of strings. Although there is also 
some code in TFpDebugDebugger.EvaluateExpression and probably other 
places that change the formatting of string-values.


So I've made my change in TFpValueDwarfV3FreePascalString, but I don't 
know if this is the right place. After all, it is about formatting, 
and this class is related to the Dwarf-debug info. On the other hand. 
I do understand why this logic in implemented here. This is *the* 
place where all the relevant information is present.


But that the design is problematic can be seen in a comment in the file:

  // TODO: X Dynamic max limit
This is not really about formatting. A corrupt debug target, could 
return a string length of 2^31, not something that the debugger should 
attempt to read. (newer gdb have similar options, if the data is to 
large they return nothing / for strings we can do better and get the start)

That can happen when reading locals before the stackframe is set up.

Part 2 is formatting related  In most cases the user does not need a 
10kb string, the user may want offset 1500 len 500. Ideally then the 
debugger only reads that part. That part may move to the formatter. But 
also may need an extension to target reading the correct subset of the data.


Currently config for FpDebug does not exist. It needs to be integrated 
with the config for LazDebuggerFp (i.e. use TDebuggerProperties so it 
can be streamed). Yet separated from config that is only for LazDebuggerFp.

That is why the value is hardcoded.
I want to avoid having to copy all the values in from LazDebuggers 
config to FpDebug config (which happens now for the 2 configs avail)


max memory limits can be passed via TFpDbgMemReader = class(TDbgMemReader)
TDbgMemReader could have a property that can be read by the dwarf classes.




This seems an easy task, but it is not. 
TFpValueDwarfV3FreePascalString is not bound to the GUI or does not 
have formatting-settings. But it is the place where the formatting 
takes place! But adding a formatting-setting (like a max-length for 
strings) at this location would be really strange.

Well the current code (your commit) does not do formatting.
It adds the info to the string.

The formatter, getting the longstring, can read the codepage from it. 
The formatter can also read the string byte by byte.


 SetCodePage(RResult, Codepage, False);
Does not change the raw data in the string (only the meaning it has).
As long as it does not accidentally get converted while being passed around.

I see two solutions: Besides the AsString property we could add a 
GetAsString procedure with some parameters on how to format the 
string. Maybe the easiest at this moment, and this morning I though it 
was a good idea. (Note that I want to add more stuff, like function to 
retrieve the code-page, and the raw-data)
If needed I would rather add the 2 new functions. Though it seems the 
data is actually returned as part of the longstring?


If you need individual calls to retrieve that info, it could be done by 
something like GetMember.

GetMember has to much overhead. as it returns a big object.

But something like
   GetDataProperty(AnPropId: Integer): Pointer;
would be generic enough to return any additional data.
(yes ID is integer. quicker to much than doing string compare)

Or you add dedicated properties to TFpValueDwarfV3FreePascalString and 
use type casting.  *** For starters, I would go with that, and later 
redesign


I am not sure about adding to many methods to for up the hierarchy, and 
needing meaningless defaults for them.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

Ok, here are some of my ideas/hopes/dreams/wishes for the IDE
They are all "ideas only", with on knowledge of when/if they may be done.

I provide them, in the hope they will help choosing a path for the backend.

The IDE should receive a "TWatchWhateverValue" from any of the backend, 
that provides:


1) async interface (that is actually for the benefit of the backends)
Currently the IDE would call a method (example callstack)
- IDE calls "count" => not yet known = 0
- the backend starts retriving the value, and once the value is avail, 
it triggers an "changed" event

- IDE calls count again.
- IDE starts accessing the items in the list.
  They may be available, but if not the return "evaluating" (or 
whatever dummy value), and the backend will get them and trigger 
"change" again.


Alternative, there could be a CountState, that would return if the count 
is already avail. The trigger to get the count, would still be to call 
"count".


However, the backend must be able to retrieve any requested data from 
fpdebug, and that should be in a format that is ready for the IDE. 
(TDebuggerIntf classes)


Evaluating huge data, may need to be "interruptible" => either called in 
small blocks (like the callstack at current), or by run in a thread, and 
check for an "abort state".

For single watches this is currently not needed.

2) the IDE must be able to retrieve values in different formats, with 
minimum work of the backend (but allowing for async)
- An ordinal value must either be known as ordinal (none text form), 
then the IDE can do dec/hex/bin...
  or it can be retrieved from the TWatchWhateverValue in any of those 
formats (and does not need complete re-eval)

- Hex representation: this can do a re-eval if needed
- A structure may have different text formats (more or less verbose...)
- objects for fields/members (array element) can be retrieved.
  array element, probably re-use one instance, changing the value. One 
would not want to create thousands of instances


Because any op can be async, the current way of just calling the getter, 
and getting a dummy "evaluating" value/object works well.
The IDE does not need to differ if the value is final or not. If it is 
not final a "changed" event is triggered, and the IDE starts again (same 
as if the debugger entered pause)


3) The TWatchWhateverValue must be able to store (and serialize) its 
data. Or a part of it.

It must be able to "work on the stored data only".
Watches are added to debug history. If viewed from history, no further 
eval is possible. The debugged app has changed its state...

Currently this stores the display-text. Limiting changed to display format.
It would be up to the IDE how match the watch stores, and the watch 
would then only be able to return the stored subset of data.
It also must be able to serialize, as the history can be saved/loaded 
to/from xml.


-

The async part may make things tricky

IF a watch asks for the list of fields, it gets TDbgFields or similar.
But a field may be an object with fields of its own.
So if this TDbgField is asked for its field, that must somehow be async to.

Yet the baseclass may not necessary need that implementation..
So PascalBuilder would need to create Fields, but the exact subclass 
could be given by the backend.


Disclaimer: I have not fully thought that through And many thinks 
should probably only be added, when they will be needed.

As I said, just to help keeping the design flexible enough.





___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

On 20/05/2020 19:54, Martin Frb wrote:
If you look at using FpDebug directly, then you use TFpValue. 
(returned by PascalParser, or any Parser you want to add)

All you need is to encapsulate PascalBuilder into a class.
And stick the value and the builder into yet another object, holding 
both of them.


TPascalBuilder would then be a formatter class.
It would also deliver the structures for fields, elements, children.

TPascalBuilder  can be configured, for verbosity. (optino to skip all 
the typenames, it currently includes)


With TPascalBuilder  it can also be passed to whatever code builds 
stackframes. So formatting for those can be affected. (because the 
class carries the config)


And then there is/was the idea with: getting data on request.

Creating a list of objects for all the fields of a class, needs to be 
optional.

Well it is, by means of flags passed to Pascalbuilder.

What is missing, is the ability to later upgrade. There are 2 
considerations.

1) re-reading target mem.
There already is a cache for target mem.
If TFpValue and TPascalBuilder are hold by a "watch value class", this 
can control the cache, and keep the memory.

This memory is only the class. Vaules by ref, like strings are not included.

2) adding list of fields, to watch that was text only
This will also rebuild the text. That can be suppressed, if needed
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

On 20/05/2020 17:50, Joost van der Sluis wrote:
I was very disappointed when i (re?)-discovered that fpDebug has a 
dependency on DebuggerIntf.

It is a bit of a catch22:
- On the one hand, FpDebug is/should be stand alone.
- On the other hand, it would be a pity to have to copy all the used types.

There is basic stuff like TDbgPtr. If needs must, that could be 
redeclared, with IFDEF
But there is also result classes for PascalBuilder (and probably 
somewhere stackframes). Removing this may add a lot of overhead.


FpDebug also uses LazUtils package. And that wont be easy to resolve, 
unless by "copy and paste" :(





Picture1: http://amira.cnoc.nl/fpc/FPDebugDesign1.svg
Picture1 show what I want to achieve. I want to use the formatting of 
variables and such in another environment as Lazarus. And ind the long 
term I want to make it possible  for Lazarus to use other debuggers. 
Also for other languages. (Using DAB or others)

Should the arrows be the other way round?
  console  === "has a / uses " ===> var/type-formatter


Picture2: http://amira.cnoc.nl/fpc/FPDebugDesign2.svg
Picture2 shows the current situation at a high abstraction level. The 
logic for displaying variables is all over the place, as you explained.

Please correct me, if I'm wrong somewhere.
"There are several implementations of DebuggerIntf, each for a specifig 
debugger"

There is only one "DebuggerIntf" (aka API).
The Interface is "designed" to provide base-classes for both: the IDE 
and each backend.


So GDBMIDebugger is a "debugger backend". As such it inherits the 
provided base classes of the DebuggerIntf.

The Backends then use an actual debugger (gdb, lldb, fpDebug)

Formatting does not really happen in the Frontend (IDE) or DebuggerIntf.

It happens either in the "Backend": reformat from what gdb gave us.
Or in the debugger: FpDebug/PascalBuilder.




Picture3: http://amira.cnoc.nl/fpc/FPDebugDesign3.svg
Picture3 shows a possible solution. We add a new class, in the picture 
called 'formatter' to handle the display of variables. As an input it 
will need some 'handler' which implements an interface with functions 
to retrieve debug-information and access memory. It's output can be in 
something like the TDbgVariable format I showed before. (Needs 
adaptation, though).

I think some arrows go the wrong way round?



In the picture I let the IDE make a direct connection to this new 
'formatter'. But maybe it is better to do this in DebuggerIntf.


I also thought about a migration-path: we can just add this new route, 
without using it. And then enable it bit-by-bit. We could alse add a 
'default' implementation in DebuggerIntf. So all debug-handlers may 
use it, or add overrides to do it in a different way.



DAB and Console => those should be handled like debugger backends. 
Except they do not need IDE compatibility. But they do the same task.

And add FpDebugServer.


*** FORMATTER CLASS
First of all "Formatter" (PascalBuilder) is already somewhat exchangeable.
It is currently up to the "backend" what to call to get text.
  "Backend" calls Parser (currently PascalParser) to get FpDebug 
internal value.

  "Backend" hands result to Formatter (PascalBuilder)
The Formatter still needs to read memory. This needs to be the case, as 
the amount of memory to be read can depend on the format (i.e. a pointer 
in the data may display the address, or read the data at the address).


Some formatting should be responsibility of the IDE (or debugger frontend)
1) I.e Changing decimal to hex => no need for the backend
2) On the other hand, the IDE does not know, how to display a 
"structure" (record, class, object, or even none Pascal). That is work 
the backend needs to do.

   (That is as a single text, not be expanding a [+] subitems view)
3) The backend also needs to deliver different data for hex dump.

Most of that exists, in the current classes in TDebuggerIntf. (with some 
issues though)


-
If you look at using FpDebug directly, then you use TFpValue. (returned 
by PascalParser, or any Parser you want to add)

All you need is to encapsulate PascalBuilder into a class.
And stick the value and the builder into yet another object, holding 
both of them.


TPascalBuilder would then be a formatter class.
It would also deliver the structures for fields, elements, children.

TPascalBuilder  can be configured, for verbosity. (optino to skip all 
the typenames, it currently includes)


With TPascalBuilder  it can also be passed to whatever code builds 
stackframes. So formatting for those can be affected. (because the class 
carries the config)


-
For the IDE it is more work. There needs to be an abstraction that works 
with all backends.
And the abstraction must be serializable (for DebugHistory window) / or 
partly serializable.


For the IDE it is important that the "formatter" delivers fields, 
elements, children in the classes provided by TDebuggerInf.
Otherwise the backends, must copy all the data into the 

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

On 19/05/2020 15:55, Joost van der Sluis wrote:

On 5/19/20 12:59 PM, Martin Frb wrote:

Where is that documented? Assuming this is part of the API?
E.g. what goes into Flags/AdditionalInfo?


You misunderstood me. The class above is my own design. The 
variable-definition of DAB is even simpler. (As you already found out)


It is not documented, and, to be honest, only name, value and type are 
being used now. It is just a rough idea, we have to figure things out.

Ah, I see.

In that case, the decision to be made is, if the classes from the 
DebuggerIntf package can be used (potentially after being updated).
There already is TFields, and that can be used (and can be generalized) 
for that kind of thing.


About DebuggerIntf:

1) DebuggerIntf was meant to be the API between IDE and the 
debugger-backend.

The backend is TFpDebugDebugger.
FpDebug is not the backend, its used by the backend. But it currently 
provides for the backend, and that means it uses those classes


2) DebuggerIntf was never "designed".
It was ripped out of GDBMIDebugger, with the hope to be cleaned up and 
refactored. That hope is still there


That also raises the question what you base your DAB classes on.
Some code that you will need, does live in TFpDebugDebugger
- Detecting the instantiated class, instead of the declared class.
- Checking breakpoint conditions (Though part of this should move into 
FpDebug)
- Handling Exceptions / stepping to except,finally (not sure if that is 
likely to move)





Btw, for Children (I guess Fields of a struct?) we have TDbgFields. 
So maybe that can be replaced? But it affects all debuggers


They don't have to be fields. It can be anything. To the user it is 
presented as something they can collapse/expand. If you want to give a 
hint to the GUI how to represent the data, you can set a flag.

Of course.

Arrays should also be collapse/expand able, so you can inspect each 
element (important of array of struct).
But arrays may contain thousands of elements.  So only a subset would be 
gotten at a time.


When designing collapse/expand, it is important to consider, that in the 
IDE data needs to be retrieved in async calls (i.e. IDE requests, 
debugger triggers event if data is ready)

- This is (not only) because gdb debuggers are slow
- This is also because the IDE needs to keep running when many values 
are queried, and the IDE needs to be able to send "step/run" while eval 
still runs => debugger should abort eval, if user wants to continue
Otherwise stepping becomes very sluggish, if you have a bigger list of 
watches.


At least that's how it is implemented in DAB. I thought it would be a 
good idea to add a second 'group of children', the AdditionalInfo. For 
example for the character-set of a string. Things like that.


There are different kind of children (and the question is, if they can 
be mixed)

- named structure members
- indexed/numbered (array) members (low / high / request any (sub)range)
- internal properties (e.g. charset).
- Flags (set of enum)

Internal properties do not need a name. They could have an ID, which is 
an enum.
FpDebug can only provide internal properties about which it knows. So 
the full list of possible ID must always be known.

It would be a list (unique by ID).

Not sure if we need a list of base classes?
It be enough to have one (internal property) "base class", and search 
that recursively. Or allow it to be called with an index.


There also is the question, should (all/some/none) of the internal 
properties be created by default?
The structure could have a field "set of (id-list)" which indicates the 
available internal props. To be created on request.
And when creating a watch, one could pass in a set of ID, that should be 
pre-created.


There also may need to be control over caching the memory that was read. 
If that will still be needed for evaluating further info. (a cache 
exists, and is used for objects)





Though that creates issues:
- Calling in correct thread
- any data retrieval from the debugger needs to be async. I.e. on 
callback. The IDE demands the data, and it will be available in/after 
a callback.
However, maybe that can be done in a subclass/wrapper in the 
TFpDebugDebugger class. That is were the async is currently handled.


Maybe. I don't really have a solution yet. Maybe the reference-id is 
not that bad. (In FPDServer the id is an auto-incremented field. In a 
map I store the related info, like the thread-id, callstack-index and 
such. When this info is not available anymore, the item is removed 
from the map. Seems to work ok)


It depends a lot where the cut between FpDebug and FpDebugDebugger goes.

FpDebug would not be async. But the design should allow for the caller 
to easily add that.


Also one more note:
- It should not affect above design to much
- I have not yet looked into how to archive this, but threading may get 
added to fpdebug at some time (not 

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

On 19/05/2020 12:59, Martin Frb wrote:

Where is that documented? Assuming this is part of the API?

The closest I could find:
https://microsoft.github.io/debug-adapter-protocol/specification#Types_Variable

I would much prefer if "Flags: TStringArray" could be a "set of (...)"
And then somehow be mapped.

FpDebug could take a "class of TDbgVariable". And then create whatever 
subclass you need.

So your subclass could map that into strings.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

On 19/05/2020 10:42, Joost van der Sluis wrote:


Yes, you write about it earlier. Now it's time to discuss things.

Looking at the DAB-protocol I came to some new insights. Microsoft 
managed to create a simple interface which makes it possible for all 
kinds of debuggers to work with the same GUI. Just by adding an 
abstraction layer.


Only thing is that I missed a few functions and do not need others.

So I've added my own abstraction layer. Now it is in the FPDServer 
project, but I think it should be made part of fpDebug itself.


It is basically this class: (see 
https://gitlab.freepascal.org/Joost/fpdserver/blob/master/fpdbgvariables.pas)


  TDbgVariable = class
  private
    FName: string;
    FValue: string;
    FType: string;
    FVisibleInScope: Boolean;
    FFlags: TStringArray;
    FAdditionalInfo: TDbgVariableList;
    FInheritedChildren: TDbgVariableList;
    FChildren: TDbgVariableList;
  published
    property Name: string read FName write FName;
    property Value: string read FValue write FValue;
    property : string read FType write FType;
    property VisibleInScope: Boolean read FVisibleInScope write 
FVisibleInScope;

    property Flags: TStringArray read FFlags write FFlags;
    property AdditionalInfo: TDbgVariableList read FAdditionalInfo;
    property InheritedChildren: TDbgVariableList read FInheritedChildren;
    property Children: TDbgVariableList read FChildren;
  end;

I think that we can give a frontend (Lazarus, Console, DAB) all the 
information it needs with this structure.


The advantage is that it is layered, so a GUI can collapse 
information. We could expand the TDbgVariableBuilder to create these 
structures.


For strings for example, we could add the length, string-type, 
binary-representation and character-set of the string in 
AdditionalInfo. In VS Code this info will end-up as a child of the 
variable, which a user could expand if needed.


A lot of the existing functionality can be used.

Where is that documented? Assuming this is part of the API?
E.g. what goes into Flags/AdditionalInfo?

Btw, for Children (I guess Fields of a struct?) we have TDbgFields. So 
maybe that can be replaced? But it affects all debuggers


Things like Children should have a Getter, so they can be produced on 
demand.

Though that creates issues:
- Calling in correct thread
- any data retrieval from the debugger needs to be async. I.e. on 
callback. The IDE demands the data, and it will be available in/after a 
callback.
However, maybe that can be done in a subclass/wrapper in the 
TFpDebugDebugger class. That is were the async is currently handled.


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] fpDebug extension for Visual Studio Code

[Martin Frb]

On 18/05/2020 23:43, Joost van der Sluis wrote:
All the basics should work, if someone could test it a bit that would 
be nice.


Threading-support is still very lacking, and how variables are 
presented is not really nice. I'll be working on that.


While this can be changed in PascalBuilder, there are some considerations.

Some of those may want to become configurable. So not sure yet.
More likely the formatting may want to depend an arguments passed to the 
functions.
In the Lazarus IDE currently representation of the values is entirely to 
the backend. And that is plain wrong. The IDE will have to have some 
influence on that.


I haven't yet given it much consideration. Just putting it out there for 
thought

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Debug-Adapter-Protocol support for fpDebug

[Martin Frb]

On 26/04/2020 20:58, Mattias Gaertner via fpc-pascal wrote:

On Sat, 25 Apr 2020 15:49:30 +0200
Martin Frb  wrote:


On 23/04/2020 22:10, Joost van der Sluis wrote:

But maybe it should become a separate package now. Lazarus can use
is as a dependency. We'll see.

That would then reverse the burden

As it is part of bigide, it must be shipped with the installer.
And also having it in the Lazarus repro means that there is no issue
with version incompatibilities.

Good point.

Maybe fppkg or fpcupdelux can support a more granular lazarus.


Having a package in the Lazarus svn, or outside makes quite a difference.

The debugger packages in the IDE relay sometimes on the exact revision 
of fpdebug (and I assume codetool is not so different in that).

Sometimes the interface between them will have to change. [1]

People using trunk IDE then need to always know the correct revision of 
fpdebug.
But even if they can use older/newer versions => see below what happens 
if they are not bound to one fixed correct version.



For installation packages (release installers), someone would need to 
rewrite the build scripts. But that is not all.
Currently the next version is getting tested in trunk. All testers test 
with the correct package version mix.
Once we can no longer be sure that trunk users used the correct version 
of externals, we need a lot more testing of the release builds.
(This is not just some external package, the stability of the IDE itself 
depends on it)



Further more, it is not only the IDE that relies on fpdebug.
fpdebug relies on the Lazarus packages DebuggerIntf and LclBase.

Given the above, taking fpdebug out of the Lazarus svn would (as it is 
currently) would probably make it more fragile.


===
[1]
I can foresee a few things about PascalBuilder.
Currently the entire formatting of values happens in fpdebug (not even 
LazDebuggerFp, but fpdebug).

However, some part of the formatting belong in the frontend.
Example: A watch of an integer, can be shown decimal or hex. That is 
something the frontend should do. It currently happens in fpdebug.

There is probably more.

Of course this poses a problem for external projects, which face the 
reverse problem.

But either one side needs to use specific revisions. Or a fork is needed.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Debug-Adapter-Protocol support for fpDebug

[Martin Frb]

On 25/04/2020 16:07, Ryan Joseph via fpc-pascal wrote:



On Apr 24, 2020, at 3:10 AM, Joost van der Sluis  wrote:

I'm working on the support of the debug-adapter-protocol for fpDebug. It's 
quite easy to implement, as there already is a json-based tcp/ip interface. 
(https://microsoft.github.io/debug-adapter-protocol)

I use the debugger in VSCode and while LLDB works pretty well, short strings 
are always a problem. I've never used fpDebug though so I can't say if it's 
better than LLDB (I thought it was no very mature).


FpDebug has the advantage that it knows "fpc".

That is on top of what is specified by the dwarf info, fpdebug does look 
for other info.

Of course only, if it the dwarf info contains the producer = fpc.

ShortString (depending on dwarf version) is IIRC encoded as record. So 
any debugger will show this. But fpdebug looks for some details in how 
fpc writes various dwarf entries. And then detects it as shortstring. 
Though this works for known fpc versions only.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Debug-Adapter-Protocol support for fpDebug

[Martin Frb]

On 23/04/2020 22:10, Joost van der Sluis wrote:
But maybe it should become a separate package now. Lazarus can use is 
as a dependency. We'll see.


That would then reverse the burden

As it is part of bigide, it must be shipped with the installer.
And also having it in the Lazarus repro means that there is no issue 
with version incompatibilities.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Issues with svn?

[Martin]

I suddenly start receiving errors:
B:\FPC\SVN\build_fixes_3_2\fpcsrc
Error running context: An existing connection was forcibly closed by the 
remote

 host.
B:\FPC\SVN\build_fixes_3_2\fpcdocs
Unable to connect to a repository at URL
 'https://svn.freepascal.org/svn/fpcdocs/trunk'
Error running context: An existing connection was forcibly closed by the 
remote

 host.

Are there any known issues?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Prevent full unit path in ppu files? together with -Ur

[Martin Frb]

On 12/04/2020 16:31, Martin wrote:

When building packages for an installer, one uses -Ur.

Yet (on Windows) I noted, that the ppu contain the full path to the 
source file used to build that ppu.


Not a major issue, but slightly awkward.
- The files (ppu, and maybe sources) will be packed into an installer
- The end user installs them to a patch of their choice. This is most 
likely different from the build system.


In the best case, the end users system has now links to none existing 
files.
In the worst case, the links point to a different installation, with 
different versions of the files.


Well probably no harm, since fpc will not recompile those files.
Problematic maybe if other tools (like Lazarus) read that info from 
the ppu.


Therefore the question: Can that full path be prevented from getting 
into the ppu (or any other file)?




Just digging a bit deeper, searching all files indicates that this full 
path is stored in *.fpm files

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Prevent full unit path in ppu files? together with -Ur

[Martin]

When building packages for an installer, one uses -Ur.

Yet (on Windows) I noted, that the ppu contain the full path to the 
source file used to build that ppu.


Not a major issue, but slightly awkward.
- The files (ppu, and maybe sources) will be packed into an installer
- The end user installs them to a patch of their choice. This is most 
likely different from the build system.


In the best case, the end users system has now links to none existing files.
In the worst case, the links point to a different installation, with 
different versions of the files.


Well probably no harm, since fpc will not recompile those files.
Problematic maybe if other tools (like Lazarus) read that info from the ppu.

Therefore the question: Can that full path be prevented from getting 
into the ppu (or any other file)?


___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] Error on https://www.freepascal.org/download.var

[Martin]

The page https://www.freepascal.org/download.var gives an error.

It is still linked in many places as the download page for fpc.

Has it moved, or does it need fixing?
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375

[Martin Frb]

On 02/02/2020 04:22, fredvs via fpc-pascal wrote:

Hello everybody.

Good time to go back with that problem and fix it forever the right way!
The problem is isolated and is fixed "hardcoded".

 From rev 42375, in msegui function dynarrayelesize(const typinfo:
pdynarraytypeinfo): sizeint; inline;
the result is always = 0.



I do not know if fpc has an official way to get the size of an array 
element from the typeinfo.


But comparing the internals:
{$ifdef VER3_0}
  typeInfo:=aligntoptr(typeInfo+2+PByte(typeInfo)[1]);
{$else VER3_0}
  typeInfo:=aligntoqword(typeInfo+2+PByte(typeInfo)[1]);
{$endif VER3_0}

So alignment changed, which is why the old code no longer works

mse always does

 ti:= aligntoptr(ti);

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

[fpc-pascal] threads, memory barriers and RTLeventSetEvent / RTLeventWaitFor

[Martin]

I am currently looking at a strange issue in FpDebug.

The main thread loads a lot of data from a file, and creates various 
objects.


Then some code is executed in a sub-thread. The timing of that 
(start/stop of the 2 threads) is handled by RTLeventSetEvent / 
RTLeventWaitFor.
This code does not seem to find (some of/ all?) the data. (for 
comparison, on windows the same code continues to run in the main 
thread, and finds the data).


So the suspicion arises that maybe the thread has older data cached?

Therefore my question:
Does RTLeventSetEvent / RTLeventWaitFor make sure memory is synchronized 
between threads?


//MAIN thread
procedure TFpDebugDebugger.ExecuteInDebugThread(AMethod: TFpDbgAsyncMethod);
begin
  assert(not assigned(FFpDebugThread.AsyncMethod));
  FFpDebugThread.AsyncMethod:=AMethod;
  RTLeventSetEvent(FFpDebugThread.StartDebugLoopEvent);
  RTLeventWaitFor(FFpDebugThread.DebugLoopStoppedEvent);
  RTLeventResetEvent(FFpDebugThread.DebugLoopStoppedEvent);
  FFpDebugThread.AsyncMethod:=nil;
end;

// OTHER thread
procedure TFpDebugThread.Execute;
begin
...
    repeat
    RTLeventWaitFor(FStartDebugLoopEvent);
    RTLeventResetEvent(FStartDebugLoopEvent);
  if assigned(FAsyncMethod) then
    begin
    try
  FAsyncMethod();
    finally
  RTLeventSetEvent(FDebugLoopStoppedEvent);
    end;
    end;
    until Terminated;
end;

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Illegal counter variable?

[Martin Wynne]

If step is wanted, it's easy enough:

For n:=a to b Do
   Begin
     if n Mod step <> 0 then Continue;
     ...



p.s. make that

  if (n-a) Mod step <> 0 then Continue;

for cases where a is not a multiple of step.

Martin.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Illegal counter variable?

[Martin Wynne]

I am not aware of any Pascal implementation that does have a STEP 
parameter for FOR loops


If step is wanted, it's easy enough:

For n:=a to b Do
  Begin
if n Mod step <> 0 then Continue;
...


Martin.

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Illegal counter variable?

[Martin Wynne]

On 09/09/2019 15:11, James Richters wrote:

If (I>86) And (I<95) then Continue;
What does continue do exactly?  Loop back to the beginning of the for loop 
right away?


Hi James,

Yes in effect -- it jumps forward to the test at the end of a loop. Very 
useful.


See: https://www.freepascal.org/docs-html/rtl/system/continue.html

cheers,

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Illegal counter variable?

[Martin Wynne]

On 09/09/2019 13:38, James Richters wrote:

Var
I:Byte;
Begin
   I:=57;
   For I := I to 100 do
 Begin
If I=87 then
   I:=95;
Write(I,' ');
 End;
End.


Why not:

Var
I:Byte;
Begin
   I:=57;
   For I := I to 100 do
 Begin
If (I>86) And (I<95) then Continue;
Write(I,' ');
 End;
End.

which is much easier to follow the logic.

cheers,

Martin.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Very vague gettickcount64 description?

[Martin Frb]

On 08/09/2019 02:07, Alexander Grotewohl wrote:
but the resolution is not a ms at all. every call to gettickcount is 
something like 10-15ms or so off. you'd be lucky to call it a ms after 
it was updated by the os. do we document that too?

As I said: "The minimum resolution may vary, and may be more than one tick."

I have no crystal ball, but I would guess, that when it was first 
introduced, it aimed to mimic the windows function.
The point is, it is not very exact. And it may on some platform already 
have completely different units.


But that does not mean, it needs to be changed on existing targets. And 
if it is not going to be changed, then it can be documented.


While I can only speak from my experience, a typical usage would be a 
"timeout" (or timer) in a calculation loop. The loop would utilize the 
CPU all the time. So a TTimer  would not be all that practical.
But every about 100ms you want to call ProcessMessages that is likely 
more expensive than GetTickCount. (ok move it to a thread, but that is 
not the point).
So you check the diff between to GetTickCount. A diff of 100 means 
around 100ms +/- something (in that case +/- 50% would even be ok).
But make GetTickCount = 0.0001ms, and it matters (too much time in 
ProcessMessages / slowdown of calculation).


In some unit test, I use it for timeouts of 5 or 10 seconds. It does not 
matter if that is 4 or 6 (8 to 12) seconds..., just approx.




___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal