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] 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] 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] 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] 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] 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] 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) ); // Integer

  writeln;
  writeln('  c,b = ',Add(c, b) ); // Cardinal
  writeln('  

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 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

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

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

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

Re: [fpc-pascal] Very vague gettickcount64 description?

[Martin Frb]

On 07/09/2019 21:42, Zoe Peterson wrote:

GetTickCount and GetTickCount64 are Windows API functions that are
explicitly documented as returning milliseconds, and FPC on Unix up to
now is has matched that. Why in the world would you think that
changing that behavior would be a good idea, *especially* if you keep
the function name the same?!?

As an FPC user, this seems like an astoundingly bad decision to even
be considering.



I do back that.

vague-ness or "the absence of documenting" is  not the same as (from the 
beginning on) documenting that "the unit is not given, *because* it may 
*vary*"


I would suggest to amend the documentation to the current state. 
Something like:



The length of a tick depends on the platform/OS/...
Therefore a tick can be a different amount of time on different targets.

For the following targets, the ticks are specified as follows. For other 
targets they may change, until documented.

Windows: tick = millisecond
Linux: tick = millisecond
OSx/Mac/Darwin: tick = ?

The minimum resolution may vary, and may be more than one tick.
The function itself may also take a varying amount of ticks, and the 
returned result may on top of resolution issues be outdated by any 
amount of ticks.

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

Re: [fpc-pascal] specify variable name with string variable

[Martin Frb]

On 08/07/2019 14:09, James Richters wrote:

I'm on windows

Generics.Collections seems to be something that was added after 3.0.4,  I've 
downloaded the current FPC source code, but I’m not sure how to build it.. can 
someone point me in the right direction on how to compile the current source 
code?



If it is in 3.2-beta, you can get a 3.2-beta from here: 
https://sourceforge.net/projects/lazarus-snapshots/files/

You can install as 2ndary install.

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

Re: [fpc-pascal] specify variable name with string variable

[Martin Frb]

On 08/07/2019 14:09, James Richters wrote:

I'm on windows

Generics.Collections seems to be something that was added after 3.0.4,  I've 
downloaded the current FPC source code, but I’m not sure how to build it.. can 
someone point me in the right direction on how to compile the current source 
code?



If it is in 3.2-beta, you can get a 3.2-beta from here: 
https://sourceforge.net/projects/lazarus-snapshots/files/

You can install as 2ndary install.

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

Re: [fpc-pascal] Lazarus Release 2.0.2 - suggestions

[Martin Frb]

On 16/04/2019 22:17, Ralf Quint wrote:

On 4/16/2019 1:11 PM, Martin Frb wrote:

On 16/04/2019 22:03, Ralf Quint wrote:


Schwachfug. (Bollocks for the Anglophiles around here)

And for those with American English: B*S*

But I really dont see where to put 2nd, let alone a 3rd  50 inch 
screen. ;) ;) ;)


Showoff! :P

You did read my next line? "not"



PS: Seriously, I rather buy 2 (or 3) smaller 24" or 27" monitors than 
one 50". Maximizing any window on such a big screen (even if it would 
support a pixel resolution that would be the same as 2-3 smaller 
screens) is still a HUGE downside, beside the mere cost...

You are preaching to the choir

I never maximize any of the IDE windows.
Typically I have 2 source editors, side by side, full height (which 
means I need another screen for the IDE main bar, and msg window).


But screens space belongs in the category: You don't miss what you don't 
know.
I remember hacking 68k asm on a 14 inch tube I was perfectly happy 
with then, with the space I had.

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

Re: [fpc-pascal] Lazarus Release 2.0.2 - suggestions

[Martin Frb]

On 16/04/2019 22:03, Ralf Quint wrote:


Schwachfug. (Bollocks for the Anglophiles around here)

And for those with American English: B*S*

But I really dont see where to put 2nd, let alone a 3rd  50 inch screen. 
;) ;) ;)


... not (unfortunately)

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

Re: [fpc-pascal] Lazarus Release 2.0.2 - suggestions (screen reader)

[Martin Frb]

About ctrl+shift+arrow key: Do you know any documentation on how to 
implement this. What API to call, to let the screen reader know?


Also for other modifications needed, any documentation?

