Re: [fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas

[Michael Van Canneyt via fpc-pascal]

On Sat, 4 May 2024, Tony Whyman via fpc-pascal wrote:


Michael,

I believe that the diplomatic answer to your response is that it is 
"disappointing". This is a serious problem and needs to be discussed.


Thank you for being diplomatic.



Interfaces between modules written in different programming languages or 
even built with different compilers are never easy and depend on having 
published and stable definitions for each data type and structure. This 
is a common problem for anyone using Pascal given how so many code 
libraries are written 'C' or C++. Change can imply breaking many user 
programs and should not be done lightly and for purely internal reasons.


We guarantee backwards compatibility (as much as possible) on the language 
level and API level, but not on the internal structure of objects.


The only structure that is guaranteed to work with C or C++ is the record.

Hence my proposed solution using a record.

Both object and class type data structures are published in the Free 
Pascal Documentation


You may wish to re-read the documentation and specifically this:

https://www.freepascal.org/docs-html/current/ref/refsu23.html#x73-970006.3.1

'As of version 3.0 of the compiler, the compiler can re-order the fields in memory 
if this leads to better alignment and smaller instances. That means that in an instance, 
the fields do not necessarily appear in the same order as in the declaration.'


So your vTable also is in no way guaranteed to be correct, the above
explicitly says that your assumptions are invalid.

In the case of monitor data, you have said that Delphi have implemented 
this as a "hidden" field. I presume that you mean that this uses a 
technique such as a negative offset to the object instance pointer.


No, actually behind all other fields.

I don't intend to do work on this, since nowhere was there any guarantee
that TObject has no fields. As I wrote, this assumption has no basis and
this is even documented. It works purely by chance, not through design.

I have given you a possible way to fix it, which is IMO the only correct and
future proof way to implement what you need.

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

Re: [fpc-pascal] FPC 3.3.x breaks the Firebird Project's Firebird.pas

[Michael Van Canneyt via fpc-pascal]

On Thu, 2 May 2024, Tony Whyman via fpc-pascal wrote:

This is a problem reported to me by an IBX user. I have not yet confirmed it 
(need to find the time to set up the latest development branch of FPC), but 
the issue looks solid, and is due to the following addition to TObject 
(copied from the GitLab master branch)


|TObject = class|{$IFDEF SYSTEM_HAS_FEATURE_MONITOR}
strictprivate
_MonitorData : Pointer;
private
functionSetMonitorData(aData,aCheckOld : Pointer):Pointer; inline;
functionGetMonitorData:Pointer; inline;
{$ENDIF}
  ...

Since Firebird 3.0, the Firebird project has provided a file called 
"Firebird.pas" in order to provide an interface to Pascal (both Delphi and 
FPC) from a C++ environment. There is an underlying assumption in the 
interface. That is TObject contains no fields.


This assumption is not valid in Delphi either. It also has this field, but
it is 'hidden' at a not-fixed location.



The idea is simple enough. There is a single entry point to the Firebird 
client library with the Pascal signature


function fb_get_master_interface : IMaster; cdecl;

This returns a pointer to a structure that may contain fields but is 
primarily a list of pointers to cdecl functions. These functions can perform 
various tasks. In the case of IMaster, they can also return similar 
structures representing other "interfaces".


On the Pascal side, IMaster is defined as a class with no virtual methods and 
a single field called "vTable" and this is set to the pointer to the 
structure returned by fb_get_master_interface. The rest of the class 
comprises methods used to call functions from the vTable. This makes IMaster 
look like a normal class and hides the use of function pointers. The code is 
generated by a program know as "cloop". All Firebird interfaces declared in 
Firebird.pas follow the same approach.


Given the assumption that TObject defines no fields, it is possible to coerce 
the pointer returned by fb_get_master_interface to appear as an object 
"instance" of the IMaster class, and similarly for every other Firebird 
interface class. This coercion ceases to be valid as soon as a field, such as 
_MonitorData is added to TObject.


It is probably a valid argument to say that this is Firebird's problem as the 
TObject definition is an internal data structure. However, this ignores a 
serious real world problem.


The real problem is the invalid assumption.

This assumption is invalid for Delphi as well. TObject is not empty there either. 
The memory layout is simply different.


A fix or workaround is needed and that has to be 
in Firebird.pas. It would be a logistic nightmare to try and change the C++ 
Firebird client DLL/SO.


It would be a logistic nightmare in FPC as well.



Also, does anyone know whether a similar problem will arise with Delphi, or 
is thus just an FPC issue?


One of the following seems to be needed:

a) Rewriting Firebird.pas to set the vTable field explicitly rather than 
implicitly through coercion - ideally without breaking any user code... 
(note: no current need to free IMaster etc)


b) Taking a different approach to introducing _MonitorData e.g.


This field was introduced for Delphi compatibility:
The implementation of TMonitor requires this data.

Delphi has this field as well but "hides" the field behind all other actually 
declared fields.

If you examine the actual memory size allocated for TObject, you'll see that an 
extra field is actually present.

In FPC this turned out to be not so easy to do without modifying the compiler, 
so it was decided that the cleanest approach is to actually introduce the field as part of TObject.


The firebase people use a trick to save you some work, based on an invalid 
assumption.
I don't think this is sufficient reason to expect the FPC team to adapt their 
compiler.

The correct solution is to change the cloop program to produce a 
pascal record definition with procedural type fields at the correct offsets. 
It should be perfectly usable without too many changes.


So something like (adapt to actual procedure types)

Type
  RMaster = Record
init : procedure(xyz:sometype);
// etc
  end;
  IMaster = ^RMaster;

  // optionally; although it seems this already exists?
  TMaster = class
intf : IMaster;
procedure Init(xyz : sometype);
constructor create;
  end;


function fb_get_master_interface : IMaster; cdecl;

constructor TMaster.Create;

begin
  intf:=fb_get_master_interface;
end;

Procedure TMaster.Init(xyz : sometype);
begin
  intf^.init(xyz);
end;

if you cannot change cloop, you can use fcl-passrc or some other tool 
to actually parse the definition generated by cloop and change it to a record, 
possibly with a wrapper class for easier access as in the above.


That should not be difficult to do, and it will work in Delphi as well.
The advantage is that it will be more robust against future changes as it
makes no assumptions about the layout of objects.

Michael.

Re: [fpc-pascal] AnsiString address changed

[Michael Van Canneyt via fpc-pascal]

On Mon, 18 Mar 2024, Hairy Pixels via fpc-pascal wrote:





On Mar 18, 2024, at 3:27 PM, Hairy Pixels  wrote:

Oh, it's a pointer to a pointer? I guess that explains how it can resize itself 
and not invalidate shared references, if those are even possible with 
AnsiString.


Wait, that's totally wrong. :) @s is the address of the local variable of 
course. I didn't think before I did that. I just wanted the address of the 
AnsiString.

That still doesn't explain how they resize though. There must be not be more 
than 1 reference to any AnsiString at a time.


Of course there must be, that's the whole point of copy-on-write.

As soon as one reference is changed, a copy is made if the reference count
is larget than 1, and this copy is changed.

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

Re: [fpc-pascal] AnsiString address changed

[Michael Van Canneyt via fpc-pascal]

On Mon, 18 Mar 2024, Hairy Pixels via fpc-pascal wrote:


Curious, why did the address of "s" change here? Shouldn't the AnsiString be 
incrementing a reference  count and not actually changing the actual pointer or copying?

Correct me if I'm wrong, AnsiString is ref counted when passing in/out 
functions but copies on assignment so technically no two AnsiStrings can be 
shared in two locations, which makes sense because if they were resized they 
would invalidate each others memory anyways when ReAllocMem is called.

I guess if that's true then there must be only pointer to any AnsiString in any 
given scope otherwise they could resize and corrupt their memory.

Not sure if that makes sense, I'm struggling to understand myself. :)



 procedure PassString(s: AnsiString);
 begin
   writeln(hexstr(@s));
 end;

var
 s1: AnsiString;
begin
 s1 := '123';
 writeln(hexstr(@s1));
 PassString(s1);
 writeln(hexstr(@s1));
end.

Output:

00010259AC00
00016DBC2F80
00010259AC00


An ansistring is a pointer to a memory block.

You are printing the address of S1 and the address of S, i.e. the address of
the pointer itself, not the address of what S (or s1) points to. 
Obviously the address of the s is different of s1.


What you want to do is print hexstr(pointer(s))
if you do that, you'll have the same output 3 times.

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

Re: [fpc-pascal] FP IDE sources

[Michael Van Canneyt via fpc-pascal]

On Thu, 14 Mar 2024, Florian Klämpfl via fpc-pascal wrote:


Still, it is more logical to place it under utils, with the rest of the
programs.

The argument about the time to compile seems simply false to me:

If you consider the FPC toplevel 'make all' as the only command to
issue, then you may win some time, although I doubt it will be that much.

But 99% of the time, you don't need to recompile the utilities.


I do always a make all as it takes only a few more seconds than a make 
cycle and then I am sure everything builds.


You must have a very fast PC, here the difference is very measurable.

1:06 for a 'make cycle'
2:05 for a toplevel 'make all'.

So almost a minute difference. This is with -j 4 and the according fpmakeopt.


I certainly do not:
I usually do a make cycle followed by a compilation of the rtl/packages 
with debug info.


So if we moved the IDE to utils where it logically belongs, I would 
actually be winning time, contrary to the argument for having it in 
packages.


As I moved it, my thinking was that it is not really a utility but a 
package (in particular in the sense of the installer). And having 
executables is also the case for other packages.


Here I differ in opinion: Normally packages do not constitute a program.
If that was the criterium, all utils could be put in the packages directory.

It may be that some packages have a demo program, but the package itself is
normally just a set of units. I know of no package other that is a program.
chm has some tools but IMO they are also misplaced and should be in utils.

So the IDE - for me - is definitely a utility. Given the times indicated above,
it would make a considerable difference to move it.

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

Re: [fpc-pascal] FP IDE sources

[Michael Van Canneyt via fpc-pascal]

On Thu, 14 Mar 2024, Tomas Hajny via fpc-pascal wrote:


On 2024-03-14 11:06, Marco van de Voort via fpc-pascal wrote:

Op 14-3-2024 om 11:04 schreef Michael Van Canneyt via fpc-pascal:



To me it therefore seems a better idea to move the IDE to utils, and to 
have a

toplevel make command that does the same as 'make all' simply without the
utilities. Or have a 'NOUTILS=1' define.


Or let fpmake simply build the union of packages and utils in
parallel. So separate directories, but one build stage


Well, whatever. I remember having raised the same question in the past 
(indeed - on the 5th of February 2020 at 1:30am ;-) on the core list) and 
this is what I got... I even explicity raised the point also mentioned by 
Michael now (quoting my follow-up mail on the same day):


"OK, that would be addressed in case of inclusion under utils as well. Even 
more so, actually - users who want to recompile packages for whatever reason 
(e.g. to have debug information included as discussed here recently ;-) ) 
aren't probably interested in waiting for rebuilding of the IDE at all."


However, Michael refused to move it to utils at that point in time in order 
not to delay the release. ;-)


Given the delay we're experiencing on 3.2.4, my refusal was not without reason 
:-)

However, if there is agreement to do so, maybe we can move it in trunk.

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

Re: [fpc-pascal] FP IDE sources

[Michael Van Canneyt via fpc-pascal]

On Thu, 14 Mar 2024, Karoly Balogh via fpc-pascal wrote:


Hi,

On Thu, 14 Mar 2024, Guillermo Martínez Jiménez via fpc-pascal wrote:


I thought "packages" were libraries not applications, as there is an
"utils" directory with programs.


I agree, I'm also not very fond of the IDE being in packages, but most of
the team considers it a legacy piece of code (which it is, no argument
there), and at least this way it doesn't need constant special treatment,
unlike when it was in the root folder of the repo under "ide". It's less
"in the way".


Still, it is more logical to place it under utils, with the rest of the
programs.

The argument about the time to compile seems simply false to me:

If you consider the FPC toplevel 'make all' as the only command to
issue, then you may win some time, although I doubt it will be that much.

But 99% of the time, you don't need to recompile the utilities.

I certainly do not:
I usually do a make cycle followed by a compilation of the rtl/packages with 
debug info.

So if we moved the IDE to utils where it logically belongs, 
I would actually be winning time, contrary to the argument for having it in packages.


To me it therefore seems a better idea to move the IDE to utils, and to have a
toplevel make command that does the same as 'make all' simply without the
utilities. Or have a 'NOUTILS=1' define.

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

Re: [fpc-pascal] [fcl-web] [jsonrpc] [fpjsonrpc.pp] DoCheckParamArray in TCustomJSONRPCHandler

[Michael Van Canneyt via fpc-pascal]

On Thu, 22 Feb 2024, Michael Anochin via fpc-pascal wrote:


Hello,

the TCustomJSONRPCHandler.DoCheckParamArray in fpjsonrpc.pp causes an
exception with the message "List index (0) out of bounds".

This happens, for example, if ParamArray is empty and there are not
required parameter in ParamDef (required not set).  In that case
ParamArray[i] not exists, so Param:=ParamArray[i] raises "index out of
bounds" exception.

I would like to check this before assignment, may be like this

procedure TCustomJSONRPCHandler.DoCheckParamArray(const ParamArray:
TJSONArray);
var
 I : Integer;
 Param: TJSONData;
 Def : TJSONParamDef;

begin
 for I:=0 to ParamDefs.Count-1 do
   begin
   Def:=ParamDefs[i];
   if I>=ParamArray.Count then
 if ParamDefs[i].Required then
   JSONRPCParamError(SErrParamsRequiredParamNotFound,[def.Name]);
   //Check ParamArray.Count first
   if (IjtUnknown) and not
(Param.JSONType=def.DataType) then

JSONRPCParamError(SErrParamsDataTypeMismatch,[def.Name,JSONTypeName(def.DataType),JSONTypeName(Param.JSONType)]);


As it happens, I was working on adding some things to fpjsonrpc, 
so I fixed this issue by putting the code in an else branch. 
I pushed that change.


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

Re: [fpc-pascal] Floating point question

[Michael Van Canneyt via fpc-pascal]

On Sun, 18 Feb 2024, James Richters via fpc-pascal wrote:


And if you have set the precision, then the calculation will be identical to 
the calculation when you use a variable of the same type (if not, it's indeed a 
bug).


This is what I have been trying to point out.  Math with identical casting with 
variables and constants are not the same.
Maybe if I try with a simpler example:

program Const_Vs_Var;

Const
  A_const = Byte(1);
  B_const = Single(3.5);
Var
  A_Var : Byte;
  B_Var : Single;
  Const_Ans1, Var_Ans1 : Extended;

