Re: [fpc-devel] endless loop in compiler

[Michael Van Canneyt via fpc-devel]

On Mon, 28 Oct 2024, Martin Frb via fpc-devel wrote:


I don't have much info, but maybe someone can look here.

It's about fpc 3.3.1, and my best guess is that the compiler enters an 
endless loop.
There is a bit of a stacktrace,but not much possible unit loading 
related.


https://forum.lazarus.freepascal.org/index.php/topic,69067.msg535575.html#msg535575


Without example project there is not much we can do.

I can have a look at it, but only with some example code.
If need be the code can be sent to me privately.

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

Re: [fpc-devel] threadvar vs docs

[Michael Van Canneyt via fpc-devel]

On Fri, 18 Oct 2024, Nikolay Nikolov via fpc-devel wrote:



On 10/18/24 12:10 AM, Martin Frb via fpc-devel wrote:

https://wiki.freepascal.org/Threadvar
If threads are used then a copy is made for each thread (including 
the main thread). Note that the copy is made with the original value 
of the variable, not with the value of the variable at the time the 
thread is started. 


But what is that original value? Since
threadvar
  foo: integer = 1;

gives
Error: Cannot initialize variables declared as threadvar


I think the documentation is wrong. Threadvars are always initialized as 
zero.


Then please explain what do copy_all_unit_threadvars and copy_unit_threadvars 
do ?

This is called from InitThreadVars when a new thread is started.

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

Re: [fpc-devel] unicodertl fails to compile on darwin

[Michael Van Canneyt via fpc-devel]

On Sun, 8 Sep 2024, Mattias Gaertner via fpc-devel wrote:


Hi,

Following the instructions on the wiki compiling the subtarget unicodertl 
fails.


Wiki:

https://wiki.freepascal.org/FPC_Unicode_RTL#Compiling_the_namespaced_unicode_RTL

Compiling rtl works, but compiling packages fails:

make -C rtl clean all SUB_TARGET=unicodertl FPC_DOTTEDUNITS=1 
PP=/path/to/fpc/3.3.1/ppcx64
make -C packages clean all SUB_TARGET=unicodertl FPC_DOTTEDUNITS=1 
PP=/path/to/fpc/3.3.1/ppcx64


with:

system.regularexpressionscore.pp(40,96) Fatal: Can't find unit Api.PCRE2_16 
used by System.RegularExpressionsCore


On darwin, only Api.Api.PCRE2_8 is available.

That is why I had to introduce an extra define specially for this case :/

I'm surprised, I tested compilation for darwin.


Fatal: Compilation aborted

Same with passing

OPT=-dUSEWIDESTRING

Btw, is this -dUseWideString needed or not?

This is on macos darwin.


On darwin, it must absolutely not be specified. On linux/windows, it must be.

Suggestions for improvement are welcome.

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

Re: [fpc-devel] Published record

[Michael Van Canneyt via fpc-devel]

On Sat, 17 Aug 2024, Michalis Kamburelis wrote:


Thanks Michael!

OK, that's partially good news :)

I understand that streaming records by default to LFM would lead to
too many questions (and I'm unsure whether Delphi does it too, for
records and DFM).


It does not. 
Streaming has not changed in an essential way since  D7, I think.


With the coming of extended rtti, they could have changed it, but they
didn't, I believe since it would be difficult to maintain backwards
compatibility.


If this means they are not allowed in the
"published" section, *but* the RTTI is capable of telling me what
records are in the "public" section, and read / write them (using
proper getters / setters), this is something we can work with.


You should be fine then, as this is supported.



I mean, I can 1. add my own serialization / deserialization of them,
and 2. make them exposed in the object inspector in CGE editor.

(
Details:
AD 1 - For serialization / deserialization, in Castle Game Engine, we
use CastleComponentSerialize on top of FpJsonRtti. One of the reasons
I like JSON and FpJsonRtti over LFM is that this gives us more control
-- I know I can add code to CastleComponentSerialize to deal with
records, if only RTTI tells me about them.


I prefer JSON too.


AD 2 - For object inspector, we use Lazarus "ObjectInspector" unit.
I'm less sure about it, but hopefully it is possible to add there
"fake" subcomponents too.
)


Actually, it is!

see the work the FP/Lazarus foundation sponsored in

lazarus/components/jitclasses/



Can you expand your statement "It is since some time, but you must
explicitly enable it."? What compiler switch enables it? What API
should I use to access it -- Rtti unit in FPC has all we need? (I
guess TypeInfo unit API does not expose it, or it does?)

To make my question more concrete, imagine a code like this:

"""
type
 TVector3 = record X, Y, Z: Single end;
 TCastleTransform = class
 public
   property Translation: TVector3 read ... write ...;
   property Scale: TVector3 read ... write ...;
 end;
"""

I'm looking for a way to tell, at runtime, using RTTI, having any
instance of TObject (maybe of TCastleTransform):

- what public properties of type TVector3 are there (like
"Translation" and "Scale"),
- what public fields does TVector3 have (like X, Y, Z) (this is
nice-to-have, we could work without this info but then limiting our
record serialization / deserialization to only specific record types),
- read / write these record properties using the proper getter /
setter (whether it's direct field access or a method).


This is all perfectly possible.

Simply add

  {$RTTI EXPLICIT
 PROPERTIES([vcPublic])
 FIELDS([vcPublic])
 METHODS([vcPublic])}

in your units and you're all set.

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

Re: [fpc-devel] Published record

[Michael Van Canneyt via fpc-devel]

On Sat, 17 Aug 2024, Kostas Michalopoulos via fpc-devel wrote:


On 8/16/24 8:40 PM, Michalis Kamburelis via fpc-devel wrote:

If we could instead just put TVector3 in the published section, and
make it exposed in the object inspector (maybe adding some additional
code to use RTTI, but that is made *once*, not every time we need to
expose TVector3) this would be great :)


Seconding this, for pretty much the same use case: my 3D game engine also 
uses TVector, etc records (and objects! - stuff being allocated in stack or 
"inline" other objects/classes is incredibly important) and needs to expose 
them via RTTI/published and i have to use various kludgy hacks to work around 
a language limitation that IMO was already questionable back in the 90s when 
Delphi 2 was released (i might kinda accept it for Delphi 1 having to work in 
16bit mode :-P).


Instead of having a proxy object, i "flatten" the fields using getters and 
setters so, e.g., a "property Position: TVector read FPosition write 
SetPosition" in the public section also has "property PositionX: Single read 
GetPositionX write SetPositionX" and similar for PositionY and PositionZ. 
Obviously with something like "property Transformation: TTransformation read 
FTransformation write SetTransformation" which has Position, Rotation and 
Scale properties (as TVectors) that get flattened to nine published 
properties so they can be accessed via RTTI (and thus have automatic 
serialization, deserialization, property editing UI, clipboard copy/paste, 
undo/redo support via property diffs, etc without having to do all that 
manually via code) it becomes kinda unwieldy fast.


Sadly i also do have to use proxy objects in some cases, e.g. i have a 
generic object "TDynArray" for dynamic arrays which is wrapped via a 
"TSerializableCollection" class so that the serialization/deserialization 
code can automatically write/construct/read published collections of objects.


It'd be very useful if the Run-Time Type Information could describe all the 
Type Information the compiler already knows about :-P


See my answer to Michalis: It is possible, but no streaming, so no published.

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

Re: [fpc-devel] Published record

[Michael Van Canneyt via fpc-devel]

On Fri, 16 Aug 2024, Michalis Kamburelis via fpc-devel wrote:


You cannot publish records, and this is not planned.

This is because things like

MyClass.MyRecord.MyField:=12;

do not work as one would naively expect. It does work if you use a TPersistent
instead of a record (the very reason the TPersistent class was invented)


Do you mean the trap when "MyField" is actually a property (with
possible setter) and "MyClass.MyRecord.MyField:=123" effectively (may)
modify a temporary value? I feel this is something a bit independent
to being able to publish the records.


Partly, yes.

You need "published" when you want to stream them (in a .lfm file).

But for streaming the above behaviour is prohibitive.

When using a TPersistent, it is a class which behaves 'normally' 
and you get the streaming "for free": streaming a TPersistent is not

different from a TComponent.

To be able to stream published records one would need to create an empty 
record, fill it with data and then assign the record (possibly recursively)

because of the above behaviour.

Doing this correctly would simply lead too far, since basically you need 
to duplicate the whole mechanism that exists for classes.


A more funddamental reason is of course that records can have variant 
parts and streaming that in a correct way is impossible: 
you do not know what actual data is present. 
Which of the variants should then be streamed ?



Last time I checked, the RTTI information was not generated for
records in only the "public" section, and (as per above) the records
could not be placed in the "published" section. Is now one of the
above possible? :)


It is since some time, but you must explicitly enable it. 
The basic TObject does not have extended RTTI enabled as it is in Delphi, 
except when you compile the unicode rtl.


Enabling it in TObject doubles the binary size of any project I tested it
with, so I don't plan to enable it in the default RTL.

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

Re: [fpc-devel] Published record

[Michael Van Canneyt via fpc-devel]

On Thu, 15 Aug 2024, Mattias Gaertner via fpc-devel wrote:


Hi,

What is the state of published record in fpc trunk?


You cannot publish records, and this is not planned.

This is because things like

MyClass.MyRecord.MyField:=12;

do not work as one would naively expect. It does work if you use a TPersistent
instead of a record (the very reason the TPersistent class was invented)

However, you can use extended RTTI to access this typeinfo and manipulate the record. 
That works.


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

Re: [fpc-devel] [Fpc-mirrors] FPC 3.2.2, miért nincs tovább fejlesztve ...

[Michael Van Canneyt via fpc-devel]

Hungarian:
--

Legyen szíves angolul írni.
A levelezőlista nyelve angol.
Valószínűleg csak néhány ember van itt, aki ért magyarul.
Valószínűleg a többiek is szeretnék érteni, amit írsz.

(a "Google fordító" segítségével fordítva)

Köszönöm.


English:


Please have the courtesy of writing in English. 
The mailing list language is English.

There are probably only a few people here who understand Hungarian.
The others would probably also like to understand what you write.

(translated using "Google translate")

Thank you.



On Tue, 13 Aug 2024, atiatiati...@gmail.hu wrote:




A https://www.freepascal.org/ oldalon, 2021-es fejlesztési
befejezés van, ráadásul már meghalt 2024 a szerző.

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

Re: [fpc-devel] Maybe missing assigned check? TBasicActionLink.Update

[Michael Van Canneyt via fpc-devel]

On Sat, 10 Aug 2024, Martin Frb via fpc-devel wrote:


Other functions of  TBasicActionLink have checks like
   if FAction <> nil then

But "Update" does not. Is that intended?
Or shall I bug report it?

function TBasicActionLink.Update: Boolean;
begin
  Result := FAction.Update;
end;


I added a check. Thanks for pointing it out!

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

Re: [fpc-devel] Unnoticed bug report

[Michael Van Canneyt via fpc-devel]

On Thu, 27 Jun 2024, Bart via fpc-devel wrote:


On Thu, Jun 27, 2024 at 4:51 PM Michael Van Canneyt via fpc-devel
 wrote:



As a consequence, things may go unnoticed, this is not a reflection
on the seriousness of an issue or quality of the patch.

Feel free to contact us here or by other means if you feel that a bugreport
is ignored.


I know, which is exactly why I suggest Werner to contact the devels on this ML.
So, what I believe Werner wants to ask is that he would like someone
to review his patch in said issue.


It would be not very helpful on my part to answer here and do nothing else :)

If you look at the issue, you will see I already merged it before replying to 
his mail here.

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

Re: [fpc-devel] Unnoticed bug report

[Michael Van Canneyt via fpc-devel]

On Thu, 27 Jun 2024, Werner Pamler via fpc-devel wrote:


Hello

Two months ago I submitted the bug report 
https://gitlab.com/freepascal.org/fpc/source/-/issues/40748 about an issue in 
TDBF. Although I was able to add a patch along with test programs this report 
has remained unnoticed until now. A bit de-motivating, I am afraid...


We're not a company with a policy on a guaranteed response time.
We all have day-time jobs.

Gitlab notifies me of new bugreports. If I don't somehow interact with them,
then I will not be notified of follow-up messages, so your follow-up
messages (including patches) are not seen by me (or, so I suspect, 
anyone else in the team).


As a consequence, things may go unnoticed, this is not a reflection
on the seriousness of an issue or quality of the patch.

Feel free to contact us here or by other means if you feel that a bugreport
is ignored.

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

Re: [fpc-devel] What about splitting compiler and packages releases?

[Michael Van Canneyt via fpc-devel]

On Sat, 25 May 2024, Peter via fpc-devel wrote:


Hi all,

I was wondering: would it make sense to split the release schedule of
the compiler and the included packages?

Compiler releases are not frequent (latest is May 2021). In the
meantime, useful functionality, bug fixes and improvements have been
added to the packages. To use these added and updated packages, AFAIK,
there are two possibilities:

1. Use the trunk compiler (eg using fpcupdeluxe). Not recommended for
production environments.
2. Use a stable compiler, manually download updated packages to a
different location and make sure the compiler uses the updated
packages instead of the ones included with the compiler distribution
(bit of a hassle).

I think it would be very useful to have more frequent (stable) package
releases, while the compiler itself can stick to the current frequency
of (thoroughly tested) releases.


We are in agreement.

But it is not so easy as it may seem: 
Some parts (e.g. rtti, namespaces etc.) require compiler support, a careful

selection of what can be updated is needed.



If I miss a smart way to use updated packages with a stable compiler,
please let me know. Thanks!


There is none better than what you described above.

We're currently attempting to get 3.2.4 out of the door, after that I plan a
new debate in the FPC group about a more regular release schedule.

Several companies that use FPC have asked for a more regular release
schedule, and I even received offers of funding to ensure a more regular 
release schedule. So you're not alone with your request.


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

Re: [fpc-devel] download or compile documentation

[Michael Van Canneyt via fpc-devel]

On Thu, 9 May 2024, Marģers . via fpc-devel wrote:


Is there a way to download human readable format documenation?


Please explain ?