--

On 16/04/2019 14:31, Mgr. Janusz Chmiel wrote:
For now, I would like to thank you, that you have allowed visually 
impaired users to use edit field inside source code wiev. Screen 
readers users are even notified about line number on focus. Sure, 
because it is not standard Windows Microsoft Edit control, it is 
impossible to use CTRL+SHIFT+arrow keys to assign some block of text 
with screen reader, but I know, that also commercial Delphi which uses 
his own controls not standard Windows controls from Microsoft have 
similar issue.
The most difficulty question is to determine, what is more complex. 
Modify Lazarus component sources or customize NVDA screen reader for 
accessibility of non standard controls.


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

[fpc-pascal] MacOS wrong timestamp in debug map object file

[Martin Frb]

I don't know the Mac well enough... What could cause the below?

From
https://forum.lazarus.freepascal.org/index.php/topic,44950.msg317604.html#msg317604

The logfile tells that the units have been compiled right before lldb 
was launched. So the date 15.4 should be correct.


LLDB complains
error: project1 debug map object file 
'/Users/andy/Lazarus/lcl/units/i386-darwin/carbon/carbonint.o' has 
changed (actual time is 2019-04-15 12:17:05.0, debug map time is 
2019-04-11 08:51:18.0) since this executable was linked, file 
will be ignored


Our code in the IDE also rejects the files because of the wrong timestamp.

Apparently the files may be on an NAS. Not sure if relevant... I.e. 
maybe if there is some cache...


I suspect it might be the linker (from apples developper tools?) that 
writes the timestamp into the debug map? So not fpc?
Would the linker maybe have it's own cache, that may cause something 
like this?


I also (strongly) suspect, that the files have been recompiled once or 
more between the 11th Apr, and the current date. If so, then the linker 
(if it is the linker) must have some cache somewhere.
This is because the same issue is in yesterdays log. The files also 
where rejected. With the 11th April in the debug map. But yesterday they 
would not have had todays timestamp...


Or maybe it is creation vs modification time?

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

Re: [fpc-pascal] class contracts [[was: Re: Optional param modifier]]

[Martin Frb]

On 15/04/2019 09:41, Sven Barth via fpc-pascal wrote:

Am 14.04.2019 um 23:48 schrieb Martin Frb:
As for "documentation". I disagree with the way it is done in oxygen. 
But I am not sure I have any good alternative.

For me a class contract (require/ensure) is part of the interface.


Putting them in the implementation as oxygen does may also cause a 
technical issue.

As pointed out, for a class the contract also affects inherited methods.


Unit A
interface
  TFoo= class
    procedure DoFoo(a:TSome); virtual;
 end;
implementation
uses B;
  procedure DoFoo(a:TSome);
  requires
    whatever



Unit B;
interface
uses A; // AFAIK can only read the interface, the implementation has a 
circular "uses B"

  TFooSpecial= class(TFoo)
    procedure DoFoo(a:TSome); override; // needs to know implementation 
details from unit A

 end;


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

[fpc-pascal] class contracts [[was: Re: Optional param modifier]]

[Martin Frb]

On 15/04/2019 09:41, Sven Barth via fpc-pascal wrote:

Am 14.04.2019 um 23:48 schrieb Martin Frb:

type
  TFoo= class
 function DoTheFooThing(Foo1, Foo2: TFoo): Tbar;
    requires
   assigned(Foo1) or assigned(Foo2): 'Need at least 1 foo, 
for the connection';

    guarantees // better than ensure
   assigned(result);
   result.KnowsMyFoo = true: 'Connection exists';  // the 
=true is redundant

    procedure DoTheBar;
  end;

It is to be noted, that requires and guarantees contain conditions 
(expressions), not pascal code. So technically it is ok, that they 
are in the interface and not implementation.
If I want something in the implementation, I can use normal "assert" 
(which by the way, have often great documenting value)
The problem is that both "require" and "ensure" can check for fields 
as well (think of a setter for example or something that changes the 
state). Thus you could use a field name that the compiler does not yet 
know. So you would need to order your methods in a order dictated by 
the compiler due to the method's implementation instead of an order of 
your own choosing.