Begin
  A_Var := A_Const;
  B_Var := B_Const;

  Const_Ans1 := Extended(Byte(A_Const)/Single(B_Const));
  Var_Ans1   := Extended(Byte(A_Var)/Single(B_Var));

  WRITELN ( ' Const_Ans1 = ', Const_Ans1);
  WRITELN ( '   Var_Ans1 = ',   Var_Ans1);
End.

Const_Ans1 =  2.85714298486709594727E-0001
  Var_Ans1 =  2.85714285714285714282E-0001

Windows 10 Calculator shows the answer to be
0.28571428571428571428571428571429  Which matches up with the way variables 
have done this math, not the way constants have done it.


I would not put too much trust in Windows calculator, since there you have
no control over the precision at all.

It seems to be a windows-specific problem. Here is the result of your
program when executed on Linux:

 Const_Ans1 =  2.85714298486709594727E-0001
   Var_Ans1 =  2.85714298486709594727E-0001

As you can see, the result is identifical.

As for the explanation, I will have to leave that to the compiler developers.

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

Re: [fpc-pascal] Floating point question

[Michael Van Canneyt via fpc-pascal]

On Sat, 17 Feb 2024, wkitty42--- via fpc-pascal wrote:


On 2/16/24 9:57 AM, James Richters via fpc-pascal wrote:
So you are saying when constant propagation is on, an expression should 
have a different result than with constant propagation off?


The result of math when using constants MUST be the same as the result of 
identical math using variables.


As far as I can see, in that case you must simply type your constants.

Variables are always typed - their precision is determined by the type you
have specified.

For constants, the compiler will choose a type and consequently the precision. 
Jonas and others have explained the rules that the compiler uses.


If you don't like the rules that the compiler uses, you can set a type for your
constants. When you explicitly set a type, you are also specifying the 
precision of the calculation.

And if you have set the precision, then the calculation will be identical to the
calculation when you use a variable of the same type (if not, it's indeed a 
bug).

There are 2 ways to do so:

Const
  MyConst : Double = 1.23e45;

or

Const
  MyConst = Double(1.23e45);

The latter can also be used in an expression

 X := Y * Double(1.23e45);

There can be discussion about the rules that the compiler uses when it chooses a type, 
but any given set of rules will always have consequences that may or may not be desirable.


Possibly some compiler switches can be invented that modify the compiler's
rules for the constant type to use.

(incidentally, this is one of the reasons the FPC team does not want to make
inline variables as Delphi does, since there the type will again be determined 
by
the compiler - just as for constants, leading to ambiguity...)

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

Re: [fpc-pascal] FPReport: Split text across two or more pages

[Michael Van Canneyt via fpc-pascal]

On Fri, 16 Feb 2024, Pique7 via fpc-pascal wrote:


On Mon, 8 Jan 2024 22:08:16 +0100 (CET)
Michael Van Canneyt via fpc-pascal  wrote:




On Mon, 8 Jan 2024, Pique7 via fpc-pascal wrote:


Disregarding the RTF for a moment, you'd need to save the contents of the
text fields in a TStringlist instance in the 'afterscroll' event of the dataset.

This instance can then be used to create a data loop for a sub band
(using TFPReportUserData).
The band connected to the dataset (the master band) would not print anything.
Instead, the child band will print the cell content line by line and split it 
over pages.

From your drawing, it is not quite clear how you construct your columns,
if you're using columns, I'm not sure how the band will behave.

Michael.


Thanks again for your suggestions. I haven't tried it yet but now I've got the 
idea. Your are so optimistic but I still fear all the things which might make 
troubles in a more complex report with grouping, master/detail data, 
calculations, layout adjustments, HTML tags, table borders etc.

However, finally I've tried to extend/improve the original FPReport classes and 
now I really have a FPReport version that supports band splitting for simple 
FPReportMemos.
I was not able to implement this using inheritance - I've had to change the 
original source code in the FPC folder.
Without any doubt there are still many bugs in my FPReport. But if you want a 
copy, let me know! :-)


I am always open for improvements.
Please do send me your sources or a diff...

Michael.


I have just started to resume my work on FPReport. I have found some errors in 
my first version and currently I am trying to add RTF support. I utilize 
TRichMemo for this because I think it is sufficient for my case (I only develop 
and test for Windows 10/11 at the moment). Also SVG support is wanted.
What would be an appropiate way to provide my work and partial results? As I 
deal with the FPC source code, your opinion and suggestions might be 
particularly meaningful.


SVG support for FPC (and consequently FPReport) is on my wishlist. 
RTF support using TRichmemo is useless for FPC itself as FPReport needs to be free of LCL or other dependencies.

If at some point RTF support is added, it will be using the RTF parser included 
in Free Pascal.

If you wish to submit contributions, you can supply patches using the gitlab 
issue tracker.
The RTF support for FPReport can of course be submitted to the Lazarus issue 
tracker or
kept on github or some other repository...

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

Re: [fpc-pascal] Floating point question

[Michael Van Canneyt via fpc-pascal]

On Tue, 13 Feb 2024, James Richters via fpc-pascal wrote:


Sorry for the kind of duplicate post, I submitted it yesterday morning and I
thought it failed, so I re-did it and tried again.. then after that the
original one showed up.

A thought occurred to me.   Since the complier math is expecting all the
constants would be in full precision, then the compiler math doesn't need to
change, it's just that the reduction in precision is just happening too
soon.  It's evaluating and reducing each term of an expression, then the
math is happening, and the answer is not coming out right.

If instead everything was left full precision until after the compiler math
(because this is what the compiler math expects), and then the final answer
was reduced in precision where possible, then it would work flawlessly.  So
the reduction in precision function only needs to run once on the final
answer, not on every term before the calculation.


As Jonas said, this would result in less efficient code, since all the math 
will then be done at full precision, which is slower.


As usual, it is a trade-off between size (=precision) and speed.

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

Re: [fpc-pascal] Floating point question

[Michael Van Canneyt via fpc-pascal]

On Mon, 12 Feb 2024, Thomas Kurz via fpc-pascal wrote:


I wouldn't say so. Or at least, not generally. Why can't the compiler do what 
the programer intends to do:

var
 s: single;
 d: double;
 e: extended;

begin
 s := 8427.0 + 33.0 / 1440.0; // treat all constants all "single"
 d := 8427.0 + 33.0 / 1440.0; // treat all constants all "double"
 e := 8427.0 + 33.0 / 1440.0; // treat all constants all "extended"
end.


You cannot do this in Pascal. 
The evaluation of the expression on the right of := does not

know (and should not know) what the type is of the expression on the left.

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

Re: [fpc-pascal] Read Field names from VMT

[Michael Van Canneyt via fpc-pascal]

On Wed, 31 Jan 2024, Amir--- via fpc-pascal wrote:



Without more info (declaration of ChildTClass, declaration of the 
constructor

of that class etc), it is not possible to comment.

We need a complete compilable code sample to provide you with more insight.


Please have a look at the attachment.


The constructor of TObject is not virtual, in difference with the destructor.

Given the definitions

  ChildObj: TObject;
  ChildTClass: TClass;

The following statement

  ChildObj := ChildTClass.Create;

will always use the TObject.Create, since it is not virtual.

In general, you cannot use TObject for this kind of thing.

For this to work, you need to create a descendent of TObject with a virtual
constructor (call it TMyObject) of known signature, and do

  ChildObj: TMyObject;
  ChildTClass: TMyClass; // class of TMyobject

then

  ChildObj := ChildTClass.Create;

will take the correct overridden constructor.

Your code is also incomplete in the sense that it will only work for classes
with a constructor without arguments. 
If a overloaded constructor exists which takes arguments (like TComponent), 
it will not be called and the class will not be instantiated correctly.

But maybe that will not be your use-case.

I attached a version of your program that works and has no memleaks.

Michael.program FieldAddress;

{$mode objfpc}{$H+}

uses
  {$IFDEF UNIX}
  cthreads,
  {$ENDIF}
  Classes, TypInfo
  { you can add units after this };

type
  {$M+}

  { TValue }
  TMyObject = class (TObject)
constructor create; virtual;
  end;
  TMyClass = class of TMyObject;
  
  TValue = class(TMyObject)
  private
FV: PInteger;
  public
constructor Create; override;
destructor destroy; override;
  end;

  { TParam }

  TParam = class(TObject)
  
  public
destructor destroy; override;
  
  published
V1: TValue;
V2: TValue;

  end;

procedure Process(vft: PVmtFieldTable; Obj: TObject);
var
  vfe: PVmtFieldEntry;
  i: SizeInt;
  Name: AnsiString;
  ChildObj: TMyObject;
  ChildTClass: TMyClass;
  FieldClass : TClass;

begin
  if vft=nil then exit;
  Writeln(vft^.Count, ' field(s) with ', vft^.ClassTab^.Count, ' type(s)');
  for i := 0 to vft^.Count - 1 do
  begin
 vfe := vft^.Field[i];
 Name := vfe^.Name;

 Writeln(i, ' -> ', vfe^.Name, ' @ ', vfe^.FieldOffset, ' of type ', 
vft^.ClassTab^.ClassRef[vfe^.TypeIndex - 1]^.ClassName);

 FieldClass := vft^.ClassTab^.ClassRef[vfe^.TypeIndex - 1]^;
 if FieldClass.InheritsFrom(TMyObject) then
 begin
   Writeln('Inherits');
   ChildTClass := TMyClass(FieldClass);
   WriteLn('ChidTClass: ', ChildTClass.ClassName);
   ChildObj := ChildTClass.Create;
   if ((ChildObj as TValue).FV = nil) or ((ChildObj as TValue).FV^ <> 1) 
then
   begin
 WriteLn('ERROR');
 Halt(1);
   end;
   writeln('Calling sub');
   TObject(Obj.FieldAddress(Name)^):=ChildObj;
   Process(
 PVmtFieldTable(PVMT(ChildTClass)^.vFieldTable),
 ChildObj
   );
 end;
   end;

end;


{ TValue }

constructor TMyObject.create;
begin
end;

constructor TValue.Create;
begin
  inherited Create;
   Writeln('Called');
  FV := New(PInteger);
  FV^ := 1;

end;

destructor TValue.Destroy; 
begin
  dispose(FV);
  inherited;
end;

{ TParam}

destructor TParam.Destroy;

begin
  V1.Free;
  V2.Free;
  Inherited;
end;

var
  Param: TParam;

begin
  Param := TParam.Create;

  Process(PVmtFieldTable(PVMT(TParam)^.vFieldTable), Param);

  Param.Free;
end.

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

Re: [fpc-pascal] Read Field names from VMT

[Michael Van Canneyt via fpc-pascal]

On Mon, 29 Jan 2024, Amir--- via fpc-pascal wrote:


I am still struggling with this!

for i := 0 to vft^.Count - 1 do
begin
   vfe := vft^.Field[i];
   Name := vfe^.Name;

   ChildTClass := vft^.ClassTab^.ClassRef[vfe^.TypeIndex - 1]^;
   ChildObj := ChildTClass.Create;
   TObject(Obj.FieldAddress(Name)^) := ChildObj;
end;

Looks like "ChildTClass.ClassName" is correct but the constructor of the 
appropriate class is not being called.


Without more info (declaration of ChildTClass, declaration of the constructor
of that class etc), it is not possible to comment.

We need a complete compilable code sample to provide you with more insight.

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

Re: [fpc-pascal] Read Field names from VMT

[Michael Van Canneyt via fpc-pascal]

On Mon, 22 Jan 2024, Amir--- via fpc-pascal wrote:


  Params := TParams.Create;
  WriteLn(Params.Int2.IntVal);
  WriteLn(TInteger(Params.FieldAddress('Int2')).IntVal);

The third line does not work (the zipped code is attached).


It should be

WriteLn(TInteger(Params.FieldAddress('Int2')^).IntVal);

Terribly convoluted code, though...

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

Re: [fpc-pascal] Read Field names from VMT

[Michael Van Canneyt via fpc-pascal]

On Sun, 21 Jan 2024, Amir--- via fpc-pascal wrote:


How can I set the value?
I tried something like

Test := TTest.Create

Ptr := Pointer(Test);
TSub(Ptr+8) := TSub.Create;

But it is not working?


Depending on your platform, it can be an alignment issue.

Use

 function TObject.FieldAddress(const name : shortstring) : pointer;

This function is used internally by the streaming system (see
TComponent.SetReference), so it should always work.

Michael.

You can use the PVmtFieldTable and PVmtFieldEntry types from the 
TypInfo unit:


=== code begin ===

program tfield;

{$mode objfpc}{$H+}

uses
  TypInfo;

type
  {$M+}
  TSub = class

  end;

  TTest = class
  published
    fTest: TSub;
  end;

var
  vft: PVmtFieldTable;
  vfe: PVmtFieldEntry;
  i: SizeInt;