The documentation is available as PDF. That's human readable ?


Looking documentation of 3.2.2 and it is bad. Errors and errors. Wanted to 
crosschech, maybe it is all fixed meanwhile.


You can check the actual state of documentation on the daily build:
https://www.freepascal.org/daily/



Failing to compilde documentation by myself. Where to download or how to 
compile?


The documentation is in gitlab, just as the rest of FPC:

https://gitlab.com/freepascal.org/fpc/documentation

If you find errors in the documentation, the documentation bugtracker is also 
where you should report issues.


Simple "make" does not work. It is allways "Target not supported, run fpcmake". 
And that is not valid solution.


If you tried make to build the documentation, then I assume you downloaded the 
documentation
so you should be aware of the gitlab location. So why do you ask where to 
download it ?

Anyway: I suspect you tried this on windows ?

Building the documentation on windows is not supported, you need linux to build 
the documentation.

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

Re: [fpc-devel] fpc 3.3.1 fails in fpjwarsa

[Michael Van Canneyt via fpc-devel]

I just did the same for 55 platforms (cross-compile), on ubuntu. 
All work without errors ?


Michael.

On Wed, 20 Mar 2024, Martin Frb via fpc-devel wrote:


Older Ubuntu, trying to update (starting compiler is 3.2.2)


make clean
make all  OPT=" -O-1 -gw3 "
make install INSTALL_PREFIX=/home/m/fpc/


Compiling ./fcl-web/src/fcm/fpfcmstrings.pp
Writing Resource String Table file: fpfcmstrings.rsj
Compiling ./fcl-web/src/jwt/fpjwarsa.pp
fpjwarsa.pp(21,35) Error: Identifier not found "TJWTSigner"
fpjwarsa.pp(21,35) Error: Class type expected, but got ""
fpjwarsa.pp(25,64) Error: Identifier not found "TJWTKey"
fpjwarsa.pp(26,62) Error: Identifier not found "TJWTKey"
fpjwarsa.pp(23,20) Error: There is no method in an ancestor class to be 
overridden: "class AlgorithmName:System.AnsiString;"
fpjwarsa.pp(25,14) Error: There is no method in an ancestor class to be 
overridden: "CreateSignature(TJWT;):System.AnsiString;"
fpjwarsa.pp(26,14) Error: There is no method in an ancestor class to be 
overridden: "Verify(const AnsiString;):System.Boolean;"

fpjwarsa.pp(56,38) Error: Identifier not found "TJWTSigner"
fpjwarsa.pp(56,38) Error: Class type expected, but got ""
fpjwarsa.pp(60,64) Error: Identifier not found "TJWTKey"
fpjwarsa.pp(61,62) Error: Identifier not found "TJWTKey"
fpjwarsa.pp(58,20) Error: There is no method in an ancestor class to be 
overridden: "class AlgorithmName:System.AnsiString;"
fpjwarsa.pp(60,14) Error: There is no method in an ancestor class to be 
overridden: "CreateSignature(TJWT;):System.AnsiString;"
fpjwarsa.pp(61,14) Error: There is no method in an ancestor class to be 
overridden: "Verify(const AnsiString;):System.Boolean;"

fpjwarsa.pp(89,1) Fatal: There were 14 errors compiling module, stopping
Fatal: Compilation aborted

The installer encountered the following error:
Compilation of "BuildUnit_fcl_web.pp" failed
  $00542579
  $0054C7E2
  $0054B87E
  $0054CADB
  $0054FEAA
  $00540F3B
  $005415C0
  $0047868F
  $004A5AF9

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

[Michael Van Canneyt via fpc-devel]

On Tue, 19 Mar 2024, Martin Frb via fpc-devel wrote:


On 19/03/2024 15:41, Mattias Gaertner via fpc-devel wrote:



On 19.03.24 14:58, Maxim Ganetsky via fpc-devel wrote:

[...]
#7 944.7 fpmake.pp(228,5) Error: Identifier not found "T"


Ah, you are using fpc 3.3.1 to compile it.

Fixed.

But I get strange linker errors compiling webidl2pas:

(9015) Linking bin/x86_64-linux/webidl2pas
/usr/bin/ld.bfd: 
/path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x50): 
undefined reference to `DEBUGSTART_$CUSTAPP'
/usr/bin/ld.bfd: 
/path/compiler/utils/pas2js/units/x86_64-linux/webidl2pas.o:(.fpc.n_links+0x58): 
undefined reference to `DEBUGEND_$CUSTAPP'


It compiles with the ppu files of fpc 3.3.1 and 3.2.2 tough, but not with 
the sources ...


I don't know if it applies.

But I have in some cases seen similar linking issues, if parts of the code 
were compiled with DWARF-2 and other parts with DWARF-3


This happens regularly to me since years, usually indeed different debug
formats (or sometimes no debug info at all). 
Recompiling everything fixes the issue.


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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests - again

[Michael Van Canneyt via fpc-devel]

On Mon, 18 Mar 2024, Maxim Ganetsky via fpc-devel wrote:


Hello.

After recent update of FPC 3.3.1 (and Pas2JS) in Lazarus CI several Codetools 
tests related to Pas2JS started failing again:


TTestPas2js.TestPas2js_ReadSettings: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration_AWait: pas2js system unit not found

They worked fine with FPC 3.3.1 from the end of December.

Contents of Pas2JS configuration files follow:


#7 1429.0 Contents of /usr/local/bin/pas2js.cfg:
|
#7 1429.0 #
||
#7 1429.0 # Minimal config file for pas2js compiler
||
#7 1429.0 #
||
#7 1429.0 # -d is the same as #DEFINE
||
#7 1429.0 # -u is the same as #UNDEF
||
#7 1429.0 #
||
#7 1429.0 # Write always a nice logo ;)
||
#7 1429.0 -l
||
#7 1429.0
||
#7 1429.0 # Display Warnings, Notes and Hints
||
#7 1429.0 -vwnh
||
#7 1429.0 # If you don't want so much verbosity use
||
#7 1429.0 #-vw
||
#7 1429.0
||
#7 1429.0 # Allow C-operators
||
#7 1429.0 -Sc
||
#7 1429.0
||
#7 1429.0 #IFDEF FPC_SUBTARGET_NAMESPACED
||
#7 1429.0 -Fu$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/namespaced
||
#7 1429.0 -Fi$CfgDir/../lib/fpc/3.3.1/pas2js/*/*/src


This seems wrong to me, but Mattias will need to look at this.

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

Re: [fpc-devel] i386-win32 -CriotR fails to build

[Michael Van Canneyt via fpc-devel]

On Fri, 1 Mar 2024, J. Gareth Moreton via fpc-devel wrote:

Just want to confirm that the failure also occurs on x86_64-win64 under 
-CriotR rules.


On all platforms. I fixed compilation with these flags.

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

Re: [fpc-devel] Question about "Default()"

[Michael Van Canneyt via fpc-devel]

On Thu, 22 Feb 2024, Martin Frb via fpc-devel wrote:


https://www.freepascal.org/docs-html/rtl/system/default.html
Default is a compiler intrinsic: it returns for every type T a default 
value. In essence, this is a block of memory that is zeroed out. It can be 
used to correctly initialize any type, and more importantly, a managed 
type. It also works using a generic type template. 


But zero isn't always a valid value => so how can it be used to initialize a 
type where that is invalid.


The below will runtime error "invalid enum value".
(And also, in the past, I saw it pointed out countless times, that setting an 
enum to an ordinal value that is not matching any of its members does not 
have a defined behaviour).


So is that a bug in Default?
Or is the documentation wrong "any type"? (it contradicts itself anyway 
"zeroed" <> "any type")


I have amended the documentation to say that a block of zeroes is not
necessarily a correct value, and have given 3 examples of types where it can
go wrong.

Michael.


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

Re: [fpc-devel] Possible bug in "chmreader"

[Michael Van Canneyt via fpc-devel]

On Wed, 21 Feb 2024, Christo Crause via fpc-devel wrote:


Hi Kit,

fwindowslist is created in the constructor, which may explain why this bug
is dormant.
I assume this is supposed to be a defensive check, although fwindowslist is
also accessed
later in this method without a safety check. Perhaps the "if not?
assigned()" check can be omitted
since it isn't sufficient protection and the constructor should have
automatically created the fwindowslist class.


I checked the code. 
I removed the check, the check is pointless as you correctly pointed out.


There is more scary code in these units, a general overhaul would not go amiss.

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

Re: [fpc-devel] Compiler warning when built with -dDEBUG_NODE_XML

[Michael Van Canneyt via fpc-devel]

On Wed, 14 Feb 2024, J. Gareth Moreton wrote:


Hi everyone,

After some recent updates to the trunk, the compiler no longer successfully 
builds when -dDEBUG_NODE_XML is specified:


symsym.pas(2885,9) Warning: (treated as error) Case statement does not handle 
all possible cases


This is located within "procedure TConstSym.XMLPrintConstData(var T: Text);", 
which outputs information on defined constants into the node dump.  I assume 
this is because of commit fe62b3ace8c237d8bd1800beb5969e5cb540723f (Michael 
Van Canneyt's work) which introduces the "constwresourcestring" constant 
type, which isn't handled by the identified case block.


Sorry about that, I fixed it.

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

Re: [fpc-devel] {$push} and {$pop} on trunk [2024/02/13] for aarach64 doen't work

[Michael Van Canneyt via fpc-devel]

On Fri, 16 Feb 2024, Hairy Pixels via fpc-devel wrote:


His email looks good to me. Much easier to see code with formatting.

Who doesn't have email clients with HTML support these days? I can't imagine 
how old your system must be to not have this.


I don't have HTML support in my mail program. My mail program is text based.

HTML in mail is for 99.99% of cases a waste of bandwidth. 
I care about the content of a message, not about the markup.


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

Re: [fpc-devel] Default-max-precision for different float types?

[Michael Van Canneyt via fpc-devel]

On Tue, 13 Feb 2024, Martin Frb via fpc-devel wrote:


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

Are there any defaults, with which precision each float type 
(single/double/extended) should be printed?


Sysutils contains some defaults used by the format function:

 case ValueType of
fvExtended:
  Str(Extended(Value):25, Buffer);
fvDouble,
fvReal:
  Str(Double(Value):23, Buffer);
fvSingle:
  Str(Single(Value):16, Buffer);
fvCurrency:
  Str(Currency(Value):25, Buffer);
fvComp:
  Str(Currency(Value):23, Buffer);
  end;


There are probably some other constants in the flt_core.inc file in the rtl
for the write/str functions...

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

Re: [fpc-devel] debug info and TAlphaColor = Cardinal;

[Michael Van Canneyt via fpc-devel]

On Sat, 10 Feb 2024, Martin Frb via fpc-devel wrote:


The below leads to debug info reporting TAlphaColor as Cardinal.

Maybe it could be changed (like TColor is a distinct type)?


Done.

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

Re: [fpc-devel] Modifiers...

[Michael Van Canneyt via fpc-devel]

On Tue, 30 Jan 2024, Hairy Pixels via fpc-devel wrote:





On Jan 30, 2024, at 8:01 PM, Michael Van Canneyt via fpc-devel 
 wrote:

It's probably more correct to say that you don't want there to be an override
in a descendent class. Offhand I can't think of a use-case, but why not...


yes you do, because the descendent doesn't know the class inheriting from it is 
the final class in the chain or not.


'yes I do' what exactly ?

I thought I understood after your previous mail. 
Now I read your sentence as an argument for not having a "final" at all, so this is again confusing for me :/


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

Re: [fpc-devel] Modifiers...

[Michael Van Canneyt via fpc-devel]

On Tue, 30 Jan 2024, Hairy Pixels via fpc-devel wrote:





On Jan 30, 2024, at 3:56 AM, Michael Van Canneyt via fpc-devel 
 wrote:

Unfortunately I still don't understand after your explanation what adding 
'final' is supposed to accomplish. It may well be legitimate, but I have 
currently no opinion as I don't understand it.


Final means there is no possible implementation in another subclass so the
compiler doesn't need to invoke the method via the vtable.  Ideally this
works on the class level too because it's a useful optimization.


Yes, that is one of the effects. I understood that part.

It's probably more correct to say that you don't want there to be an override
in a descendent class. Offhand I can't think of a use-case, but why not...

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

Re: [fpc-devel] Modifiers...

[Michael Van Canneyt via fpc-devel]

On Mon, 29 Jan 2024, Sven Barth via fpc-devel wrote:


over whether the method had been declared as virtual.


Hm. That makes no sense at all to me ?

You normally add override only when you know the base class has virtual.
Otherwise, don't add virtual. The compiler will tell you if it was 
possible

or not.


But that's the point: you *have* to add override. It will *always* be a 
virtual method ("reintroduce" doesn't count, because that's essentially 
the same as using a method with a completly different name). It's not in 
the control of the user. With "final" the user has that control.


Especially in application code (*not* library code) this can be useful, 
especially if the compiler generates different code in both cases (as 
said the compiler doesn't need to go through the VMT then if called with 
the real class type which can be important in performance relevant code).


Languages like C++, Java and C# all have these functionality as well and 
only because *you* can't think of a legitimate use for it, doesn't mean 
that no one can.


Please refrain from using things like '*you*' in your replies, 
it comes over as very agressive and authoritarian.


I didn't say I cannot think of a legitimate use. I said it does not make
sense to me, as in

"I don't understand what people try to accomplish with this modifier".

Unfortunately I still don't understand after your explanation what adding 'final' is supposed to accomplish. 
It may well be legitimate, but I have currently no opinion as I don't understand it.


Maybe an actual code example would be more enlightening.

That way I can also add it to the docs once I understand the intended use 
myself.

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

Re: [fpc-devel] Modifiers...

[Michael Van Canneyt via fpc-devel]

On Mon, 29 Jan 2024, Sven Barth via fpc-devel wrote:


Am 28.01.2024 um 12:14 schrieb Michael Van Canneyt via fpc-devel:





2)
Is there, or has there once been?
(found in the synedit highlighter)
  final


final comes after virtual/dynamic. Its supposed to stop you from 
overriding

