Re: [fpc-devel] make OPT= OPTFPC= NEWOPT=
On 10/6/23 16:11, Marco van de Voort via fpc-devel wrote: OPT= always to my best knowledge NEWOPT is opt only for later cycles and the rest, iow not for the first FPC bootstrap cycle (that might be started with an older compiler version). So it is for additional options that are not supported by the bootstrap compiler, but are supported by the newer compiler. It might be a good idea to have a wiki page describing all the variables that go in the makefile, i always end up using Google to search the wiki for make invocations of the the partial variables i remember. Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] rtl_do_close is not called in the embedded and freertos targets
Hi all, I was looking at the RTL code to see if the embedded target could be used as a workaround for unsupported OSes (e.g. some custom kernel) and noticed that there are some global function pointers used as callbacks for system-specific functionality - which is neat. However i also noticed that the do_close procedure in sysfile.inc doesn't do anything (it is empty) and nothing calls the rtl_do_close callback (the other do_xxx procedures do call the equivalent rtl_do_xxx if they are set). I don't have any actual program to test that out, it was just something i noticed by reading the code but it seems like a bug to me as i can't see a way to close a file handle otherwise. The code can be seen here: https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/embedded/sysfile.inc?ref_type=heads#L25 My guess is that the code above should call rtl_do_close defined here: https://gitlab.com/freepascal.org/fpc/source/-/blob/main/rtl/embedded/system.pp?ref_type=heads#L108 ...like it is done in the other procedures in the sysfile.inc file. FWIW the code for freertos seems to be exactly the same - empty do_close despite there being a rtl_do_close callback (which isn't used anywhere). Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] WebAssembly compilation problems - Wasm32 symbol xxx without index value error
On 3/28/23 02:12, Michalis Kamburelis via fpc-devel wrote: We're experimenting with compiling Castle Game Engine using FPC WebAssembly target. [..] x3dcamerautils.pas(344,0) Error: Wasm32 symbol X3DFIELDS$_$TSFROTATION_$__$$_SETVALUE$TGENERICVECTOR4 without index value error FWIW i experienced the same problem when trying to build my Post Apocalyptic Petra game some months ago as i posted back then: https://lists.freepascal.org/pipermail/fpc-devel/2022-July/044721.html Sadly i never found a workaround but it does sound like an issue with whatever generates the wasm code itself instead of the assembler - as mentioned in the message above, trying other assemblers produced different errors. The errors also seem to be more of a symptom than a cause as, as you also figured out, trying to fix things just move the error around and it happens in various places that do not seem to have much in common. But i didn't look further into it because i was busy with other stuff. I mainly wanted to make the wasm build for fun and perhaps to put it on the itch.io landing page if it worked fine but that was very low priority. Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Is this supposed to work (generic)?
On 3/26/23 14:30, Martin Frb via fpc-devel wrote: >generic GenLinkedList = class > Data: D; > Next: T; >end; >TSome = class; >TSome = class(specialize GenLinkedList); AFAIK "specialize" essentially "pastes" the parameters (after some checking) so it'd be as if you had declared... TSome = class; GenLinkedList = class Data: Integer; Next: TSome; end; TSome = class(GenLinkedList); ...which is perfectly valid Free Pascal code. Also AFAIK the reason the others do not work is because when specialize is called, TFoo and TBar are not known to the compiler yet, but the forward declaration with TSome tells to the compiler that it is a class. I guess it *is* a bit inconsistent that you can use the name of the type you are declaring during the declaration itself for classes - like "TFoo = class Foo: TFoo; end" - or target a type with a pointer before the targeted type is even known and yet specialization needs to know ahead of time everything, but that's how things are :-P Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Additional generic type constraints
On 2/22/23 15:11, Sven Barth wrote:
Kostas Michalopoulos via fpc-devel <mailto:fpc-devel@lists.freepascal.org>> schrieb am Mi., 22. Feb. 2023,
10:37:
> Because Delphi doesn't have them and when constraints were
implemented
> they were implemented for Delphi compatibility.
Can they be added? The original announcement ~13 years ago mentioned
that those could be added at some point. "object" and "operator X"
would
be quite useful for me.
Some additional constraints might be added. However I have none of them
planned currently and enough other things to do.
I tried to use constraints at some point in my code but they proven too
limited in functionality - the biggest issue i faced was that i
couldn't
use a specialization with a forward declared class (which is the entire
point of the forward declaration). For example i have a generic
collection that only works on TSerializable subclasses so i gave it
that
constraint, but in another unit i need to define a specialization
for it
before it was defined (so the class was available with a forward class
declaration) since that specialization also needs to be used by the
class itself. In general it seems like having constrained generic work
with a tree structure of derived types that use the generic itself is
impossible.
Wouldn't storing a list of "specializations to confirm later in this
unit" work (with later being when the class is actually defined in the
unit)? The language already has forward declarations for a bunch of
other things.
Forward declarations can not be used for constraints, because a
specialization of the generic might be used before the forward declared
type is fully defined and the compiler *must* be able to check whether
the parameter in question is compatible at the time the specialization
is declared.
Regards,
Sven
That is what the compiler does now, but can't it be changed to treat
constraints that use forward declarations as unconstrained (at least as
far as these forward declarations are concerned) until the moment they
are declared and validate those constraints at that point?
After all the code below does work if there is no constraint despite the
specialization being used before the forward declaration:
program Test;
{$MODE OBJFPC}{$H+}
type
TProvidesFoo = class
function Foo: Integer; virtual; abstract;
end;
// The following with a constraint could be instead:
// generic TGetFoo = class
generic TGetFoo = class
Wrap: T;
function GetFoo: Integer;
end;
type
TForwardClass = class;
// Instead of making the test here, add it to a list to check later...
TFCHasFoo = specialize TGetFoo;
procedure DumpFoo(FCHasFoo: TFCHasFoo);
begin
Writeln(FCHasFoo.GetFoo);
end;
function TGetFoo.GetFoo: Integer;
begin
Result:=Wrap.Foo;
end;
type
// ...and when this is declared check the if any of the remaining
// checks in the list will be valid or not and remove it from the list
TForwardClass = class(TProvidesFoo)
function Foo: Integer; override;
end;
function TForwardClass.Foo: Integer;
begin
Result:=42;
end;
var
FC: TForwardClass;
HF: TFCHasFoo;
begin
HF:=TFCHasFoo.Create;
HF.Wrap:=TForwardClass.Create;
DumpFoo(HF);
HF.Wrap.Free;
HF.Free;
end.
At the end of the day this isn't a major flaw, after all if the expected
functionality wasn't there (e.g. the generic code tried to access
something the type used in the specialization didn't provide) you'd
still get a compile error anyway, though it does feel a bit like there a
hole in Free Pascal's type safety here (e.g. imagine passing a type to a
specialization that happens to have the same function call so the code
compiles but the call does something different than what you'd expect).
Kostas
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Additional generic type constraints
Because Delphi doesn't have them and when constraints were implemented they were implemented for Delphi compatibility. Can they be added? The original announcement ~13 years ago mentioned that those could be added at some point. "object" and "operator X" would be quite useful for me. I tried to use constraints at some point in my code but they proven too limited in functionality - the biggest issue i faced was that i couldn't use a specialization with a forward declared class (which is the entire point of the forward declaration). For example i have a generic collection that only works on TSerializable subclasses so i gave it that constraint, but in another unit i need to define a specialization for it before it was defined (so the class was available with a forward class declaration) since that specialization also needs to be used by the class itself. In general it seems like having constrained generic work with a tree structure of derived types that use the generic itself is impossible. Wouldn't storing a list of "specializations to confirm later in this unit" work (with later being when the class is actually defined in the unit)? The language already has forward declarations for a bunch of other things. Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
[fpc-devel] Wasm/embedded target compilation error
Hi all, I was trying to use the Wasm/embedded target to port a game i made some time ago[0] to WebAssembly to run inside a browser, but i am getting a bunch of errors that i can't figure out the issue. When compiling with the embedded wasm assembler i get errors like: SndEmit.pas(171) Error: Wasm32 symbol RESMAN/home/badsector/.local/bin/fpcTRESOURCEMANAGER_$__$$_GETRESOURCE$ANSISTRING$$TRESOURCE without index value error SndEmit.pas(171) Error: Wasm32 symbol SNDDRV/home/badsector/.local/bin/fpcTSOUNDDRIVER_$__$$_SETCHANNELCLIP$LONGINT$TSOUNDCLIP$BYTE without index value error (more errors) However i'm not sure if it is the internal assembler issue because using, e.g. llvm-mc-12 i get other errors like: ./Engine/Misc.wat:7340:3: error: symbol MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing .functype call MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT ^ ./Engine/Misc.wat:7670:3: error: symbol MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT missing .functype call MISC$_$TSTRINGKEYVALUESET_$__$$_INDEXOFKEY$ANSISTRING$$LONGINT Trying other assemblers i get other errors too, e.g. wabt/wasa displays a bunch of "stream read error" messages and then fails to link. Does anyone have any idea about what is wrong? This is running on Linux with a custom built crosscompiler from latest git (last commit is 6915cd9b269649ca945a4fc952ee7dedb1b38b85 - Thu Jul 21 14:01:50). I've stripped out the game's sources to only contain the units that i try to compile, you can get it and try to reproduce the issue from here (the archive is ~660KB): http://runtimeterror.com/pages/badsector/nyan/gimme/papwasm.tar.xz Just type ./makewasm.sh (the script uses -Awasm here but can be changed to try other assemblers). Note that obviously this wont build since it is missing any wasm-specific functionality since i never got to the point where the "cross platform" units compile properly to start writing the wasm-specific stuff. Kostas [0] https://bad-sector.itch.io/post-apocalyptic-petra ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
On 5/11/2021 4:09 AM, Ryan Joseph via fpc-devel wrote: On May 10, 2021, at 5:59 PM, Kostas Michalopoulos via fpc-devel wrote: You do not need any special language feature for that, you can simply do something like ReleaseLater(TObject.Create) yes but we can't get back the reference. It's a small thing but making this possible as return type means we can chain the calls together and make it a one line statement. It's just a nice thing from Objective-C which we use heavily to manage memory and it works very well. How about function ReleaseLater(Obj: TObject): TObject that simply returns Obj? (though TBH i can't say i am a fan of these chains from a readability perspective). Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Defer keyword
On 5/8/2021 8:27 PM, Ryan Joseph via fpc-devel wrote: That was a bad example. It's for ANY class really. o := TObject.Create.AutoRelease; Then next event cycle the autorelease pool frees all the objects added to it. Very simple but effective however we can't do this in Pascal without a new permissive return type. You do not need any special language feature for that, you can simply do something like ReleaseLater(TObject.Create) and have ReleaseLater and ReleaseQueuedObjects procedures in a shared unit like procedure ReleaseLater(Obj: TObject); procedure ReleaseQueuedObjects; and have ReleaseQueuedObjects called on app idle. LCL already has something like that with TApplication.ReleaseComponent but, as the name implies, it is only for TComponent instances. However nothing prevents you from making your own, it is just a few lines of code and certainly an app with flow complex enough to need such a construct wont be bothered by a few additional lines for this. You could even use type helpers to make it look like a method :-P. Kostas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Allow object type property getter to expose a field as one of its base/parent types (patch included)
Any further thoughts on this? I am already using it in a new project for quite some time now and it has proven to be very useful in several cases by exposing read only views of the same container that is used internally by classes without additional boilerplate and with fast access and rtti availability. TBH I've found it so useful that even if it isn't included I'll maintain the patch myself (it is tiny and the relevant code doesn't seem to be modified frequently anyway :-P), but I think it is a very useful feature for everyone because of what it enables you to do (see example in my last message). Not having it feels like going back to pre-generics FP or pre-dynamic arrays Delphi; sure, you do not need the functionality, but it is better when the compiler enables you to avoid busywork and let you focus on more important parts :-P Kostas On Sun, Jun 14, 2020, 04:00 Kostas Michalopoulos wrote: > On Sat, Jun 13, 2020 at 12:07 PM Sven Barth via fpc-devel > wrote: > > I'm against it. It would essentially mean that you can't use the same > > field for the setter or that you'd need to go through a method. > > Exchanging one restriction (can't use a base class for the property) for > > another (can't use the same field for the setter) isn't worth it > > especially as you can avoid performance issues by using a getter method > > that is declared inline (the only case where this won't help is if you > > access it using RTTI, but one call more or less doesn't really change > > much anyway). > > These two restrictions are not equal, using a setter method is much > more common than using a getter that accesses the field directly. Also > there is no exchange since you cannot use a property with a base type > as a setter for the base field. None of this functionality already > exists, this patch does not introduce any new restriction, it only > removes an existing one (which is even inconsistent since in other > places you can use values as their base type when the base type is > needed). > > Performance-wise inlining doesn't always work (more often than not the > compiler fails to inline methods, especially when nesting inlines) and > so it cannot be relied upon. In addition, using a getter method does > change the RTTI data which is a significant difference. > > To give you an idea on how i'm using this, i have a generic object > type (not class) that provides a read only view of a collection and a > mutable view that extends it, like this: > > generic TDynArrayView = object ... > generic TDynArray = object(specialize TDynArrayView) ... > > This allows me to use a property like > > property Items: specialize TDynArrayView read FItems; // FItems is > TDynArray > > that always provides direct access to the items but without the API > allowing any modifications that ensures all modifications to the > collection itself will be done through the methods of the class that > provides the property but all accesses will have minimum overhead. > > The RTTI data is also important because i have a custom serialization > system that tries to automate as much as possible with minimal > hand-holding (i also use custom attributes for this). All objects are > assumed to descent from a TRootObject object that provides functions > like SerializeToStream/DeserializeFromStream and this does deep > de/serialization (ie. serializes all objects, not just just the root > one). > > This takes advantage of getter-only field-access properties to assume > that they are meant to also be serialized and owned by the object > itself (which is a safe assumption for most objects, custom attributes > can be used to change the behavior) so when deserializing, it writes > to those getter-only field-access properties directly. The implication > of this is that the address of the field must be available and thus an > getter function wouldn't work (before doing the patch i did try to > take the offset of the field variable and store it in a custom > attribute as a workaround, but it didn't work since parameters to > custom attributes do not seem to be able to do that - and besides i'm > not a fan of this since it adds extra noise to the declaration and > custom attributes seem to be unable to have any statically allocated > data and you need to allocate new instances just to access their data > - though that is another issue that i have with custom attributes in > general). > > What the above means is that i can have two objects like > > TSomething = class(TRootObject) ... > > TAnother = class(TRootObject) > private > FSomething: TSomething; > published > property Something: FSomething read FSomething; > end; > > and then when i do Another.SerializeToStream(SomeStream) and > Another.DeserializeFromStream(SomeStream) i can have the TSomething > instance automatically be stored and recreated without any additional > hand-holding boilerplate code (you need to provide a default Create > constructor, but this is basically the same requirement like >
Re: [fpc-devel] Advanced objects
There should be at least support for operators. I have a custom dynamic array object type (i use objects instead of classes to avoid unnecessary heap allocations) which would benefit a lot from such support. I worked around not having management operators by putting the data fields and core functionality inside a generic advanced record which implements these operators and then using that inside the object (so the values do get released automatically when the object itself is released), but i also need support for at least the equality operator as the dynamic array object has an IndexOf method that uses that and it cannot be used with other dynamic arrays (so i cannot have a dynamic array object which itself contains dynamic array objects because i cannot provide a = operator for the dynamic array object itself). ___ fpc-devel maillist - fpc-devel@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] Advanced objects
Hi, I'd also like to repeat that question since i was just trying to use management operators for a generic object type (not class, not record) that i want it to automatically initialize/shutdown itself (right now i'm doing it manually but i'd prefer it if the compiler would do that for me) and found that bug too. Kostas On Mon, Mar 23, 2020 at 10:43 AM Ryan Joseph via fpc-devel wrote: > > Checking in on old bug report for "advanced objects" which was marked as > acknowledged on the tracker. Was there ever any discussion of this and > possibility of it being applied? I don't think it caused any controversy so I > was hoping to get to use it some time soon. :) > > https://bugs.freepascal.org/view.php?id=36350 > > Regards, > Ryan Joseph > > ___ > 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] Allow object type property getter to expose a field as one of its base/parent types (patch included)
On Sat, Jun 13, 2020 at 12:07 PM Sven Barth via fpc-devel wrote: > I'm against it. It would essentially mean that you can't use the same > field for the setter or that you'd need to go through a method. > Exchanging one restriction (can't use a base class for the property) for > another (can't use the same field for the setter) isn't worth it > especially as you can avoid performance issues by using a getter method > that is declared inline (the only case where this won't help is if you > access it using RTTI, but one call more or less doesn't really change > much anyway). These two restrictions are not equal, using a setter method is much more common than using a getter that accesses the field directly. Also there is no exchange since you cannot use a property with a base type as a setter for the base field. None of this functionality already exists, this patch does not introduce any new restriction, it only removes an existing one (which is even inconsistent since in other places you can use values as their base type when the base type is needed). Performance-wise inlining doesn't always work (more often than not the compiler fails to inline methods, especially when nesting inlines) and so it cannot be relied upon. In addition, using a getter method does change the RTTI data which is a significant difference. To give you an idea on how i'm using this, i have a generic object type (not class) that provides a read only view of a collection and a mutable view that extends it, like this: generic TDynArrayView = object ... generic TDynArray = object(specialize TDynArrayView) ... This allows me to use a property like property Items: specialize TDynArrayView read FItems; // FItems is TDynArray that always provides direct access to the items but without the API allowing any modifications that ensures all modifications to the collection itself will be done through the methods of the class that provides the property but all accesses will have minimum overhead. The RTTI data is also important because i have a custom serialization system that tries to automate as much as possible with minimal hand-holding (i also use custom attributes for this). All objects are assumed to descent from a TRootObject object that provides functions like SerializeToStream/DeserializeFromStream and this does deep de/serialization (ie. serializes all objects, not just just the root one). This takes advantage of getter-only field-access properties to assume that they are meant to also be serialized and owned by the object itself (which is a safe assumption for most objects, custom attributes can be used to change the behavior) so when deserializing, it writes to those getter-only field-access properties directly. The implication of this is that the address of the field must be available and thus an getter function wouldn't work (before doing the patch i did try to take the offset of the field variable and store it in a custom attribute as a workaround, but it didn't work since parameters to custom attributes do not seem to be able to do that - and besides i'm not a fan of this since it adds extra noise to the declaration and custom attributes seem to be unable to have any statically allocated data and you need to allocate new instances just to access their data - though that is another issue that i have with custom attributes in general). What the above means is that i can have two objects like TSomething = class(TRootObject) ... TAnother = class(TRootObject) private FSomething: TSomething; published property Something: FSomething read FSomething; end; and then when i do Another.SerializeToStream(SomeStream) and Another.DeserializeFromStream(SomeStream) i can have the TSomething instance automatically be stored and recreated without any additional hand-holding boilerplate code (you need to provide a default Create constructor, but this is basically the same requirement like TPersistent). I also have a THidden custom attribute which is used to mark published properties that are not to be exposed to the UI. Also note that i use both of the above cases with classes like generic TItemCollectionView = class(TRootObject) ... generic TItemCollection = class(specialize TItemCollectionView) ... Which allows me to automatically de/serialize collections owned by objects without any additional custom code (these two classes actually wrap the TDynArray generic objects i mentioned above). So basically as you see not only inline functions aren't equivalent (they change the RTTI data, they can potentially be slower - especially when considering value types like objects) but i'm actually having two real use cases for this functionality. I cannot think of a use case for the restriction you mention about allowing to write to the setter (and again, that wouldn't make sense logically either - you can "get" a base type value from a derived type value, but nowhere in the language you can "put" a base type value to a derived type value
[fpc-devel] Allow object type property getter to expose a field as one of its base/parent types (patch included)
Hello,
I'd like to add a small feature for property getters to allow
themselves be exposed as a base type of the real field. Example:
===
program ExposeDerivedAsBase;
{$mode objfpc}
type
TBase = class
end;
TDerived = class(TBase)
end;
TSomething = class
private
FProp: TDerived;
public
property Prop: TBase read FProp;
end;
begin
end.
===
The reasoning for this patch is to expose fields directly, without any
additional overheads while being able to hide the real type that the
object uses internally.
One use on a project that i'm currently working on is collections that
are implemented as two classes, one base class that provides a
read-only view of the items in the collection and a derived class that
provides read-write access (this is similar to how C# has List
implement IReadOnlyList but using a class instead). This approach
is actually implemented in two collections, one that uses
object types so that the collection data can be embedded inside other
types (as opposed to creating separate objects on the heap) and one
that uses class types that wraps around the object type (this is
mainly to be able to expose the collection to RTTI for a custom
serialization system i'm working on that relies on properties and
custom attributes for its functionality).
You can find a Mantis entry with the patch here:
https://bugs.freepascal.org/view.php?id=37175
This basically adds an additional check in
add_getter_or_setter_for_sym when the call to compare_defs doesn't
return an adequate value to see if the relevant defs are compatible
objects, which should not introduce any additional overhead in
existing code (initially i considered modifying compare_defs_ext but i
noticed that it is used in several places so i found this special case
safer).
Kostas Michalopoulos
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Re: [fpc-devel] FPC 3.2.0RC1 released!
Hm, for me the new compiler produces slightly slower results. The difference is tiny, but consistent. I use my raytracing benchmark from here: http://runtimeterror.com/tools/raybench/ The results on my AMD Ryzen 3700X are: FPC 3.0.4: 3.984 seconds FPC 3.2.0RC1: 4.047 seconds As i wrote, the difference is tiny, but over several runs it is pretty much consistent. Note that these are for 32bit Windows executables. Also i'm using the Lazarus-bundled build mentioned by Martin Frb above. On Tue, Mar 31, 2020 at 11:59 PM Florian Klämpfl wrote: > Am 31.03.20 um 05:55 schrieb Joao Schuler: > > Just tested with my own neural networks API and I can confirm that it > works! > > Environment: WIN10 64bits AVX > > > > Tested with: > > > https://github.com/joaopauloschuler/neural-api/blob/master/examples/SimpleImageClassifier/SimpleImageClassifier.lpr > > > > > > In this test, there is a performance gain (speed) against 3.0.4 at about > 9%. > > Do you have numbers in comparison with trunk? > > ___ > 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