begin
  vft := PVmtFieldTable(PVMT(TTest)^.vFieldTable);
  Writeln(vft^.Count, ' field(s) with ', vft^.ClassTab^.Count, ' 
type(s)');

  for i := 0 to vft^.Count - 1 do begin
    vfe := vft^.Field[i];
    Writeln(i, ' -> ', vfe^.Name, ' @ ', vfe^.FieldOffset, ' of type 
', vft^.ClassTab^.ClassRef[vfe^.TypeIndex - 1]^.ClassName);

  end;
end.

=== code end ===

=== output begin ===

PS C:\fpc\git> .\testoutput\tfield.exe
1 field(s) with 1 type(s)
0 -> fTest @ 8 of type TSub

=== output end ===

Side note: contrary to what I had originally written only classes, but 
not interfaces are allowed for published fields and they need to have 
$M enabled.


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 maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] IntToStr implementation

[Michael Van Canneyt via fpc-pascal]

On Thu, 18 Jan 2024, Adriaan van Os via fpc-pascal wrote:




Also something which cannot be handled by 'standard' syntax.
(unless you wish to count generics and implicit specialization as "standard 
syntax")


actual-parameter =  expression { ":" expression } .
actual-parameter-list = "(" actual-parameter { "," actual-parameter } ")" .


The compiler obviously can parse it.

More accurately, I meant: you cannot write a function declaration to handle 
that syntax.

procedure Str(O : Integer { what to write here for the :N:M ??? }; var S);


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

Re: [fpc-pascal] IntToStr implementation

[Michael Van Canneyt via fpc-pascal]

On Thu, 18 Jan 2024, Hairy Pixels via fpc-pascal wrote:





On Jan 18, 2024, at 1:51 PM, Sven Barth via fpc-pascal 
 wrote:

There is no source for Str() in that sense, because Str() is a compiler 
intrinsic implemented in the compiler's ninl.pas.



Well that explains everything now! What is this an intrinsic? I was curious how 
it was implemented and now I'm even more curious.


I asked myself the same question.

The reason is it needs to support the same syntax as Write(ln) for padding the 
output:

Str(I:N:M,S);

This is not a "standard" syntax and needs to be handled specially by the 
compiler.

Additionally, Str() can be used to convert an enum to a string value:

Type
  TMyEnum = (one,two,three);

var
  M : TMyEnum = one;
  S : String;

begin
  Str(M,S);
end.

Also something which cannot be handled by 'standard' syntax.
(unless you wish to count generics and implicit specialization as "standard 
syntax")

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

Re: [fpc-pascal] Trash variables (-gt) - Translation

[Michael Van Canneyt via fpc-pascal]

On Thu, 18 Jan 2024, LacaK via fpc-pascal wrote:


Hi *,
I am translating "Trash variables" (from English to Slovak), but I can 
not find appropriate words.

That's why I want to describe it in more words.
Is this correct: "Initialize local variables with random values" ? Or 
better suggestion?


That seems most correct to me.

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

Re: [fpc-pascal] Extra linkxxx.res files left over when compiling/building project

[Michael Van Canneyt via fpc-pascal]

On Mon, 15 Jan 2024, Bo Berglund via fpc-pascal wrote:


I have been working on troubleshooting a command line FreePascal project for a
couple of weeks now and when I look in the project dir it is full of link files:

2021-09-12  10:2323 900 link.res
2024-01-15  00:3023 833 link11600.res
2024-01-13  10:3923 833 link17204.res
2024-01-13  10:3523 833 link19736.res
2024-01-13  10:4323 833 link22340.res
2024-01-13  10:4523 833 link23748.res
2024-01-13  13:3523 833 link24944.res
2024-01-13  10:4123 833 link25456.res
2024-01-13  21:1525 743 link3564.res
2024-01-13  13:4023 833 link5720.res

Of course I can delete them but why has this happened? Should these not be
temporary or else located below the lib dir somewhere?


If the linking stage fails (or some other external tool) then this file is 
left, it helps to examine what happened.


You can delete them.

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

Re: [fpc-pascal] "Address of" question

[Michael Van Canneyt via fpc-pascal]

On Sun, 14 Jan 2024, Hairy Pixels via fpc-pascal wrote:


I just noticed it's possible to do @Byte in FPC. Are these 2 lines even 
different? It doesn't exactly make sense to take the address of a type 
identifier so I'm curious what this may mean.

var
 b: Byte;
 p: PByte;
begin
 p := @Byte(b);


This is a typecast of b from which you take the address. The typecast is 
superfluous.

p:=@b

will have the same effect.

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

Re: [fpc-pascal] Virtual methods on sealed classes

[Michael Van Canneyt via fpc-pascal]

On Tue, 9 Jan 2024, Hairy Pixels via fpc-pascal wrote:


Do sealed classes actually call virtual methods statically or are they just for 
compiler warnings?


The virtual methods are called exactly like other virtual methods.

Sealed just means you cannot create a descendant class. No optimizations are
done.

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

Re: [fpc-pascal] FPReport: Split text across two or more pages

[Michael Van Canneyt via fpc-pascal]

On Mon, 8 Jan 2024, Pique7 via fpc-pascal wrote:


Disregarding the RTF for a moment, you'd need to save the contents of the
text fields in a TStringlist instance in the 'afterscroll' event of the dataset.

This instance can then be used to create a data loop for a sub band
(using TFPReportUserData).
The band connected to the dataset (the master band) would not print anything.
Instead, the child band will print the cell content line by line and split it 
over pages.

From your drawing, it is not quite clear how you construct your columns,
if you're using columns, I'm not sure how the band will behave.

Michael.


Thanks again for your suggestions. I haven't tried it yet but now I've got the 
idea. Your are so optimistic but I still fear all the things which might make 
troubles in a more complex report with grouping, master/detail data, 
calculations, layout adjustments, HTML tags, table borders etc.

However, finally I've tried to extend/improve the original FPReport classes and 
now I really have a FPReport version that supports band splitting for simple 
FPReportMemos.
I was not able to implement this using inheritance - I've had to change the 
original source code in the FPC folder.
Without any doubt there are still many bugs in my FPReport. But if you want a 
copy, let me know! :-)


I am always open for improvements. 
Please do send me your sources or a diff...


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

Re: [fpc-pascal] Quiz

[Michael Van Canneyt via fpc-pascal]

On Sun, 7 Jan 2024, Adriaan van Os via fpc-pascal wrote:



Quiz.

Which of below constant declarations are accepted by the compiler and what is 
their value ?


 const
   ki1   = + 2;
   ki2   = +2;


+x is a unary expression.


   ki3   = 2+;


Does not compile, the binary expression is not complete.


   kr1   = 1.;


There is some special handling for 1. 
(ending with a dot) due to Delphi/TP compatibility, they accept it.




   kr2   = 1e-2;
   kr3   = 1e+2;
   kr4   = 1.e+2;


kr4: Same as kr1 in FPC, but Delphi does not accept it.


   kr5   = 1 . e + 2;


Same as kr1, but not accepted by Delphi.


   kr6   = 1 . 0 e + 2;


kr6 does not compile, although I don't see why if kr5 is accepted..

Delph does not accept it.


   kr7   = 1.0e+2;
   kr8   = 1.0 e + 2;


kr8 Does not compile, probably same reason as kr6. Delphi does not accept it.

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

Re: [fpc-pascal] What's in Hello World

[Michael Van Canneyt via fpc-pascal]

On Sun, 7 Jan 2024, Sven Barth via fpc-pascal wrote:



- FPC compiled as is: 388976 B
- FPC compiled with full smartlinking: 55920 B
- FPC compiled with C linkage: 388760 B
- FPC compiled with full smartlinking and C linkage: 56792 B


Maybe it is a good idea to add these numbers to the above WIKI page, 
to quantify

the discussion and to illustrate what the effect is of various options.


Probably... 路‍♀️

And just for the fun of it, the size if the RTL is compiled into a 
dynamic package and that is used:


- no smartlinking: 15784 B
- with smartlinking: 15608 B

With the librtl.so having a size of 649912 B which will ammortize itself 
if multiple applications use dynamic packages.


Nice result. Smaller than a C program :-)



I think we should also explain why linking to C has almost no effect 
on actual binary size.


That's mainly because the functions that differ between FPC_USE_LIBC and 
not are rather slim syscalls anyway, so the main bunch of Pascal code is 
still the same in both cases.


I know this, but most likely users will not realize this... :-)

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

Re: [fpc-pascal] What's in Hello World

[Michael Van Canneyt via fpc-pascal]

On Sun, 7 Jan 2024, Sven Barth via fpc-pascal wrote:


Am 07.01.2024 um 10:01 schrieb Florian Klämpfl via fpc-pascal:



Am 06.01.2024 um 20:05 schrieb Matthew Phillips via fpc-pascal 
:


I compiled the Hello World program from the docs and noticed that it's
435k. Compared to a lot of newer languages, like Golang, that's not bad
at all.

I then compiled the equivalent C program with gcc which came out at
33k. So I'm just curious, where does the difference comes from?
Could it be that fpc is including some parts that are not being used in
this simple of a program or is more going on?


https://wiki.freepascal.org/Size_Matters

To underline this with some numbers (I assume you mean the demo/text/hello.pp 
which only contains a mere "Writeln('Hello World')" and no additional units; 
all tests on x86_64-linux with 3.3.1):


- FPC compiled as is: 388976 B
- FPC compiled with full smartlinking: 55920 B
- FPC compiled with C linkage: 388760 B
- FPC compiled with full smartlinking and C linkage: 56792 B


Maybe it is a good idea to add these numbers to the above WIKI page, to quantify
the discussion and to illustrate what the effect is of various options.

I think we should also explain why linking to C has almost no effect on actual 
binary size.

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

Re: [fpc-pascal] RIP: Software design pioneer and Pascal creator Niklaus Wirth

[Michael Van Canneyt via fpc-pascal]

On Fri, 5 Jan 2024, Tony Whyman via fpc-pascal wrote:

"Swiss computer scientist Professor Niklaus Wirth died on New Year's Day, 
roughly six weeks before what would have been his 90th birthday."


https://www.theregister.com/2024/01/04/niklaus_wirth_obituary/?utm_source=daily_medium=newsletter_content=top-article


Yes, we put a short notice on the Free Pascal homepage...

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

Re: [fpc-pascal] FPReport: Split text across two or more pages

[Michael Van Canneyt via fpc-pascal]

On Tue, 2 Jan 2024, Pique7 via fpc-pascal wrote:


On Tue, 2 Jan 2024 00:02:35 +0100 (CET)
Michael Van Canneyt via fpc-pascal  wrote:




On Mon, 1 Jan 2024, Pique7 via fpc-pascal wrote:


Hello everyone,

I have already asked this and related questions in the Lazarus Forum.

I want to improve FPReport in order to use it for my project - if possible.
Some features are missing for this, e.g. automatic splitting of text across two 
or more pages.

As far as I can judge, the current development status of FPReport does not 
really allow me to extend it without modifying the original classes.


Why do you think so ?


Thanks for your reply.  I am not sure whether I have defined the problem
correctly from my point of view.  I have tried both FPReport and
LazReport.  LazReport is able to create page breaks within a band
automatically (though not always correctly calculated).  This is traceable
by viewing the source code of LazReport.  I haven't found anything similar
in the source code of FPReport and thus considered to implement it myself. 
But I haven't found a straightforward solution.


There is no straightforward solution if you wish to break a memo.

The layouter is not equipped for splitting bands.


What approach do you suggest? Would this be feasible/reasonable at all? I ask 
this because I am new to Lazarus and FPC. I come from Delphi 2007 ...


If you ask me, it's perfectly doable without any changes.

There is a demo that shows how to print a text by splitting it in lines, and
simply printing a band per line. That will have the same effect as what you
seem to need.  Basically, it means using a TStringList as a data source
for a (sub)band instead of using it as the text of a single memo.


Unfortunately I couldn't find the demo program you mention.  I know the
fcl demos in "source\packages\fcl-report\demos".  Admittedly I haven't
examined every single unit yet.  Most of the demo reports get the data
from a TStringList.  Is it this what is meant?


Yes. Normally you'll be using a dataset-based "data loop" (TFPReportData).

But the data loop can be an event-based loop, which uses a TStringList to
define the items in the loop. (an instance of TFPReportUserData is used for 
this)


What you may need to do is to split the text "correctly" over the lines of the
TStringList, but that should be easily doable. All you need is a function to
calculate the length of the text.

I think this is perfectly doable without any changes to the original code.


Okay, probably you're right and I think I understand the basic idea but I
still don't know how to transfer it to my case.  I have a table with
several columns containing multiline text.  The data comes from a TDataSet
descendent.  If one the cells (Memo) content is to large to fit on the
current page, the whole band should be split at the correct position and
continued on the next page, e.g.:

   [PAGE 1 - DATABAND 1 (bottom of page)]
   COL 1-1  COL 2-1
   COL 1-2  COL 2-2
   COL 1-3  COL 2-3

   [PAGE 2 - DATABAND 1 (continued)]
   COL 1-4  COL 2-4
   COL 1-5

I also have one report with one column containing richtext (RTF).  I doubt
that the TStringList solution will be helpful in this case.


If RTF is a requirement, in that case you can desist your efforts: 
RTF is not supported in FPReport. A limited subset of html is.


I don't know if RTF is supported in lazreport. Maybe on windows it is.

FPC comes with an RTF parser, but it would require a large amount of work to
integrate that in FPReport. RTF is a huge subject. 
It would be a nice addition, no doubt.




So in a nutshell, I think I need a function like "Continue (data) band on
the next page if remaining space is insufficient".


At the moment, I don't see how to create this function. 
IMO It would require a major rewrite of the layouter to introduce this.



 If you still think
your suggested approach is suitable, please let me know.  Maybe it is
obvious, but at the moment it seems that I don't make any progress.


Disregarding the RTF for a moment, you'd need to save the contents of the
text fields in a TStringlist instance in the 'afterscroll' event of the dataset.

This instance can then be used to create a data loop for a sub band
(using TFPReportUserData).
The band connected to the dataset (the master band) would not print anything. 
Instead, the child band will print the cell content line by line and split it over pages.



From your drawing, it is not quite clear how you construct your columns,

if you're using columns, I'm not sure how the band will behave.

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

Re: [fpc-pascal] FPReport: Split text across two or more pages

[Michael Van Canneyt via fpc-pascal]

On Mon, 1 Jan 2024, Pique7 via fpc-pascal wrote:


Hello everyone,

I have already asked this and related questions in the Lazarus Forum.

I want to improve FPReport in order to use it for my project - if possible.
Some features are missing for this, e.g. automatic splitting of text across two 
or more pages.

As far as I can judge, the current development status of FPReport does not 
really allow me to extend it without modifying the original classes.


Why do you think so ?


What approach do you suggest? Would this be feasible/reasonable at all? I ask 
this because I am new to Lazarus and FPC. I come from Delphi 2007 ...


If you ask me, it's perfectly doable without any changes.

There is a demo that shows how to print a text by splitting it in lines, and
simply printing a band per line. That will have the same effect as what you
seem to need.  Basically, it means using a TStringList as a data source
for a (sub)band instead of using it as the text of a single memo.

What you may need to do is to split the text "correctly" over the lines of the
TStringList, but that should be easily doable. All you need is a function to
calculate the length of the text.

I think this is perfectly doable without any changes to the original code.

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

Re: [fpc-pascal] How to avoid Copy

[Michael Van Canneyt via fpc-pascal]

On Mon, 1 Jan 2024, Hairy Pixels via fpc-pascal wrote:





On Dec 30, 2023, at 3:18 PM, Michael Van Canneyt via fpc-pascal 
 wrote:

And try to avoid "for r in data" because it will create a copy for each element
in the list.


This seems more like bad compiler design than anything.  From the users
perspective a for loop is a read-only operation and shouldn't be copying
anything.  I know it's how the enumerator thing is done but that may have
been a bad design from the start or needs some extra optimization
somewhere.


You can't optimize that. As said, a generic is convenient but slow.



For OP I would just kill the for-in loop in favor of a normal for-do loop and 
be done with the problem.


That will not help, since he is using a TList, it cannot work without
copy: any read implies a copy. Unless you use a pointer as Marco and I 
suggested.

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

Re: [fpc-pascal] How to avoid Copy

[Michael Van Canneyt via fpc-pascal]

On Sun, 31 Dec 2023, Amir--- via fpc-pascal wrote:




On 12/31/23 02:46, Marco van de Voort via fpc-pascal wrote:


Op 31/12/2023 om 04:11 schreef Amir--- via fpc-pascal:


I compiled the code with `fpc -O3 -Sd -gv -g -gl ` and ran `valgrind` 
on it (the output is attached). It does not look like there is a big 
difference between the Check1 and Check2 but Check3 is about 20 times 
faster than the other two.
I believe the issue could be resolved if we make 
"TCustomListWithPointers.GetPtrEnumerator" a public method. Then, one 
can implement the following function:


 I also do this (an enumerator using a pointer type) in one of my 
container types. It also makes assignment in the for in possible. Note 
though that it is not necessarily needed to switch the whole 
collection to use a pointer, defining a separate iterator (e.g. 
collection.pointeriterator) that returns an iterator instantiated for 
^T.   You can then select the iterator by using for element in 
collection.iterator do.
Understand (and this is what I ended-up doing). I guess my question is 
that why we do not to have a PointerIterator in TList class.


Because no-one thought to implement it, or no-one saw the need.

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

Re: [fpc-pascal] How to avoid Copy

[Michael Van Canneyt via fpc-pascal]

On Fri, 29 Dec 2023, Amir via fpc-pascal wrote:




On Dec 29, 2023 9:50 PM, Adriaan van Os  wrote:

  Amir--- via fpc-pascal wrote:
  > Hi all,
  >
  >  I have a List of record, where the record has a WideString field.
  >   I have some code like the following:
  >
  > function check(constref v: TMyRecord; data: TListOfMyRecord): Boolean;
  > var
  >   r: TMyRecord;
  >
  > begin
  >   Result := False;
  >   for r in data do
  > if r.State = v.State then
  >   Exit(True);
  > end;
  >
  > I call this method a lot and the CPU profiling shows a lot of cpu time
  > spent on "fpc_copy_proc" (which I assume is doing the deep copy on
  > records) from "TCustomListEnumerator.GetCurrent".
  > I considered other alternatives like using enumerators but they all need
  > a to return a record (and hence copying the widestring field).
  > I can think of two solutions to get rid of the wasting(!) so much time
  > on "fpc_copy_proc":
  > 1) Changing the TMyRecord to TMyClass. But then I need to Create and
  > Free a "lot" of objects.
  > 2) Update TListOfMyRecord to TListOfPointerToMyRecord. This requires a
  > "lot" of memory allocation/fragmentation.
  >
  > Is there a better solution?

  Pass the data parameter by reference.

This means I need to have a ListOfMyRecord and a ListOfConstRefMyRecord, right?


It means you use 
constref  data: TListOfMyRecord
or 
var data: TListOfMyRecord


And try to avoid "for r in data" because it will create a copy for each element
in the list.

I don't know how you defined TListOfMyRecord, but if it is a
generic TList, better change it to a TArray or Array
of TMyRecord, in which case you can use a pointer to the consecutive records
in the array. Generics are convenient, but slow.

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

Re: [fpc-pascal] Procedures that work like WRITELN()

[Michael Van Canneyt via fpc-pascal]

On Wed, 27 Dec 2023, James Richters via fpc-pascal wrote:


I wanted to write what I thought should be a simple procedure, just instead
of calling WRITELN() with some arguments,
call WRITELOG() with the same arguments that you would use to write to a
file, but my WRITELOG() procedure would
write to the screen and the file.. but I can't figure out how to pass all
the arguments to the two WRTIELNs.

So..

Procedure WriteLog(Filename:String, AllOtherAurguments:);
Begin
   Writeln(Filename,AllOtherAurguments);
   Writeln(AllOtherAurguments);
End;

How can I make this work?  Since WRITELN can take any number of many kinds
of arguments,
how can I get them all and pass them along without knowing how many or what
types they are?
How does WRITELN even work when you don't know this information?

I'm guessing there should be some way to do this, because WRITELN itself
works, but how it could
possibly work is not within my experience.

The only way I could think of would be if there were versions of WRITELN
with every combination
of possible arguments, but that seems completely unmanageable and
ridiculous,
so there must be something more advanced going on, but maybe WRTELN is
special and not something I can duplicate?


Writeln() is special. You cannot duplicate it.

What you can do is use WriteStr(), it has the same action as Writeln() but
writes to a string instead of a file.

https://www.freepascal.org/docs-html/current/rtl/system/writestr.html

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Mon, 25 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:

This is not correct either, as it suggests that ( ... ) is correct. It is 
not, if you use ... there must be other arguments present.


That is offending the reader: "You are to stupid to be given complete 
information".


That is a load of nonsense.

I agree that logical and correct thinking is a necessity.
I agree that modern teaching misses the point entirely.

But even in classical schooling you don't start by teaching general 
relativity theory to first-year secondary school students either. 
You need to build it up.


There are simply so many exceptions and limitations that the 100% correct
diagram would be incomprehensible and needlessly complicated if you tried to
capture every aspect for the full 100%.

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sun, 24 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:


I added univ and documented it.


Something seems to have gone wrong with the  defintion on page 
212.


Corrected, thanks.



Having a better look, the  rule defines just one 
parameter. So, we get instead


formal-parameter-list = "(" [ parameter-declaration { ";" 
parameter-declaration } ] [ "..." ] ")" .

parameter-list = formal-parameter-list .

comprising also the "ellipsis" parameter, which, according to Appendix D.6 
of the Programmer's Manual is functionally equal to the varargs

keyword.


Added to the diagrams.

I changed the diagram to be more clear (hopefully).


But the rule for  on page 211 now suggests that  "..." 
can be used in the middle of the other declarations, which is not true.


I am aware of this. It is mentioned in the text, see below why this is so.




	formal-parameter-list = "(" [ parameter-declaration { ";" 
parameter-declaration } ] [ "..." ] ")" .


This is not correct either, as it suggests that ( ... ) is correct. 
It is not, if you use ... there must be other arguments present.

You're also missing the ";" in front of the "...".

Likewise using parameter-declaration is not really correct, as it suggests that
parameters with default values can appear on any location in the list.
That is not correct, they must be the last parameters and cannot be followed
by a parameter without default value.

Likewise, "array of const" with a "cdecl" call-modifier can only appear as last
element in the list (it is translated to varargs). This is another
limitation. There are some limitations for possible combinations.

In short: To make a EBNF grammar which is 100% correct is not so simple and
will make the scheme extremely difficult to understand for a reader.

So I prefer to present a simpler version, and mention some limitations only in 
the
text:

That ... must be the last parameter is just one of them.




Can't a variable also be qualified ? Therefore ?

variable-reference = qualified-identifier .


Yes.


I didn't see a rule for  yet in the Language Reference.


I added it.





But to parse that, the rules for  and  
need something like an , don't they ?


Yes, I had come to this conclusion myself, and I added it.


I can't find the change yet.


That should be fixed now.

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sun, 24 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:


The following zip file contains the updated documentation:
http://downloads.freepascal.org/fpc/beta/3.2.4-rc1/docs/doc-pdf.zip

Besides correcting your remarks, I did a general overhaul:
- I changed the use of space character in syntactic elements to dash (-)
- Improved some diagrams.
- synchronized some syntactical elements.
- Tried to make sure every syntactical element has a definition.


Sorry, but are you sure this is the right download for all mentioned changes 
?


No, the git submodule was not yet up-to-date when I built the docs.

Should be OK now, I uploaded a new version.

Sorry about that, thanks for pointing it out !

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sun, 17 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt wrote:

32. Are the set operators "include", "exclude" missing in the syntax 
diagrams ? Is "><" missing (specifically) as set operator in the syntax 
diagrams ?


Include/Exclude are not operators. They are procedure calls.


Section 12.8.5 says "Elements can be added or removed from the set with the
Include or Exclude operators" and table 12.6 lists them as "Set operators". 
So, that is confusing (to me).






22. Various rules refer to a rule  for which I can't 
find the rule. What is it ?


identifier.


Can't a variable also be qualified ? Therefore ?

variable-reference = qualified-identifier .


Yes.



41. Is it correct that  is referenced only in the 
record  rule ? I would expect something like an 
 in various declaration rules.


To the best of my knowledge, only records support operator definitions.

The 'operator' chapter handles 'global' operators which are at the level of
global functions/procedures.


Your reply puzzles me.


Your question puzzled me.



But to parse that, the rules for  and  need 
something like an , don't they ?


Yes, I had come to this conclusion myself, and I added it.

The following zip file contains the updated documentation:
http://downloads.freepascal.org/fpc/beta/3.2.4-rc1/docs/doc-pdf.zip

Besides correcting your remarks, I did a general overhaul:
- I changed the use of space character in syntactic elements to dash (-)
- Improved some diagrams.
- synchronized some syntactical elements.
- Tried to make sure every syntactical element has a definition.

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

Re: [fpc-pascal] More syntax questions (part 4)

[Michael Van Canneyt via fpc-pascal]

On Sun, 17 Dec 2023, Adriaan van Os via fpc-pascal wrote:



Michael Van Canneyt via fpc-pascal wrote:



On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:



More questions about the FreePascal Language Reference (version 3.2.0), 
part 4


34. Are macpas LEAVE and CYCLE statements undocumented ?


Yes.


Well, according to Appendix D.6 of the Programmer's Manual, CYCLE is 
equivalent to CONTINUE and LEAVE to BREAK. Contrary to the information 
presented there, the CYCLE and LEAVE statements have been implemented for 
macpas mode.


I don't see BREAK and CONTINUE in the syntax diagrams either. I put together 
some examples (stressing that I am not a proponent of these C constructs).


That is because "break" and "continue" as well as leave are not keywords: 
you can use them as identifiers.


As such they are considered normal procedure calls and are documented in the 
system unit.

That explains why they're not in the syntax diagrams: when they appear, they are
treated as procedure calls.

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sun, 17 Dec 2023, Adriaan van Os via fpc-pascal wrote:



Another use of UNIV is type-compatibility of procedural parameters. For 
example with


 function BinaryFind
( theValuePtr : univ UnivPtr;
  theFirstIndex   : Int32;
  theLastIndex   : Int32;
 function SmallerThan
( theIndex: Int32;
  theValuePtr : univ UnivPtr): boolean;
 function EqualTo
( theIndex: Int32;
  theValuePtr : univ UnivPtr): boolean;
  var theFoundIndex   : Int32): boolean;


But this kind of procedural parameter doesn't seem to be included in the rule 
for . it is allowed in macpas and iso modes.


I added univ and documented it.

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sun, 17 Dec 2023, Adriaan van Os via fpc-pascal wrote:



On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:



More questions about the FreePascal Language Reference (version 3.2.0) 
part 3


26. Am I correct to assume the following equivalents for rules that I 
couldn't find a definiton for:


formal-parameter-list  = parameter-declaration .
parameter-list = parameter-declaration .


Having a better look, the  rule defines just one 
parameter. So, we get instead


	formal-parameter-list = "(" [ parameter-declaration { ";" 
parameter-declaration } ] [ "..." ] ")" .

parameter-list = formal-parameter-list .

comprising also the "ellipsis" parameter, which, according to Appendix D.6 of 
the Programmer's Manual is functionally equal to the varargs

keyword.


Added to the diagrams.

I changed the diagram to be more clear (hopefully).

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

Re: [fpc-pascal] More syntax questions (part 4)

[Michael Van Canneyt via fpc-pascal]

On Sun, 17 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:


37. Shouldn't the macpas "mwpascal" modifier be added to ?

call-modifiers = "register" | "cdecl" | "pascal" | "stdcall" | 
"safecall" | "inline" | "mwpascal" .
call-modifiers = "cdecl" | "inline" | "local" | "nostackframe" | 
"overload" | "pascal" | "register" | "safecall" | "saveregisters" | 
"softfloat" | "stdcall" | "varargs" | "mwpascal".


Yes. There are even more.


And, according to Appendix D.6 of the Programmer's manual:

7. The cdecl modifier keyword can be abbreviated to C.

in macpas mode.


Added to the docs.

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sun, 17 Dec 2023, Adriaan van Os via fpc-pascal wrote:



Michael Van Canneyt via fpc-pascal wrote:

28.  The documentation for macpas "UNIV" is missing ?


I have no idea what this is ?


UNIV is macpas specific (as mentioned in Appendix D.6 of the Programmer's 
Manual)


Thank you, added to the docs.

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

Re: [fpc-pascal] Double finalize

[Michael Van Canneyt via fpc-pascal]

On Wed, 20 Dec 2023, Hairy Pixels via fpc-pascal wrote:


I feel like this was addressed but I couldn't find any references. The program 
below prints the following:

 Initialize
 Create
 Finalize
 Finalize

Why is Finalize called twice? I thought those were supposed to be called in 
pairs with initialize?


If you look at the generated code, you see that there is an implicit 
try/finally block
and the  finally block does a finalize.

callfpc_pushexceptaddr
movq%rax,%rdi
callfpc_setjmp
movl%eax,-92(%rbp)
cmpl$0,%eax
jne .Lj10
leaq-96(%rbp),%rdi
callP$TEST$_$TMANAGEDOBJECT_$__$$_CREATE$$TMANAGEDOBJECT
movq$INIT_$P$TEST_$$_TMANAGEDOBJECT,%rsi
leaq-96(%rbp),%rdi
callfpc_finalize
.Lj10:
callfpc_popaddrstack
movq$INIT_$P$TEST_$$_TMANAGEDOBJECT,%rsi
leaq-96(%rbp),%rdi
callfpc_finalize
movl-92(%rbp),%eax


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

Re: [fpc-pascal] More syntax questions (part 4)

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:



More questions about the FreePascal Language Reference (version 3.2.0), part 
4


34. Are macpas LEAVE and CYCLE statements undocumented ?


Yes.



35. Are macpas ellipsis (...) parameters undocumented ?


Yes.



36. Is the macpas RETURN statement undocumented ?


Yes.



37. Shouldn't the macpas "mwpascal" modifier be added to ?

	call-modifiers = "register" | "cdecl" | "pascal" | "stdcall" | 
"safecall" | "inline" | "mwpascal" .
	call-modifiers = "cdecl" | "inline" | "local" | "nostackframe" | 
"overload" | "pascal" | "register" | "safecall" | "saveregisters" | 
"softfloat" | "stdcall" | "varargs" | "mwpascal".


Yes. There are even more.



38. Is a  rule missing ?

	constref-parameter = "CONSTREF" identifier-list [ ":" [ "ARRAY" "OF" 
] type-identifier ] .


where

	parameter-declaration = value-parameter | variable-parameter | 
out-parameter | constant-parameter | out-parameter  | constref-parameter .


Yes.



39. Section 16.7 defines a rule  and a rule 

library = library-header ";" [ uses-clause ] block "." .
exports-clause = "exports" exports-list ";" .

The exports-clause rule however doesn't seem to be referenced anywhere in the 
syntax, so it may have to be added to the  rule ?