And yes, that would also be a problem with "class invariants", though 
there it's more clear if we say that only identifiers can be used that 
have been declared before as it's the same with properties and their 
setters/getters.


Also to be ask if properties can have contract conditions. Especially 
thinking of indexed properties, where the index is a constant. Several 
properties using the same getter/setter (with diff index) may have 
different conditions for the contract.


Yes accessing fields is valid. Though easily leads to confusion what 
should and what should not be in the contract. (Yet that is not to be 
enforced...)
I saw an example, where the "ensure" of a setter checked that the field 
was set. That may be valid, but it also may have been something for a 
normal assert. Depends on the intend.
The ensure (again I prefer guarantees) is a contract. (between the 
class/method and someone else).
So if the check for the field is an internal detail, it should be a 
normal assert.  (the getter result, could be part of the contract then / 
that is different)


Only a normal assert is not quite the same. Contracts are checked too, 
if an inherited overwritten method is called. Assert are not (not if 
there is no call to inherited).
So a contract post condition could be used to make sure that any 
overwritten setter method will have changed the field. In that case the 
partner in the contract is the inherited class. And the post condition 
is less of a guarantee, but more a hidden requirement to the contract 
partner.


Anyway about the field order (and there could be circular 
requires/guarantees)

It would be an option to specify the contract details deferred

type
  TFoo= class
 function DoTheFooThing(Foo1, Foo2: TFoo): Tbar;
 procedure DoTheBar;
// need full declaration, could be overloaded // may skip param names?, 
just types should be ok

     requirements for DoTheFooThing(Foo1, Foo2: TFoo): Tbar;
   assigned(Foo1) or assigned(Foo2): 'Need at least 1 foo, for 
the connection';

 guarantees for DoTheFooThing(TFoo, TFoo): Tbar;
   assigned(result);
   result.KnowsMyFoo = true: 'Connection exists';  // the =true 
is redundant

  end;

Bit awkward because you need the full signature
The compiler could allow both the "requires" right after the method, and 
the deferred "requirement for"


Alternative (but I do like that even less) named forward requirements
type
  TFoo= class
 function DoTheFooThing(Foo1, Foo2: TFoo): Tbar; requires 
'WhatTheFooWants';

 procedure DoTheBar;
     requirements for WhatTheFooWants;
   assigned(Foo1) or assigned(Foo2): 'Need at least 1 foo, for 
the connection';

  end;

That way, 2 methods could refer to the same requirements block.
Then it could even be possible to refer to several blocks
 function DoTheFooThing(Foo1, Foo2: TFoo): Tbar; requires 
'WhatTheFooWants', 'TheFooSpecials';


But this will make it hard to read. Especially in the reverse, if you 
are in a named requirement block, it is not easy to find all methods 
that are affected by it.


Anyway just throwing in some ideas and possibilities.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 15/04/2019 01:19, Ryan Joseph wrote:



On Apr 14, 2019, at 7:08 PM, Martin Frb  wrote:

Almost. assert takes the condition itself

assert(condition_that_must_be_true, 'error message')

so it would be
   assert(name<>'', 'requires "name <> " failed for CreateHero');

You can already insert such asserts yourself. assert exists.

If you compile with -Sa then they are compiled in the code, otherwise not.

 From the compilers perspective isn’t it faster to test the condition first in 
an if statement so the assert function doesn’t get called? Assert tests for 
false also so it needs to invert the test to “name = ‘’” which is not how the 
“requires” statement is worded.

I’ve always made a “fatal” function which works in the opposite direction as 
assert, i.e if the condition is *true* then crash. Don’t know why but that’s 
easier for me to understand. I like the requires section because it works in 
the same logic.


You had

requires
  name <> '';

Or in other words: bail if name = ''

  assert(name<>'', ...)
does that.
It bails if name = ''. (then the condition "name <> '' " would be false 
=> bail)


requires, like assert want the condition(s) to be true

Assert is for testing, so speed doesn't matter.
I don't know how it is internally implemented.

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

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 15/04/2019 00:53, Ryan Joseph wrote:


Here’s what I imagine that would look like:

procedure CreateHero (name: string; hp: integer);
requires
   name <> '';
   (hp > 0) and (hp < 100);