a method. Which is a bit strange because then you should not declare it
virtual to begin with.


A person that overrides virtual methods does not always have control 
over whether the method had been declared as virtual.


Hm. That makes no sense at all to me ?

You normally add override only when you know the base class has virtual.
Otherwise, don't add virtual. The compiler will tell you if it was possible
or not.

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

Re: [fpc-devel] Modifiers...

[Michael Van Canneyt via fpc-devel]

On Wed, 24 Jan 2024, Martin Frb via fpc-devel wrote:


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

Is this list complete/correct?

1)
It lists bitpacked, but
    program foo; var  bitpacked: integer;  begin end;
gives an error.

I thought modifiers can be used as var names?


Normally, yes.



2)
Is there, or has there once been?
(found in the synedit highlighter)
  final


final comes after virtual/dynamic. Its supposed to stop you from overriding
a method. Which is a bit strange because then you should not declare it
virtual to begin with.

AFAIK not supported in FPC.


  automated


It is a visibility section. Delphi has/had it for win32, activeX server stuff.
It's the same as public in all other aspects.

AFAIK not supported in FPC.


  optional


I have no idea what this is.




3)
Not on the list, but suspected the should?
Some are on https://www.freepascal.org/docs-html/ref/refse100.html
  sealed
  inline
  mwpascal
  noinline
  weakexternal
  compilerproc
  vectorcall


I have added these to the list, thank you.

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

Re: [fpc-devel] Changes to TProcess

[Michael Van Canneyt via fpc-devel]

On Thu, 4 Jan 2024, Michalis Kamburelis via fpc-devel wrote:


Michael Van Canneyt wrote:

Needless to say, the component remains backwards compatible.

There is now a testsuite for the TProcess command, so everything was tested.
but nothing beats testing in the wild, so I would appreciate it if people
could test it and provide feedback.


Great additions -- making it easier to use pipes is important, and
it's very natural to be able to connect with pipes a few TProcess
instances.

I tested the changes with Castle Game Engine (not using new features
yet, just tested it is backwards-compatible for us), it works great.
We use TProcess in our build tool and editor (editor runs build tool,
build tool can run FPC and other programs).


Thanks for the feedback.

There were some fixes yesterday, but relevant only for "ancient" 
platforms that do not have proper pipe support, I guess that is not your

case.

The FPC buildchain also uses TProcess, so we'd notice serious shortcomings
quite quickly :-)

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

[fpc-devel] Changes to TProcess

[Michael Van Canneyt via fpc-devel]

Hello,

I merged a significant evolution of the TProcess component to FPC trunk.

Until recently, there were 2 options for TProcess when starting a new
process:

- use the parent process standard input/output/error
- use pipes to make the standard input/output/error available as streams in the 
parent process.

This has been enhanced with the following new possibilities:

- For the new process, the standard input/output/error can be configured 
separately.

- You can specify a filename as input/output/error.
  (additionally, you can rewrite or append to the file in case of output)

- You can specify a custom I/O handle as input/output/error
  (e;g. at least on unix, you can pass a socket handle)

- You can specify the null file (/dev/null on unixes or NULL on windows)

- You can specify another TProcess instance.

The last option means that you can now chain processes, just as the command 
shell does.

So the equivalent of the following chain of commands:

command  file.txt

would then be

  Proc.Executable:='command';
  Proc.InputDescriptor.FileName:='input.txt';
  Proc2.Executable:='sed';
  Proc2.Parameters.Add('s/delphi/FPC/g');
  Proc2.OutputDescriptor.FileName:='file.txt';
  Proc.OutputDescriptor.Process:=Proc2;
  Proc2.Execute;
  Proc.execute;

Needless to say, the component remains backwards compatible.

There is now a testsuite for the TProcess command, so everything was tested.
but nothing beats testing in the wild, so I would appreciate it if people
could test it and provide feedback.

Enjoy,

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

Re: [fpc-devel] Cannot create Merge Request

[Michael Van Canneyt via fpc-devel]

On Tue, 2 Jan 2024, Amir--- via fpc-devel wrote:


Hi there,

I never used gitlab before, so my question might be very stupid!
I am trying to follow the instruction here 
 
to create a patch. I have created a Feature Request 
 but cannot 
figure out how to create a MergeRequest?


If you created a patch file, don't make a merge request. 
Simply attach the patch file to the issue.


To create a merge request, you must fork the gitlab repo on gitlab, create a
branch in your fork, commit the change in the branch, and then use the gitlab 
UI to create a merge request. When you push your change, gitlab will automatically

propose a URL to create the merge request and git will display it.

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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Michael Van Canneyt via fpc-devel]

On Fri, 29 Dec 2023, Marco van de Voort via fpc-devel wrote:



Op 27/12/2023 om 13:37 schreef Marco van de Voort via fpc-devel:


- The short description in the overview (#rtl) page still doesn't appear ,


After some debugging, my guess is that in this specific case the path 
chopping code in TDocNode.CreateChildren at dglobals:455 and further is to 
blame.


The tag gets chopped up, and a node is made with name "system" not 
"system.uitypes"


I will have a look.

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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Michael Van Canneyt via fpc-devel]

On Tue, 26 Dec 2023, Marco van de Voort via fpc-devel wrote:



Op 26/12/2023 om 19:53 schreef Michael Van Canneyt via fpc-devel:


Can you explain what the exact problem is with system.uitypes other than
that the description file was not included in the build project xml ?

I built the docs with it and it is as complete as can be expected. All 
works as it is supposed to work, links and all.


See the link I posted to the daily snapshot. The lemmas of the symbols exist 
but only contain the declaration, no information whatsoever from the XML. Not 
even the short description of the unit on the main contents page.


Don mostly clicked through because of the TColor description.


Well, I can't reproduce it.

The relevant texts are there when I generate the HTML documentation with the 
latest trunk version of fpdoc.

Most likely the fpdoc version on idefix used to generate the daily docs needs 
to be updated.

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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Michael Van Canneyt via fpc-devel]

On Tue, 26 Dec 2023, Marco van de Voort via fpc-devel wrote:



Op 26/12/2023 om 18:20 schreef Michael Van Canneyt via fpc-devel:


To fix this either we have to e.g. keep a list of packages and a 
list of units and then try to disambiguate to only pick the longest 
match. That maybe have risks that other corner cases be found or 
that the list of units is not yet complete at any point when this 
system is inside fpdoc. This requires no changes to the .xmls


This is the road to take. It's similar to what the compiler does, 
after all.
Not the easiest, not the safest, if at any time during the fpdoc run, 
the complete list of units is available.


The complete list is always available.


If you say so.   It is still ambiguous though, even if most common cases 
can disambiguated.   (a.b.c.d  is either symbol d in unit b.c  or field 
d in structure type c in unit b), which is why I didn't favor it.


Can you explain what the exact problem is with system.uitypes other than
that the description file was not included in the build project xml ?

I built the docs with it and it is as complete as can be expected. 
All works as it is supposed to work, links and all.


I removed it again from the build project (commented out the relevant
entries), since the xml file is horribly incomplete, and we only 
include completed units in the docs.


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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Michael Van Canneyt via fpc-devel]

On Tue, 26 Dec 2023, Marco van de Voort via fpc-devel wrote:



Op 26/12/2023 om 10:29 schreef Michael Van Canneyt via fpc-devel:




To fix this either we have to e.g. keep a list of packages and a list 
of units and then try to disambiguate to only pick the longest match. 
That maybe have risks that other corner cases be found or that the 
list of units is not yet complete at any point when this system is 
inside fpdoc.  This requires no changes to the .xmls


This is the road to take. It's similar to what the compiler does, 
after all.
Not the easiest, not the safest, if at any time during the fpdoc run, 
the complete list of units is available.


The complete list is always available.

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Tue, 26 Dec 2023, Maxim Ganetsky via fpc-devel wrote:



So `make install` does not work as expected?


It does, but 'make install' only does half the job for making a release:
pas2js works with sources only, which are not installed by 'make install'.


They were before. I rolled back to Pas2Js commit 
bdf63857de5cc53bde6d72f1261ecff5d08c8d7b, and with this commit hello.pas 
builds successfully and I see the following files installed by `make 
install`:


Aha, the plot thickens...

OK. I see that code was added to fpmake to install the sources.
I adapted and enhanced that code, now all sources are again installed.
(I checked that)

So I hope that now the 'hello world' will compile.

Michael.

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Tue, 26 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


26.12.2023 11:49, Michael Van Canneyt via fpc-devel пишет:

On Mon, 25 Dec 2023, Maxim Ganetsky wrote:
Thanks. But still no luck. It seems like asterisks in config file are not 
expanded properly. See the output of compilation run for a trivial "Hello, 
World!" program:


They are expanded. I've been using it for quite some time now.
I don't think I've been hallucinating. See below :-)


||
Info: Macro defined: UNICODE
||
Info: Compiler exe: "/usr/local/bin/pas2js"
||
Info: Using working directory: 
"/builds/freepascal.org/lazarus-sandbox/lazarus-test-4"

||
Info: Using unit path: "/usr/local/lib/fpc/3.3.1/pas2js/*/src"
||
Note: unit path not found: "/usr/local/lib/fpc/3.3.1/pas2js/*/src"


Is the path correct to begin with ?


Sigh, no it is not:

$ ls -l /usr/local/lib/fpc/3.3.1/pas2js
|
total 4
||
drwxr-xr-x 2 root root 4096 Dec 25 17:37 rtl
||
$ ls -l /usr/local/lib/fpc/3.3.1/pas2js/rtl
||
total 48
||-rw-rw-r-- 1 root root 45451 Dec 25 15:49 rtl.js|

So `make install` does not work as expected?


It does, but 'make install' only does half the job for making a release:
pas2js works with sources only, which are not installed by 'make install'.

Normally, Mattias makes a pas2js release, but how he does this is still a 
secret, even for me :-)
(not that this 'secret' is intended)

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

Re: [fpc-devel] fpdoc path + system.uitypes problems.

[Michael Van Canneyt via fpc-devel]

On Mon, 25 Dec 2023, Marco van de Voort via fpc-devel wrote:



(forum thread: 
https://forum.lazarus.freepascal.org/index.php/topic,65629.0.html)


Don noticed that the system.uitypes lemma's in the CHM are empty, both 
with 3.2.x as 3.3.x fpdoc.


I checked the only html snapshot and it is the same: 
https://www.freepascal.org/daily/doc/rtl/system.uitypes/index-5.html


I can remember that I tried to debug this a while back, and that this is 
a fundamental problem of fpdoc because it uses dots to separate the 
parts of a lemma. (e.g. packagename.unitname.recordtype.fieldname).  
Separating a path on dot then breaks the unit name. If unit name is 
system.uitypes.somevariable, it tries to find symbol uitypes in system, 
and then searches for a  field in somevariable  etc.


This obviously needs to be extended. dotted unit names didn't exist when
fpdoc was made.



To fix this either we have to e.g. keep a list of packages and a list of 
units and then try to disambiguate to only pick the longest match. That 
maybe have risks that other corner cases be found or that the list of 
units is not yet complete at any point when this system is inside 
fpdoc.  This requires no changes to the .xmls


This is the road to take. It's similar to what the compiler does, after all.



A more definitive choice is to change something about the notation and 
somehow replace or escape dots within identifiers. like  
rtl.#system.uitypes#.recordtype.fieldname  or like


The # notation is already taken to indicate a fully qualified name.

rtl.system#uitypes.recordtype.fieldname or 
rtl.system..uitypes.recordtype.fieldname. (exact characters to be used 
T.b.d.    Only requires changes to the XML for dotted unit names.


and everything referring to it since any cross-reference would also need to be 
changed.

I will have a look this week, I have holidays so I have some time.

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Mon, 25 Dec 2023, Maxim Ganetsky wrote:


25.12.2023 18:35, Michael Van Canneyt via fpc-devel пишет:



On Mon, 25 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


||
-Fu$CfgDir../lib/fpc/3.3.1/pas2js/rtl/src
|


I see that there are missing directory separators after $CfgDir, maybe this 
is the reason?


I added it.

Thanks. But still no luck. It seems like asterisks in config file are not 
expanded properly. See the output of compilation run for a trivial "Hello, 
World!" program:


They are expanded. I've been using it for quite some time now.
I don't think I've been hallucinating. See below :-)


||
Info: Macro defined: UNICODE
||
Info: Compiler exe: "/usr/local/bin/pas2js"
||
Info: Using working directory: 
"/builds/freepascal.org/lazarus-sandbox/lazarus-test-4"

||
Info: Using unit path: "/usr/local/lib/fpc/3.3.1/pas2js/*/src"
||
Note: unit path not found: "/usr/local/lib/fpc/3.3.1/pas2js/*/src"


Is the path correct to begin with ?

i.e. do the directories /usr/local/lib/fpc/3.3.1/pas2js/*/src actually exist ?

Partial output here:


pas2js -va hello.pas

Debug: quick handling option "hello.pas"
Info: Configfile search: /home/michael/.pas2js.cfg
Info: Reading options from file "/home/michael/.pas2js.cfg"
Debug: interpreting file option "#ifdef FPC_SUBTARGET_NAMESPACED"
.pas2js.cfg(1,1) Debug: cfg directive "#ifdef FPC_SUBTARGET_NAMESPACED": false 
-> skip
Debug: interpreting file option 
"-Fu/home/michael/P2JS/main/packages/*/namespaced"

Debug: interpreting file option "-Fi/home/michael/P2JS/main/packages/*/src"
Debug: interpreting file option "#else"
.pas2js.cfg(4,1) Debug: cfg directive "#else": execute
Debug: interpreting file option "-Fu/home/michael/P2JS/main/packages/*/src"
...
Info: Using unit path: "/home/michael/P2JS/main/packages/nodejs/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/opentok/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/pdfjs/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/pushjs/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/tinyeditor/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/vscode/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/wasi/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/webwidget/src"
Info: Using unit path: "/home/michael/P2JS/main/packages/xterm/src"

So the path is definitely expanded.

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Mon, 25 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


||
-Fu$CfgDir../lib/fpc/3.3.1/pas2js/rtl/src
|


I see that there are missing directory separators after $CfgDir, maybe this 
is the reason?


I added it.



Also probably it would be worth to consider removing code duplication between 
createconfig.pp and fpmake.pp in regards of config file generation.


I'd rather not. Preferably, the fpmake.pp file should not depend on anything.

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Sun, 24 Dec 2023, Maxim Ganetsky via fpc-devel wrote:

As far as I know, Mattias is busy with it and has at least fixed the 
tests ?


I see the commit by Mattias now, but it does not affect config file 
created by `make install`, because the following duplicated code is 
used for creating config files when running `make install`:




https://gitlab.com/freepascal.org/fpc/pas2js/-/blob/main/fpmake.pp?ref_type=heads#L20


I updated the config file writing. 2 files are written now. My local 
tests are all OK.


Please elaborate. I just updated FPC and Pas2Js, nothing changed in 
behavior. Where is the commit?


Sorry, forgot to push. fpmake.pp in pas2js repo.

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Sun, 24 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


24.12.2023 01:07, Michael Van Canneyt via fpc-devel пишет:



On Sat, 23 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


20.12.2023 12:36, Mattias Gaertner via fpc-devel пишет:



On 20.12.23 10:18, Michael Van Canneyt via fpc-devel wrote:


[...]
Is this an FPC regression or the tests should be adapted somehow? 
Can this be related to introduction of subtargets to Pas2JS?


It could be, although I suspect it is more likely that the sources 
moved to

a subdir src in each of the package directories, to support namespaced
files.


Yes.


I was not aware that there were tests for pas2js in the lazarus 
codebase, so yes, probably some tests or the underlying code in the 
IDE need to be adapted.



utils/createconfig.pas needs to be adapted...

Any news on this? What changes are needed?


As far as I know, Mattias is busy with it and has at least fixed the 
tests ?


I see the commit by Mattias now, but it does not affect config file 
created by `make install`, because the following duplicated code is used 
for creating config files when running `make install`:


https://gitlab.com/freepascal.org/fpc/pas2js/-/blob/main/fpmake.pp?ref_type=heads#L20


I updated the config file writing. 2 files are written now. 
My local tests are all OK.


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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Sat, 23 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


20.12.2023 12:36, Mattias Gaertner via fpc-devel пишет:



On 20.12.23 10:18, Michael Van Canneyt via fpc-devel wrote:


[...]
Is this an FPC regression or the tests should be adapted somehow? 
Can this be related to introduction of subtargets to Pas2JS?


It could be, although I suspect it is more likely that the sources 
moved to

a subdir src in each of the package directories, to support namespaced
files.


Yes.


I was not aware that there were tests for pas2js in the lazarus 
codebase, so yes, probably some tests or the underlying code in the 
IDE need to be adapted.



utils/createconfig.pas needs to be adapted...

Any news on this? What changes are needed?


As far as I know, Mattias is busy with it and has at least fixed the tests ?

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

Re: [fpc-devel] Failing Lazarus Codetools Pas2JS-related tests

[Michael Van Canneyt via fpc-devel]

On Wed, 20 Dec 2023, Maxim Ganetsky via fpc-devel wrote:


Hello.

After recent update of FPC 3.3.1 (and Pas2JS) in Lazarus CI several 
Codetools tests related to Pas2JS started failing:


TTestPas2js.TestPas2js_ReadSettings: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration: pas2js system unit not found
TTestPas2js.TestPas2js_FindDeclaration_AWait: pas2js system unit not found

They worked fine with FPC 3.3.1 from November 30.

Is this an FPC regression or the tests should be adapted somehow? Can 
this be related to introduction of subtargets to Pas2JS?


It could be, although I suspect it is more likely that the sources moved to
a subdir src in each of the package directories, to support namespaced
files.

I was not aware that there were tests for pas2js in the lazarus codebase, so
yes, probably some tests or the underlying code in the IDE need to be adapted.

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

Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)