To the library rule, but also to the unit rule, because it can also appear
in a unit...



40. < recordoperator-definition> =  ?


Yes.



41. Is it correct that  is referenced only in the record 
 rule ? I would expect something like an 
 in various declaration rules.


To the best of my knowledge, only records support operator definitions.

The 'operator' chapter handles 'global' operators which are at the level of
global functions/procedures.

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Wayne Sherman wrote:


On Sat, Dec 16, 2023 at 7:35 AM Michael Van Canneyt wrote:

Hm. Lot of corrections to do.. I'll be busy tonight :-)


Are these grammars in GIT so others can help by submitting merge
requests?  That way you can spread the love :-)



Everything concerning FPC is in git :-)

https://gitlab.com/freepascal.org/fpc/documentation/-/tree/main/syntax?ref_type=heads

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

Re: [fpc-pascal] More syntax questions (part 3)

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:



More questions about the FreePascal Language Reference (version 3.2.0)  part 
3


26. Am I correct to assume the following equivalents for rules that I 
couldn't find a definiton for:


formal-parameter-list  = parameter-declaration .
parameter-list = parameter-declaration .
hint-directives= { hint-directive } .
hint-modifiers = call-modifiers .
hintdirective  = hint-directive .
hintdirectives = hint-directives .
integer   := [ sign ] unsigned-integer .
integer-constant  := integer .
integerconstant   := integer-constant .
typed-declaration  = type-declaration .


Yes, although integer-constant, integerconstant and integer should simply all be
the same. I will correct that.



27. Section 13.2 defines a rule for  refering to a rule 



	structured-statement = compound-statement | conditional-statement | 
repetitive-statement | with-statement | exception-statement .


Am I correct to assume ?

exception-statement = try-except-statement | try-finally-statement .


Yes.



where

	try-except-statement = "try" statement-list "except" 
exceptionhandlers "END" .
	try-finally-statement = "try" statement-list "finally" 
finally-statements "END" .


Yes.



28.  The documentation for macpas "UNIV" is missing ?


I have no idea what this is ?



29. Am I correct to assume ?

ordinal-type = ordinal-type-identifier .
ordinal-type-identifier = identifier .


Yes.



30. Am I correct to assume that  was meant to be 
 ?


Yes.



31. Are the operators "<<" and ">>" missing  in the syntax diagrams ?


Yes and no.

I preferred not to document these since they are in fact C operators which I 
think
are a historical mistake.



32. Are the set operators "include", "exclude" missing in the syntax diagrams 
? Is "><" missing (specifically) as set operator in the syntax diagrams ?


Include/Exclude are not operators. They are procedure calls.

To illustrate, the following fails to compile:
---
type
  TEnum = (one,two,three);
  TEnums = set of TEnum;

var a : TEnums;

begin
  a:=[];
  a:=Include(a,one);
end.
---
iu.pp(9,6) Error: Incompatible types: got "untyped" expected "TEnums"
iu.pp(10,4) Fatal: There were 1 errors compiling module, stopping

The missing >< is an oversight



33. Section 12.1 gives "sign" in boldface in the rule for , 
suggesting that it is a keyword. Is that correct ?


No.

It is not a keyword, but one of '+' or '-'.

Hm. Lot of corrections to do.. I'll be busy tonight :-)

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

Re: [fpc-pascal] More syntax questions (part 2)

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:



More questions about the FreePascal Language Reference (version 3.2.0)  part 
2


17. For the following rules, I couldn't find a definition in the Language 
Reference. Can I assume they can all be defined as  ?


object-type-identifier = identifier .
field-identifier   = identifier .
interface-identifier   = identifier .
interface-type-identifier  = identifier .
method-identifier  = identifier .
procedure-identifier   = identifier .
protocol-identifier= identifier .
protocol-type-identifier   = identifier .
qualified-method-identifier= identifier .
result-identifier  = identifier .
type-identifier= identifier .
function-identifier= identifier .
unit-identifier= identifier .
variable-identifier= identifier .


Yes.

The idea was to use these "dedicated names" to convey that the identifier must 
be of a certain type.

You cannot express this concept in a formal syntax, but for a formal syntax the 
above is correct.



18. Section 14.4.1 defines a rule 

	value-parameter = identifier-list ":" [ "ARRAY" "OF" ] parameter-type 
| identifier ":" type-identifier "=" default-parameter-value .


I couldn't find a rule for . If  equals 
 then it may be easier to name it  ?


Not quite. it can also be 'const' (the 'array of const' construct).

This diagram needs to be enhanced, I suppose the following is more correct:

(identifier [ "=" constant-expression ] | "array" "of" ("const" | identifier))



19. Sections 3.6, 14.2 and 15.2 refer to a rule .

function-header = "FUNCTION" formal-parameter-list ":" result-type .
	function-header = "FUNCTION" ( identifier | 
qualified-method-identifier ) formal-parameter-list ":" result-type [ 
modifiers ] [ hintdirectives ] .
	operator-definition = "operator" ( assignment-operator-definition | 
arithmetic-operator-definition | comparision-operator-definition ) 
result-identifier ":" result-type ";" subroutine-block .


I couldn't find a rule for . Can I assume ?

result-type = type-identifier .


Yes.



20. For the following rules, I couldn't find a definition in the Language 
Reference. Can I assume they can all be defined as  ?


guid = single-quoted-string .
string-constant-declaration = single-quoted-string .
string-literal = single-quoted-string .
stringconstant = single-quoted-string .


Yes.



where  is a parser built-in rule that parses two 
consecutive single-quote chars as a literal single-quote char ? and that may 
not contain CR and LF characters  ? or any other control characters ?


Yes. 
Following your remarks, I was planning to introduce a list of "parser built-in"

rules, as I need them to define the constants.



21. Can I assume ?

statement-list = statement { ";" statement } .
statementlist = statement-list .


Yes.



22. Various rules refer to a rule  for which I can't find 
the rule. What is it ?


identifier.



23. Section 12.2 defines a rule  that references rules 
 and .


	function-call = ( function-identifier | method-designator | 
qualified-method-designator | variable-reference ) [ actual-parameter-list ] 
.


I can't find the rules for  and 
. What are they ?


With the appearance of nested classes and type definitions, they are actually 
the same.

method-designator = qualified-method-designator = identifier ({ "." identifier 
})

So the function-call can be simplified to
  function-call = ( method-designator | variable-reference ) [ 
actual-parameter-list ]

maybe introducing a

  fully-qualified-identifier = identifier ({ "." identifier })

and using that everywhere instead is a better approach.



24. Sections 14.4.1 and 14.4.4 define rules that refer to a rule 
.


	value-parameter = identifier-list ":" [ "ARRAY" "OF" ] parameter-type 
| identifier ":" type-identifier "=" default-parameter-value .
	constant-parameter = "CONST" ( identifier-list [ ":" [ "ARRAY" "OF" ] 
type-identifier ] | identifier ":" type-identifier "=" 
default-parameter-value ) .


I can't find the rule for . What is it ?


default-parameter-value = constant-expression



25. Section 16.2 defines a  rule  that refers to a rule 



	interface-part = "INTERFACE"  [ uses-clause ]  { 
constant-declaration-part  | type-declaration-part | 
variable-declaration-part | property-declaration-part | 
procedure-headers-part } .


I can't find the rule . What is it ?



That should be
   property-declaration-part = property definition { ";" property definition }

("property definition" is defined in the class declaration diagram)

Michael.
___
fpc-pascal 

Re: [fpc-pascal] More syntax questions (and more to follow)

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:

Thanks for the replies.


Please note that the syntax diagrams are NOT meant to be exhaustive.
They are an aid to explain the syntax. I strive to make them as correct as
possible, but they make no pretense to being complete.


Anyway, I strive to make the syntax complete and correct. When it is ready, I 
can send it in to be added as an Appendix to the Language Reference manual. I 
have an ebfn-driven general (back-parsing) parser, that already works for 
Oberon-0 end UCSD-Pascal. So, the ebnf can be tested.


There are several typesetting systems that can convert EBNF to a nice
diagram, so it can be nicely typeset too.

I have long been looking for an EBNF, and only found several syntaxes for other
systems, so that would be really good if you could make one. I would include
it at once :-)

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

Re: [fpc-pascal] More syntax questions (and more to follow)

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Adriaan van Os via fpc-pascal wrote:



More questions about the FreePascal Language Reference (version 3.2.0)

1. Section 17.1 defines a rule  and 

	raise-statement = "raise" [ exception-instance [ exception-address ] 
] .
	exception-address = "at" exception-address [ "," address-expression ] 
.


a) Is it correct that  defines itself recursively ?


No.

That should be exception-address = "at" address-factor

Corrected.



b) I can't find the rule that defines . What is it ?


Typo, should be address-factor.

Corrected.



c) I can't find the rule that defines . What is it ?


An expression of type exception.

Added.



2. Section 12.1 refers to a rule 

	factor = "(" expression ")" | variable-reference | function-call | 
unsigned-constant| "NOT" factor | "sign" factor | set-constructor | 
value-typecast | address-factor .


I can't find the rule  but it may be the same as the rule 
 given in section 12.7 ?


Yes. Corrected.



	addressfactor = "@" ( variable-reference | procedure-identifier | 
function-identifier | qualified-method-identifier ) .


3. Section 2.2 refers to a rule 

	typed-constant = constant | address-constant | array-constant | 
record-constant | procedural-constant .


I can't find the rule . What is it ?


A constant of type address. So either Nil or @identifier.



4. Section 2.2 also refers to a rule 

	typed-constant = constant | address-constant | array-constant | 
record-constant | procedural-constant .


I can't find the rule . What is it ?


A constant of type array, obviously.

Needs to be added.



5. Section 2.2 also refers to a rule 

	typed-constant = constant | address-constant | array-constant | 
record-constant | procedural-constant .


I can't find the rule . What is it ?


A constant of type record.

Needs to be added.



6. Section 2.2 also refers to a rule 

	typed-constant = constant | address-constant | array-constant | 
record-constant | procedural-constant .


I can't find the rule . What is it ?


Address-factor of procedural type.

Needs to be added.



7. Section 13.3 refers to a rule 

asm-statement = "asm" assembler-code "END" [ registerlist ] .

I can't find a rule for  What is it, from the point of view 
of parsing Pascal ?


Undefined. Skip all tokens till you meet END.




8. Section 10.1 refers to  a rule 

	helper-type = ( "CLASS" | "RECORD" | "TYPE" ) "helper" [ "(" 
basehelper ")" ] "FOR" identifier  { helper-component-list } "END" 
hint-modifiers .


I can't find a rule for . What is it ?


An identifier.

Corrected.




9. Sections 17.2 and 6.1 refer to a rule 

	exception-handler = "ON" [ identifier ":" ] class-type-identifier 
"DO" statement .
	class-heritage = "(" class-type-identifier [ 
class-implemented-interfaces ] ")" .


I can assume ?

class-type-identifier = identifier .


Yes.

Added.



10. Section 11.2 refers to a rule 

	objc-class-heritage = "(" [ objective-Cclass-type-identifier ] [ 
objc-implemented-protocols ] ")" .


I can assume ?

objective-Cclass-type-identifier = identifier .


Yes.

Added.



11. Section 6.1 refers to a rule 

class-reference-type = "CLASS" "OF" classtype .

I can't find a rule for . What is it ?


class-type-identifier (or identifier)

Added.



12. Section 13.2 refers to a rule 

	structured-statement = compound-statement | conditional-statement | 
repetitive-statement | with-statement | exception-statement .


I can't find a rule for . What is it ?


You missed it. It is defined under 'Structured statements'.



13. Section 6.1 referes to a rule 

	component-list = [ visibility-specifier ] { field-definition } { 
const-declaration-part | type-declaration-part | variable-declaration-part | 
class-variable-declaration-part | method-definition | property-definition } .


I can assume ?

const-declaration-part = constant-declaration-part .


Yes. Corrected.



14. Sections 2.2, 3.1.1, 3.3.2, 4.7 and 13.2.2 refer to a rule 

	typed-constant = constant | address-constant | array-constant | 
record-constant | procedural-constant .

subrange-type = constant ".." constant .
variant = constant { "," constant } ":" "(" [ field-list ] ")" .
default-specifier = "default" [ constant ] | "nodefault" .
stored-specifier = "stored" ( constant | identifier ) .
	case = constant [ ".." constant ] { "," constant [ ".." constant ] } 
":" statement .


I can't find a rule for . What is it ?


A simple constant. ordinal, string or float.

Needs to be added.




15. Sections 5.1 and 6.6.1 refer to a rule 

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


I can assume ?

constant-expression = expression .


As far as parsing is concerned, yes.




16. Section 12.1 refers to a rule 

	unsigned-constant = unsigned-number | 

Re: [fpc-pascal] case statement

[Michael Van Canneyt via fpc-pascal]

On Fri, 15 Dec 2023, Adriaan van Os wrote:


Michael Van Canneyt via fpc-pascal wrote:


The fact that the semicolon before the else is optional ?


I don't see a semicolon in the formal syntax.


This works:


OK, than an optional semicolon must be added to the  rule

exceptionhandlers =  [ exception-handler { ";" exception-handler } [ ";" ] [ 
"ELSE" statement-list ] | statement-list ] .


Well, you can have ; as well.

It means exception-handler can be empty in your repeat:

{ ';' [exception-handler] }

Or the whole ; is simply sloppyness on the part of the compiler.

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

Re: [fpc-pascal] method-definition

[Michael Van Canneyt via fpc-pascal]

On Sat, 16 Dec 2023, Hairy Pixels via fpc-pascal wrote:





On Dec 15, 2023, at 8:56 PM, Adriaan van Os via fpc-pascal 
 wrote:

What complicates things, is that many conflicting rules have the same name in 
the Language Reference. For example, conceptually we have object-methods, 
record-methods, class-methods, interface-methods and objcclass-methods. But 
only the record method rules are prefixed as such.


You mean like why records require you to add "static" to class methods? Makes 
no sense to me either.


Well, I guess the explanation is something like the following:

Because class methods normally get a TClass pointer (a class reference) as Self 
unless you
specify self (in which case they become normal records).

Since records do not have a TClass concept, this 'Self' cannot be passed. 
To be consistent with classes and to make this explicit, the 'static' is

required.

In my opinion this is superfluous, but embarcadero decided otherwise.

The requirement for parameters in record constructors I guess comes from C++ builder by Embarcadero. 
There are some limitations imposed by C++.


Whether they could be dropped in FPC is something Sven Barth should answer.

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

Re: [fpc-pascal] case statement

[Michael Van Canneyt via fpc-pascal]

On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:



On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:

Note that the same ambiguity exists in the  syntax (and 
this is less well known)