begin
   // compilers parses the conditions and inserts as if statements:
   // if name <> ‘’ then
   //   assert(‘condition "name <> ‘'" for CreateHero failed’);
   // if (hp > 0) and (hp < 100) then
   //   assert(‘condition "(hp > 0) and (hp < 100)" for CreateHero failed);
end;




Almost. assert takes the condition itself

assert(condition_that_must_be_true, 'error message')

so it would be
  assert(name<>'', 'requires "name <> " failed for CreateHero');

You can already insert such asserts yourself. assert exists.

If you compile with -Sa then they are compiled in the code, otherwise not.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 22:08, Ryan Joseph wrote:

function FindThing: TThing; optional;

means you MUST check for nil. If the value is nil that’s not an error. 
“optional” is probably a bad name for this I know.

function MakeThing: TThing;

this means maybe check for nil or maybe not check for nil. We don’t know what 
the programmer intended because no extra information was given (at least in the 
declaration). Because of the name we probably assume this is going to return a 
new object which is safe so checking for nil would be a waste.


I would actually argue that it is infinitely more important to check for 
nil after MakeThing. (Unless I know for sure it is not needed: proof, docs)


Assuming (taking the danger of doing so) both do what there name 
indicates, then:
- If I forget to check after FindThing, it is likely to cause an error 
very soon, and most probably while I am testing myself.
- If I forget it after MakeThing, it may be very rare to cause an error. 
It will likely pass my tests, and cause a customer of mine some stress.



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

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 23:48, Martin Frb wrote:


I admit the contract/assert stuff may have made it seem different. But 
that is because this approach does not hold up (IMHO). And therefore 
the closest alternative was presented.


In the very end it is to avoid crashing on nil de-ref. And the 
contract/assert can help there. Though in a completely different way.


The contract actually can lead to the thing you want. Though you need to 
complete it for *all* your code, rather than just one or two functions


If/Once you have your entire code base with contracts, you know that any 
method/function that does not have a "assigned" contract, can return nil 
(i.e. nil is a documented expected return value / or input )


So at that time, you can enable a compiler warning of the kind you 
wanted. It would act on all the params/results that per contract can be 
nil (are not forbidden to be nil).


-
The only thing you do not have, is the undefined bit. The it can return 
nil, but I do not want to check it.
If you really want that, there will be a directive like {$PUSH}{$R-} 
 {$POP}.

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

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 22:08, Ryan Joseph wrote:


Per my example, currently we know that GetThing() COULD return nil so unless we 
know what the function does by reading the documentation or looking at the 
implementation we need to test for nil. Right? I suggest the modifier simply to 
enforce that check and let it be known that’s the desired usage.
I do get what you want. But not why (the personal why I get, the 
objective one not).
Or not what sense is it makes... Where again I get your description, but 
it seems arbitrary/randomly picked.
Sure perfectly fine on the few examples you gave. But then by that 
measure others will bring their examples (and believe me they will, and 
it will be examples neither of us would be able to derive today). And 
then we need further rules/modifiers/dedicated-checks for whatever 
examples they bring up...


As you wrote: "we need to test for nil"
Yes, and we need to do that for all of them. Even if they are not marked 
as "expect-me-to-be-nil". Because even if they are not marked, they 
still can be.


That means if we start warning in selected cases (the ones that are 
marked), then we give the user **false security** over all other cases. 
(I did not get a warning, so why does it crash on a nil-deref?)


The only place where we do not need to check for nil, is if we know it 
can not be nil.

We can gain that knowledge from 1 of 2 places
- some sort of modifier to the type declaration - or some sort of 
class-contract

- the docs

We can NOT get it from code review. Code may change, and then all the 
depended code becomes wrong. (It may be that the code should return nil, 
but due to a bug the current implementation does not)



So, in other words:

function FindThing: TThing; optional;

means you MUST check for nil. If the value is nil that’s not an error. 
“optional” is probably a bad name for this I know.

Don't worry about the name.

How does the compiler know that I have checked. Code can be arbitrarily 
complex. There will always be code that does check, but the compiler can 
not tell (heck I may have a checkAssigned procedure in assembler).
So at best the compiler can warn during compilation, but never give an 
error.



function MakeThing: TThing;