[Michael Van Canneyt via fpc-devel]

On Thu, 14 Dec 2023, Martin Frb via fpc-devel wrote:


On 14/12/2023 21:33, Marco van de Voort via fpc-devel wrote:


Op 14-12-2023 om 21:27 schreef Martin Frb via fpc-devel:


I am actually pretty sure, on Linux, I can get what I want by doing 
it in the "OnFork" event of TProcess.
But on Windows it is well hidden away in the "Execute" method, 
nothing virtual that could be intercepted.


Change the input handle and use popassinput ?
As I said, not possible (unless I make a copy of the entire TProcess 
code).  There is no way to intercept "Execute", and it must be done 
before the Windows API is called to create the process.




But I wonder if this is not too specialistic. It depends on how well 
you can abstract it into TProcess, and preferably in a somewhat 
similar way for all OSes.


Well Michael's answer looks like he is about to have what I need. 
Depends on the when...


I pushed what I have to the extended_process branch. I tested on linux.
Most simple scenarios I threw at it seem to work OK but I need to do some more 
testing
for correct pipelines, for example:

ProcessA | ProcessB > out.txt

(so yes, we should be able to make a good 'pascal shell' :-))

Windows compiles and in code does what it takes, but needs more testing.

(in particular: when opening a file for input/output, does the parent need to 
close the file
just as it does for pipes ?)

Note that there are still writeln() stements in it, this is WIP.

You're  of course welcome to provide patches if I messed something up :)

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

Re: [fpc-devel] TProcess and redirection of StdIn/Out (e.g. from/to files)

[Michael Van Canneyt via fpc-devel]

On Thu, 14 Dec 2023, Martin Frb via fpc-devel wrote:

If I am right the TProcess currently does not allow redirection of StdOut/In 
to/from a file (or other handle provided).


If it does, and I have been missing the "how to", then please enlighten me 
and disregard the remainder of the mail.


It does not exist out in the open :-)




The code for setting up redirection to pipes (to be read/write by the parent 
process) already exists. So this is mainly a call to add properties to 
explicitly set those handles.

Or provide some other method.

Is this something that should be added? (I.e. a feature request to be added)
If yes, should there just be 3 properties for the handles? A callback to 
create/provide them? A virtual method?

Should there be a flag?


Actually, I already started an implementation of an extension half a year ago.
(although I have the design in mind since several years. Time constraints...)

It's nearly finished, there are still some corner cases that need testing.

The idea is a property of type TIODescriptor (reduced code for readability):

TIOType = (iotNone,iotPipe,iotFIle,iotHandle,iotProcess);

TIODescriptor = class(Tpersistent)
Public
  Property Handle : THandle;
Published
  property IOType: TIOType;
  property FileName : string;
  property OnGetHandle : TGetHandleEvent;
  property Process : TProcess; 
end;


uses as

TProcess = Class()
// ...
Published
  Property InputDescriptor : TIODescriptor;
  Property OutputDescriptor : TIODescriptor;
  Property ErrorDescriptor : TIODescriptor;
end;



What should be the resolving order if handles are give, but other flags 
(pipes/input) are set?


Backwards compatibility first and foremost. Setting the poUsePipes option
switches all descriptors to IOType = iotPipe.

I'll see if I can finish the implementation ASAP.

Michael.

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

Re: [fpc-devel] Wrong debug info when using clang backend

[Michael Van Canneyt via fpc-devel]

On Wed, 13 Dec 2023, Jonas Maebe via fpc-devel wrote:


On 09/12/2023 13:35, Adriaan van Os via fpc-devel wrote:

Jonas Maebe via fpc-devel wrote:
So if/when we would get FPC equivalents of such directives, I could 
translate those to LLVM IR as well.


Then I suggest the following (and I can prepare a patch to the code and 
docs if it were to be accepted)


$vectorize ON}
{$vectorize OFF}
{$vectorize WIDTH=VALUE}
{$vectorize TYPE=FIXED}
{$vectorize TYPE=SCALABLE}
{$vectorize PREDICATE=ON}
{$vectorize PREDICATE=OFF}

For a description, see 
. And


{$unroll ON}
{$unroll OFF}
{$unroll FULL}
{$unroll COUNT=VALUE}

For a description, see 


.

I'd rather not introduce directives that are specific to clang, and 
especially none only apply to the next loop. We don't have a single 
directive yet that works like this.


Maybe attributes would be more appropriate, although I don't think 
Delphi (or FPC) currently supports attributes for statements.


Please don't:
Attributes are designed for runtime consumption. I'm heavily opposed to
start using them to influence the code generation. The compiler should
remain ignorant of their meaning and use.

Maybe a single {$PRAGMA XYZ} directive can be introduced to control this
kind of stuff, with a fixed list of XYZ. 
Backends can intepret the XYZ pragmas as they see fit.


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

Re: [fpc-devel] jsonrpc - does it still work?

[Michael Van Canneyt via fpc-devel]

On Fri, 24 Nov 2023, Joost van der Sluis via fpc-devel wrote:


Hi all,

I'm playing with json-rpc but can't get it to work.

I've tried the examples in fcl-web/examles/jsonrpc. I couldn't follow
the readme as there are no lpi-files, so that the rttirpc.lpg does not
work. But also this fails:


The .lpi files where not there because .lpi is in the ignore list, so I
never noticed they were not in the repo :/

I committed them, and removed the *.lpi stance from the .gitignore file.

I corrected the example. The "classname" property in the json-rpc request 
has been renamed to "class", but the example was not adapted for this. This

is now done.

I tested both client examples, both work.

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

Re: [fpc-devel] jsonrpc - does it still work?

[Michael Van Canneyt via fpc-devel]

On Fri, 24 Nov 2023, Joost van der Sluis via fpc-devel wrote:


Hi all,

I'm playing with json-rpc but can't get it to work.

I've tried the examples in fcl-web/examles/jsonrpc. I couldn't follow
the readme as there are no lpi-files, so that the rttirpc.lpg does not
work. But also this fails:

[joost@fed4k rtti]$ ppcx64 demorpcrtti.lpr
Free Pascal Compiler version 3.3.1 [2023/11/23] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling demorpcrtti.lpr
Compiling resource demorpcrtti.or
Linking demorpcrtti
demorpcrtti.lpr(32,1) Warning: "crtbegin.o" not found, this will
probably cause a linking failure
demorpcrtti.lpr(32,1) Warning: "crtend.o" not found, this will probably
cause a linking failure
33 lines compiled, 0.2 sec, 1304576 bytes code, 623944 bytes data
2 warning(s) issued

[joost@fed4k rtti]$ ppcx64 rpcclient.lpr
Free Pascal Compiler version 3.3.1 [2023/11/23] for x86_64
Copyright (c) 1993-2023 by Florian Klaempfl and others
Target OS: Linux for x86-64
Compiling rpcclient.lpr
Linking rpcclient
88 lines compiled, 0.2 sec, 1166496 bytes code, 527936 bytes data

[joost@fed4k rtti]$ ./demorpcrtti &
[1] 2913859

[joost@fed4k rtti]$ ./rpcclient
= Testing SayHello
An unhandled exception occurred at $7F96D7E6A010:
EAccessViolation: Access violation
 $7F96D7E6A010
 $00401A06

It fails at 'client.SayHello'. The invoke-logic is never called.


I have the jsonrpc in use in various commercial applications in production, 
so yes it definitely works.


But I must admit I have not looked at the examples in a long time.

I'll have a look this weekend.

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

Re: [fpc-devel] Build failure in FPC Build repository, attn. Florian

[Michael Van Canneyt via fpc-devel]

On Mon, 13 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


13.11.2023 0:14, Michael Van Canneyt via fpc-devel пишет:



On Sun, 12 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


12.11.2023 19:44, Michael Van Canneyt via fpc-devel пишет:



On Thu, 9 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Is there any estimation how much will it take to be fixed?


No, since I don't even know yet what the fix is.



If it will take too long, I would like to suggest to temporarily 
disable generation of documentation in order to have binary 
snapshots available again.


That is what I proposed in the first place.


Since the units reference documentation has become too big for LaTeX 
to handle,
I have disabled the generation of PDF for the units reference 
documentation.


Henceforth, the documentation for the units will only be available as 
HTML.

(and, presumably, chm)

The build should again be OK. 


Now FPC 3.3.1 crashes when trying to build cross-compiler for i386-win32:


Oh bloody hell, an IFDEF MSWINDOWS... The IDE didn't create the
implementation for that :/


You may want to create an issue.


Well, it's debatable whether it actually should do so. 
And if so, should the implementation also be in an IFDEF MSWINDOWS ?


I'm inclined to give the IDE the benefit of the doubt :-)

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

Re: [fpc-devel] Build failure in FPC Build repository, attn. Florian

[Michael Van Canneyt via fpc-devel]

On Sun, 12 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


12.11.2023 19:44, Michael Van Canneyt via fpc-devel пишет:



On Thu, 9 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Is there any estimation how much will it take to be fixed?


No, since I don't even know yet what the fix is.



If it will take too long, I would like to suggest to temporarily disable 
generation of documentation in order to have binary snapshots available 
again.


That is what I proposed in the first place.


Since the units reference documentation has become too big for LaTeX to 
handle,
I have disabled the generation of PDF for the units reference 
documentation.


Henceforth, the documentation for the units will only be available as HTML.
(and, presumably, chm)

The build should again be OK. 


Now FPC 3.3.1 crashes when trying to build cross-compiler for i386-win32:


Oh bloody hell, an IFDEF MSWINDOWS... The IDE didn't create the
implementation for that :/

Fixed.

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

Re: [fpc-devel] Build failure in FPC Build repository, attn. Florian

[Michael Van Canneyt via fpc-devel]

On Sun, 12 Nov 2023, Florian Klämpfl via fpc-devel wrote:





Am 12.11.2023 um 17:44 schrieb Michael Van Canneyt via fpc-devel 
:



On Thu, 9 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Is there any estimation how much will it take to be fixed?

No, since I don't even know yet what the fix is.

If it will take too long, I would like to suggest to temporarily disable 
generation of documentation in order to have binary snapshots available again.

That is what I proposed in the first place.


Since the units reference documentation has become too big for LaTeX to handle,
I have disabled the generation of PDF for the units reference documentation.

Henceforth, the documentation for the units will only be available as HTML.
(and, presumably, chm)

The build should again be OK.