exceptionhandlers =  [ exception-handler { ";" exception-handler } [ 
"ELSE" statement-list ] | statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO" 
statement .


as  ends with a  and the optional <"ELSE" 
statement-list> part start with "ELSE". Sloppy language design, I assume 
by Borland.


What exactly do you consider "sloppy" ?


The ambiguity in the syntax whether ELSE belong to  or to <"ELSE" 
statement-list>.


Why do you think this is ambiguous ? It always belongs to statement list.

If there is ambiguity, it is in the if then else construct.
This makes it difficult to read for humans.


The fact that the semicolon before the else is optional ?


I don't see a semicolon in the formal syntax.


This works:

---
{$mode objfpc}

uses sysutils;

begin
  try
  except
on E: EAccessViolation do
  begin
  end;
on E: EInoutError do
  begin
  end; // can be removed or not.
else
  begin
  Writeln('OK');
  end;
  end;

end.
---

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

Re: [fpc-pascal] case statement

[Michael Van Canneyt via fpc-pascal]

On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:

Note that the same ambiguity exists in the  syntax (and 
this is less well known)


exceptionhandlers =  [ exception-handler { ";" exception-handler } [ "ELSE" 
statement-list ] | statement-list ] .
exception-handler = "ON" [ identifier ":" ] class-type-identifier "DO" 
statement .


as  ends with a  and the optional <"ELSE" 
statement-list> part start with "ELSE". Sloppy language design, I assume by 
Borland.


What exactly do you consider "sloppy" ?

The fact that the semicolon before the else is optional ?

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

Re: [fpc-pascal] implementation-part

[Michael Van Canneyt via fpc-pascal]

On Fri, 15 Dec 2023, Adriaan van Os via fpc-pascal wrote:



The Freepascal Language Reference (version 3.2.0) states in section 16.2

"As can be seen from the syntax diagram, a unit always consists of a 
interface and an implementation part."


and

"Both the interface part or implementation part can be empty, but the 
keywords Interface and implementation must be specified.


However, this was changed when implementing macpas mode (or at least for the 
macpas mode) in that the implementation part is no longer obligatory. This is 
useful for units with (only) external declarations.


Really ?

Not being a macpas user, I was not aware of this. 
I will update the documentation.


Thank you for pointing it out.

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

Re: [fpc-pascal] case statement

[Michael Van Canneyt via fpc-pascal]

On Thu, 14 Dec 2023, Adriaan van Os via fpc-pascal wrote:



I am looking in detail at the syntax diagrams in the Freepascal Language 
Reference (version 3.2.0)


Section 13.2.2 discusses the case-statement. Translated to EBNF (WSN) the 
syntax is


case-statement = "CASE" expression "OF" case { ";" case } [ else-part ] [ ";" 
] .
case = constant [ ".." constant ] { "," constant [ ".." constant ] } ":" 
statement .

else-part = [ "ELSE" | "OTHERWISE" ] statementlist .

If this is correct (and the compiler really allows it) then a semicolon 
between  and  is not required.


It is not required.

Consequently, there is an 
ambiguity between an if-then-else statement (as last statement of the ) 
and an if-then statement (as last statement of the ) and an 
. This is extremely dangerous and I feel that at least the 
Language Reference should warn against it.


A good point. I will add a warning.



Even with an obliged semicolon, I always use "OTHERWISE instead of ELSE, but 
that's my personal preference.


Indeed. By contrast I abhorr the OTHERWISE. Tastes differ.

Thanks for bringing the ambiguity to my attention.

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

Re: [fpc-pascal] Question regarding building fpc from sources

[Michael Van Canneyt via fpc-pascal]

On Wed, 29 Nov 2023, Bo Berglund via fpc-pascal wrote:


I have for many years been building my Linux versions of fpc and lazarus from
sources downloaded first from the svn repository and later from github.
When doing the build on a new Linux system I need a seed compiler for the
platform and I usually get that from earlier builds on other devices.
To simplify things I have made tgz archives of the compilers I have built and
put them on my website so I can then use wget on a new device to download them
into the fpc dir on that platform.

Now there has been a bit of pause in these activities and I am trying to catch
up so I wanted to create the tgz files for two compilers on my latest build
system (a Raspberry Pi4B running 32 bit bookworm OS).

After building 3.2.2 using a compiler I already had in the fpc dir I exctracted
the ppcarm compiler from the compiler directory in the source tree and put it
into a tgz archive.
But amazingly when I tried to locate the output compiler from when I built the
3.2.0 version a week ago it has disappeared!
No trace of it inside the fpc/3.2.0/compiler directory!

The difference from the newly built compiler is that a week ago I also ran the
make install command to put source files etc into a directory below my $HOME
dir. This step is not yet done for 3.2.2

My script does this for the install operations (variables set before of course).
The current dir for the command is at the top of the source tree such as
$HOME/devel/fpc/3.2.0

make install PREFIX="$HOME" FPC="$HOME/devel/fpc/3.2.0/compiler/$FPCCOMPILER"

rm "$HOME/bin/$FPCCOMPILER"

ln -sf "$HOME/lib/fpc/3.2.0/$FPCCOMPILER" "$HOME/bin/$FPCCOMPILER"

make sourceinstall PREFIX="$HOME" FPC="$HOME/bin/$FPCCOMPILER"

$HOME/lib/fpc/3.2.2/samplecfg $HOME/lib/fpc/3.2.2 $HOME

mv "$HOME/fpc.cfg" "$HOME/.fpc.cfg"

Somewhere in the process above the newly built compiler/ppcarm disappears from
the compiler dir

Is this what should happen or is it an error?


Because installing sources requires a 'clean' source tree, 
'make sourceinstall' does a clean first.


So you should not do this as long as the compiler binary has not been 
moved somewhere else. (the make install normally does this).


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

Re: [fpc-pascal] TPath enhancements (Issue #40513): can somebody test with Delphi 12?y

[Michael Van Canneyt via fpc-pascal]

On Sun, 19 Nov 2023, Bart via fpc-pascal wrote:


On Sun, Nov 19, 2023 at 3:50 PM Bart  wrote:


Thanks again for testing.


What about ['c:','a','b']
Does it return c:a\b, or c:\a\b (on Windows), or IOW: does it take
into account driveletters?
The first one IMO would be correct.


It returns c:a\b

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

Re: [fpc-pascal] TPath enhancements (Issue #40513): can somebody test with Delphi 12?y

[Michael Van Canneyt via fpc-pascal]

On Sun, 19 Nov 2023, Bart via fpc-pascal wrote:


On Sun, Nov 19, 2023 at 2:31 PM Michael Van Canneyt via fpc-pascal
 wrote:



> This raises the question what the result of
> TPath.Combine(['a','\b',c'','\d','e']) would be (I would then expect
> either \b\c or \d\e)?

\d\e

>
> If ValidateParams is True, will it raise an error on invalid path
> characters in an argument that will not be used for the final result
> e.g. ['a','<|>','c:\foo']?

Yes. All arguments are checked.


Thanks again for testing.
Where is EInOutArgumentException defined?
Probably it's defined as class(EInOutError)?


No. EArgumentException.


If so, what is the value of the ErrorCode property in this case?


There is no errorcode, since there is no IO. It's purely a string operation.

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

Re: [fpc-pascal] TPath enhancements (Issue #40513): can somebody test with Delphi 12?y

[Michael Van Canneyt via fpc-pascal]

On Sun, 19 Nov 2023, Bart via fpc-pascal wrote:


On Sun, Nov 19, 2023 at 12:59 PM Michael Van Canneyt via fpc-pascal
 wrote:


The output is in linux.txt and windows.txt


Thanks for testing.

It seems that it'll pick the last absolute path it finds, not the
first one in the argument list.

It seems that DoTest('regular 1','a','\b','c'); will give '\b\c'
That's confucing given that the Delphi docs suggest that if an
absolute path is found (being not the firts argument), then this path
will be the function result.


Given the purpose, I think it's perfectly logical since it starts from the back.

The purpose is to create an absolute path given some partial or complete paths.
So you must start from the back.

I have a file myfile = 'c:\something\myfile.inc' that I must find in a path
so I do

For P in SearchPath do
  begin
  F:=TPath.Combine(P,MyFile);
  if FileExists(F) then
Exit(F)

The above  should return myfile since that is an absolute filename.


If that were to be true, I would expect the result to be '\b' in that case.

This raises the question what the result of
TPath.Combine(['a','\b',c'','\d','e']) would be (I would then expect
either \b\c or \d\e)?


\d\e



If ValidateParams is True, will it raise an error on invalid path
characters in an argument that will not be used for the final result
e.g. ['a','<|>','c:\foo']?


Yes. All arguments are checked.

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

Re: [fpc-pascal] TPath enhancements (Issue #40513): can somebody test with Delphi 12?

[Michael Van Canneyt via fpc-pascal]

On Sun, 19 Nov 2023, Bart via fpc-pascal wrote:


On Sun, Nov 19, 2023 at 11:04 AM Sven Barth via fpc-pascal
 wrote:



Also: does this depend on the operating system and/or file system? Cause Linux 
file systems have different invalid characters (usually only slash and NUL) 
than NTFS or FAT.


Determining FileSystem at runtime, is that even possible?
Adjusting the TPath.HasValidPathChars and TPath.GetInvalidPathChars
functions for *nix maye be rather easy (there laready is non-windows
code in that unit)

ValidateParams may even mean (ATM nobody seems to know) that the
params must represent a valid path (either on it's own or after
concatenation).


You cannot test that as the path does not need to exist or does not even
need to be complete. Consequently it's also not possible to determine the 
filesystem and hence not possible to test on that.


Note that there is also a 4 path elements version of the call.
Seems to me you can simply repeatedly call the 2 path version from back to
front.

If I need to do more tests, let me know.

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

Re: [fpc-pascal] TPath enhancements (Issue #40513): can somebody test with Delphi 12?

[Michael Van Canneyt via fpc-pascal]

On Sun, 19 Nov 2023, Sven Barth via fpc-pascal wrote:


Bart via fpc-pascal  schrieb am Sa., 18.
Nov. 2023, 18:24:


1. The docs state that an exception is raised if the given paths
contain invalid characters. Does the vlaue of the ValidateParams have
any influence on this?



Also: does this depend on the operating system and/or file system? Cause
Linux file systems have different invalid characters (usually only slash
and NUL) than NTFS or FAT.


Attached program tests for invalid characters. if ValidateParams is
False, no tests are done on input.

The output is in linux.txt and windows.txt


From what I can see all characters with ascii code < 32 are invalid.

For windows additionally, the > " < and | characters are invalid.

This is for paths only. I didn't test filename characters.

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

Re: [fpc-pascal] fcl-web websocket

[Michael Van Canneyt via fpc-pascal]

On Wed, 8 Nov 2023, k1 via fpc-pascal wrote:



Hi guys,

do somone know how to enable ssl with the websocket semod

fcl-web/examples/websocket/server/wsserver
fcl-web/examples/websocket/client/wsclient

the client working fine with a node websocket server,
with just one command more

FClient.UseSSL := True;
and uses opensslsockets

but the server with the same command crash

what do i have to do on the server side to have a ssl connection


It should work out of the box. I tested it when it was developed,
the 'wss' scheme worked.

If it does not work for you, please report it in the issue tracker and
attach a sample console program that shows the issue.

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

Re: [fpc-pascal] Difference between string and Tbytes as procedure arguments?

[Michael Van Canneyt via fpc-pascal]

On Sun, 5 Nov 2023, Bo Berglund via fpc-pascal wrote:



You must copy the data. The copy() function can be used for this.


Follow-up question:

Can I change the function declaration like this and preserve the content?

function TSSConnection.ParseCmdFileData(var SSCmdFile: TSSCommandFile; const
Buf:  TBytes): boolean;


This does not preserve the content. The "const" means you cannot change the
pointer, so

Buf:=a;

will fail

But

Buf[0]:=1;

will still compile.



Or must I copy the argument Buf inside the function to a local BufL version?
That is what you adviced, right?


Yes.

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

Re: [fpc-pascal] Difference between string and Tbytes as procedure arguments?

[Michael Van Canneyt via fpc-pascal]

On Sun, 5 Nov 2023, Bo Berglund via fpc-pascal wrote:


I am maintaining an old utility program that started out about 20+ years ago
using Delphi7.

The utility communicates via RS232 with a measuring system in order to retrieve
and process recorded data and at the time this was started I used strings as
buffers for the serial comm.

A string at the time was really just an array of 1-byte characters but it had
useful functions for manipulating data inside so it made sense to use strings at
the time.

But as time evolved and Borland changed the meaning of string to now be
unicodestring it could no longer be used as a comm buffer, so I switched
declaration to AnsiString or even RawByteString to keep the existing utility
tools operational.

New programs I wrote would use TBytes as buffer instead...

Then about 6-7 years ago I had to do a major overhaul of the program in order to
improve the user interface and add support for switching languages in the UI and
at that time I also tried my best to replace the AnsiString buffers with TBytes
buffers. At this time I was on Delphi XE5.

It all looked OK until I recently got a call from a distributor who had
discovered that for a certain type of seldom used data collection mode the
output was corrupted when transfered to disk

And now I have found that the corruption happens inside a function that analyzes
one of the data packets where it will remove the start header record from the
buffer and then continue parsing the data items. (The buffer is sent in as a
regular argument without the var specifier).

Following this analysis in main code the buffer itself (that was used in the
previous call) is saved to disk in binary format.
And here is the problem:

The saved image of the buffer lacks the header part (30 bytes)...

So my question is this:
Is there a difference in handling the arguments between string, AnsiString,
RawByteString and TBytes in a declaration like this:

function TSSConnection.ParseCmdFileData(var SSCmdFile: TSSCommandFile; Buf:
AnsiString): boolean;

and this:

function TSSConnection.ParseCmdFileData(var SSCmdFile: TSSCommandFile; Buf:
TBytes): boolean;

In the first instance it looks like the function receives a *copy* of the data


No, but an ansistring is copy-on-write. As soon as you change it, a copy is
made if your routine is not the only one using the string.


in the Buf argument and in the second case it receives a pointer to the actual
live data such that in the first case the argument source remains untouched
whereas in the second case the argument source is changed just as it had been
declared as var...


That is correct. TBytes is a fancy wrapper around a pointer with some
reference counting added to the mix.



Is there a way to simply tell Delphi/FreePascal to treat also TBytes as copy
rather than a pointer to the real data?


You must copy the data. The copy() function can be used for this.

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

Re: [fpc-pascal] fcl-pdf custom font from memstream

[Michael Van Canneyt via fpc-pascal]

On Thu, 2 Nov 2023, Mattias Gaertner via fpc-pascal wrote:




On 02.11.23 14:00, Michael Van Canneyt via fpc-pascal wrote:



On Thu, 2 Nov 2023, Alexey Torgashin via fpc-pascal wrote:




How to load a custom font from a stream instead of from a file?


Currently no way to my knowledge,


But fpparsettf.pp has this:

 TTFFileInfo = class(TObject)
 ...
 public
   // Load a TTF file from file or stream.
   Procedure LoadFromFile(const AFileName : String);
   Procedure LoadFromStream(AStream: TStream); virtual;


Yes, but the font cache/manager in fpttf does not support this, and all 
font access happens
through the font cache. (at least that is how I understood Mattias' 
request)


Yes. I added two functions and extended the example.

To my surprise it turns out that a ttf file is loaded up to 3 times:
Once for AddFont, once for gTTFontCache and once in SaveDocument.

SaveDocument now uses the TPDFFont stream if available, so only 2 times.

Wouldn't it be better if TPDFDocument.Fonts and gTTFontCache share the 
stream?


Yes, absolutely.

But we may need a ref. counting mechanism then. Or at least we need to
decide who 'owns' the streams; 
At first sight it seems to me the gTTFontCache should own all font streams.


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

Re: [fpc-pascal] fcl-pdf custom font from memstream

[Michael Van Canneyt via fpc-pascal]

On Thu, 2 Nov 2023, Alexey Torgashin via fpc-pascal wrote:




How to load a custom font from a stream instead of from a file?


Currently no way to my knowledge,


But fpparsettf.pp has this:

 TTFFileInfo = class(TObject)
 ...
 public
   // Load a TTF file from file or stream.
   Procedure LoadFromFile(const AFileName : String);
   Procedure LoadFromStream(AStream: TStream); virtual;


Yes, but the font cache/manager in fpttf does not support this, and all font 
access happens
through the font cache. (at least that is how I understood Mattias' request)

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

Re: [fpc-pascal] fcl-pdf custom font from memstream

[Michael Van Canneyt via fpc-pascal]

On Thu, 2 Nov 2023, Mattias Gaertner via fpc-pascal wrote:


Hi,

How to load a custom font from a stream instead of from a file?


Currently no way to my knowledge, but I am open for patches !

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

Re: [fpc-pascal] IDispatch with Variant is not working on Linux. Why?

[Michael Van Canneyt via fpc-pascal]

On Wed, 1 Nov 2023, Anthony Walter via fpc-pascal wrote:


Thank you Micahel,

I was doing some research last night and found that there are two specific
stubs in the System unit that are implemented by the ComObj unit.
Specifically, a stub for safe call exception handling and dispatch invoke.


Yes, exactly.

I think the dispatch invoke callback/stub is in the variants unit: 
the VarDispProc procedural variable



I was working with my example and added my own OS agnostic implementations
of those two functions. This eliminated the access violations.

I am not finished testing my solution, but in cases where late binding is
desired, it ought to be possible to have it work on all platforms so long
as the late binding is not attempting to cross process boundaries, which is
common on Windows when using out of process servers such as Word or Excel.
Perhaps my use case for late binding to a self contained scripting library
might be useful for other people Free Pascal who do not run Windows. I am
sure there are other possible use cases as well. In that light, it might be
useful to integrate my eventual implementation into some unit included with
FPC.


Indeed.

I would be very grateful if you donate it, it would be useful for all FPC users 
!

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

Re: [fpc-pascal] IDispatch with Variant is not working on Linux. Why?

[Michael Van Canneyt via fpc-pascal]

On Tue, 31 Oct 2023, Anthony Walter via fpc-pascal wrote:


Is there any reason why the late binding of properties and methods through
of IDispatch interface with the Variant type is not working on Linux?



Variant dispatching requires OS bindings.

They are enabled when the ComObj unit is included, and this is only included on 
windows.

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

Re: [fpc-pascal] [Lazarus] Running FPC in the browser...

[Michael Van Canneyt via fpc-pascal]

On Sat, 28 Oct 2023, Wayne Sherman via fpc-pascal wrote:


On Sun, Oct 22, 2023 at 3:20 AM Michael Van Canneyt wrote:

Thanks to the efforts of Nikolay Nikolov, the FPC compiler can now recompile
itself to webassembly


I just watched an interesting talk from StrangeLoop called:

"Inside the Wizard Research Engine" by Ben L. Titzer
https://www.youtube.com/watch?v=43ENxjq2Vhc

The Wizard Research Engine is a WASM interpreter for research and
analysis that can help compiler and program writers analyze and debug
their code.  It can be used to perform WASM code coverage, branch
profiling, memory/cache profiling, dynamic call graph construction,
debug breakpoints, watchpoint, tracing and fuzzing and fault
injection. (see talk @ 11:14 and 13:54)

Wizard: An advanced WebAssembly Engine for Research
https://github.com/titzer/wizard-engine


Thank you. I didn't know this one yet !

The WebAssembly eco system is already so big, there are really great tools
our there. I've reduced FPC generated modules to 1/3rd of their size, and
the resulting webassembly runs faster than the original FPC generated
(webassembly) code.

With the wasmtime or wasmedge library, Lazarus could integrate the FPC
compiler into the lazarus binary: the module needs to be loaded only once,
and can be executed as often as necessary. One can even imagine compiling
packages in parallel in separate threads. Output can be read directly, no
need to use processes, pipes etc.

Some benchmarking is of course needed to see if there is a speed benefit.

And we're just at the beginning.

I would not be surprised to see that webassembly will eventually make the 
JVM and C# runtime engines redundant...


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

[fpc-pascal] Running FPC in the browser...

[Michael Van Canneyt via fpc-pascal]

Hello,

Thanks to the efforts of Nikolay Nikolov, the FPC compiler can now recompile
itself to webassembly (the support for the goto statement made this possible).

As a consequence, this means FPC can now be run in a browser. 
See the screenshot at


https://wiki.freepascal.org/WebAssembly#Running_in_Web_Browsers

There are still some steps to do before FPC will actually compile and link a
program, but this is in the works as well.

If you think this is just a cute geeky achievement, it is not.

Think about the possibilities: being able to work without the need for an 
installation. Just go to a webpage and start developing as you would on your 
desktop.


For teaching programming, a teacher does not need to provide anything except a
browser and still have all the possibilities he would have when using a 
desktop.

No heavy server infrastructure is needed, everything happens in the browser.

No doubt, other possibilities will come to mind.

Stay tuned for more goodies from the FPC team :-)

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

Re: [fpc-pascal] All methods vitrual ?

[Michael Van Canneyt via fpc-pascal]

On Mon, 16 Oct 2023, Adriaan van Os via fpc-pascal wrote:




That's absurd, there are many features in modes objfpc and macpas
that don't compile with Delphi.


That doesn't make it any less true. 


Also we won't add it anyway, so... 路‍♀️


Apperently, a sensible discussion, based on logical arguments, instead of 
dogma, is impossible.


This has nothing to do with dogma.

You ask to change the language. A considerable change by any standards,
requiring persuasive arguments, and your arguments for this change are simply 
not persuading enough.


Changing the language so you can get your list of methods is an ad-hoc
solution to a (from our point of view) non-problem.

There are (or will be) other solutions to your particular problem, 
making such a change simply unnecessary.


We can argue about the manner in which Sven closed the discussion, 
but that's a matter of style, not dogma.


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

Re: [fpc-pascal] What is webasssembly?

[Michael Van Canneyt via fpc-pascal]

On Wed, 11 Oct 2023, Steve Litt via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal said on Wed, 11 Oct 2023 08:27:35
+0200 (CEST)


On Tue, 10 Oct 2023, Steve Litt via fpc-pascal wrote:


What is webasssembly?


A bytecode format (similar to what is used in Java and C# runtimes)
which is an open standard and which runs in all major browsers or in a
host application.


Does this mean I can code an application in Pascal and use webassembly
to turn it into a web application? If so, could you please point me to
some simple examples?


Careful, there is no 'simple' in webassembly :-)

Basically, yes, this can be used to run a pascal program.

At the moment, all console applications will work in the browser, 
except for input, unless you use pre-prepared input.


Most packages in FPC that do not rely on external libraries will compile.

For demos:

In the pas2js project, there are demos under the 'wasienv' directory. 
You can adapt the helloworld example to load any .wasm file you want:


https://gitlab.com/freepascal.org/fpc/pas2js/-/tree/main/demo/wasienv/simple

You can do graphics using a HTML canvas (see the canvas demo), 
you can also manipulate the DOM. (see the job_* units in the 'dom' demo)


You cannot (yet) write a Lazarus LCL program and compile it to webassembly.

For those that also use Delphi, I'm currently working on porting FMX to 
Webassembly for my job, to be able to make full-fledged UI programs. 
The outcome is as yet uncertain, but we think it should be doable.


Michael.

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

Re: [fpc-pascal] All methods vitrual ?

[Michael Van Canneyt via fpc-pascal]

On Wed, 11 Oct 2023, Adriaan van Os via fpc-pascal wrote:


Michael Van Canneyt via fpc-pascal wrote:

$M controls the inclusion of RTTI, i.e. it allows or disallows the use of 
the published section.

No more, no less.


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


While I agree with your statement about allowing/disallowing use of
'published' based on a directive, we inherited this from Delphi 
and it is a very basic part of the language & RTL, so changing it 
is simply not an option.


The extended RTTI is meant to remedy this (also in Delphi), 
but IMO it introduces its own problems (you'll love the amount 
of compiler directives it needs ;)).


I'm surprised to hear about your failure to get fcl-passrc to work, 
since it is used to create the docs based on the fpc sources. 
Additionally it forms the basis of pas2js, which fully supports all FPC constructs.


That said, I realize the (correct) use of fcl-passrc may be a bit hermetic...

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

Re: [fpc-pascal] All methods vitrual ?

[Michael Van Canneyt via fpc-pascal]

On Wed, 11 Oct 2023, Adriaan van Os via fpc-pascal wrote:


Sven Barth via fpc-pascal wrote:

Ah, yes, only classes and interfaces can be used for published fields. For 
properties anything is allowed. 


However, what makes the whole thing unuseable is that with {$M-} the compiler 
doesn't accept "published". So, without using macros, the same source code 
can not be compiled with both {$M+} and {$M-}. That is really clumsy. With 
{$M-} "published" (or some other visibility specifier) should be equal to 
"public".


Of course not.

$M controls the inclusion of RTTI, i.e. it allows or disallows the use of the 
published section.
No more, no less.

It has no impact on the other visibilities whatsoever. 
And that will not change, if only for Delphi compatibility.


If this is not acceptable, then you will need to wait for the extended RTTI or use fcl-passrc 
to solve your need.


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

Re: [fpc-pascal] What is webasssembly?

[Michael Van Canneyt via fpc-pascal]

On Tue, 10 Oct 2023, Steve Litt via fpc-pascal wrote:


What is webasssembly?


A bytecode format (similar to what is used in Java and C# runtimes) which is
an open standard and which runs in all major browsers or in a host
application.

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

Re: [fpc-pascal] All methods vitrual ?

[Michael Van Canneyt via fpc-pascal]

On Mon, 9 Oct 2023, Adriaan van Os via fpc-pascal wrote:

Is there a trick to make (in mode macpas) all class methods implicitely 
virtual ? I mean, without adding the virtual keyword to all of them ? The 
reason is that I want to create a tree view of the class hierarchy with all 
the method names (not just those that are normally in the VMT because they 
are overridden).


Any other ideas ?


If you need this tree at run-time:

- The "extended RTTI" branch of fpc allows you to list all methods,
  regardless of their visibility

- In the released compiler, if you remove all visibility specifiers, you can
  get a list by specifying {$M+} on your base object and then list all
  published methods using the RTTI.

If you simply need this tree:

- You can simply use fcl-passrc to analyse your source tree and create the 
complete
  list. No changes to code needed. I have several programs that do this.

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

Re: [fpc-pascal] fpc webassembly and node

[Michael Van Canneyt via fpc-pascal]

On Mon, 9 Oct 2023, Michael Van Canneyt via fpc-pascal wrote:



Hello,

Either list is fine.

This should compile and work.

I'm using webassembly and classes quite a lot, even with threading, so I see 
no reason why this simple code should not run.


How did you start the webassembly ? How much memory did you provide to the 
webassembly ?

Did you use pas2js to start it ? What browser did you test ?


Disregard the last question, it's node of course, so the V8 engine.

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

Re: [fpc-pascal] fpc webassembly and node

[Michael Van Canneyt via fpc-pascal]

Hello,

Either list is fine.

This should compile and work.

I'm using webassembly and classes quite a lot, even with threading, 
so I see no reason why this simple code should not run.


How did you start the webassembly ? 
How much memory did you provide to the webassembly ?

Did you use pas2js to start it ? What browser did you test ?

Michael.

On Sun, 8 Oct 2023, k1 via fpc-pascal wrote:



Hi guys,

i have a question concerning webassembly,
please let me know if this is the wrong list.

is it possible to use classes and compile to webassemly,
the following code is working well but wen i uncomment the constructor line
the code can be compiled but will not run anymore

RuntimeError: memory access out of bounds

is the result

i compile with the following command

ppcrosswasm32 -Twasi -oadd.wasm add.pas



library add;

{$mode objfpc}

type
 TConnection = class
 private
   n : Integer;
 public
   constructor Create;
 end;

constructor TConnection.Create;
begin
 n := 4711;
end;

function add( a1, a2 : Integer ) : Integer;
var
 connection : TConnection;
begin
 //connection := TConnection.Create;
 Result := 4711;
end;

exports
 add name 'add';
end.
___
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] Issue #39746 fpwidestring case conversion string too long

[Michael Van Canneyt via fpc-pascal]

On Mon, 25 Sep 2023, Tony Whyman via fpc-pascal wrote:

This issue seems to be still open after one year. There was a proposed fix: 
https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/158. However 
the discussion seems to tail off without an obvious resolution.


This is a clear bug in fpwidestring and needs to be fixed. What is the 
status?


Unresolved, someone needs to take a deep dive into this; 
The comments by Florian and Jonas are still unresolved:


- As far as I can see, no testcases are provided.
  (a requirement for the compiler)
- I don't see a clear resolution to Jonas' remark that the len is already taking
  into account the null terminator.

- Unfortunately the branch can no longer be merged as-is, since trunk has 
evolved too much :/

The patch also mixes various issues: some things in the compiler, some
things in the RTL. These should be separated out. I think that is easily
doable. I'll look at applying the RTL patches separately next week if no-one
did it before. It would help if there was a testcase for the compiler.

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

Re: [fpc-pascal] Closure hangs compiler

[Michael Van Canneyt via fpc-pascal]

On Sun, 24 Sep 2023, Hairy Pixels via fpc-pascal wrote:


This program hangs during compiling. Does this happen to you too?


I can confirm. Please create a bugreport.

Michael.



===

 Free Pascal Compiler version 3.3.1 [2023/03/03] for aarch64

{$mode objfpc}
{$modeswitch anonymousfunctions}
{$modeswitch functionreferences}

program test;

type
 TProc = reference to procedure;

function TestNested: TProc;

 procedure NestedProc2;
 begin
 end;

begin
 result := procedure
 var
   p: TProc;
 begin
   p := @NestedProc2;
 end;
end;

var
 p: TProc;
begin
 p := TestNested;
 p();
end.

Regards,
Ryan Joseph

___
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] SeekEof issue & 2020 blog post by A Stolyarov

[Michael Van Canneyt via fpc-pascal]

On Mon, 11 Sep 2023, Tomas Hajny via fpc-pascal wrote:


On 2023-09-11 11:08, Alexey Torgashin via fpc-pascal wrote:

Translation of blog post http://www.stolyarov.info/node/290 from Ru to En.
Sep 6 2020.
Author: Andrey Stolyarov, author of Ru books about programming.

.
.

Q (reader): Judging by the state of the ticket, has success been achieved?
A (Stolyarov): To be honest, it's not clear - you'll have to pull out
a snapshot and see. I really hope that this Tomas Hajny didn't
understand what happens when you open a text stream and ended up not
being able to do what he wanted to do -- cut off buffering for
anything that isn't a file. If he succeeded, then "the victory has

.
.

"This Tomas Hajny" still believes that a user having a different opinion on a 
certain thing doesn't automatically prove that his different view is wrong. 
"This Tomas Hajny" tried to provide reasoning on his position - among others, 
"this Tomas Hajny" still values consistency among supported platforms and 
consideration of various use cases more than opinions of people only 
interested in their particular use case on one particular platform. "This 
Tomas Hajny" also sees that FPC RTL already provides variety of possibilities 
for achieving what the user having a different opinion intends to achieve. 
"This Tomas Hajny" understands that different people may differ in priorities 
of various arguments which is why he consulted the topic among the FPC core 
team. On top of that, "this Tomas Hajny" has by no means exclusive access to 
changing FPC RTL, i.e. any other member of the FPC core team may have decided 
to change the implementation according to preferences of the user having a 
different opinion.


I fail to see what's still the problem ?

Functions GetTextAutoFlush and SetTextAutoFlush were added to control the 
behaviour.

So, original poster can set behaviour as he wants it, and the issue is closed.

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

Re: [fpc-pascal] Visual studio code

[Michael Van Canneyt via fpc-pascal]

On Fri, 11 Aug 2023, Darius Blaszyk via fpc-pascal wrote:


Quick question for you all.  Has anyone here worked with Visual Studio
Code for Free Pascal?  I've got the Free Pascal Toolkit plugin up and
running, but I'm hitting a bit of a roadblock with setting up GDB
debugging.  After installing  GDB Debugger - Beyond I still cant debug my
app upon setting a breakpoint.  Anyone familiar with this and can help me
out?


I tried it (to check the LSP support, which I found lacking) and it worked, 
I could inspect variables etc. but I seem to remember that I had to do some 
fixes before it worked.


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

Re: [fpc-pascal] Pointer question

[Michael Van Canneyt via fpc-pascal]

On Thu, 10 Aug 2023, Hairy Pixels via fpc-pascal wrote:





On Aug 10, 2023, at 4:23 PM, Hairy Pixels  wrote:

// 4) subscript (inc and dereference in one step)
v := i[1];


#4 was not  in the list for example so I wonder what others exist.


I found another one in the typinfo.pp unit. What does,

1) taking the address of a type (@TAlignCheck) yield and
2) what does dereferencing nil yield?

Both I've never seen before until now.

type
TAlignCheck = record
  b : byte;
  w : word;
end;
var
p: pointer;
begin
p := @TAlignCheck(nil^).w;
end;


This is a very dirty trick to get the offset of a field in a record.

Note that you're not dereferencing a type but a variable of type TAlignCheck 
located
at memory address zero. The address of w (this is what the expression is
doing) is then the offset of w in the record.

It's probably more clear if you write it as
 p := @(TAlignCheck(nil^).w);

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

Re: [fpc-pascal] Pointer question

[Michael Van Canneyt via fpc-pascal]

On Thu, 10 Aug 2023, Hairy Pixels via fpc-pascal wrote:





On Aug 10, 2023, at 10:49 AM, Sven Barth via fpc-pascal 
 wrote:

Then you simply aren't using them often enough. E.g. the RTTI internal code is 
full of them and additional typecasts would simply muddle up otherwise 
relatively clear code.



Here's a question, what is the full list of possible pointer operators? I 
didn't even know about pointer - pointer until now and there may be more.


https://www.freepascal.org/docs-html/current/ref/refse15.html#x42-620003.4

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

Re: [fpc-pascal] TStringHelper not found

[Michael Van Canneyt via fpc-pascal]

On Mon, 24 Jul 2023, Rafael Picanço via fpc-pascal wrote:


I just updated to trunk (Lazarus 3.99 4ed7ff9b1c, FPC
3.3.1-13378-gceddc2aec3) and I am getting an "Identifier not found" error
for TStringHelper:


I introduced an alias.

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

Re: [fpc-pascal] Documentation or compiler bug?

[Michael Van Canneyt via fpc-pascal]

On Sat, 8 Jul 2023, Michael Van Canneyt via fpc-pascal wrote:




On Sat, 8 Jul 2023, Hairy Pixels via fpc-pascal wrote:

In fact I filed a bug today which was related. Notice how I didn't use 
cdecl in the program but another user tried to compile and had problems 
with cdecl also.


https://gitlab.com/freepascal.org/fpc/source/-/issues/40342 
<https://gitlab.com/freepascal.org/fpc/source/-/issues/40342#note_1462402401>


Small addition:

He did not have problems with cdecl, but with the fact that the c library
was not linked. But this was intended: he wrote it explicitly 'as intended'. 
So all is well, except the internal error (AFAIK you cannot pass a record to printf())


Just so you have a correct picture of what is happening.

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

Re: [fpc-pascal] Documentation or compiler bug?

[Michael Van Canneyt via fpc-pascal]

On Sat, 8 Jul 2023, Hairy Pixels via fpc-pascal wrote:


In fact I filed a bug today which was related. Notice how I didn't use cdecl in 
the program but another user tried to compile and had problems with cdecl also.

https://gitlab.com/freepascal.org/fpc/source/-/issues/40342 


Basically this program:

{$mode objfpc}

program test;

function printf(format: PChar): Integer; external; cdecl; varargs;


You must put the cdecl (which is the calling convention) before the external:

{$linklib c}

function printf(format: PChar): Integer; cdecl; external; varargs;

begin
  printf('%d is the answer'#10,42)
end.

Will work and will print

42 is the answer

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

Re: [fpc-pascal] Documentation or compiler bug?

[Michael Van Canneyt via fpc-pascal]

On Sat, 8 Jul 2023, Hairy Pixels via fpc-pascal wrote:


I get the error "Procedure directive "CDECL" cannot be used with "EXTERNAL"" when I use 
"cdecl" with external modifiers yet the docs at https://www.freepascal.org/docs-html/ref/refsu73.html say":

When compiling this, and linking to the C-library, the strlen function can be 
called throughout the program. The external directive tells the compiler that 
the function resides in an external object file or library with the “strlen” 
name (see 14.7).

Suggesting they can be used together, so which is right? Compiler is: Free 
Pascal Compiler version 3.3.1 [2023/03/03] for aarch64



They are used together. The FPC sources are full of them, most import
libraries work like that:

function PQconnectStart(conninfo:Pchar):PPGconn;cdecl;external External_library 
name 'PQconnectStart';

It would be helpful if you would give the exact statement you are writing.

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

Re: [fpc-pascal] reverse for in loop

[Michael Van Canneyt via fpc-pascal]

On Fri, 7 Jul 2023, Zamrony P. Juhara via fpc-pascal wrote:


I like simplicity for .. in .. loop. but is there equivalent for reverse loop?


If you code your enumerator so then yes.

For standard types there is none.

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

Re: [fpc-pascal] Pchar from constant string

[Michael Van Canneyt via fpc-pascal]

On Fri, 30 Jun 2023, Michael Van Canneyt via fpc-pascal wrote:




On Fri, 30 Jun 2023, Hairy Pixels via fpc-pascal wrote:





On Jun 30, 2023, at 9:03 AM, Hairy Pixels  wrote:

That's why that worked. Hmm with short strings the null terminator could 
be truncated when copying right? Something to look out for.


this is what I meant about truncation. S is no longer null terminated and 
now the pchar will fail when passed to C libraries right?


var
 s: String;
 p: Pchar;
begin
s := 'hello';
p := @s;


S will still be null-terminated for ansistrings and shortstrings.

change to

 s:=s+s;
 p:=@s[1]; // and not @s
 writeln(p[Length(s)+1]=#0);


this should have been p[Length(s)] obviously.

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

Re: [fpc-pascal] Pchar from constant string

[Michael Van Canneyt via fpc-pascal]

On Fri, 30 Jun 2023, Hairy Pixels via fpc-pascal wrote:





On Jun 30, 2023, at 9:03 AM, Hairy Pixels  wrote:

That's why that worked. Hmm with short strings the null terminator could be 
truncated when copying right? Something to look out for.


this is what I meant about truncation. S is no longer null terminated and now 
the pchar will fail when passed to C libraries right?

var
 s: String;
 p: Pchar;
begin
s := 'hello';
p := @s;


S will still be null-terminated for ansistrings and shortstrings.

change to

  s:=s+s;
  p:=@s[1]; // and not @s
  writeln(p[Length(s)+1]=#0);

and it will print TRUE.

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

Re: [fpc-pascal] Pchar from constant string

[Michael Van Canneyt via fpc-pascal]

On Thu, 29 Jun 2023, Mattias Gaertner via fpc-pascal wrote:


On Thu, 29 Jun 2023 21:18:44 +0700
Hairy Pixels via fpc-pascal  wrote:


What is really happening in this snippet? I think it must be
implicitly taking the address of the constant string but is it also
adding the null terminator automatically? The string prints with
writeln so it must be null terminated right?

var
  p: Pchar;
begin
  p := '123';
  writeln(p);


AFAIK the trailing #0 is already stored in the binary.


Yes, it is:

---
_$PROGRAM$_Ld1:
# [4] p := '123';
.ascii  "123\000"
.Le11:
---

Just as it is for a shortstring and ansistring:
---
# [6] s:='456';
.ascii  "\003456\000"
.Le12:
.size   _$PROGRAM$_Ld2, .Le12 - _$PROGRAM$_Ld2
---

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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Michael Van Canneyt via fpc-pascal]

On Mon, 26 Jun 2023, Steve Litt via fpc-pascal wrote:


Steve Litt via fpc-pascal said on Mon, 26 Jun 2023 22:26:17 -0400


Where does one get ComObj?  On my box this errored out with:


I went off half cocked. I'm using Linux. Is ComObj even available on
Linux? Would you expect Voice := CreateOLEObject('SAPI.SpVoice') and
Voice.Speak('I am speaking.', 0) to work on Linux? I know soundon and
soundoff don't work with Linux.


comobj and everything COM related is windows specific. 
So this will never work on linux.


The technology that comes closest on Linux is DBUS.

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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Michael Van Canneyt via fpc-pascal]

On Mon, 26 Jun 2023, Marco van de Voort via fpc-pascal wrote:



On 26-6-2023 20:26, Michael Van Canneyt via fpc-pascal wrote:


I suspect COM is not properly initialized, and that Lazarus does this for 
you.

(it needs com for some components on windows)

So, try adding unit windows to the uses clause and add

CoInitialize(nil);

as the first statement of your program.



(afaik 3.2.2's comobj does this automatically, in older version YMMV).


Well, I checked prior to sending my answer. If it does this, it's well hidden. 
There seems to be some hook for it, though.


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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Michael Van Canneyt via fpc-pascal]

On Mon, 26 Jun 2023, Michael Van Canneyt via fpc-pascal wrote:




On Mon, 26 Jun 2023, James Richters wrote:



I tried to make your example into a FPC program without Lazarus:
{$mode objfpc}{$H+}
uses
 comobj;
var
 SavedCW: Word;
 v: OleVariant;
begin
  v:=CreateOleObject('SAPI.SpVoice');
  v.Speak('Hello');
End.
I get:
Running "i:\programming\gcode\mill\sapi.exe "
An unhandled exception occurred at $00414370:
EOleError: Variant does not reference an automation object
 $00414370
 $0041948D
 $0040B941
 $004018DF  main,  line 9 of i:/programming/gcode/mill/sapi.pas


I suspect COM is not properly initialized, and that Lazarus does this for 
you.

(it needs com for some components on windows)

So, try adding unit windows to the uses clause and add


That should be unit activex instead of unit windows.

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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Michael Van Canneyt via fpc-pascal]

On Mon, 26 Jun 2023, James Richters wrote:



I tried to make your example into a FPC program without Lazarus:
{$mode objfpc}{$H+}
uses
 comobj;
var
 SavedCW: Word;
 v: OleVariant;
begin
  v:=CreateOleObject('SAPI.SpVoice');
  v.Speak('Hello');
End.
I get:
Running "i:\programming\gcode\mill\sapi.exe "
An unhandled exception occurred at $00414370:
EOleError: Variant does not reference an automation object
 $00414370
 $0041948D
 $0040B941
 $004018DF  main,  line 9 of i:/programming/gcode/mill/sapi.pas


I suspect COM is not properly initialized, and that Lazarus does this for you.
(it needs com for some components on windows)

So, try adding unit windows to the uses clause and add

CoInitialize(nil);

as the first statement of your program.


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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Michael Van Canneyt via fpc-pascal]

On Mon, 26 Jun 2023, Travis Siegel via fpc-pascal wrote:

Thank you, this one works for me with a command line compile.  I 
compared the two programs, and the line that asks for the voices is the 
culprit.


I'll have to do some digging to see why that line breaks the runtime 
execution.


Try changing the selected voice to 0 instead of 1.

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

Re: [fpc-pascal] Microsoft SAPI on Freepascal

[Michael Van Canneyt via fpc-pascal]

On Mon, 26 Jun 2023, Marco van de Voort via fpc-pascal wrote:



On 26-6-2023 15:54, Michael Van Canneyt via fpc-pascal wrote:


  v.Voice:=v.GetVoices().Item(1);

I have to change that to (0) to get it to work. Might depend on 
configuration?


Probably the number of voices installed in the system determines this.

I simply took OP's code, I assume he has 2 voices installed as I do...

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