this means maybe check for nil or maybe not check for nil. We don’t know what 
the programmer intended because no extra information was given (at least in the 
declaration). Because of the name we probably assume this is going to return a 
new object which is safe so checking for nil would be a waste.

What if it run out of memory? And catches the exception.
Checking for nil is never a waste. Unless you have proof (in the 
mathematical sense) that nil can not happen.
Or if your rules allow you to trust the docs, and the docs say you can 
relay on it.



  But we don’t know that except for what the name implies or if we read the 
code.
Neither name, nor implementation are a reliable source for that info. 
See above.



Is that more clear? If there’s a better way to express this then please let me 
know.

Its been perfectly clear from (almost) the start.

I admit the contract/assert stuff may have made it seem different. But 
that is because this approach does not hold up (IMHO). And therefore the 
closest alternative was presented.


In the very end it is to avoid crashing on nil de-ref. And the 
contract/assert can help there. Though in a completely different way.



For parameters I like what Sven suggested to have a “requires” section 
in functions to check this but wouldn’t it make sense if the function 
parameter gave some hint also? “can be nil” or “can’t be nil” would 
both be helpful in terms of documentation and compile time errors 
instead of runtime errors. 


The pre-condition (requires) would have the same amount of compile time 
checks (and the remainder runtime) as a keyword like notnil or maybenil. 
In the same way range checks and others go part compile, part runtime.


As for "documentation". I disagree with the way it is done in oxygen. 
But I am not sure I have any good alternative.

For me a class contract (require/ensure) is part of the interface.

So it would have to be like (and similar for plain procedures, no class) 
// can be all on one line


type
  TFoo= class
 function DoTheFooThing(Foo1, Foo2: TFoo): Tbar;
    requires
   assigned(Foo1) or assigned(Foo2): 'Need at least 1 foo, for 
the connection';

    guarantees // better than ensure
   assigned(result);
   result.KnowsMyFoo = true: 'Connection exists';  // the =true 
is redundant

    procedure DoTheBar;
  end;

So reading this declaration, you immediately know what is valid. And if 
custom messages are give, they may tell you way


It is to be noted, that requires and guarantees contain conditions 
(expressions), not pascal code. So technically it is ok, that they are 
in the interface and not implementation.
If I want something in the implementation, I can use normal "assert" 

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 19:53, Ryan Joseph wrote:



On Apr 14, 2019, at 1:38 PM, Sven Barth via fpc-pascal 
 wrote:

As already said by Martin: the compiler *can not* determine all cases whether 
the parameter is Nil or not, so it *must* be done at runtime to ensure this. 
Otherwise the feature is just as useful as this:

I’ve read over what Martin said and honestly I’m confused now. :) I’m not sure 
if I don’t understand you guys or you don’t understand me.

Lets use the example of the optional (i.e. "could be nil") return value because 
it’s most easy to understand. Why can’t the compiler know that the result of GetThing is 
an optional and therefore you *must* always check any code that dereferences it? Isn’t 
this a compile time issue?

In the example below I would always check for not nil if the documentation said 
it may be nil so why can’t the compiler just make you do that anyways and 
provide the information right there in the declaration? I don’t understand 
where the runtime element of this is.

function GetThing: TThing; optional;

var
   thing: TThing;
begin
   thing := GetThing;
   if assigned(thing) then
 writeln(thing.name);


Well the answer has several parts.

One thing is what checks can be done, to help the programmer not to 
accidentality  de-ref nil.

The other thing is how.

1) The "optional" is actually the default. If anything towards a 
deref-warn feature was done, then *every* parameter,  *every* 
return-value (and even every other var) of a nil-able type should be 
seen as optional.
If a type is not optional, then it should be declared as "not nil-able" 
=> function foo(notnil a: TObject): notnil TOBject;


That is in the same way as range checks. There is on "type 
x=array[1..50] with range checks of integer;"


Using your "Optional" is just specifying what already applies. In other 
words: redundant.


Now specifying it for a result, is different than specifying it for a 
parameter.

- For a parameter, the problem was:
   that if I want the compiler to check that I test for "assigned",
   => then I must remember that I want the compiler to do that,
   => because if I do not remember, then I would not add the "optional"
  But:
  If I already remember that I want to have a check for "assigned", 