For the CI it should be no problem.  But most installers only come with
the PDFs and fixing this properly will be probably a tedious task).  Is it
possible to split the affected document?


It is possible, but then 50% of the references are broken...

I need to think how this can be fixed.

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

Re: [fpc-devel] Build failure in FPC Build repository, attn. Florian

[Michael Van Canneyt via fpc-devel]

On Thu, 9 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Is there any estimation how much will it take to be fixed?


No, since I don't even know yet what the fix is.



If it will take too long, I would like to suggest to temporarily disable 
generation of documentation in order to have binary snapshots available 
again.


That is what I proposed in the first place.


Since the units reference documentation has become too big for LaTeX to handle,
I have disabled the generation of PDF for the units reference documentation.

Henceforth, the documentation for the units will only be available as HTML.
(and, presumably, chm)

The build should again be OK.

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

Re: [fpc-devel] Build error, main branch, compiler/options.pas 889:33

[Michael Van Canneyt via fpc-devel]

On Fri, 10 Nov 2023, drichards--- via fpc-devel wrote:


I am getting an incorrect type error at line 889 column 33 in
compiler/options.pas. This is the , following the parameter More to the
function Copy. More is defined as a String. I do not understand why the
function Copy would have a problem with a String as its first parameter.
This is my first attempt to build the compiler. Am I making a newbie mistake
here?
I am building on a Raspberry Pi, Bullseye, 64-bit with 8GB of RAM
and a 1T drive.
Dave


Make sure you use version 3.2.2 of the compiler to start the build.

This error is typical of the situation where you use another compiler to
start the build.

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

Re: [fpc-devel] Build failure in FPC Build repository

[Michael Van Canneyt via fpc-devel]

On Thu, 9 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


03.11.2023 17:34, Michael Van Canneyt via fpc-devel пишет:



On Fri, 3 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


03.11.2023 17:05, Michael Van Canneyt via fpc-devel пишет:



On Fri, 3 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Hello.

Currently builds in FPC Build repository are failing for FPC main 
branch:


https://gitlab.com/freepascal.org/fpc/build/-/pipelines


I am aware. I cannot build the docs myself.

The problem is:

Recently the documentation became too big for pdfLaTeX to handle, too 
many

identifiers. (well over 2500 pages)

I have not (yet) found a way to increase TexLive's memory bounds.
I am investigating this but it seems save_size is stuck at a value of 
8.


So unless I find a solution, either I need to split up the docs, or 
completely abandon the idea of PDF docs for the API reference.


For the moment, simply disable the building of the PDF docs.
The problem is, in our CI we rely on precompiled FPC snapshot TAR 
installers in order to save time when updating an image. So no new 
installer, no new FPC.


Well, all I can say is that I am looking into it.

Till a solution is found, you'll need to be patient...


Is there any estimation how much will it take to be fixed?


No, since I don't even know yet what the fix is.



If it will take too long, I would like to suggest to temporarily disable 
generation of documentation in order to have binary snapshots available 
again.


That is what I proposed in the first place.

But I have no idea who generates the snapshots you use, or how they are
generated.

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

Re: [fpc-devel] Request for review of patch for security risk in fcl-web/openssl

[Michael Van Canneyt via fpc-devel]

On Sat, 4 Nov 2023, Peter via fpc-devel wrote:


Hi,

Issue 40479 is about a security risk when OpenSSL is used in fcl-web
(TFPHTTPClient). Using the current source/trunk, TLS certificates
having a wrong hostname are accepted, while they should be rejected.

An easy patch for this is available, I kindly ask for a review by one
of the developers:

https://gitlab.com/freepascal.org/fpc/source/-/issues/40479

If I can help in any way to facilitate this review, please let me know.


You have already done more than what was needed, so no need to do anything else, 
it is only a matter of available time for us (me).


If anything, this patch shows IMO that people are better off with GnuTLS rather
than OpenSSL, GnuTLS is more safe by default.


(BTW I also submitted a patch for a GnuTLS problem, which is less
important because it is no security risk, but still a review is highly
appreciated:
https://gitlab.com/freepascal.org/fpc/source/-/issues/40195#note_1621128840)


I checked the patch and I applied it.

Many thanks for taking the time to investigate and fix these issues !

If you see a patch is not being treated "soon enough", pleae don't hesitate 
to ping here, or even in a personal mail.


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

Re: [fpc-devel] Build failure in FPC Build repository

[Michael Van Canneyt via fpc-devel]

On Fri, 3 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


For the moment, simply disable the building of the PDF docs.
The problem is, in our CI we rely on precompiled FPC snapshot TAR 
installers in order to save time when updating an image. So no new 
installer, no new FPC.


Well, all I can say is that I am looking into it.

Till a solution is found, you'll need to be patient...


I understand, thanks. It is amazing to see how big FPC project has 
become so it triggers limitations in well established external tools. :)


Indeed.

I recently added TPlatforms in SysUtils for Delphi compatibility.

In Delphi, this set has max 4 elements and can be used as a published property.
(and it is used as such in e.g. FMX)

In Free Pascal, this set has max 40+ elements (yes, we support that many
platforms), and cannot be used as a published property !
(Max 31 elements allowed)

Such things you only find out the hard way...


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

Re: [fpc-devel] Build failure in FPC Build repository

[Michael Van Canneyt via fpc-devel]

On Fri, 3 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


03.11.2023 17:05, Michael Van Canneyt via fpc-devel пишет:



On Fri, 3 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Hello.

Currently builds in FPC Build repository are failing for FPC main 
branch:


https://gitlab.com/freepascal.org/fpc/build/-/pipelines


I am aware. I cannot build the docs myself.

The problem is:

Recently the documentation became too big for pdfLaTeX to handle, too 
many

identifiers. (well over 2500 pages)

I have not (yet) found a way to increase TexLive's memory bounds.
I am investigating this but it seems save_size is stuck at a value of 
8.


So unless I find a solution, either I need to split up the docs, or 
completely abandon the idea of PDF docs for the API reference.


For the moment, simply disable the building of the PDF docs.
The problem is, in our CI we rely on precompiled FPC snapshot TAR 
installers in order to save time when updating an image. So no new 
installer, no new FPC.


Well, all I can say is that I am looking into it.

Till a solution is found, you'll need to be patient...

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

Re: [fpc-devel] Build failure in FPC Build repository

[Michael Van Canneyt via fpc-devel]

On Fri, 3 Nov 2023, Maxim Ganetsky via fpc-devel wrote:


Hello.

Currently builds in FPC Build repository are failing for FPC main branch:

https://gitlab.com/freepascal.org/fpc/build/-/pipelines


I am aware. I cannot build the docs myself.

The problem is:

Recently the documentation became too big for pdfLaTeX to handle, too many
identifiers. (well over 2500 pages)

I have not (yet) found a way to increase TexLive's memory bounds.
I am investigating this but it seems save_size is stuck at a value of 8.

So unless I find a solution, either I need to split up the docs, 
or completely abandon the idea of PDF docs for the API reference.


For the moment, simply disable the building of the PDF docs.

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

Re: [fpc-devel] Request for review of patch for issue 40261

[Michael Van Canneyt via fpc-devel]

On Sat, 30 Sep 2023, Bart via fpc-devel wrote:


Hi,

Issue 40261 is about TStrings.AddObject issueing 2 consecutive
OnChange events (and in the first one the to be added object is
unassigned when accessing Objects[] property) when using InsertObject,
AddObject and AddPair.
This is Delphi incompatible.

The patch attached to
https://gitlab.com/freepascal.org/fpc/source/-/issues/40261#note_1406426712
fixes this at the expense of calling BeginUpdate/EndUpdate (and for
that use a try..finally construct).

I kindly ask for this patch to be reviewed by one of the devels.


I did so, I left a small request.

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

Re: [fpc-devel] Recent changes break distclean for utils

[Michael Van Canneyt via fpc-devel]

On Fri, 18 Aug 2023, Mattias Gaertner via fpc-devel wrote:




On 18.08.23 09:36, Michael Van Canneyt via fpc-devel wrote:

[...]


After doing "make disctlean" I still have many ppu files left:

./compiler/x86_64/units/x86_64-linux/cutils.ppu
...
./compiler/x86_64/lazbuild/nobj.ppu
...
./rtl/units/x86_64-linux/cp8859_1.ppu


Compiler and RTL are not using fpmake, so this must be something else.

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

Re: [fpc-devel] Recent changes break distclean for utils

[Michael Van Canneyt via fpc-devel]

On Fri, 18 Aug 2023, Mattias Gaertner via fpc-devel wrote:




On 18.08.23 09:36, Michael Van Canneyt via fpc-devel wrote:

[...]


After doing "make disctlean" I still have many ppu files left:

./compiler/x86_64/units/x86_64-linux/cutils.ppu
...
./compiler/x86_64/lazbuild/nobj.ppu
...
./rtl/units/x86_64-linux/cp8859_1.ppu
...
./utils/pas2js/lib/x86_64-linux/pas2jsjsresources.ppu

That's why I get on "make all OPT='-gw2'":

make[5]: Entering directory '/home/mattias/pascal/fpc/3.3.1/compiler'
/usr/bin/ppcx64 -Ur -Xs -O2 -n -Fux86_64 -Fusystems 
-Fu/home/mattias/pascal/fpc/3.3.1/rtl/units/x86_64-linux -Fix86_64 
-FEx86_64/bin/x86_64-linux -FUx86_64/units/x86_64-linux -Cg 
-Fl/usr/lib/gcc/x86_64-linux-gnu/11 -dRELEASE -gw2 -dx86_64 -dGDB -Fux86 
-Fix86 -o/home/mattias/pascal/fpc/3.3.1/compiler/ppc1 pp.pas

PPU Loading /home/mattias/pascal/fpc/3.3.1/rtl/units/x86_64-linux/system.ppu
PPU Invalid Version 208
Fatal: Can't find unit system used by pp


Where do you do this "make all" ?

1. The error is that it cannot find the system unit. 
To my knowledge, that cannot be caused by stray leftover units.


2. At the top level, You must call "make all " with a release compiler.
   I do not see you specifying this option.

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

Re: [fpc-devel] Recent changes break distclean for utils

[Michael Van Canneyt via fpc-devel]

On Fri, 18 Aug 2023, Maxim Ganetsky via fpc-devel wrote:


16.08.2023 4:29, Garry Wood via fpc-devel пишет:

Hello,

Just letting you know that some recent changes seem to have broken “make 
distclean” for source/utils


Please create a bug report.


Makefile.fpc in the source/utils folder contains the line:

CLEAN_TARGET_DIRS=$(subst /Makefile.fpc, ,$(wildcard */Makefile.fpc))