then I can do it right away.
  I do not need the "optional", so that I get a warning for forgetting 
something that I actually just though of.


As something applied to the result, the reminder is for some other 
person. The person that will write the code.

Now that idea is perfectly fine.
- But the "optional" still is not. The user, the compiler, everyone 
already knows that the result can be nil. Every TObject can be nil. This 
is the default.
- So to improve this we would need a way to say: It will never be nil. 
(I.e., it is different from the default)
If we had that, then there would be nothing wrong with the compiler 
giving a hint, in case the user does not check.


So that is about the how.
- Reverse the spec, so it acknowledges the current default.
- Then issue warnings for every parameter or return value, that has not 
been marked as non-nil.


2) If the compiler does check, we have to consider that all current code 
defaults to nil-able.

To avoid floods of warnings the check would need to be off by default.
It could be enabled by
- directive
- command line to the compiler
- fpc.cfg

3) If the compiler does check, it can issue (at compile time) hints, 
notes, or in very very few cases warnings.
You can use -we to tread them as error, but they can never be error by 
default.


Code can be very complex. The compiler can never understand all possible 
ways of implementation. Therefore the compiler will always have false 
positives.
If those were errors by default, then perfectly valid code could not be 
compiled.

So hints, notes, and occasional warnings.

4) runtime checks:
Are entirely independent of the above.

However they can be helpful. They would work exactly like range-check 
errors work today.
If you declare a function can never return nil, then the compiler can 
(as a separate feature, with its own option) in addition to the 
hints/notes at compile time, add checks at runtime.


You do not write try except for range checks (at least that is not what 
range checks are meant for), and you would not do that for nil checks.


---
In conclusion:

The nil-deref-protection would be very much like range checks. (except 
that the nature of tracing the nil value is more complex, meaning you 
get notes instead of errors)


range checks can occur at compile time SomeString[-1] should give a 
compile time error (in that case actually an error)

range checks also occur at runtime.

nil-deref-protection  does the same.
It applies to *ALL* nil-able types by default.

In order to be useful it is necessary that the programmer has a way to 
tell the complier that variable/param/returnval do not fall into the 
default, and that they are never nil.



Invalid contracts are an 

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 18:04, Martin Frb wrote:

On 14/04/2019 16:05, Ryan Joseph wrote:
On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal 
 wrote:


Your idea requires exceptions as well. The compiler is not capable 
checking whether valid entries are passed in at compile time except 
for simple, constant cases, so runtime checks are needed and the 
only way to abort something is by exceptions.
My idea didn’t require the procedure to exit so I don’t see where an 
exception would be needed. It just says if a param was flagged you 
would need to check for nil before dereferencing other you get a 
compile time error.
First of all the max you should get is a note (warning, maybe). But 
never a compile time error.
As for your feature of getting a note from the compiler, if you deref a 
param (or other variable) that according to the compilers awareness 
could be nil at the time.


There is on need to say "optional".
Technically any nil-able var could be nil. So the compiler note should 
be for any such variable. Exactly like currently the "variable not 
initialized".


The downside: That would flood current code with compiler-notes. Because 
any param could be nil, even if the programmer has documented somewhere 
that this is not allowed.


But if pre-conditions where available, this could be combined.
The compiler could assume that if you wrote pre-conditions for a method, 
and that if you did non add "foo <> nil" to those conditions, then you 
expect that foo can be nil.
And in that case the compiler could add appropriate notes, if it finds 
you do not check for nil.


Existing code has no pre-conditions and is not affected. New code then 
must contain this.


Or the warning could apply to all code, but by default is not generated. 
You can enable it for each unit via commandline switch or directive. 
Again no "optional" needed.

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

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 16:05, Ryan Joseph wrote:

On Apr 14, 2019, at 3:15 AM, Sven Barth via fpc-pascal 
 wrote:

Your idea requires exceptions as well. The compiler is not capable checking 
whether valid entries are passed in at compile time except for simple, constant 
cases, so runtime checks are needed and the only way to abort something is by 
exceptions.

My idea didn’t require the procedure to exit so I don’t see where an exception 
would be needed. It just says if a param was flagged you would need to check 
for nil before dereferencing other you get a compile time error.
First of all the max you should get is a note (warning, maybe). But 
never a compile time error.


I have code like
  If a > 7 then
 (* If b = nil then *) b:= somedefault;
  foo();
  if a = 8 then
 a := b;  // compiler claim b is not initialized     (* a := b.Foo *)

So if your request for a compile time error was implemented, and above 
was a pointer deref on the last line, the code would not compile. Yet it 
is safe.


Also see my previous comment.
What is the point, if the compiler checks for potential issues, but only 
if I insert a request for the check on top of the potential unsave code.


If I have to write "optional" so the compiler checks for "if assigned" 
then what good is it? I can write "if assigned " immediately and save 
myself the optional.



And please do not counter this with: "But it documents for the user that 
he can use nil". The documentation is a separate distinct issue, and it 
can be solved in other ways.
You proposed one keyword to archive 2 features, be prepared to discuss 
each of them separately.



I like the idea (because it feels Pascalish) to make a code section that checks 
requirements but the exit condition is up for debate. I personally wouldn’t use 
the feature if it meant I need to start the tedious process of wrapping 
everything in try blocks and taking on what performance costs there are to 
exceptions (we can’t opt into exceptions via modeswitch so I don’t know what 
those things are doing and where they are).

There would be no need for try blocks.

It is the same as "assert". An assert raises an exception. But you do 
not write try except blocks for it.
An assert should never happen, therefore you do not handle it. An assert 
is a controlled crash of the app. Asserts are compiled into your app, if 
you test it. But you leave them out if you release.
Once you have tested (automatic test case), you no longer need the 
assert, because the case can never happen. (Or the third party using 
your code have to test, they follow the API. Or you allow nil for them, 
and you tested that it does work)


I understand that this is not the same you propose.
It is for cases where nil is NOT allowed, rather than for cases were nil 
is allowed. (as above, if nil is allowed, the code must be tested with 
nil. The compiler can never detect all cases, therefore the compiler can 
never enforce that you do "if assigned"... You may have done, without 
the compiler having noted)



We have custom error systems in our code also so forcing everyone into 
exceptions would not be nice. I could imagine a bail condition that was jumped 
to but it would have to be in the code section. That’s usually how we do it now 
anyways so it shouldn’t be too strange.

function MakeHero (name: string; hp: integer; level: integer): THero;
require
   name <> ‘’;
   hp > 0;
   (level > 0) and (level < 10);
begin
   …
bail
   MyCustomErrorHandler(‘MakeHero() params are invalid’);
   exit(THero.Invalid);
end;

You do not need the exit. Because the purpose of the assert is to abort 
the entire application (controlled crash).


If you get a call with invalid param, you have to assume this is because 
something else went wrong before. So in this case you have to assume 
worst case, something like the entire memory of the application has been 
corrupted.
There no longer is a way to rescue the app. All you can do is make sure 
that it will not do further damage. So you exit the app.


The IDE for example uses Application.OnException.
It tells the user that it is now unstable. Save your work and exit.

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

Re: [fpc-pascal] Optional param modifier

[Martin Frb]

On 14/04/2019 00:01, Sven Barth via fpc-pascal wrote:


Well, there is Oxygene's concept of Class Contracts (see
https://docs.elementscompiler.com/Concepts/ClassContracts/ ), so if
anything in that direction would be done I'd be inclined towards their
syntax (and I've played with the idea to implement this in FPC for quite
some time already).

Though of course it wouldn't necessarily solve the point of knowing
whether one may pass Nil or not, cause especially in compiled code you
can't look at the source. So the compiler would need to store the
conditions in the PPU as well, so that the IDE could present them as
part of the tooltip even if no source is available...


Well it needs to be in the ppu anyway, because even without source, an 
object can be inherited from.


And the inherited method must fulfil some of the conditions
- It can't accept less than its base (requirements can be looser, but 
not tighter)
- It must fulfil the "ensure"s, or be even stricter. (as that would 
still fulfil them)


Also being in the ppu, would allow compile time errors, when passing 
violating constants.


There are a few things about the oxygen syntax.

1) require is outside the begin..end, but ensure is inside.

2) As the nature of those conditions can be inherited, they are more to 
be thought of as declaration, than implementation.
That would call for them to be in the interface. Though of course that 
messes up the interface



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