But a recent commit (25 July 2023) removed all the Makefile.fpc files 
from source/utils/* so it now finds no targets to clean.


And that is how it is supposed to be. 
The distclean is only needed at the toplevel. The rest is handled by fpmake.

So there is no need to call distclean for subdirectories, this means that
CLEAN_TARGET_DIRS must be empty.

So what is the actual problem ?

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

Re: [fpc-devel] specialization with type alias, bug or feature

[Michael Van Canneyt via fpc-devel]

On Thu, 17 Aug 2023, Mattias Gaertner via fpc-devel wrote:


Hi,

FPC and Delphi handle type alias differently and I wonder if this was 
deliberate.


type
 TMyDouble = type double;

 TBird = class
   a: T;
 end;
 TDoubleBird = TBird;
 TMyDoubleBird = TBird;

Both FPC and Delphi create different classes for TDoubleBird and 
TMyDoubleBird.


In Delphi they are not assign compatible, in FPC they are. For example:
var
 a: TDoubleBird;
 b: TMyDoubleBird;
begin
 b:=TMyDoubleBird.Create;
 a:=b; // forbidden in Delphi
 writeln(a is TDoubleBird); // writes false

Bytewise the assignment is ok, but logic wise "a" is no longer a TDoubleBird.

Is this a bug or a feature?


Depends on how you look at it. Double and TMyDouble are assignment compatible.
There is no reason why the same should not hold true for TDoubleBird and 
TMyDoubleBird ?

In Delphi

Type
  TArrayInteger1 = Array of Integer;
  TArrayInteger2 = Array of Integer;

var
  A1 : TArrayInteger1;
  A2 : TArrayInteger2;

begin
  A1:=A2;
end.

Will not work, but in FPC it does. This is IMO similar.

Of course, the method addresses are different. Other than that and the
different RTTI (which has 100% the same structure) the classes are
identical. So based on that we could argue they are not assignment
compatible.

I am inclined to go for feature, but maybe there are arguments to tip the
balance in the direction of bug.

Michael.

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

Re: [fpc-devel] Just to confirm, "with" behaviour expected

[Michael Van Canneyt via fpc-devel]

On Mon, 14 Aug 2023, Martin Frb via fpc-devel wrote:

In the below code, the array is resized (and more important relocated in 
mem) inside the function "bar".


The commented line (without "with") works as expected.

The "with" line has a different behaviour. I guess it is by design. Just 
wanted to confirm.


The version with "with" prints 12345 for  "  writeln(a[i,j].x);"
For all I can tell the return value of "bar" was written to the old 
address of that array-entry.


Does "with" take the "address" of the value, and operate on that 
address, even if the address of that value could change within the 
"with" statement.


You may not do this. It is even documented.

See the remark at the end of this page:

https://www.freepascal.org/docs-html/current/ref/refsu62.html#x172-19600013.2.8

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

Re: [fpc-devel] Unicode RTL

[Michael Van Canneyt via fpc-devel]

On Fri, 28 Jul 2023, Adriaan van Os via fpc-devel wrote:


Michael Van Canneyt via fpc-devel wrote:


Hello,

I have just completed phase one of the "Unicode RTL" effort.


I object to the name "Unicode" RTL. Where people talk about what they call 
"Unicode" they usually mean UCS-16 or UTF-16 or UTF-16-mishandled-as-UCS16.


Objection duly noted.

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

Re: [fpc-devel] Unicode RTL

[Michael Van Canneyt via fpc-devel]

On Fri, 28 Jul 2023, Mattias Gaertner via fpc-devel wrote:


On 24.07.23 21:49, Michael Van Canneyt via fpc-devel wrote:

[...]
Subtarget support is explained in more detail here:
https://wiki.freepascal.org/FPC_Subtarget_Support



* compile the various Lazarus widgetsets into different directories
* ... any other things you may think of ...

all with a single installation of FPC.


The -t switch alters the $fpctarget, and therefore searches the fpc units in 
another directory. So a non-fpc project must add the -Fu for the fpc units 
itself.


How can a project be non-fpc ? Every project is compiled with fpc ?

If I understand your question correct:

If you don't wish to honor the subtarget in non-fpc sources, you don't need
to do anything, as long as you don't use the $fpctarget in your own -Fu/-FU.

It will then simply use the FPC units for the specified subtarget.

If you wish to 'honor' the subtarget in your own output paths,
you must add $fpctarget in -FU (and subsequently to -Fu) for your 
own compiler settings.




Can you elaborate, how -t gives non-fpc projects new possibilities?


I think of it as "fpc-global build modes".

(build modes as implemented by lazarus may do some additional tricks,
obviously)

It is of course mainly geared towards being able to have different unit trees
in the fpc distribution.

But it is a new concept, and time will have to tell what uses can be made of it
outside the fpc distribution itself. It can be that the answer is 'none'.

Maybe some small adaptations are needed to make it more useful. 
"Time will tell" also applies here, I suppose.


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

[fpc-devel] FPC compiler error messages file update

[Michael Van Canneyt via fpc-devel]

Hello,

We're preparing FPC fixes release 3.2.4.

There are some new error messages in the compiler/msg/errore.msg file,
they need to be translated to other available languages:

errorct.msg (Catalan)
errorda.msg (Danish)
errord.msg  (German, CP 850)
errordu.msg (German, UTF8)
errores.msg (Spanish)
errorfi.msg (Finish)
errorf.msg  (French)
errorhe.msg (Hebrew CP 1255)
errorheu.msg (Hebrew UTF8)
errorid.msg (Indonesian CP 20127)
erroriu.msg (Italian)
errorn.msg  (Dutch)
errorpli.msg (Polish CP 8859-2)
errorpl.msg (Polish CP 852)
errorpt.msg (Portugese CP 850)
errorptu.msg (Portugese UTF8)
errorr.msg (Russian CP 866)
errorru.msg (Russian UTF8)
errorues.msg (Spanish UTF8)

The tool compiler/utils/msgdif can be used to compare the language-specific
file with the original file, and will write a new.msg file.

so after compiling msgdif, if you execute the following command 
in the compiler/msg directory (I'm taking dutch as an example, you should

obviously use your language file):

msgdif errore.msg errorn.msg

it will result in a file new.msg which has all original messages from errorn.msg 
and all new messages: this 'new.msg' file needs to be corrected/updated.


I have not updated the various files myself using this method, since I am not
capable of interpreting the resulting new.msg since I don't read all these
languages, and would possibly commit wrong files as a result.

If you speak one of these languages, please consider updating the
corresponding language file and uploading a patch to the issue tracker, 
or you can send a diff to me and I will apply it.


If creating the msgdif tool and the new.msg file is too difficult for you, 
feel free to mail me and I will gladly do it for you.


Thanks in advance,

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

Re: [fpc-devel] Unicode RTL

[Michael Van Canneyt via fpc-devel]

On Mon, 24 Jul 2023, Kirinn via fpc-devel wrote:


Hi,

A "unicode" RTL is of course great for targeting legacy Windows platforms,
but for those of us on Linux, UTF-8 is the way.


It is not only for legacy windows platforms.
The target platform is secondary.

What to use depends more on your codebase than on your target platform.
There is a lot of Delphi code out there that assumes that string=unicodestring.

If, like my current company, you have a large Delphi application that you wish
to run on linux, then you may be better off with a unicode RTL.


To this end, it would be
helpful to add a paragraph on the wiki page underlining how to retain the
single-byte RTL; or, if no user action is necessary, mention that, to set
minds at ease. Thank you for this hard work!


No user action is necessary.

But your advice is good: I have added this to the page, and made clear
that the RTL as it currently exists, is still the default RTL.

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

[fpc-devel] Unicode RTL

[Michael Van Canneyt via fpc-devel]

Hello,

I have just completed phase one of the "Unicode RTL" effort.

The 'Unicode RTL' is an effort to be more Delphi compatible:
- Char = Unicode Char and String = UnicodeString
- Provide dotted filenames.
Basically closer to the RTL as it exists in more recent versions of Delphi 
(essentially post - Delphi 2009)


This RTL will co-exist with the current RTL (single-byte char, no dotted
names), but will share the same codebase.

More explanations can be found here:

https://wiki.freepascal.org/FPC_Unicode_RTL

This coexistence of 2 RTLs is accomplished with 'Subtarget support'.

Subtarget support is a means to consistently apply a set of Free Pascal
compiler settings to everything that you compile.

Subtarget support is explained in more detail here:
https://wiki.freepascal.org/FPC_Subtarget_Support

While it is now used to create a unicode rtl, it could also be used to

* create a llvm-compiled RTL.
* create an rtl with debug info and one without. 
* compile the various Lazarus widgetsets into different directories

* ... any other things you may think of ...

all with a single installation of FPC.

For the second part of the effort, 'provide dotted filenames', the actual
work is finished, but still needs merging to trunk.

This second part is expected to be merged in the next days/weeks.

But today, using FPC trunk, you can now recompile the Free Pascal RTL, 
Packages and Utils (but not the compiler itself!) into a set of units where


Char = UnicodeChar
String = UnicodeString

To compile (and install) the unicode rtl, all you need to do is follow the
steps outlined in

https://wiki.freepascal.org/FPC_Unicode_RTL

Basically, this means creating a 2-line configuration file for the unicodertl
subtarget, and compiling the RTL, packages and utils with

make SUB_TARGET=unicodertl

For those that need/want more delphi-compatible code, I would love to hear
of your experience with the unicode rtl. I have done extensive testing, but
as practice shows, there will always be cases which defy ordinary test
cases...

If the 2 wiki pages need more explanations, please let me know and I will do
my best to improve the explanations.

Hopefully, in the near future the compiler settings dialog in Lazarus will also 
allow you to specify a subtarget.


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

Re: [fpc-devel] Maybe room for better documentation? open array as var param

[Michael Van Canneyt via fpc-devel]

On Thu, 20 Jul 2023, Sven Barth via fpc-devel wrote:



It's IMO probably better to outright forbid passing open array by
reference.



There are valid use cases for that. E.g. multiply a slice of a dynamic
array by two or whatever. And forbidding var would solve nothing, see
below.


printing length(a) after x:=Nil; gives 10, which is simply wrong.



That is true for many cases where you modify the global variable that has
been passed on by reference, e.g. with constant parameters: the compiler
will more often than not pass a reference then, because it's more optional
and the function can't modify it anyway, but if you change the global that
was passed in you get what you deserve... (that's true no matter if it's an
open array, a string or a primitive type).


Valid point...

I will document the behaviour with the example Martin made.

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

Re: [fpc-devel] Maybe room for better documentation? open array as var param

[Michael Van Canneyt via fpc-devel]

On Thu, 20 Jul 2023, Martin Frb via fpc-devel wrote:

For const param, it is well documented that the value (that includes the 
variable that is passed) must not be changed.


But for "var param"?

Well maybe, but not explicit
https://www.freepascal.org/docs-html/ref/refsu68.html#x184-20800014.4.5
>> Open parameters can be passed by value, by reference or as a 
constant parameter. In the latter cases the procedure receives a pointer 
to the actual array.


So a user with sufficient experience could detect that if a pointer is 
received, then the value which is pointed to must not be changed.


Maybe that should be mentioned more explicitly.
And maybe it should additionally also be mentioned on 
https://www.freepascal.org/docs-html/ref/refsu65.html



Because the below may be unexpected to quite a few users.

It will (at least on my test on windows / of course depends on mem 
manager) print numbers starting at 300.

Even so 200++ has been assigned.

But (with sufficient luck or lack of luck) "y" will re-use the memory of 
"x". And "a" will then change "y" which may not be expected.



program Project1;
{$mode objfpc}

var x,y: array of integer;
  i: Integer;

procedure foo(var a: array of integer);
var
  j: Integer;
begin
  x := nil;
  SetLength(y, 10);
  for j := 0 to 9 do y[j] := 200+j;

  for j := 0 to 9 do a[j] := 300+j;
end;

begin
  SetLength(x, 10);
  for i := 0 to 9 do x[i] := 100+i;
  foo(x);
  for i := 0 to 9 do writeln(y[i]);
  readln;
end.


It's IMO probably better to outright forbid passing open array by reference.

printing length(a) after x:=Nil; gives 10, which is simply wrong.

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

Re: [fpc-devel] cthreads and fpc.cfg?

[Michael Van Canneyt via fpc-devel]

On Wed, 19 Jul 2023, Martin Frb via fpc-devel wrote:


On 19/07/2023 10:22, Michael Van Canneyt via fpc-devel wrote:



The error is logical. What is not logical is that it pops up now.

By all logic, we should have seen this error pop up as early as 2016.

Why it pops up only now is a mystery that we need to solve...


I don't have all the details, but maybe there is something buried in the 
following findings.


Thank you.

We already found the issue. The introduction of unit Types in unit fpmkunit 
(used by fpmake and fpmkcfg) caused a change in the initialization order of units.


Types depends on Math, Math depends on Sysutils -> sysutils was initialized
before cthreads but uses a critical section -> cthreads detected this and
raised an error.

The solution was to remove the use of cthreads in the fpmkunit unit, this is
simply wrong: cthreads may only be used in the program uses clause, since
otherwise there is no telling when the unit will get initialized.


We're looking at removing the dependency of Types on Sysutils:
It stands to reason that defining a simple type should not introduce 
exception support.


We were simply lucky since around 2016 when a critical section was
introduced in sysutils initialization code, necessitating the use 
of cthreads before sysutils.



The solution has been committed and solved the errors you were
experiencing...

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

Re: [fpc-devel] cthreads and fpc.cfg?

[Michael Van Canneyt via fpc-devel]

On Wed, 19 Jul 2023, Maxim Ganetsky via fpc-devel wrote:


19.07.2023 3:25, Maxim Ganetsky via fpc-devel пишет:

19.07.2023 0:15, Martin Frb via fpc-devel пишет:

On 18/07/2023 22:56, Martin via fpc-devel wrote:

Using 33dba315366ec3002e062c3aa6dcb15b88356580 (3.3.1)
My fpc.cfg looks like this / any idea?:

Threading has been used before cthreads was initialized.

Make cthreads one of the first units in your uses clause.


tried 757f65d0e283c9fd33f2f99e794203590711c686
still...


JFYI, today I have been testing a build image containing FPC 3.3.1 no 
older than ce37431a3f57ce11da4e8025a12a0eda3e651ff0. Just checked, 
config is OK there. Also compiler itself works fine.


Hmm, I was just lucky, correct config in my case probably generated by 
another FPC version. ;) I see the following output of FPC 3.3.1 binary 
.sh installer:


I am investigating the problem.

The error is logical. What is not logical is that it pops up now.

By all logic, we should have seen this error pop up as early as 2016.

Why it pops up only now is a mystery that we need to solve...

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

Re: [fpc-devel] Error: (3069) Call by var for arg no. xx has to match exactly: Got "ShortString" expected "AnsiString"

[Michael Van Canneyt via fpc-devel]

On Sun, 16 Jul 2023, Maxim Ganetsky via fpc-devel wrote:


16.07.2023 20:08, Michael Van Canneyt via fpc-devel пишет:



On Sun, 16 Jul 2023, Maxim Ganetsky via fpc-devel wrote:


Hello.

Recent changes in FPC `main` led to the following errors when 
building some code in Lazarus tree:


Error: (3069) Call by var for arg no. xx has to match exactly: Got 
"ShortString" expected "AnsiString"


See:

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

Note that the unit which fails to build has {$H-} directive.

Is it a bug in compiler?


No. We're preparing for the unicode RTL.

Part of that was changing string -> shortstring and pchar -> ansichar.

In some rare places I changed string to ansistring in preparation of
unicodestring, in this case it was misplaced since it was a var 
argument. I added an overloaded version, which should fix the 
compilation error.


But I thought that it was possible to assign ShortString to AnsiString. 
Am I mistaken?


It is, but not for a var argument. As it says in the error message 
"Call by var for arg no. xx has to match exactly"


Anyway, please try the fix with the latest fpc.

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

Re: [fpc-devel] Error: (3069) Call by var for arg no. xx has to match exactly: Got "ShortString" expected "AnsiString"

[Michael Van Canneyt via fpc-devel]

On Sun, 16 Jul 2023, Maxim Ganetsky via fpc-devel wrote:


Hello.

Recent changes in FPC `main` led to the following errors when building some 
code in Lazarus tree:


Error: (3069) Call by var for arg no. xx has to match exactly: Got 
"ShortString" expected "AnsiString"


See:

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

Note that the unit which fails to build has {$H-} directive.

Is it a bug in compiler?


No. We're preparing for the unicode RTL.

Part of that was changing string -> shortstring and pchar -> ansichar.

In some rare places I changed string to ansistring in preparation of
unicodestring, in this case it was misplaced since it was a var argument. 
I added an overloaded version, which should fix the compilation error.


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

Re: [fpc-devel] BUG REPORT: Fail to compile when using the out keyword instead of var

[Michael Van Canneyt via fpc-devel]

On Sun, 18 Jun 2023, Dylan Lamb via fpc-devel wrote:


[image: fpcbug.png]



This is not a bug. You're using mode fpc, in which the "out" keyword is not
supported. You have 3 possibilities to activate this:

Use mode objfpc:

{$mode objfpc}

Use mode delphi:

{$mode delphi}

or enable the use of out in mode fpc:

{$modeswitch out}

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

Re: [fpc-devel] Curious about the effect of all the new optimizations....

[Michael Van Canneyt via fpc-devel]

On Wed, 1 Mar 2023, Mattias Gaertner via fpc-devel wrote:


On Wed, 1 Mar 2023 14:10:28 +0100
Sven Barth via fpc-devel  wrote:


[...]
> I can't remember the proverb that Florian used, but it essentially
> boils down to very small changes, individually not amounting to
> much, but which accumulate into a noticable difference when in
> large numbers. 


It's a German proverb: "Mühsam ernährt sich das Eichhörnchen"


Maybe more like "Kleinvieh macht auch Mist" ?


These proverbs come from the "German Farmer & gardeners association"'s 
yearly gift calendar ?


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

Re: [fpc-devel] Unexpected "Range check error while evaluating constants" when compiling for Win64

[Michael Van Canneyt via fpc-devel]

On Mon, 13 Feb 2023, Ondrej Pokorny via fpc-devel wrote:


On 12.02.2023 23:08, Bart via fpc-devel wrote:

On Sun, Feb 12, 2023 at 10:47 PM Jonas Maebe via fpc-devel
 wrote:


Afaik it's because "default" doesn't support qword values, iirc because
of (at least old) Delphi compatibility.

OK, I removed the "default".

Theoretically would that lead to problems when storing the value in
lfm and reading it back using different bitness versions of Lazarus?
Should I even publish such a property?
(I don't think Lazarus has a property editor for HKEY...)


I wouldn't publish the HKEY property but create an own enumeration for it:

TRegKey = (rgClassesRoot, rgCurrentUser, )

and publish this instead. Pro: you can put only valid values into the 
property and object inspector shows you nice enum names instead of strange 
integers.


Then make a simple transformation to HKEY:

RegKeyToHKey: array[TRegKey] of HKEY = (HKEY_CLASSES_ROOT, HKEY_CURRENT_USER, 
...);


Yes, I also think this is the best solution...

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote:


On 02.02.2023 10:22, Michael Van Canneyt via fpc-devel wrote:

On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote:

On 02.02.2023 10:15, Michael Van Canneyt via fpc-devel wrote:

On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote:
I myself cannot think of any real use case of constref other than hacks 
like the FreeAndNil in recent Delphi versions:


procedure FreeAndNil(const [ref] Obj: TObject);

that needs the ref because it changes it to nil (so is not really a 
const - it used to be an untyped var). As a result FreeAndNil allows you 
to happily pass read-only properties to it that are then nilled.


Which is a clear violation of the concept of Const... :/


Exactly.


Probably an ill-advised "fix" to the problem that FreeAndNil accepted an 
untyped var

and you could basically pass anything.


Yes. Solving one problem by creating a different one. The best would be if 
the FreeAndNil declaration alternated between constref and untyped var 
between builds. In that case you would be able to hunt both the issues :)


Seriously, having a [loose] modifier would be much more useful, IMO:

FreeAndNil(var [loose] Obj: TObject);

That would allow you to pass any TObject descendant.


It would solve this problem, but introduces another problem, since it would be
usable anywhere:

Procedure DoSomething(var [loose] Obj: TObject);

var
  a : TSomeObject;

begin
  a:=TSomeobject.Create;
  DoSomething(a);
end;

after DoSomething, A may contain a class that is not a TSomeObject at all,
leading to more problems.

In userspace, the best seems

Function FreeAndNil(Obj : T) : T;

begin
  Obj.Free;
  Result:=Nil;
end;

With automatic type inference for generics, this allows you to do

A:=FreeAndNil(A);

Which is quite acceptable IMO. If you could add inline to the generic
definition the overhead would be minimal.

As it is, FreeAndNil() seems like another candidate for a compiler intrinsic ;-)

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote:


On 02.02.2023 10:15, Michael Van Canneyt via fpc-devel wrote:

On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote:
I myself cannot think of any real use case of constref other than hacks 
like the FreeAndNil in recent Delphi versions:


procedure FreeAndNil(const [ref] Obj: TObject);

that needs the ref because it changes it to nil (so is not really a const 
- it used to be an untyped var). As a result FreeAndNil allows you to 
happily pass read-only properties to it that are then nilled.


Which is a clear violation of the concept of Const... :/


Exactly.


Probably an ill-advised "fix" to the problem that FreeAndNil accepted an 
untyped var
and you could basically pass anything.

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Thu, 2 Feb 2023, Hairy Pixels via fpc-devel wrote:





On Feb 2, 2023, at 3:57 PM, Adriaan van Os via fpc-devel 
 wrote:

- under what circumstances (and in what compiler mode) does FPC pass large (say 1 MB or 1 
GB) "const" parameters by value (which is extremely inefficient) ?
- for what reasons ?

As long as these questions are not addressed and cleared and documented "const" 
parameters are not a useable in actual code.


That’s what I want to know.  There should be a hard rule like records over
X bytes are passed by reference.  In the issue you posted they said they
had a massive performance penalty in their library because const was
passing by value and this makes people like myself paranoid so I’m
inclined to use constref everywhere with larger records.


It depends on the platform ABI, and hence we don't document it.

I don't see your problem, to be honest:

You want to indicate a parameter to a function cannot be changed in its 
implementation.

If you don't care about how it is passed, use const.

If really want a reference to be passed for performance or other reasons, use 
constref.

So you're doing the right thing by using constref.

Couldn't be simpler.

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Thu, 2 Feb 2023, Ondrej Pokorny via fpc-devel wrote:


On 02.02.2023 07:42, Sven Barth via fpc-devel wrote:
The case when you *need* a constant reference. Case in point: the 
passing of TGuid in IInterface.QueryInterface. Delphi code relies on 
it being a reference, but “const” does not guarantee that for all 
platforms.


Maybe I am missing something, could you please explain why 
IInterface.QueryInterface needs constref?


IIRC Joost introduced it at some point, but I don't remember exactly why.

I seem to remember constref was introduced as the equivalent of const * 
parameters in C.
It allows to skip the pointer.


  function TObject.GetInterface(const iid : tguid;out obj) : boolean;

that has a const without ref.

---

I myself cannot think of any real use case of constref other than hacks 
like the FreeAndNil in recent Delphi versions:


procedure FreeAndNil(const [ref] Obj: TObject);

that needs the ref because it changes it to nil (so is not really a 
const - it used to be an untyped var). As a result FreeAndNil allows you 
to happily pass read-only properties to it that are then nilled.


Which is a clear violation of the concept of Const... :/

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Thu, 2 Feb 2023, Sven Barth via fpc-devel wrote:


Am 02.02.2023 um 02:09 schrieb Hairy Pixels:


On Feb 2, 2023, at 4:38 AM, Sven Barth  

wrote:


Which types are passed by-value or by-reference when using const is 
determined by the size of the record and the types of the fields based on 
whatever the corresponding ABI defines (e.g. the x86_64 Sys V ABI is rather 
explicit about some field combinations). The compiler will however not switch 
between passing a specific type once by-value and another time by-reference.
So if the compiler is making the choice using const which is more efficient 
then we should be using const always I would think? What problem does 
constref solve then?


The case when you *need* a constant reference. Case in point: the 
passing of TGuid in IInterface.QueryInterface. Delphi code relies on it 
being a reference, but “const” does not guarantee that for all platforms.


Exactly. That is why they introduced [ref], which serves essentially the same 
purpose as
constref.

https://docwiki.embarcadero.com/RADStudio/Sydney/en/Parameters_(Delphi)#Constant_Parameters

We were way ahead of them on that particular one. 
Benefits of being cross-platform since a long time :-)


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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Wed, 1 Feb 2023, Sven Barth via fpc-devel wrote:


Am 01.02.2023 um 11:30 schrieb Bart via fpc-devel:

I thought that constref would be OK for that (the word constref
suggests to me tah the paramter will be treated (by me) to be a
constant, and that it shall be passed by reference in all cases,
whereas with a const parameter the compiler decides upon the best way
to pass it: by value or by reference).
I tried to find documentation for constref, but all I could find was:
https://wiki.freepascal.org/FPC_New_Features_2.6.0#Constref_parameter_modifier
There it says:
"Note that in general, it should only be used for interfacing with
external code or when writing assembler routines."


“constref” is guaranteed to pass the parameter by reference. And the compiler 
will ensure that it can't be modified as reasonably possible (as with “const” 
there are ways to circumvent this, e.g. by passing around a pointer to the 
parameter, but the general cases are covered).

(B.t.w.: Where can I find the official documentation on constref?)


There is no full documentation for that parameter modifier (someone might 
want to file a bug report for that), but the documentation for “const” ( 
https://www.freepascal.org/docs-html/current/ref/refsu67.html#x183-20700014.4.4 
) contains this:


No need for a bugreport, this already is changed in trunk docs:

https://www.freepascal.org/daily/doc/ref/refsu68.html#x184-20800014.4.4

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Wed, 1 Feb 2023, Hairy Pixels via fpc-devel wrote:





On Feb 1, 2023, at 8:27 PM, Michael Van Canneyt via fpc-devel 
 wrote:

That's exactly what Adriaan is saying. With const the compiler can choose.
With constref, you force it not to copy. But this is not so efficient for
small parameter sizes.


So const will always pass records that are over a certain size by
references?  That’s good to know since “const” is more pleasant to look at
it than constref.  :)


As I wrote: The compiler can choose. 
Whether it will always do what you think it should do is another matter.


It's not for no reason that constref was introduced: to leave the compiler no
choice...

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

Re: [fpc-devel] Question on constref

[Michael Van Canneyt via fpc-devel]

On Wed, 1 Feb 2023, Hairy Pixels via fpc-devel wrote:





On Feb 1, 2023, at 8:16 PM, Adriaan van Os via fpc-devel 
 wrote:

Because, if e.g. the byte-size of a parameter is such that it fits into a CPU 
register, then passing the parameter itself is more efficient than passing a 
reference to it. For large byte-size parameters, const and constref function 
the same. The difference is with small byte-size parameters.


Hmmm I was told otherwise by one of the compiler devs and that I should use 
constref if I want to guarantee it will not be copied. Maybe one of them can 
confirm this….


That's exactly what Adriaan is saying. With const the compiler can choose.
With constref, you force it not to copy. But this is not so efficient for
small parameter sizes.

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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Mon, 16 Jan 2023, Wayne Sherman via fpc-devel wrote:


On Mon, Jan 16, 2023 at 12:16 PM Wayne Sherman wrote:

I need clarification about the auto generated class index
specifiers.  Do they always start at 0 in each descendant
class, or are they unique across all descendant classes?

TBaseObject --> TChild --> TGrandChild

TChild = class(TBaseObject)
...
  published
property Field1: string index 0...
property Field2: string index 8...
  end;

TGrandChild = class(TChild)
...
  published
property Field3: string index 16...  // does this continue at 16
or start at 0 again?
property Field4: string index 24...
  end;


It appears the index specifiers restart at 0 in each descendant class.
Which is why this code works:

procedure TBaseObject.MarkPropertyChanged(AIndex: Integer);
begin
 If Assigned(FBits) then
   FBits.SetOn(GetParentPropCount+(AIndex shr IndexShift));
end;


Yes. The reason is the code generator:

Ideally, every property simply has a unique index specifier.

But when generating classes, the code generator has no way of knowing how
many properties exist in parent classes, so it must start at 0.

(
one could imagine helping the code generator by specifying a start point
per class:
1000
2000
3000
etc.
)



function TBaseObject.IsPropertyModified(Info: PPropInfo): Boolean;
begin
 Result:=Not Assigned(FBits) or FBits.Bits[Info^.NameIndex]
end;

The name list (from which NameIndex gets its value) includes the
published property names of all the parents plus the names in the
current class, so for a REST property in a descendant class with Index
specifiers starting at 0:
 GetParentPropCount+(IndexSpecifier shr IndexShift) = NameIndex


Yes.

This was long ago, but I seem to remember that I changed that code in production, 
so it would use the same mechanism as MarkPropertyChanged, because there were 
published properties not part of the REST scheme, and in that case, the equation does
not hold true (becasue nameindex includes non-REST properties). 
That change does not seem to have made it in FPC.


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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Sun, 15 Jan 2023, Wayne Sherman wrote:


On Sun, Jan 15, 2023 at 9:24 AM Michael Van Canneyt wrote:

On Sat, 14 Jan 2023, Wayne Sherman wrote:


I see a couple of problems TBaseObject.SaveToJSON

1) TBaseObject.SaveToJSON cannot distinguish properties that are part
of the REST protocol from properties that are not part of it.  It only
knows that properties which have been modified are part of the rest
protocol, but properties which have not been modified might be part of
the REST protocol or might not be.  For example, a client receives a
JSON object from a server (via LoadFromJSON) and wants to persist the
complete JSON object to disk, database, or send it to another server.
But, at present, there is no way to save all the properties that are
part of the REST protocol without getting contaminated with non-REST
properties.


The non-REST properties will never be marked as changed, so they will not be
saved.


LoadFromJSON calls StartRecordPropertyChanges and
StopRecordPropertyChanges.  Both of these destroy the change records.
At present, there is no opportunity to save modified records after
loading.  If that was fixed I think it would be a step in the right
direction.


It seems to me we're talking cross-purpose. From my point of view, 
the code works as designed. It has been in use in production since many

years (in fact, since it was committed to FPC).

Can you please make a small example that demonstrates the problem you are
experiencing, so I can look at it ?

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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Sat, 14 Jan 2023, Wayne Sherman wrote:


I see a couple of problems TBaseObject.SaveToJSON

1) TBaseObject.SaveToJSON cannot distinguish properties that are part
of the REST protocol from properties that are not part of it.  It only
knows that properties which have been modified are part of the rest
protocol, but properties which have not been modified might be part of
the REST protocol or might not be.  For example, a client receives a
JSON object from a server (via LoadFromJSON) and wants to persist the
complete JSON object to disk, database, or send it to another server.
But, at present, there is no way to save all the properties that are
part of the REST protocol without getting contaminated with non-REST
properties.


The non-REST properties will never be marked as changed, so they will not be
saved.



2) Lack of control.  With TBaseObject.SaveToJSON it would be nice to
control what is saved (Save all REST properties, or Save modified REST
properties).


It should be easy to add a flag for that.

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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Sat, 14 Jan 2023, Wayne Sherman wrote:


On Sat, Jan 14, 2023 at 12:36 PM Michael Van Canneyt wrote:

On Sat, 14 Jan 2023, Wayne Sherman wrote:

On Sat, Jan 14, 2023 at 10:34 AM Michael Van Canneyt wrote:

On Sat, 14 Jan 2023, Wayne Sherman wrote:

2) Doesn't each object already have the parent properties included in
its own properties by inheritance?


Why this question ?
An object does not know the property count of the parent.


True, but why does it need to know the property count of the parent?

 TBaseClass = class
 private
   FField1: integer;
 protected
   FPropModifiedFlags: TBits;
 published
   property Field1: integer read FField1 write FField1;
 end;

GetTypeData(TBaseClass.ClassInfo)^.PropCount = 1

 TDescendant = class(TBaseClass)
 private
   FField2: integer;
 published
   property Field2: integer read FField2 write FField2;
 end;

GetTypeData(TDescendant.ClassInfo)^.PropCount = 2

TDescendant has two properties (one inherited and one declared
directly) and let's say it can record if any of the properties have
been modified.  So why does it have to know about the number of
properties it inherited vs the properties it declares directly?


Because there may be other published properties that are not part of the
REST protocol. You may for instance decide to add published properties to a
base class that describe where to save the object in a local database.


Ok, that clears up that.  If I understand correctly, the behavior
should be as follows:

(restbase.pp)
In TBaseObject descendants, SaveToJSON only saves object properties
defined directly in the final descendant class and none of the
properties of parent classes.  This is implemented by only marking
properties as modified that are defined directly in the final
descendant class and skipping properties of all parent classes (which
always appear to be unmodified, and thus not saved).  This prevents
properties which are not part of the REST protocol from contaminating
the generated JSON.  It follows that REST protocol properties should
always be defined in the final TBaseObject descendant class (and not
in any base or intermediate classes).



While in practice most REST classes will be the final classes, 
it should be possible to support inheritance in rest classes, 
that is why the 'ParentPropertyCount' exists and is taken into account.


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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Sat, 14 Jan 2023, Wayne Sherman wrote:


On Sat, Jan 14, 2023 at 10:34 AM Michael Van Canneyt wrote:

On Sat, 14 Jan 2023, Wayne Sherman wrote:

2) Doesn't each object already have the parent properties included in
its own properties by inheritance?


Why this question ?
An object does not know the property count of the parent.


True, but why does it need to know the property count of the parent?

 TBaseClass = class
 private
   FField1: integer;
 protected
   FPropModifiedFlags: TBits;
 published
   property Field1: integer read FField1 write FField1;
 end;

GetTypeData(TBaseClass.ClassInfo)^.PropCount = 1

 TDescendant = class(TBaseClass)
 private
   FField2: integer;
 published
   property Field2: integer read FField2 write FField2;
 end;

GetTypeData(TDescendant.ClassInfo)^.PropCount = 2

TDescendant has two properties (one inherited and one declared
directly) and let's say it can record if any of the properties have
been modified.  So why does it have to know about the number of
properties it inherited vs the properties it declares directly?


Because there may be other published properties that are not part of the
REST protocol. You may for instance decide to add published properties to a
base class that describe where to save the object in a local database.

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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Sat, 14 Jan 2023, Wayne Sherman wrote:


On Fri, Jan 13, 2023 at 11:48 PM Michael Van Canneyt wrote:

Markpropertychanged is called in the setter of the properties generated by
the code generator: Check all generated units.


Thanks for your explanations, it is getting more clear how modified
property tracking is being used.

More clarification please.  MarkPropertyChanged offsets the property
changed index (to TBits) by the ClassParent total property count, but
IsPropertyModified does not take this offset into account.  Consider
this example:

TBaseObject --> TGoogleBaseObject --> TSchema --> TMySchema
TBaseObjectClass = Class of TBaseObject;

If the object is TMySchema, in GetParentPropCount the TBits index gets
offset by (see reference code below):
 TBaseObjectClass(TSchema).GetTotalPropCount;
If the object is TSchema, the TBits index gets offset by:
 TBaseObjectClass(TGoogleBaseObject).GetTotalPropCount;

Questions:
1) Since the ClassParent is always cast as TBaseObjectClass isn't this
the same as just TBaseObjectClass(Self.ClassType)?


No. The method is virtual, so the actual descendant's method is called.



2) Doesn't each object already have the parent properties included in
its own properties by inheritance?


Why this question ? 
An object does not know the property count of the parent.





3) Why does MarkPropertyChanged offset the index and
IsPropertyModified does not take the offset into account?


They should be the same. I don't remember why I created the two methods
differently.

Michael.



Reference for above questions:

class function TBaseObject.GetParentPropCount: Integer;
begin
 if (ClassParent=TBaseObject) or (ClassParent=Nil) then
   Result:=0
 else
   Result:=TBaseObjectClass(ClassParent).GetTotalPropCount;
end;

procedure TBaseObject.MarkPropertyChanged(AIndex: Integer);
begin
 If Assigned(FBits) then
   FBits.SetOn(GetParentPropCount+(AIndex shr IndexShift));
end;

function TBaseObject.IsPropertyModified(Info: PPropInfo): Boolean;
begin
 Result:=Not Assigned(FBits) or FBits.Bits[Info^.NameIndex]
end;




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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Fri, 13 Jan 2023, Wayne Sherman via fpc-devel wrote:


Is there a better way to track changed TBaseObject properties (and get
rid of property index declarations)?


Not to my knowledge. If there had been, I would have used it.
The advantage of the index as opposed to using a custom assigned ID per
property is that the compiler enforces them and stores them in RTTI.
thus they are a safe mechanism.



Lazarus knows which properties on a form have been changed from their
default value and only properties which do not match the default are
saved in the lfm file.  Can the same thing be used with TBaseObject
properties?


No, since you don't have a 'default' value as in the lazarus sense: 
In lazarus, the default is a default as declared in the class.


In rest, the default value is what you got from the server.
(or empty in case you create a new object)

Your misunderstanding is that you consider any write of a property a
modification, as in Lazarus.

But in rest, only writes that happen after the load from the server 
are modifications.


Hence the stoprecording/startrecording which seems wrong to you, but is in
fact correct and as designed.

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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Fri, 13 Jan 2023, Wayne Sherman via fpc-devel wrote:


Some related misunderstandings:

1) When StopRecordPropertyChanges is called it destroys all the
change records (stored in TBits) in which case SaveToJSON saves ALL
the properties even if they were not loaded or modified previously.


That is why StopRecordPropertyChanges is called before loading.




2) Nothing in restbase.pp or TBaseObject calls MarkPropertyChanged
anyway, so no properties will get marked as modified during
TGoogleRestDescription.LoadFromJSON.

procedure TBaseObject.MarkPropertyChanged(AIndex: Integer);
begin
 If Assigned(FBits) then
   FBits.SetOn(GetParentPropCount+(AIndex shr IndexShift));
end;


Markpropertychanged is called in the setter of the properties generated by
the code generator: Check all generated units.

TGoogleRestDescription is readonly, it does not need that mechanism.



3) Both MarkPropertyChanged (above) and IsPropertyModified (below)
require the properties declarations to have indexes and
TGoogleRestDescription does not have indexes on any of its properties.


See above, point 2.

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

Re: [fpc-devel] restbase.pp LoadFromJSON calling StopRecordPropertyChanges;

[Michael Van Canneyt via fpc-devel]

On Fri, 13 Jan 2023, Wayne Sherman via fpc-devel wrote:


I am trying to check the googleapiconv "TGoogleRestDescription" object
contents (which is descended from restbase TBaseObject) by using
"SaveToJSON".  But it always saves an empty object, even when the
properties have values assigned to them (via LoadFromJSON).

https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/googleapi/generator/googlediscoverytopas.pp#L303

SaveToJSON calls SavePropertyToJSON which checks IsPropertyModified:

https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/fcl-web/src/base/restbase.pp#L1310

If the property has not been modified it is skipped and not saved.
But ALL of the properties are being skipped since none of them have
been marked as modified (even though they were actually modified
during the loading).


No, modifying means changed in user code after load.

The life cycle is one of

a/
- Load data from server. Data is 'unmodified'.
- Optionally modify properties
- If data was modified, send patch to server.

b/
- Create object
- Set properties
- Send post to server.

So the current behaviour is correct.

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

Re: [fpc-devel] Incorrect hint (5023) "unit not used", if unit is only used in a conditional compiler expression (like: {$IF ..})

[Michael Van Canneyt via fpc-devel]

On Fri, 13 Jan 2023, Bart via fpc-devel wrote:


Consider the follwoing program:
===
program test;

uses
 Version;

begin
 {$if TheVersion >= 1}
 writeln('Version 1 or higher');
 {$else}
 writeln('Version < 1');
 {$endif}
end.
===
unit version;

interface
const
 TheVersion = 1;

implementation

end.
===
Compile with -vh
You get the hint:  Unit "version" not used in test

This is obviously not true, without the unit version, the program won't compile.

Should I report this as a bug?


Yes.

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

Re: [fpc-devel] Unicode RTL for FPC

[Michael Van Canneyt via fpc-devel]

On Fri, 13 Jan 2023, Tomas Hajny via fpc-devel wrote:


On 2023-01-13 11:22, Mattias Gaertner via fpc-devel wrote:

On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:


[...]
Should have been

make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler


This does not install the new compiler, so I used the compiler/ppcx64
exe directly to compile a program.

I see in the -va output:
[0.008] Hint: Start of reading config file /etc/fpc-unicodertl.cfg
[0.008] Handling option "-dUNICODERTL"
[0.008] Interpreting option "-dUNICODERTL"
[0.008] Macro defined: UNICODERTL
[0.008] Handling option "-Municodestrings"
[0.008] Interpreting option "-Municodestrings"
[0.008] Macro defined: FPC_UNICODESTRINGS
[0.008] Macro defined: UNICODE
[0.008] Hint: End of reading config file /etc/fpc-unicodertl.cfg

But then it uses the wrong unit paths:
[0.012] Using unit path: /usr/lib/fpc/3.3.1/units/x86_64-linux/httpd22/

It should be:

[0.012] Using unit path:
/usr/lib/fpc/3.3.1/units/x86_64-linux-unicodertl/rtl/

My /etc/fpc.cfg contains:

# searchpath for units and other system dependent things
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/*
-Fu/usr/lib/fpc/$fpcversion/units/$fpctarget/rtl


What does your /etc/fpc-unicodertl.cfg contain? The correct paths should be 
there...


Nono, there was an error in calculating $fpctarget. It is fixed.

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

Re: [fpc-devel] Unicode RTL for FPC

[Michael Van Canneyt via fpc-devel]

On Fri, 13 Jan 2023, Mattias Gaertner via fpc-devel wrote:


On Sun, 8 Jan 2023 08:46:37 +0100 (CET)
Michael Van Canneyt via fpc-devel 
wrote:


[...]
Should have been

make install SUB_TARGET=unicodertl PP=path/to/the/new/compiler


This does not install the new compiler, so I used the compiler/ppcx64
exe directly to compile a program.

I see in the -va output:
[0.008] Hint: Start of reading config file /etc/fpc-unicodertl.cfg
[0.008] Handling option "-dUNICODERTL"
[0.008] Interpreting option "-dUNICODERTL"
[0.008] Macro defined: UNICODERTL
[0.008] Handling option "-Municodestrings"
[0.008] Interpreting option "-Municodestrings"
[0.008] Macro defined: FPC_UNICODESTRINGS
[0.008] Macro defined: UNICODE
[0.008] Hint: End of reading config file /etc/fpc-unicodertl.cfg

But then it uses the wrong unit paths:
[0.012] Using unit path: /usr/lib/fpc/3.3.1/units/x86_64-linux/httpd22/

It should be:

[0.012] Using unit path:
/usr/lib/fpc/3.3.1/units/x86_64-linux-unicodertl/rtl/


I am aware of this one.

This is fixed since some time but not yet pushed.

I will push this change together with many others later today.

I'm busy fixing pas2js resolver failures :-)

All packages compile using unicode meanwhile, json/xml work fine, 
pas2js for the most part as well, just the resolver needs some work. 
Down to 3 errors in the testsuite. Coming from over 2000 failures initially :/


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

Re: [fpc-devel] Why: "Can't take the address of constant expressions" here?

[Michael Van Canneyt via fpc-devel]

On Wed, 11 Jan 2023, Bart via fpc-devel wrote:


Given the following program (an excerpt form a test program for a
bugreport about the fpwidestring unit):

===
program test;
{$codepage utf8}
{$mode objfpc}
{$h+}

uses
 FpWideString;

var
 WSource: WideString = 'source';
 USource: UnicodeString = 'source';
 WDest: WideString = '' ;
 UDest: UnicodeString = '';
 ASource: AnsiString = 'source';
 ADest: AnsiString = '';
 P: array[0..99] of AnsiChar;

begin
 with WideStringManager do
 begin
   writeln(1);
   Wide2AnsiMoveProc(pwidechar(WSource),RawByteString(ADest),
CP_UTF8, Length(WSource));
   writeln(2);
   Ansi2WideMoveProc(PChar(ASource), CP_UTF8, UDest,
Length(ASource));   //<< test.lpr(24,53) Error: Can't take the address
of constant expressions (caret behind UDest)
end.

C:\Users\Bart\LazarusProjecten\bugs\Console\fpwidestring>fpc test.lpr
Free Pascal Compiler version 3.3.1 [2022/10/11] for i386
Copyright (c) 1993-2022 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling test.lpr
test.lpr(24,53) Error: Can't take the address of constant expressions
...
UDest is of the wrong type here, it compiles fine with WDest (WideString).
I just don't understand the "Can't take the address of constant expressions"
I would have expected something like "Call by var for arg no. 3 has to
match exactly: Got "UnicodeString" expected "WideString""


I think that what happens is that the compiler sees that it can convert
widestring to unicodestring and allows a conversion, so it inserts a 
conversion node, but the result of the conversion is a constant expresson 
so it generates an error in a later stage of compilation.


But my knowledge is limited, someone else will need to confirm this.

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