Re: [fpc-pascal] Managed record types

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Sa., 2. Nov. 2024, 18:47:

> when I make a record type managed by adding an `Initialize` operator
> according to [1], can I rely on the record being initialized at the
> beginning of a function in which the record is the function result?
>
> Example:
>
> type TRec = record
>   // whatsoever
>   class operator Initialize(var aRec: TRec);
> end;
>
> function DoSomething: TRec;
> begin
>   // < can I assume that `Result` is initialized when the function is
> entered?
>   // more code
> end;
>
> [1] https://wiki.freepascal.org/management_operators


As with any managed type result the Result variable will be initialized
*outside* of the function and passed in as a var-parameter. Depending on
the code and due to how the compiler manages temporary variables involved
in this, this can lead to your code receiving a Result variable upon entry
that had been used by a previous call.

So to be on the safe side assign a Default(YourType) to it (needs current
FPC 3.3.1 to work correctly) or use a local variable of the same type and
overwrite the Result.

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

Re: [fpc-pascal] type helpers in trunk

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Sa., 2. Nov. 2024, 16:14:

> Has something changed for type helpers in fpc trunk ? I don 't see a note
> of it in
> . I have code that
> compiles with 3.2.2, but the
> trunk compiler doesn't recognize (or doesn't accept) dot operations on the
> type. Very strange.
>

Please provide an example.

Regards,
Sven

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

Re: [fpc-pascal] Generic type helper

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Do., 31. Okt. 2024, 18:36:

> a quick question: how do I define a generic type helper?
>

You don't. FPC doesn't support them yet.

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

Re: [fpc-pascal] Understanding error messages in static linking

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Di., 20. Aug. 2024, 18:16:

> And this is the point where I'm completely stuck. Is there anything I can
> try or is it just impossible to create an .exe which doesn't depend need
> the libcrypto DLL?
>
> Please, I don't want to discuss the pros and cons about static linking.
> There are no high-security demands I have to satisfy. I'd just like to
> understand what I'm doing wrong.
>

The internal linker does not support static libraries created by MSVC. Try
the external linker using -Xe or use GCC compiled libraries.

Regards,
Sven

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

Re: [fpc-pascal] Library packages

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 28. Okt. 2024, 08:27:

> Can someone tell me what the status is of Library packages, aka "Delphi
> packages" ? I found the
> WIki  but it looks like a
> preliminary document.
>

Compile time usage of dynamic packages is implemented and is in theory
working for all darwin targets, the Windows targets as well as
x86_64-linux, however the functionality is not yet enabled by default,
because the build system can not yet generate the packages required.
What is missing is support to load additional packages at runtime.


> My questions
>
> 1. For MacOS, are there any differences at the Mach-O level between a
> dynamic library and a library
> package ? Are different linking switches used ? Which ones ?
>

Dynamic packages are essentially normal libraries. I'm not aware of any
special options used compared to ordinary libraries.


> 2. Are there any differences at the FreePascal RTL level ? What compiler
> building options govern this ?
>

The main difference is that a program or library compiled without dynamic
packages will each have a statically linked copy of the RTL (and any other
code it uses). If a binary uses dynamic packages then the binary itself
will not contain code that is contained in one of the used runtime
packages. Binaries are relatively free to decide which packages it uses,
except for the RTL package which always must be used if packages are to be
used (because the core units like System then need to recide in a separate
library, so that other packages and the main binary can use them).
The options involved are -Fpxxx to set the path to search for pcp files
(the metadata equivalent of a ppu for dynamic packages) and -FPxxx to
specify which packages to use.


> Probably there are differences for Lazarus too, but my first interest are
> the low-level changes.
>

Lazarus currently does not support dynamic packages, because for Lazarus to
profit from this, loading at runtime needs to be implemented.

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Nikolay Nikolov via fpc-pascal  schrieb am
Mo., 21. Okt. 2024, 08:32:

> 2) record types (as opposed to class), which can live on the stack and
> have a pass-by-value semantics. FPC trunk supports advanced records, so you
> get C++-style copy constructors.
>

Advanced records are already supported since 2.6. What you mean is records
with management operators, but even those are already supported since 3.2.
;)

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

Re: [fpc-pascal] How do I pass a call back Class and its method to an external library *.so file writting in C++

[Sven Barth via fpc-pascal]

Dennis via fpc-pascal  schrieb am Mo., 21.
Okt. 2024, 05:09:

>
>
>> I am expected to create and pass an instance of such class
>> ApiProxyWrapperReply in my calling program
>>   via a function
>> void SPAPI_RegisterApiProxyWrapperReply(ApiProxyWrapperReply*
>> apiProxyWrapperReply);
>>
>> and the external library will then call the various methods of
>> ApiProxyWrapperReply  as 'call-back' functions when needed.
>>
>
> Considering that the class only has abstract virtual methods and the
> destructor is non-virtual you *might* be able to do this by declaring a raw
> interface ({$Interfaces Corba}) and declaring all the virtual methods in
> the same order (very important!) with suitable signatures and calling
> convention (for i386 you should pick cppdecl otherwise the system default
> should be alright), implementing that interface in some Object Pascal class
> and then passing an instance of that interface to the library.
>
> It could still go wrong due to some differences in the ABI, but it might
> just as well work. 🤷‍♀️
>
> In C++, I was expected to pass the class instance to the external library.
> So, In Pascal, do I pass the interface variable to the external library?
>

Correct. As I said however: it *might* work, no guarantee.

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Liam Proven via fpc-pascal  schrieb am
Sa., 19. Okt. 2024, 21:05:

> On Fri, 18 Oct 2024 at 21:23, Travis Siegel via fpc-pascal
>  wrote:
> >
> > Also, I see very few (if any) examples of how to generate GUI apps when
> > using fpc commandline compiling, (again, without lazarus in the mix).
>
> There is a modernised version of TurboVision out there:
>
> https://github.com/magiblot/tvision
>
> It's aimed at C++.  Would it be possible to adapt that, or integrate with
> it?
>

We already have FreeVision which the textmodewis using and which is even
Unicode-capable in main. If anything is missing then that should be
improved/fixed instead of porting another one.

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Sa., 19. Okt. 2024, 15:14:

> On Oct 19, 2024 at 8:10:02 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
>
>> For a class one can override NewInstance and FreeInstance. And with
>> TVirtualMethodInterceptor (I think not yet implemented in FPC) it might
>> even be possible to replace these on an existing class type without
>> inheriting from it. I have not tested that yet, but it *might* work.
>>
>
> This isn’t good enough though. The idea is you have multiple allocators
> for different life times in your program and allocate each class from one
> of those. A type based allocator is global for all classes and while you
> can push/pop allocators in scopes this isn’t thread safe.
>

You didn't understand what I wrote. Assuming what I thought up works, it
would be possible to replace NewInstance and FreeInstance *per instance* as
desired.

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Sa., 19. Okt. 2024, 14:49:

> On Oct 19, 2024 at 7:37:15 PM, Martin Frb via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
>
>> Because if the latter, well I know some people who would shot the person
>> introducing that in a high performance software...
>>
>
> yes it’s bad except for UI apps which is what FPC and new users seem to be
> focusing on. FPC has it already on some types which are widely used.
>

For UI apps it can also be bad depending on the performance impact.


>
>> Actually, if we are talking safety (rather than comfort for the
>> developer) then we may not need ARC at all. Because freeing memory is
>> not the only (nor biggest?) worry. Running out of mem (and handling it
>> gracefully, and without vulnerability)  is important too. But ARC
>> doesn't solve that.
>> One way to solve that is pre-allocate any mem that may be needed, and
>> then never free or alloc any mem thereafter. And then you need no ARC at
>> all.
>>
>
> FPC sadly has no concept of custom allocators for classes, just something
> you can add to the type itself but that’s very limited. I really like how
> Jai and Odin have added allocators in as a core part of the language and
> library. Zig does something like this too but it’s much more clumsy and
> tedious.
>

For a class one can override NewInstance and FreeInstance. And with
TVirtualMethodInterceptor (I think not yet implemented in FPC) it might
even be possible to replace these on an existing class type without
inheriting from it. I have not tested that yet, but it *might* work.

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Sa., 19. Okt. 2024, 14:20:

> On Oct 19, 2024 at 3:35:25 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
>
>> You are not taking the reasoning to its logical conclusion.
>>
>> These "new users" will want to have some standard library - the RTL and
>> packages.
>>
>> So the whole rtl/packages needs to be recreated if you introduce this,
>> for the reasons that were mentioned by Sven.
>> Reasons that were already voiced 20 years ago, by the way.
>>
>>
> Yes all the RTL would need to be redesigned and all the manual frees
> removed. I don’t think it’s THAT difficult honestly to make that work, just
> loads of precious of time.
>

It's an unnecessary maintenance burden, because the current RTL (and
packages) needs to be kept as well for backwards compatibility. Anything
that compromises that will not be accepted, because this is one of *the*
strengths of FPC. As Michael said, we will not maintain two RTLs.

>
This is probably why C++ did smart pointers. Doing those right with Pascal
> is even harder than C++ due the predeclared variables. I’ve played with the
> management operators and they still have problems, most of all is the
> default property which has been discussed for over 5 years with no progress.
>

Smart pointers or more precisely "external reference counting" is the way
to go. And for it to simply work "default properties" or something similar
is not even needed only if we want to reduce typing. And predeclared
variables compared to C++ is also not a problem.

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Sa., 19. Okt. 2024, 03:18:

> On Oct 19, 2024 at 2:31:36 AM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
>
>> This would mean that a new class type or some kind of additional
>> attribute would have to be introduced which would have to be incompatible
>> to non-reference-counted classes as otherwise there would be the chance for
>> memory leaks or use-after-free again. This in turn would mean that
>> essenentially the whole class hierarchy would have to be reimplemented.
>>
>
> You just only adopt it when you want it or in new programs entirely.
> Remember we’re talking about new users with no programs wanting to start
> fresh.
>

You don't get it, do you? It's either all or nothing. Because otherwise
there *will* be problems.


>
>> And that whole shebang is just not worth it. If someone wants a full ARC
>> language then simply don't use Object Pascal.
>>
>
> What’s the appeal to new programmers with this attitude? FPC already has
> ARC on a few types so it stands out the classes are excluded. They don’t
> care about backwards compatibility of course. New programers will look at
> this and go for the full ARC language which is easier or go to C/C++ if
> they want performance and lots of libraries/resources.
>

New users might not care about backwards compatibility, but existing ones
do. We are not helping us if we scare away many existing users to get a few
new ones. If they want ARC/GC or high performance then those users should
simply go somewhere. One can't cater to everyone and thus we should stick
with what made Pascal strong, not chasing after some dreams.

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Fr., 18. Okt. 2024, 17:21:

> On Oct 18, 2024 at 3:41:49 PM, Karoly Balogh via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
>
>> Maybe it was mentioned in the thread, I just glanced through it, but how
>> about ARC (Automatic Reference Counting), Objective C style? To be honest,
>> I really liked that, and we already have it kind of in place for strings,
>> even temporary strings and maybe even temporary arrays created inside a
>> function. We'd just need to extend it for a bunch of other things, I
>> suppose. Manual FreeAndNil() is the ugliest part of Object Pascal for me
>> for sure... OTOH, for Object Pascal you might end up with RAII in this
>> case, instead of ARC, because how how the language works. I did not like
>> it that much in C++, but maybe because modern C++ syntax is properly
>> horrid...
>>
>
> The compiler already has all the plumbing for implementing this but they
> would need to agree to a new class type which includes has the same ref
> counting as AnsiString, Interfaces and other types. I mentioned this
> multiple times but Sven objected to it stating he already tried and
> uncounted some edge cases.
>
> I think an entirely new class type would be required and that’s where the
> resistance came from. Sven can refresh us on this if he wants.
>

The problem is that we can't simply introduce reference counting for
existing classes, because that would lead to memory leaks in existing
codes, because that might have cyclic references.

This would mean that a new class type or some kind of additional attribute
would have to be introduced which would have to be incompatible to
non-reference-counted classes as otherwise there would be the chance for
memory leaks or use-after-free again. This in turn would mean that
essenentially the whole class hierarchy would have to be reimplemented.

And that whole shebang is just not worth it. If someone wants a full ARC
language then simply don't use Object Pascal.

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Michael Van Canneyt  schrieb am Do., 17. Okt. 2024,
14:37:

>
>
> On Thu, 17 Oct 2024, Sven Barth via fpc-pascal wrote:
>
> > Michael Van Canneyt via fpc-pascal 
> > schrieb am Do., 17. Okt. 2024, 11:40:
> >
> >>
> >>
> >> On Wed, 16 Oct 2024, Hairy Pixels via fpc-pascal wrote:
> >>
> >>> On Oct 17, 2024 at 12:03:47 AM, Guillermo Martínez Jiménez via
> >> fpc-pascal <
> >>> fpc-pascal@lists.freepascal.org> wrote:
> >>>
> >>>> Prease DON'T add garbage collector.  IMO it isn't a good idea.  I had
> >>>> very bad experiences with it. Unless somebody found a new magic
> >>>> algorithm in the last decade...
> >>>>
> >>>
> >>> I used C# for Unity quite a bit and never had any problems. That’s even
> >>> with the worst case scenario for game developing that needs real time
> >>> graphics. Does that power all of .NET too and all those desktop
> >>> applications? It’s been battle tested many years as far as I can tell.
> >>>
> >>> In 2024 you don’t need the performance of manual memory management in
> UI
> >>> apps. Garbage collector or anything else will work perfectly well.
> >>
> >> I don't write UI apps, only server apps.
> >> Performance matters there, so a GC is not good.
> >> We see this at times in our servers, when the GC kicks in; everything
> just
> >> stops.
> >>
> >> In each case, it is a bad idea to slap this on an existing language:
> >>
> >> a GC collected language is a complete paradigm shift from non-GC.
> >> C# and Java (and probably others) were designed with GC in mind.
> >> That it works there is therefore not surprising.
> >>
> >> By contrast, Pascal is not designed with GC in mind.
> >> You'd need to redesign the language.
> >>
> >> If you do that, you can throw away all existing code if you introduce
> GC,
> >> because the two concepts do not merge easily.
> >>
> >> Embarcadero tried it in Delphi, and they failed. Not surprisingly,
> >> they removed again all automatic memory management.
> >>
> >
> > Probably something like the std::*_ptr (shared, unique, auto, etc.) from
> > C++ could be implemented in FPC. Main point missing for a convenient
> > solution would be a mechanism so that e.g. classes could be accessed as
> is
> > from such types (for example default fields)
> > A proof of concept implementation should be doable without that however.
>
> I have one provided by a colleague that is a C++ jedi... I planned to put
> it
> in types.pp, since the implementation is ridiculously small and depends on
> nothing.
>

Does it have tests as well? Otherwise that sounds good 😁

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Nikolay Nikolov via fpc-pascal  schrieb am
Do., 17. Okt. 2024, 09:16:

>
> In 2024 you don’t need the performance of manual memory management in UI
> apps. Garbage collector or anything else will work perfectly well.
>
> Well, surely, you can probably use something like this with Free Pascal as
> well:
>
> https://www.hboehm.info/gc/
>
> We're eagerly waiting for your patches to make this work.
>
No patches needed:
https://gitlab.com/freepascal.org/fpc/source/-/blob/main/packages/libgc/src/gcmem.pp?ref_type=heads
😉

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Do., 17. Okt. 2024, 11:40:

>
>
> On Wed, 16 Oct 2024, Hairy Pixels via fpc-pascal wrote:
>
> > On Oct 17, 2024 at 12:03:47 AM, Guillermo Martínez Jiménez via
> fpc-pascal <
> > fpc-pascal@lists.freepascal.org> wrote:
> >
> >> Prease DON'T add garbage collector.  IMO it isn't a good idea.  I had
> >> very bad experiences with it. Unless somebody found a new magic
> >> algorithm in the last decade...
> >>
> >
> > I used C# for Unity quite a bit and never had any problems. That’s even
> > with the worst case scenario for game developing that needs real time
> > graphics. Does that power all of .NET too and all those desktop
> > applications? It’s been battle tested many years as far as I can tell.
> >
> > In 2024 you don’t need the performance of manual memory management in UI
> > apps. Garbage collector or anything else will work perfectly well.
>
> I don't write UI apps, only server apps.
> Performance matters there, so a GC is not good.
> We see this at times in our servers, when the GC kicks in; everything just
> stops.
>
> In each case, it is a bad idea to slap this on an existing language:
>
> a GC collected language is a complete paradigm shift from non-GC.
> C# and Java (and probably others) were designed with GC in mind.
> That it works there is therefore not surprising.
>
> By contrast, Pascal is not designed with GC in mind.
> You'd need to redesign the language.
>
> If you do that, you can throw away all existing code if you introduce GC,
> because the two concepts do not merge easily.
>
> Embarcadero tried it in Delphi, and they failed. Not surprisingly,
> they removed again all automatic memory management.
>

Probably something like the std::*_ptr (shared, unique, auto, etc.) from
C++ could be implemented in FPC. Main point missing for a convenient
solution would be a mechanism so that e.g. classes could be accessed as is
from such types (for example default fields)
A proof of concept implementation should be doable without that however.

Regards,
Sven

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Peter B via fpc-pascal  schrieb am Do.,
17. Okt. 2024, 13:29:

> Anybody,
> on the subject of llvm; does anyone know if the option of llvm
> back-end for fpc is ever going to make an official release?
>

The LLVM port has some shortcomings that will for the foreseeable future
have it be a less good choice (like missing floating point exception
handling if I remember correctly).


> That would be really interesting if it means fpc could be bootstrapped
> to new hardware.
>

The LLVM port does not help in that regard at all, because the platform
specific backends are still required for some low level stuff.

Regards,
Sven

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Am 17.10.2024 um 01:51 schrieb Rainer Stratmann via fpc-pascal:

Am Donnerstag, 17. Oktober 2024, 00:08:27 CEST schrieb Sven Barth via fpc-
pascal:

News flash: this is how well behaved Linux applications are supposed to
behave no matter if they are a "Linux system program" or not.

Haha, I did not know this. Very good that you tell me...

As far as I know fpcupdeluxe stores everything in one folder and that works
(better).

But that doesn't make it correct from a Linux point of view.

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Am 17.10.2024 um 03:42 schrieb Ralf Quint via fpc-pascal:

On 10/16/2024 2:49 PM, James Richters via fpc-pascal wrote:


>> By and large, FPC (and Lazarus) is installed rather quickly.

The only thing I wish for the installation of FPC is that all the 
help files were included and installed by default. I am always 
annoyed by being required to go get the help files and add them in 
myself when I install FPC.I think many years ago making them separate 
files that could be downloaded if needed made sense, but those days 
are long gone and manually downloading and installing the help files 
is just not necessary anymore. I know you don’t need the help files 
if you have Lazarus, and I’m in the minority, but I like the text IDE 
and use it exclusively.


I think anyone coming across the IDE and not realizing the help needs 
to be downloaded and installed separately would just assume there is 
no help.I know it states it quite clearly on the download page, but 
when downloading it you are just tying to get it working it’s not 
until you want to really do something and try to use the help that 
you realize there is none, and by then you forgot what was on the 
download page.


Not sure what kind of help you are referring to, but Help seems to be 
installed on my system I am currently working on, and all I ever 
download when upgrading or installing a new version is the 64bit 
version of Lazarus&compiler as well as the 32bit cross-compiler...
And on Linux, I download and install in order 3 files, as clearly 
indicated, which are fpc-laz (the compiler), fpc-src (source code) and 
lazarus-project (IDE), with the later including the help files...


He's talking about the help for the textmode IDE. As he wrote Lazarus 
includes the help, but the FPC installer does not.


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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Am 17.10.2024 um 01:57 schrieb Rainer Stratmann via fpc-pascal:

Am Mittwoch, 16. Oktober 2024, 23:12:08 CEST schrieb Michael Van Canneyt via
fpc-pascal:

Actually, my employer has already offered twice to sponsor a web-designer to
overhaul the website. Money was not an issue. The idea was to announce a
contest and to select a winning design. The designer gets then the money.

What counts is a site that is alive.

Look at
https://www.mikrocontroller.net
This site is very alive. A lot of development is going on there.
You can even make a post as a guest without registration.


We don't have a way to access the Lazarus forum from the main page, so 
there is no way to make it “livlier” that way.


And for news: I prefer to spend the time coding instead of trying to 
think up something that might be useful news for the community.


That's also a difference between mikrocontroller.net and Free Pascal: 
the former is simply a community of enthusiastic users. They don't have 
a specific team that works on something concrete like we do.



May be we don't have to reinvent the wheel and ask the owner.
https://www.mikrocontroller.net/contact
There is no need to ask them, cause the main point is that they use some 
custom forum software and website. We don't for the forum and for the 
website we have static pages to reduce maintainenace.


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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Rainer Stratmann via fpc-pascal  schrieb
am Mi., 16. Okt. 2024, 01:16:

> - Linux: All relevant files (executable files, configuration files, source
> code,
> etc.) are scattered all over the Linux system. This is very complicated
> again.
> If Lazarus/Freepascal were a Linux system program it would make sense. But
> it
> is NOT a Linux system program. The chance that it will be used by several
> users on a multi-user system is close to zero.
>

News flash: this is how well behaved Linux applications are supposed to
behave no matter if they are a "Linux system program" or not.

That said the FPC installer allows you to install FPC in a completely
separate folder with only the configuration file(s) in your home directory
(I do so for example, cause I have multiple FPC versions installed).

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Nikolay Nikolov via fpc-pascal  schrieb am
Mi., 16. Okt. 2024, 11:44:

> As for the language I think for GUI apps programmers don’t need or want a
> manual memory managed language like Pascal and would prefer something like
> C#. In general the ease of programming is not there in Pascal compared to
> other languages and the community is extremely resistant to change.
>
> Do you have a garbage collection proposal for Pascal?
>
> Free Pascal has a JVM target that supports garbage collection and pretty
> much nobody is using it. Why do you think that is?
>
To be fair working with the JVM target is quite a bit different and then
not even all language constructs are supported yet (though there is a merge
request I want to take a look at to improve the situation).

Regards,
Sven

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

Re: [fpc-pascal] Fwd: What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 16. Okt. 2024, 13:49:

> As for the language I think for GUI apps programmers don’t need or want a
>> manual memory managed language like Pascal and would prefer something like
>> C#. In general the ease of programming is not there in Pascal compared to
>> other languages and the community is extremely resistant to change.
>>
>> Do you have a garbage collection proposal for Pascal?
>>
>> Free Pascal has a JVM target that supports garbage collection and pretty
>> much nobody is using it. Why do you think that is?
>>
> I don’t even know how to use that! I assume it’s not something you just
> enable on any program. I’ve never seen programs adopt it.
>

It's not something you enable. It's a completely different platform, namely
the Java Virtual Machine, so essentially a different processor.

Regards,
Sven

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Stefan-Iulian Alecu via fpc-pascal 
schrieb am Mi., 16. Okt. 2024, 23:38:

> > Lazarus does not look complicated. It has it own distinctive look & feel.
> > User
> > should be able to completely detach windows from from main so it would be
> > possible to move them to different monitor, virtual desktop & freely move
> > on monitor.
> You might've not realized that, but this is *foreign* and totally
> different from how most IDEs out there function. If you're familiar with
> Delphi 7 and lower, great, this feels natural, but the problem is that
> other IDEs aren't like Delphi 7. Lazarus is still stuck in that era, and
> that's /fine/ (at least, as far as the old Pascal devs are concerned),
> but I see most people around me (beginners and otherwise) immediately
> dock the IDE or ask me how to do it. Not to mention that it immediately
> fails to function for tiling window managers. And "distinctive look and
> feel" doesn't mean said look and feel is intuitive. I believe it would
> be better if Lazarus was docked by default and give the option to easily
> undock it, because far more beginners or curious people would want to
> dock it, it's a better default. If you don't believe me, please look at
> as many IDEs as you can and tell me *one* that's undocked like Lazarus
> is. It genuinely is something unusual and jarring to newcomers. Maybe
> there's a reason most other IDEs are docked, and even if you disagree
> with that particular decision, it would be hard to deny the reality that
> it's how people expect IDEs today to be structured. Even *RAD Studio*
> gave up on the idea. Happy birthday 2002!
>

I think there are still some issues simply switching between the docked and
undocked layout. If that would be solved (patches welcome 😉) then it would
be a much easier decision to have the IDE be docked to default, cause those
users that prefer undocked (and those *do* exist and we don't want *those*
to leave just because we did this wrong) can then easily switch it to
undocked.

Regards,
Sven

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

geneb via fpc-pascal  schrieb am Mi., 16.
Okt. 2024, 16:19:

>
> > I have always found that the self-contained nature of Pascal/Delphi
> > executables is a big advantage over other language systems. Just copy
> > the file and run it, even on a system that has never seen a
> > Pascal/Delphi executable before. If we could do that with the
> > IDE/compiler it would be magic! The install process is far from that
> > goal right now.
> >
> > Doug C.
> >
> Portable Lazarus would just kick ass.
>

At least the Windows installer already provides an option to make the
installation portable. Something similar can probably done for Linux as
well (macOS requires the installation of development tools provided by
Apple, so a totally fresh system would not work).

Regards,
Sven

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Stefan-Iulian Alecu via fpc-pascal 
schrieb am Mi., 16. Okt. 2024, 16:08:

> I am aware of your work. As long as you still depend on CodeTools and
> Lazarus internals, the language server can't be called independent.
>

The point of using CodeTools is that they are kept fairly up to date with
what the compiler supports and even across different versions of the
compiler. Completly implementing one's own language parser is essential
unnecessary duplicated work considering that we don't have easy pickings
regarding personpower.
Also once a CodeTools driven language server would be usable enough one
might argue for having it used by the Lazarus IDE as well (assuming the
language server protocol can support everything that the current direct use
of CodeTools supports), thus possibly moving CodeTools and the language
server out of the Lazarus IDE.

Regards,
Sven

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

Re: [fpc-pascal] What to do to get new users

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 16. Okt. 2024, 16:07:

> Another point is that FPC doesn’t have an official forum except for the
> mail list and that in and of itself is a problem if you ask me. Most young
> people don’t use email and won’t like this. I myself don’t prefer the mail
> list over some of the very nice forums that allow posting code and very
> easy to use and browse information.
>

The official forum for Free Pascal is the Lazarus forum. It does not make
sense to split the community even further (which it had been back when FPC
had its own forum till it was decided that the Lazarus forum is the way to
go).


> You can’t even easily browse the old messages compared to other services.
> I would much prefer what https://discourse.llvm.org/ does and many others
> for example. I brought this up a while ago and people didn’t seem to like
> the idea. Very well but for new users I think you’re shooting yourself in
> foot by not have a competitive way to get help.
>

No, thank you.

Regards,
Sven

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

Re: [fpc-pascal] AllocateThreadVars ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mi., 9. Okt. 2024, 16:44:

> I have a program on MacOS that calls CoreAudio which calls the application
> back in a so-called
> AURendererCallback in a separate (com.apple.audio.IOThread.client) thread.
> This is a pthread
> created by the system software, not by the FreePascal RTL.
>
> In that thread, a FreePascal try except block doesn't catch an exception.
> A globally installed
> TExceptProc does. if I look in the RTL code, it looks like a thread
> created with BeginThread does
> some extra things, like calling SysAllocateThreadVars. A comment notes
> that exception handling
> depends on it.
>
> So, it seems plausible that SysAllocateThreadVars (or the
> AllocateThreadVars method of the current
> TThreadManager) must be called once for  pthreads created by the system
> software ? How ? Obviously
> I couldn't use a threadvar that tells me whether AllocateThreadVars has
> been called already ?
>

You already wrote that you might have found a different cause, but
nevertheless to clarify: the RTL initialization for the thread (which
includes AllocateThreadVars) should already be done transparently by the
RTL through hooks provided by pthread.

Regards,
Sven

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

Re: [fpc-pascal] How do I pass a call back Class and its method to an external library *.so file writting in C++

[Sven Barth via fpc-pascal]

Dennis via fpc-pascal  schrieb am Fr., 4.
Okt. 2024, 08:40:

> Dear All,
>
> I am given an API linux library *.so file written in C++.
> It was expected to be consume by a program written in C++.
> However, I would like to write such a program in Free Pascal.


[snip]


> I am expected to create and pass an instance of such class
> ApiProxyWrapperReply in my calling program
>   via a function
> void SPAPI_RegisterApiProxyWrapperReply(ApiProxyWrapperReply*
> apiProxyWrapperReply);
>
> and the external library will then call the various methods of
> ApiProxyWrapperReply  as 'call-back' functions when needed.
>

Considering that the class only has abstract virtual methods and the
destructor is non-virtual you *might* be able to do this by declaring a raw
interface ({$Interfaces Corba}) and declaring all the virtual methods in
the same order (very important!) with suitable signatures and calling
convention (for i386 you should pick cppdecl otherwise the system default
should be alright), implementing that interface in some Object Pascal class
and then passing an instance of that interface to the library.

It could still go wrong due to some differences in the ABI, but it might
just as well work. 🤷‍♀️


> I consulted co-pilot but it failed to teach me how to do so in a Free
> Pascal program calling such an external library.
>

Shows that the current state of "AI" can't help with every obscure topic 😅

Regards,
Sven

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

Re: [fpc-pascal] Sub-millisecond time measuring

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Sa., 29. Juni 2024, 21:21:

> Michael Van Canneyt via fpc-pascal wrote:
> >> Is that a function in the RTL? I can't find it.
> >
> > No, these are platform-specific functions.
> >
> > g_get_monotonic_time is probably just an alias for the linux/freebsd
> > unit functions clock_gettime(CLOCK_MONOTONIC_RAW).
>
> g_get_monotonic_time is in glib <
> https://docs.gtk.org/glib/func.get_monotonic_time.html>
>
>   function g_get_monotonic_time: gint64; cdecl; external;
>
> but it requires a bug fix when using gtk on MacOSX <
> https://bugzilla.gnome.org/show_bug.cgi?id=728123>
>

I wouldn't introduce a dependency for something like GTK (especially GTK!)
on macOS only to receive some timings. Simpler and more straight forward to
just use the correct functions of the OS.

Regards,
Sven

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

Re: [fpc-pascal] Heap trace on mac still not working?

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mo., 1. Juli 2024, 03:49:

> oh it uses external debug symbols! Now it's finally reporting some
> locations, thanks I should have been able to figure that out. Hmmm can't
> the compiler print stack traces without debug info? Maybe not.
>

The *compiler* isn't printing anything.
And of course the RTL requires debug information for this, because normally
no function names are stored in a binary. That's the purpose of debug
information after all.

Regards,
Sven

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

Re: [fpc-pascal] How to use external linker on windows i386

[Sven Barth via fpc-pascal]

Sven Barth  schrieb am Do., 6. Juni 2024,
11:16:

> Ondrej Pokorny via fpc-pascal  schrieb
> am Do., 6. Juni 2024, 09:30:
>
>> Hello,
>>
>> I am on Windows 64bit, but using the i386 compiler.
>>
>> I have to link a 3rd party OBJ file with {$L 'xyz.obj'}.
>>
>> With the internal linker I get these errors:
>> Error: COMDAT selection mode 0 not supported (section: "0")
>> Error: Failed reading coff file, invalid section index while
>> reading xyz.obj
>> Error: Associative COMDAT section for section ".rdata" not found
>>
>
> Can you provide a small example as a bug report that shows this behavior
> (preferably also with source for the object file) so that we can improve
> the internal linker?
>

Thanks to your privately provided example I was able to solve that (though
it still won't link due to missing symbols, but that is not the linker's
fault and probably also the reason why the external linker fails as well).
I still don't understand why the object file contained a COMDAT field with
an invalid selection of 0, but it seems that other linkers ignore that as
well... 🤷‍♀️

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

Re: [fpc-pascal] How to use external linker on windows i386

[Sven Barth via fpc-pascal]

Ondrej Pokorny  schrieb am Do., 6. Juni 2024, 11:56:

> On 06.06.2024 11:16, Sven Barth via fpc-pascal wrote:
>
> Ondrej Pokorny via fpc-pascal  schrieb
> am Do., 6. Juni 2024, 09:30:
>
>> Hello,
>>
>> I am on Windows 64bit, but using the i386 compiler.
>>
>> I have to link a 3rd party OBJ file with {$L 'xyz.obj'}.
>>
>> With the internal linker I get these errors:
>> Error: COMDAT selection mode 0 not supported (section: "0")
>> Error: Failed reading coff file, invalid section index while
>> reading xyz.obj
>> Error: Associative COMDAT section for section ".rdata" not found
>>
>
> Can you provide a small example as a bug report that shows this behavior
> (preferably also with source for the object file) so that we can improve
> the internal linker?
>
>
>> So I tried to use the external linker with -Xe and I get these errors:
>> Linking myProgram.exe
>> ld: warning: directory not found for option '-L/usr/lib'
>> ld: warning: directory not found for option
>> '-F/System/Library/Frameworks/'
>> ld: warning: option -b is obsolete and being ignored
>> ld: file not found: pei-i386
>> Error: Error while linking
>>
>
> That reads like the compiler is picking up the wrong linker (a WSL one
> perhaps?). The ld.exe (probably with platform prefix) should already be
> located in the compiler's binary directory and PATH needs to point to that
> first.
>
> Thank you Sven for the help!
>
> I changed the PATH so that the FPC bin directory is the first entry and
> the output indeed changed: I get only "Error: Error while linking" output
> without additional information that I got before.
>
> You should probably look at the unfiltered output of the message window.

Furthermore, I see from the docs that the -XR isn't supported on Windows (
> https://www.freepascal.org/docs-html/user/userap1.html)
> -XR Prepend  to all linker search paths (BeOS, Darwin, FreeBSD,
> Linux, Mac OS, Solaris)
>
> Maybe it would be good to support it on Windows as well to be able to
> explicitly tell which linker to use.
>
-XR does not do what you think it does. It only exists for specific cross
compiling issues on *nix platforms.

If you need to specify a path for the binutils you can use -FD.

Regards,
Sven

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

Re: [fpc-pascal] How to use external linker on windows i386

[Sven Barth via fpc-pascal]

Ondrej Pokorny via fpc-pascal  schrieb am
Do., 6. Juni 2024, 09:30:

> Hello,
>
> I am on Windows 64bit, but using the i386 compiler.
>
> I have to link a 3rd party OBJ file with {$L 'xyz.obj'}.
>
> With the internal linker I get these errors:
> Error: COMDAT selection mode 0 not supported (section: "0")
> Error: Failed reading coff file, invalid section index while
> reading xyz.obj
> Error: Associative COMDAT section for section ".rdata" not found
>

Can you provide a small example as a bug report that shows this behavior
(preferably also with source for the object file) so that we can improve
the internal linker?


> So I tried to use the external linker with -Xe and I get these errors:
> Linking myProgram.exe
> ld: warning: directory not found for option '-L/usr/lib'
> ld: warning: directory not found for option '-F/System/Library/Frameworks/'
> ld: warning: option -b is obsolete and being ignored
> ld: file not found: pei-i386
> Error: Error while linking
>

That reads like the compiler is picking up the wrong linker (a WSL one
perhaps?). The ld.exe (probably with platform prefix) should already be
located in the compiler's binary directory and PATH needs to point to that
first.

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

Re: [fpc-pascal] Custom NewInstance allocator

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Di., 4. Juni 2024, 10:54:

> In the manual it at https://www.freepascal.org/docs-html/ref/refse38.html
> it says "Calling the constructor will provoke a call to the virtual class
> method NewInstance, which, in its default implementation, calls GetMem, to
> allocate enough space to hold the class instance data, and then zeroes out
> the memory."
>
> I'm trying this like below but it crashes. Is this correct? The fact
> NewInstance returns TObject instead of Pointer doesn't make sense to me and
> suggests this isn't correct.
>
>   class function TDataObject.NewInstance: TObject;
>   begin
> result := TObject(GetMem(InstanceSize));
>   end;
>

You also need to call TObject.InitInstance() on the allocated memory (that
should probably be mentioned in the documentation...).

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mi., 1. Mai 2024, 17:07:

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

In addition to what Martin said: as long as you have a non-static class
method the value of the variable you call the class method on (e.g. myClass
in your example) will be passed as Self parameter. So no need for extra
parameters.

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

Re: [fpc-pascal] AnsiString address changed

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mo., 18. März 2024, 13:30:

>
>
> > On Mar 18, 2024, at 5:29 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Of course there must be, that's the whole point of copy-on-write.
> >
> > As soon as one reference is changed, a copy is made if the reference
> count
> > is larget than 1, and this copy is changed.
>
> Oh, it does copy on write. I see now that by looking at the pointer
> addresses.
>
> So what happens if you do this? s2 is pointing to s1 but then you change
> the size of s1 and ReAllocMem gets called and invalidates the pointer to
> the original s1. How does s2 know this and not access corrupted memory now?
>
>   s1 := '123';
>   s2 := s1;
>   s1 := '';
>


Your description is inaccurate: s2 does not point to s1. Instead both point
to the string data with a reference count of 2. If you now change one of
the two (e.g. with SetLength) then a copy of the string data will be
created and that copy will be manipulated.
The memory of the string data will only be reallocated if only one
reference to that data exists.

Regards,
Sven

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

Re: [fpc-pascal] Floating point question

[Sven Barth via fpc-pascal]

James Richters via fpc-pascal  schrieb am
Di., 20. Feb. 2024, 04:42:

> I don't know why it would be different in Windows than on Linux.


If you're using Win64, then the answer is simple: x86_64-win64 unlike any
other x86 target does not support Extended, so neither the compiler nor the
code in runtime will ever calculate anything with that precision.

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

Re: [fpc-pascal] Can FPC link a program with static (.a) libraries on Windows

[Sven Barth via fpc-pascal]

Tony Whyman via fpc-pascal  schrieb am
Sa., 17. Feb. 2024, 00:50:

> I have a Pascal program, compiled with FPC 3.2.2 and which appears to
> happily link and run with a static library compiled with gcc and having
> a ".a" prefix on linux. The functions in the static library and declared
> as external functions using the "external  name  name>" directive. The "".a" library is copied to the same directory as
> the program unit before compiling and linking.
>
> However, compiling the same program on Windows always seems to result in
> the loader complaining that the corresponding .dll is not
> present, indicating that instead of linking with the static library, the
> program is attempting to "statically" load the correspoinding dll at
> initialisation time.
>
> I have tried to force it to link with the static library (e.g. using the
> -Xt command line switch) but no luck.
>
> Hence the question, does FPC 3.2.2 support linking with static libraries
> on windows?
>

"external  name " is for dynamic linking. For static
linking you need to leave out the  and instead use "{$linklib
}" or even "{$linklib , static}" . That will also work on
Linux.

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Ralf Quint via fpc-pascal  schrieb am Fr.,
9. Feb. 2024, 20:36:

> On 2/8/2024 11:01 AM, Martin Wynne via fpc-pascal wrote:
> > Hi Thomas,
> >
> > The error is not the file content after "end.".
> >
> > The error is not having the expected "end;" after "begin".
> >
> > This works ok:
> >
> > _
> >
> > program test;
> >
> > begin
> > end;
> >
> > end.
> >
> > abc 123
> >
> > _
> >
> > Martin.
>
> This is not a valid Pascal source code to begin with (pun intended)...
>
> The "begin" is the start of the actual Pascal program and by definition,
> that program is terminated by matching that with an "end." That's what
> the code completion in Lazarus for example is adding into a new "simple
> program" project source code.
>
> Just adding a random "end;" should also just yield an error message...
>
> Well, I actually did just tested this and it gives as expected an
> "Error: Syntax error,  "." expected but ";" found. It Doesn't even
> process past the "end." in that case.
>

That's what I had expected.


> What is however interesting is that an open comment, as mention by the
> OP,  immediately after the "end." results in the "Error: unexpected end
> of file" message, however any other addition text past that "end." will
> result in no error message and completing to compile the program
> successfully...
>
> I just tried a couple more things, and it seems it is just the "{" or
> "(*" opening of a comment that is causing the error message, having a
> "//" comment until end of  line after the "end."  will also compile just
> fine
>

If one knows how the compiler is structured (I do) then it isn't that
surprising that it behaves that way with a dangling comment due to the
interaction between the scanner (which is responsible for the comments) and
the parser (which triggers the consumption of the final point).
The problem is that the parser does not know that the end of the program
has been reached when that point is consumed and happily searches for the
next token, consuming all whitespace and comments along the way.

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Martin Wynne via fpc-pascal  schrieb am
Do., 8. Feb. 2024, 22:03:

> Hi Thomas,
>
> The error is not the file content after "end.".
>
> The error is not having the expected "end;" after "begin".
>
> This works ok:
>
> _
>
> program test;
>
> begin
> end;
>
> end.
>
> abc 123
>

If that works then that is a bug as well, because the begin of the main
*must* be terminated with a "end.", not a "end;".

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Do., 8. Feb. 2024, 13:31:

> Hello all,
>
> I'm unsure about whether or not to report this as a bug. Imho, it is a
> bug, but maybe there's a good reason to handle this.
>

Please report a bug.

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

Re: [fpc-pascal] Need some advice

[Sven Barth via fpc-pascal]

ppadilcdx via fpc-pascal  schrieb am Mi.,
24. Jan. 2024, 22:07:

> Thanks for that, now it compiles but it doesn't work, i.e. I added a
> pair and value and then used trygetdata and it can't find it. So perhaps
> I'm missing something else :
>

Your operator needs to establish a true order between the two passed in
values. Right now your operators only check a, but not b. That is wrong and
thus the map won't work correctly.

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

Re: [fpc-pascal] IntToStr implementation

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 18. Jan. 2024, 00:44:

>
>
> > On Jan 17, 2024, at 10:15 PM, Marco van de Voort via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> >
> > Op 17-1-2024 om 15:57 schreef Hairy Pixels via fpc-pascal:
> >> Can anyone show me where to find the IntToStr implementation in
> SysUtils? There's so many level of indirection and macros I have no idea
> where to look for it!
> >
> > Grep rtl/objpas/sysutils for it.
> >
> >
> > sysstr.inc for the implementation sysstrh.inc for the declaration
> >
>
> Which then goes to System.Str(), where is that? I found some other Str
> functions in a lstrings.pas file but I don't think that's it. All the
> macros break code tools for me and I can't find anything.
>

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

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Am 07.01.2024 um 11:39 schrieb Michael Van Canneyt via fpc-pascal:



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


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



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


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

at all.

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

this simple of a program or is more going on?


https://wiki.freepascal.org/Size_Matters

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


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


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

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


Probably... 🤷‍♀️

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


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

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


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


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


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

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

[Sven Barth via fpc-pascal]

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



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


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

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


https://wiki.freepascal.org/Size_Matters

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


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

(gotta admit, the last one surprised me though ^^')

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

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Amir--- via fpc-pascal  schrieb am Mi., 3.
Jan. 2024, 07:53:

> Yeap! That is actually what I posted here (Feature Request)
> .
>

My example allows you to access it right now with the existing FPC release.

Regards,
Sven

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

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Am 31.12.2023 um 04:11 schrieb Amir--- via fpc-pascal:


On 12/30/23 00:20, Sven Barth via fpc-pascal wrote:
Amir via fpc-pascal  schrieb am Sa., 
30. Dez. 2023, 08:11:




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

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

Pass the data parameter by reference.

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


No, that's not a thing.

You simply need to declare your "data" parameter as "constref" or 
"const" as well, just like your "v" parameter.

Have a look at this piece of code (The complete code is attached):
type
  TMyRecord = record
    Str: AnsiString;
    Index: Integer;

  end;
  PMyRecord = ^TMyRecord;

  TMyList = specialize TList;
  TMyPtrList = specialize TList;

function Check1(const MyList: TMyList): Integer;
var
   data: TMyRecord;

begin
  Result := 0;
  for data in MyList do
    if data.Index mod 100 = 0 then
  Inc(Result);

end;

function Check2(MyList: TMyList): Integer;
var
   data: TMyRecord;

begin
  Result := 0;
  for data in MyList do
    if data.Index mod 100 = 0 then
  Inc(Result);

end;

function Check3(MyPtrList: TMyPtrList): Integer;
var
   data: PMyRecord;

begin
  Result := 0;
  for data in MyPtrList do
    if data^.Index mod 100 = 0 then
  Inc(Result);

end;


I compiled the code with `fpc -O3 -Sd -gv -g -gl ` and ran `valgrind` 
on it (the output is attached). It does not look like there is a big 
difference between the Check1 and Check2 but Check3 is about 20 times 
faster than the other two.


For a class type there isn't much difference between being passed as 
"const" or not. It's mainly records and managed types this affects.


I believe the issue could be resolved if we make 
"TCustomListWithPointers.GetPtrEnumerator" a public method. Then, one 
can implement the following function:


function Check4(MyList: TMyList): Integer;

  it := MyList.GetPreEnumerator;
  while it.MoveNext do
  begin
    if it.Current^.Index mod 100 = 0 then
 
  end;


You simply need to inherit from the list class so that you can make the 
function public. And with a little trick you can also use it inside a 
for-in-loop:


=== code begin ===

program tlistitr;

{$mode objfpc}{$H+}
{$modeswitch advancedrecords}

uses
  Generics.Collections;

type
  TRec = record
    a, b, c: Int64;
    constructor Create(aArg1, aArg2, aArg3: Int64);
  end;

  { this way the GetPtrEnumerator function is available; you could also 
use a class helper }

  TMyList = class(specialize TList)
  public
    function GetPtrEnumerator: specialize TEnumerator;
  end;

constructor TRec.Create(aArg1, aArg2, aArg3: Int64);
begin
  a := aArg1;
  b := aArg2;
  c := aArg3;
end;

function TMyList.GetPtrEnumerator: specialize TEnumerator;
begin
  Result := inherited GetPtrEnumerator();
end;

{ with this you can simply do "for PtrTypeVar in List.GetPtrEnumerator do",
  though this *might* not work in mode Delphi... }
operator Enumerator(aEnum: specialize TEnumerator): 
specialize TEnumerator;

begin
  Result := aEnum;
end;

var
  l: TMyList;
  r: TRec;
  p: TMyList.PT;
begin
  l := TMyList.Create;
  l.Add(TRec.Create(1, 2, 3));
  l.Add(TRec.Create(9, 8, 7));
  for p in l.GetPtrEnumerator do begin
    Writeln(p^.a, ' ', p^.b, ' ', p^.c);
  end;
end.

=== code end ===

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

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Am 01.01.2024 um 16:51 schrieb Wayne Sherman via fpc-pascal:

On Mon, Jan 1, 2024 at 6:14 AM Hairy Pixels wrote:

On Jan 1, 2024, at 3:50 PM, Michael Van Canneyt wrote:
You can't optimize that. As said, a generic is convenient but slow.

I don't know about that. Like was mentioned the enumerator needs to return a
pointer, preferable without ^ so it feels like a record and only use that in 
the for-in
scope. You can kind of do that yourself but it's cumbersome to maintain and
missing from the RTL (maybe for this reason).

Modern Pascal compilers already do this for certain types and pass by
reference parameters.  For example, AnsiString variables and variables
of type class are handled internally as pointers, but manipulated
opaquely without explicit pointer notation.  A record passed as a var
or constref parameter is internally a pointer, but does not require
the code writer to handle it explicitly as such.
That kind of concept only exists in Pascal for parameters, but not for 
variables or result values as would be needed for this.


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

Re: [fpc-pascal] How to avoid Copy

[Sven Barth via fpc-pascal]

Amir via fpc-pascal  schrieb am Sa., 30.
Dez. 2023, 08:11:

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

No, that's not a thing.

You simply need to declare your "data" parameter as "constref" or "const"
as well, just like your "v" parameter.

Note: prefer the use of "const" instead of "constref" unless you really
need a reference, because the compiler will then pick the optimal way to
pass the value (e.g. small ones will be passed by register instead of as an
address).

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Am 27.12.2023 um 12:25 schrieb James Richters via fpc-pascal:


I wanted to write what I thought should be a simple procedure, just 
instead of calling WRITELN() with some arguments,


call WRITELOG() with the same arguments that you would use to write to 
a file, but my WRITELOG() procedure would


write to the screen and the file.. but I can’t figure out how to pass 
all the arguments to the two WRTIELNs.


So….

Procedure WriteLog(Filename:String, AllOtherAurguments:);

Begin

Writeln(Filename,AllOtherAurguments);

Writeln(AllOtherAurguments);

End;

How can I make this work?Since WRITELN can take any number of many 
kinds of arguments,


how can I get them all and pass them along without knowing how many or 
what types they are?


How does WRITELN even work when you don’t know this information?

I’m guessing there should be some way to do this, because WRITELN 
itself works, but how it could


possibly work is not within my experience.

The only way I could think of would be if there were versions of 
WRITELN with every combination


of possible arguments, but that seems completely unmanageable and 
ridiculous,


so there must be something more advanced going on, but maybe WRTELN is 
special and not something I can duplicate?




Write(Ln) is a compiler intrinsic and thus can behave in ways that are 
not possible for ordinary functions.


Your only ways are either to use "array of const" like "Format" does or 
write a text file driver as is done in the StreamIO unit which allows to 
assign a Stream to a TextFile that can in turn be used as the file 
parameter of Write(Ln). You can implement any other output through this.


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

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

[Sven Barth via fpc-pascal]

Am 26.12.2023 um 21:29 schrieb Amir--- via fpc-pascal:


On 12/26/23 01:14, Sven Barth via fpc-pascal wrote:
Amir--- via fpc-pascal  schrieb am 
Di., 26. Dez. 2023, 07:03:


Hi,

   I want to retrieve the name of the fields in a record/class,
at run
time. It looks like "TVmt.vFieldTable" is what I need. But I
cannot find
any documentation about how to explore the content of this table. I
appreciate any pointer.


This only works for published fields and only fields of type class or 
interface can be published.

That would work for me. How can I enumerate over those fields?


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


=== code begin ===

program tfield;

{$mode objfpc}{$H+}

uses
  TypInfo;

type
  {$M+}
  TSub = class

  end;

  TTest = class
  published
    fTest: TSub;
  end;

var
  vft: PVmtFieldTable;
  vfe: PVmtFieldEntry;
  i: SizeInt;
begin
  vft := PVmtFieldTable(PVMT(TTest)^.vFieldTable);
  Writeln(vft^.Count, ' field(s) with ', vft^.ClassTab^.Count, ' type(s)');
  for i := 0 to vft^.Count - 1 do begin
    vfe := vft^.Field[i];
    Writeln(i, ' -> ', vfe^.Name, ' @ ', vfe^.FieldOffset, ' of type ', 
vft^.ClassTab^.ClassRef[vfe^.TypeIndex - 1]^.ClassName);

  end;
end.

=== code end ===

=== output begin ===

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

=== output end ===

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


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

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

[Sven Barth via fpc-pascal]

Amir--- via fpc-pascal  schrieb am Di.,
26. Dez. 2023, 07:03:

> Hi,
>
>I want to retrieve the name of the fields in a record/class, at run
> time. It looks like "TVmt.vFieldTable" is what I need. But I cannot find
> any documentation about how to explore the content of this table. I
> appreciate any pointer.
>

This only works for published fields and only fields of type class or
interface can be published.

Anything more requires extended RTTI, which is not yet implemented in FPC
(it's already more or less ready in a merge request, but there's still the
one or other issue that needs to be addressed).

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Wayne Sherman via fpc-pascal  schrieb am
Mo., 25. Dez. 2023, 15:46:

> On Mon, Dec 25, 2023 Michael Van Canneyt wrote:
> > In short: To make a EBNF grammar which is 100% correct is not so simple
> > and will make the scheme extremely difficult to understand for a reader.
> > So I prefer to present a simpler version, and mention some limitations
> >  only in the text
> ...
> > There are simply so many exceptions and limitations that the 100% correct
> > diagram would be incomprehensible and needlessly complicated if you
> tried to
> > capture every aspect for the full 100%.
>
> If the EBNF grammar is only a guide provided as documentation for a
> human reader then you might want that.  But if the EBNF grammar is
> used to drive a parser then it needs to be fully complete, accurate,
> and machine readable (see below).
>

The grammar embedded in the documentation is just that: a guide.
Though that doesn't mean that Michael isn't trying to fix as many of the
points that Adriaan mentioned as reasonably possible, because there
obviously have been mistakes and oversights.

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

Re: [fpc-pascal] method-definition

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Sa., 16. Dez. 2023, 09:43:

> The requirement for parameters in record constructors I guess comes from
> C++ builder by Embarcadero.
> There are some limitations imposed by C++.
>
> Whether they could be dropped in FPC is something Sven Barth should answer.
>

We only "inherited" that for Delphi compatibility. Technically the compiler
could handle it without problems... 🤷‍♀️

Regards,
Sven

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

Re: [fpc-pascal] case statement

[Sven Barth via fpc-pascal]

James Richters via fpc-pascal  schrieb am
Do., 14. Dez. 2023, 20:13:

> I didn’t know there was such a thing as OTHERWISE.  Is there any
> functional difference between OTHERWISE and ELSE?
>

"otherwise" is what had been defined by ISO Extended Pascal for the
cause-statement.

Aside from not having the else-problem mentioned in this thread there is no
functional difference.

Regards,
Sven

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

Re: [fpc-pascal] Error when building fpc on aarch64-linux still not resolved

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
So., 10. Dez. 2023, 01:19:

> On Thu, 16 Nov 2023 13:15:27 +0100, Bo Berglund via fpc-pascal
>  wrote:
>
> >I tried to post this to the devel list but it seems to have failed so now
> trying
> >the general list instead...
> >
> >See ticket:
> >https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
> >
> >It was closed a year ago being purportedly resolved...
> >
> >But only for powerpc 64 bit...
> >
> >It is still there for aarch64-linux used by Pi-OS bookworm 64 bit, which
> is now
> >the recommended version...
> >
> >RaspberryPi is a very popular platform so a solution for that is needed.
> >
> >I have tried building (via fpcupdeluxe) several revisions of fpc up to and
> >including trunk, but all fail with the same error outlined in the ticket
> above.
>
> Soon 4 weeks and no reply to this...  :(
>
> I have now started using the Raspberry Pi5B with Pi-OS 64 bit bookworm and
> I
> cannot get past the linking error when building fpc from sources, I have
> tried
> the latest release 3.2.2 and also the pre-release 3.2.3 and 3.3.1 but all
> fail
> with the same error:
> undefined reference to `__libc_csu_init'
>
> So now I tested to download what I think might be the trunk:
>
> https://gitlab.com/freepascal.org/fpc/source/-/archive/main/source-main.tar.gz
>
> And with these sources the linker error disappears and the build all
> succeeds.
>
> Could you not just make an intermediate tag for a version where this fix
> has
> been solved for the arm64 architecture running aarch64-linux?
>

3.2.3 already contains the same fixes that main has for that problem.

And as I had written: I can not reproduce your problems as I can build and
run both 3.2.3 and main with the 3.2.2 release we provide on our download
locations.

Regards,
Sven

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

Re: [fpc-pascal] what is release plan for fpc?

[Sven Barth via fpc-pascal]

Bo YU via fpc-pascal  schrieb am Do., 7.
Dez. 2023, 12:58:

> Hi,
>
> I am sorry if this is not the right mail list to ask the question.
>
> I am helping to build fpc package on Debian riscv64 and found that:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1052557
>
> Now fpc version on Debian is 3.2.2, so I think this is fpc upstream
> latest tag, right?
> and this should be confirmed from here also:
> https://www.freepascal.org/download.html
>
> But from https://gitlab.com/freepascal.org/fpc/source/-/tags, I
> noticed there many tags newer than 3.2.2. So Could I ask here one
> question, do we have a plan to release a new version from upstream?
>
> I believe the new release will contain riscv64/mips64el support, which
> will make it easy to bootstrap them on downstream distros like Debian.
> Otherwise, backporting the huge patchset(>16K lines patch) will be not
> acceptable by maintainers.
>

The support for rv64 is only available from 3.3.1 on (aka main) for which
currently no release is planned. Even if we would say right now that we'd
start release preparation (which we don't), then it would take around half
a year for it to be released.

The next version currently planned is 3.2.4 in a soonish time frame. At
least as far as I'm aware MIPS64 should be supported there. If there are
specific commits from main that would fix issues with that platform we
could potentially still merge them to the fixes branch.

Regards,
Sven

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

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Sa., 25. Nov. 2023, 08:19:

> On Tue, 21 Nov 2023 10:33:46 +0100, Tomas Hajny via fpc-pascal
>  wrote:
>
> >On November 21, 2023 8:33:55 +0100, Bo Berglund via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >>I did not know that there is a library of seed compilers available on
> >>Sourceforge, I thought everything had moved over to GitLab nowadays, so
> where
> >>exactly can I find a binary download for PiOS 64 bit on SF?
> >>Where I have looked I only find old stuff like from 2021...
> >>
> >>https://sourceforge.net/projects/freepascal/files/Linux/3.2.2/
> >>Here are tarballs that by the size seem to contain a lot of stuff apart
> from the
> >>compiler itself.
> >
> >Yes, there are full official releases provided by the FPC team and used
> by many FPC users.
> >
>
> I tried downloading one of the ones on SF and it contains a maze of other
> tar
> file with yet other tar files etc inside.
>
> I failed to locate the actual compiler executable file anywhere, so I gave
> up on
> that
>

Why do you need to make things more complicated than necessary? Extract the
tar you downloaded and execute the install script located there. Anything
else leaves the approach I have tested and confirmed to work for you.

For a successful compilation a *complete* release is necessary anyway
(well, you can deselect the documentation and demoes during the
installation :P).

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

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

[Sven Barth via fpc-pascal]

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

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

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

Regards,
Sven

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

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Sa., 18. Nov. 2023, 11:32:

> Today after realizing that I did the following on an RPi4B where I have
> used apt
> to install the fpc compiler so I could use that as the seed compiuler to
> build
> from sources.
>

Why don't you simply follow what I DID? First of deinstall that apt fpc
again. Then download 3.2.2 for aarch64-linux from SourceForge, install it
and add /path/to/where/you/installed/fpc/bin to your PATH (using "export
PATH=/new/path:$PATH").
Best pick in an installation path like /wherever/fpc/ and select
"yes" when asked whether to adjust the fpc.cfg with $fpcversion, that will
come in handy later.

Next download the sources for 3.2.3 and extract them somewhere different
than "/wherever/fpc". Change into that directory and execute the commands
as I had written in my previous mail (you should be in the same command
line session where you adjusted PATH for this to work otherwise you need to
set it again). The INSTALL_PREFIX should be "/wherever/fpc/3.2.3".

Next set your PATH again, but this time use the directory for 3.2.3 ("echo
$PATH" plus selecting and pasting is your friend here, cause you don't want
to *extend* your path, but replace it; or simply start a new console
windows and append the path there now that I think about it 😅).

Now you should have a working FPC and you can compile Lazarus from source
(sorry, don't know how to setup fpcupdeluxe to use an existing compiler,
cause I don't use it).

In Lazarus you then also need to set the path to your compiler.

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

Re: [fpc-pascal] Cannot build fpc on Raspberry Pi4B running PiOS 64 bit (aarch64 Linux)

[Sven Barth via fpc-pascal]

Bo Berglund via fpc-pascal  schrieb am
Do., 16. Nov. 2023, 08:19:

> From the Lazarus list:
>
> >Just a quick follow-up here:
> >It seems like the fpc sources have not been updated with the solution to
> the bug
> >discussed here:
> >
> >https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
> >
> >This causes the build of Lazarus using fpcupdeluxe with the latest fpc
> 3.2.2 to
> >fail because of a problem with __libc_csu_init during linking.
> >
> >Apparently it is fixed in non-released sources of fpc which we are waiting
> >for...
>
> The GitLab ticket was opened 2 years ago:
> https://gitlab.com/freepascal.org/fpc/source/-/issues/39295
>
> According to a post on the Lazarus forum the fix that solves the fatal
> error
> during fpc build on 64 bit aarch64 Linux (like on Raspberry Pi4B with
> Pi-OS 64
> bit) has *not* been ported to the target aarch64 Linux, only to powerpc.
>
>
> https://forum.lazarus.freepascal.org/index.php/topic,34645.msg496883.html#msg496883


Wrong. Who said that the solution consisted only of a single commit?


>
> So I am sitting here unable to run Lazarus/FPC on the RPi4B with the
> latest 64
> bit Pi-OS...
>
> Is any solution to this problem in the works?
> I have tried every fpc source release from 3.2.2 up to trunk with the
> exact same
> result (here from a build try on trunk):
>
> /bin/ld:
> /home/bosse/devtools/lazarus/2.2.6/fpcsrc/rtl/units/aarch64-linux/cprt0.o:
> in
> function `_start':
> (.text+0x54): undefined reference to `__libc_csu_init'
> /bin/ld: (.text+0x58): undefined reference to `__libc_csu_init'
> /bin/ld: (.text+0x5c): undefined reference to `__libc_csu_fini'
> /bin/ld: (.text+0x60): undefined reference to `__libc_csu_fini'
> make[1]: *** [Makefile:2682: packages_smart] Error 2
> make: *** [Makefile:2837: build-stamp.aarch64-linux] Error 2
> fpmake.pp(60) Error: Error while linking
> fpmake.pp(60) Fatal: There were 1 errors compiling module, stopping
> Fatal: Compilation aborted
>
> I believe that a lot of people will experience this since the 64 bit OS on
> RPi4
> has been recently released as the *recommended* version on that popular
> platform...
>

I can not reproduce. On a Raspberry OS 10 64-bit I downloaded FPC 3.2.2 for
aarch64-linux from SourceForge as well as the sources of both 3.2.3 and
3.3.1 from GitLab.
I install 3.2.2, setup PATH to find the compiler and simply do the
following for each 3.2.3 and 3.3.1 (in their corresponding source
directories):

make all FPMAKEOPT="-T 4" -j 4
make install INSTALL_PREFIX=/path/for/fpc/ - j 4
cd /path/for/fpc//bin
ln -s .. /lib/fpc//ppca64 ppca64

(the -T and -j are simply for parallel compilation)

Both 3.2.3 and 3.3.1 (don't forget to set PATH correctly!) can successfully
compile a hello world program that links against the C library (in my case
by using the cthreads unit) while 3.2.2 can not (as expected).

Regards,
Sven

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

Re: [fpc-pascal] Incompatible procedure types

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Do., 9. Nov. 2023, 01:37:

>
>
> > On Nov 8, 2023, at 1:50 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Please provide example code so that one can look at it. Such messages
> without example are more often than not simply useless.
> >
>
> So this ended up being because I didn't enable the "nestedprocvars" mode
> switch and you get that error assigning to a "is nested" procedure
> variable. This has bitten me so many times. That error message is
> basically worthless to a user and should probably be changed.
>

Still, provide an example, please.

Regards,
Sven

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

Re: [fpc-pascal] Incompatible procedure types

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 8. Nov. 2023, 01:48:

> What does this error mean? It's comparing a pointer to a procedure to a
> procedure variable (a callback). The signature appears exactly the same
> "function(TSymbol;TSymbol):LongInt is nested" so what's the problem?
>
> error: Incompatible type for arg no. 2: Got " function(TSymbol;TSymbol):LongInt is nested;StdCall>", expected
> "TSList$1$crcCC4DE170_crc9A33B934. function(TSymbol;TSymbol):LongInt is nested;StdCall>"
>

Please provide example code so that one can look at it. Such messages
without example are more often than not simply useless.

Regards,
Sven

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

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Sa., 4. Nov. 2023, 15:48:

>
>
> > On Nov 4, 2023, at 4:22 PM, Sven Barth 
> wrote:
> >
> > Then don't assign them every "frame". If you just keep them around then
> they aren't more expensive than a virtual method call.
> > And any other mechanism would involve the heap as well, because that's
> how anonymous functions that capture variables work and thus anything that
> wants to store them must play by the same rules. There won't be any changes
> there.
> >
>
> The need for a universal function pointer type really isn't about the
> function references even though they work for that, albeit with unneeded
> overhead.
>
> Lets say you have a sort function which takes a compare callback
> parameter. You can make the callback type "is nested" which works on global
> and nested/anonymous functions but not methods. What if the user wants to
> provide the compare function as a method because they're calling it in a
> class which shares the code elsewhere? As the writer of the function you'd
> need to make 2 versions of the function, one "is nested" and "of object".
>
> The writer of the sort function shouldn't need to know what kind of
> function it will be passed, just that a comparison callback is provided,
> right?
>

Then you simply make the callback function type a function reference and be
done. The user can pass in any kind of function they want and *nearly*
every type of function-like pointer.

And if you're really worried about performance when providing such a class
then simply provide overloads woth different function-like pointer types,
the compiler will pick the most suitable one then.

It's really not that hard as an implementer of a class.

Regards,
Sven

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

Re: [fpc-pascal] Compiler probem?

[Sven Barth via fpc-pascal]

Paul Renaud via fpc-pascal  schrieb am
Sa., 4. Nov. 2023, 16:18:

> Hi, I have a question about some code.
>
> The following code segment generated a compiler error when I compiled it
> with...
>
> fpc Sample -Se -gl -al
>
> but not when it's compiled with...
>
> fpc Sample -Se -gl
>
> ...
> Asm
>   LdRH R0, [ R1, R2, LSL #1 ]
> End [ 'R0',  'R1' ];
> ...
>
> Any idea why?  Its driving me crazy.
>

Please provide information what target your compiling for, what target you
are compiling from, the compiler version you are using, the exact error you
get and a complete code example.

Regards,
Sven

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

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Sa., 4. Nov. 2023, 01:42:

>
>
> > On Nov 3, 2023, at 8:31 PM, Sven Barth 
> wrote:
> >
> > If you need a catch all type, then you should use function references.
> There is no need to invent yet another type.
> > The only thing it can not handle is the assignment of nested function
> pointers (in contrast to nested functions directly), because they can only
> ever be used in a function that is below the one where the nested function
> was assigned which is not a guaranteed property for function references.
> >
>
> not always because it creates a heap allocated interfaces for every
> function they're used in, even if it doesn't escape the scope. Maybe this
> was fine for Delphi but they can't be used for anything real time outside
> of GUI apps.
>

Then don't assign them every "frame". If you just keep them around then
they aren't more expensive than a virtual method call.
And any other mechanism would involve the heap as well, because that's how
anonymous functions that capture variables work and thus anything that
wants to store them must play by the same rules. There won't be any changes
there.

Regards,
Sven

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

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Fr., 3. Nov. 2023, 12:37:

>
>
> > On Nov 3, 2023, at 2:08 PM, Sven Barth 
> wrote:
> >
> > By default the purpose of anonymous functions assigned to function
> references *is* that they can escape their scope. This will not change,
> because they were after all introduced for Delphi-compatibility and there
> won't be any designations that the value can't escape. If the compiler
> can't figure it out by its own (see above) then tough luck; use a feature
> better suited for that.
> >
>
> Ok I misinterpreted what you previously said then.
>
> I think Swift does this because they only have a single function pointer
> type which serves all purposes while FPC has 4 distinct types.
>
> IMO FPC needs this also since it's not possible for libraries to know
> which kind of function the caller may provide. Behind the scenes the
> different types are required (global, nested, method, reference) but there
> should be a way to unify these into single type. How to store the capturer
> and manage its memory would be an open question though.
>

If you need a catch all type, then you should use function references.
There is no need to invent yet another type.
The only thing it can not handle is the assignment of nested function
pointers (in contrast to nested functions directly), because they can only
ever be used in a function that is below the one where the nested function
was assigned which is not a guaranteed property for function references.

Regards,
Sven

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

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Hairy Pixels  schrieb am Fr., 3. Nov. 2023, 02:00:

>
>
> > On Nov 2, 2023, at 1:44 PM, Sven Barth 
> wrote:
> >
> > Now for nested as well as anonymous routines the compiler determines
> whether a capturer is required at the point that the nested or anonymous
> routine is assigned to a function reference (cause otherwise it can be
> handled as a nested function or even a function or method pointer). This
> requirement is detected during the parsing of the routine.
>
> On second thought I had some questions about this part. From what I see
> FPC always allocates the interface when reference pointers are used but
> what you write suggests maybe the compiler will demote the type to
> something more optimized (like a nested function). We talked about this at
> length before but I don't think anything was decided yet.
>
> for example:
>
> procedure DoThis;
> var
>   proc: reference to procedure;
> begin
>   proc := procedure
>   begin
>   end;
>   proc();
> end;
>
> doesn't need the heap allocated instance because the function reference
> never escapes the scope and it has no captured variables so it could be
> demoted to a global function even of nested.
>

As soon as an anonymous function gets assigned to a function reference it
*must* be converted to a method of the capturer and an interface to that
must be assigned to the function reference. Because that's what function
references are: interfaces.

If you don't want that then call the anonymous function directly without
assigning it to anything or assign it to a nested function pointer and call
that.

In *theory* the compiler could detect that "proc" doesn't leave the scope
and that it's value is "constant" (namely a function) and thus could
optimize that, but that requires quite some improvements to the optimizer.


> In fact Swift requires you to mark closures types as "@escaping" if they
> can escape the current scope so that the compiler can be optimize them.
> This is the feature I was thinking FPC needs.
>

By default the purpose of anonymous functions assigned to function
references *is* that they can escape their scope. This will not change,
because they were after all introduced for Delphi-compatibility and there
won't be any designations that the value can't escape. If the compiler
can't figure it out by its own (see above) then tough luck; use a feature
better suited for that.

Regards,
Sven

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

Re: [fpc-pascal] Creating capturers

[Sven Barth via fpc-pascal]

Am 01.11.2023 um 06:18 schrieb Hairy Pixels via fpc-pascal:

I'm curious how the capturer is created in the case of anonymous functions. I 
know the function needs to create a capturer when nested functions are declared 
but what happens if there is an anonymous function which is declared in the 
code section?

I think the compiler will only know about the requirement to create a capturer 
at this point but local variables have already been assigned so do they need to 
do an extra copy to the capturer when it's created?

With nested function this is not a problem since the capturer can be created 
before any locals are assigned and thus not copying is needed, if I understand 
correctly.


The most important piece of knowledge is that in a routine with nested 
(or anonymous) routines the nested (or anonymous) routines aren't 
compiled down to machine code right away. The compiler first parses the 
whole hierarchy until it's on the global/method level again and only 
*then* it compiles the outermost routine followed by the nested ones.


Now for nested as well as anonymous routines the compiler determines 
whether a capturer is required at the point that the nested or anonymous 
routine is assigned to a function reference (cause otherwise it can be 
handled as a nested function or even a function or method pointer). This 
requirement is detected during the parsing of the routine.


If the routine requires a capturer then after the whole hierarchy has 
been parsed, then all the captured variables will be moved from the 
local symtable of the routine to the capturer or corresponding capture 
variables for parameters will be introduced and then the whole nodetree 
will be walked to adjust usages of the involved symbols.


So, no, there is no copy involved (except for parameter values right at 
the start of a routine where a parameter is captured) as the whole 
variables are relocated into the capturer and they're only ever accessed 
from there.


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

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

[Sven Barth via fpc-pascal]

Martin Frb via fpc-pascal  schrieb am Mi.,
25. Okt. 2023, 21:38:

> Thanks, but that isn't the part of the answer I was looking for
>
> I was looking for a global operaton :=
>
> That could be used for an array (rather than just record/class).
>
> But according to the docs that I found that is not possible
>

Correct.

Delphi does not support global operator overloads and not every feature
that is available in FPC is made available in mode Delphi the main purpose
of which is to compile Delphi code after all.

Regards,
Sven

On 24/10/2023 23:51, Sven Barth via fpc-pascal wrote:
>
> Martin Frb via fpc-pascal  schrieb am
> Di., 24. Okt. 2023, 23:30:
>
>> Is there a modeswitch to enable it?
>>
>>
>> Because currently I am getting an error in mode delphi.
>>
>
> In mode Delphi it's called "Implicit" as Delphi does not support symbolic
> operator overloads.
>
> Regards,
> Sven
>
>>
> ___
> fpc-pascal maillist  -  
> fpc-pascal@lists.freepascal.orghttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
> ___
> fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

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

[Sven Barth via fpc-pascal]

Martin Frb via fpc-pascal  schrieb am Di.,
24. Okt. 2023, 23:30:

> Is there a modeswitch to enable it?
>
>
> Because currently I am getting an error in mode delphi.
>

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

Regards,
Sven

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

Re: [fpc-pascal] Error: compilation raised exception internally

[Sven Barth via fpc-pascal]

Thomas Kurz via fpc-pascal  schrieb am
Sa., 21. Okt. 2023, 19:22:

> > An exception or an internal error during compilation should *always* be
> > reported.
> > Please also provide a minimal, self contained example that shows the
> > problem.
>
> This is not always trivial because the internal errors are sometimes quite
> fiddly. I have a project in which an internal error occurs sometimes. When
> I do a "cleanup and build" (in Lazarus), it works well. There seems to be
> an influence of the order in which units are compiled, because I can change
> code in many places without getting the internal error again. But when I
> change code in other units, I get the internal error, but it's clearly
> uncorrelated to the line at which it occurs.
>

Without a way to reproduce and debug the issue it's very unlikely to get
solved especially if it's a problem that only occurs in very specific
circumstances.

Regards,
Sven

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

Re: [fpc-pascal] Error: compilation raised exception internally

[Sven Barth via fpc-pascal]

Rafael Picanço via fpc-pascal  schrieb am
Sa., 21. Okt. 2023, 02:50:

> Hi everyone,
>
> I am getting a strange error when compiling a project. I am really not
> sure what is going on, because it occurs sometimes, consistently in some
> lines of the code with calls to this static variable:
> ...
> function NextID(ID : word) : word;
> ...
> NextID(ContainerClass.SomeTypeInstance.ID)
> ...
> type
>   TSomeType = class(TSomeBaseClass)
>   public
> ID : TTrialID; static;
>   end;
>
> I hit F9 again and then the project compiles with error.
>
> Any suggestions? Should I care about this error and report it??
>

An exception or an internal error during compilation should *always* be
reported.
Please also provide a minimal, self contained example that shows the
problem.

Regards,
Sven

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 16. Okt. 2023, 15:14:

>
> > That's absurd, there are many features in modes objfpc and macpas
> > that don't compile with Delphi.
> >
> >
> > That doesn't make it any less true.
> >
> > Also we won't add it anyway, so... 🤷‍♀️
>
> Apperently, a sensible discussion, based on logical arguments, instead of
> dogma, is impossible.
>

To quote our FAQ at https://www.freepascal.org/faq.html with the entry
"There is a new language extension that would be really useful. Will you
include it?" at point 2:

"The extension must have real value. Anything that is only a shorter
notation does not apply, unless it is out of compatibility with an existing
Pascal/Delphi codebase. Practically it means it must make something
possible that cannot be done otherwise or be a compatibility item"

Your suggestion fails that as it is merely syntactic sugar for something
you can accomplish using existing mechanisms even if it might be more
involved.

Regards,
Sven

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
So., 15. Okt. 2023, 08:54:

> Sven Barth via fpc-pascal wrote:
> > There will be no new visibility specifiers for something like this.
> >
> > And yes, it affects compatibility, as that means that code using that
> > feature couldn't be compiled with Delphi and especially for library
> > developers that might be an important point.
>
> That's absurd, there are many features in modes objfpc and macpas that
> don't compile with Delphi.
>

That doesn't make it any less true.

Also we won't add it anyway, so... 🤷‍♀️

Regards,
Sven

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

Re: [fpc-pascal] free pascal compiler on Linux Red Hat for target motorola 68k

[Sven Barth via fpc-pascal]

LECUYER Philippe via fpc-pascal  schrieb
am Sa., 14. Okt. 2023, 15:16:

> Hi,
>
> I search a free pascal cross compiler (for host Linux Red hat 7.x and
> target Motorola 68k)
>
> I test the last 3.2.2 version but I doesn’t find the option for target
> Motorola 68k (fpc –help)
>
> It’s run when I compile an example (in examples directory) and execute on
> Linux RH 7.x but I want to produce the binary for 68k target.
>
> Thanks for helping me.
>

You need to build a suitable compiler. For this you download the source
(either 3.2.2 or the development version 3.3.1) and do a make:

make all CPU_TARGET=m68k OS_TARGET=linux BINUTILSPREFIX=
FPMAKEOPT="-T " - j 

Where  is the prefix of the binutils for 68k (as and ld, e.g.
m68k-linux-gnu-) and  is the number of CPU cores you have.

After that you do a

make install CPU_TARGET=m68k OS_TARGET=linux BINUTILSPREFIX=
INSTALL_PREFIX=/path/to/the/destination

Depending on the destination path you need to do that as root.

There are further details, but I can't describe them right now, so don't
hesitate to ask if you have issues.

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Fr., 13. Okt. 2023, 11:02:

> Michael Van Canneyt via fpc-pascal wrote:
> >
> >
> > On Wed, 11 Oct 2023, Adriaan van Os via fpc-pascal wrote:
> >
> >> Michael Van Canneyt via fpc-pascal wrote:
> >>
> >>> $M controls the inclusion of RTTI, i.e. it allows or disallows the
> >>> use of the published section.
> >>> No more, no less.
> >>
> >> I don't see any use in allowing or disallowing something. And with the
> >> current design, it is, as I said, impossible, without macros, to
> >> compile the same code with {$M+} and {$M-}.
> >
> > While I agree with your statement about allowing/disallowing use of
> > 'published' based on a directive, we inherited this from Delphi and it
> > is a very basic part of the language & RTL, so changing it is simply not
> > an option.
>
> Well, as I said, adding a new visibility specifier, e.g. "visible",
> meaning "public" in {$M-} state
> and "published" in {$M=}", does in no way degrade compatibility with
> Delphi code. One could reserve
> the new visibility specifier for modes objfpc and macpas.
>

There will be no new visibility specifiers for something like this.

And yes, it affects compatibility, as that means that code using that
feature couldn't be compiled with Delphi and especially for library
developers that might be an important point.

Regards,
Sven

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mi., 11. Okt. 2023, 06:25:

> Sven Barth via fpc-pascal wrote:
> > Am 10.10.2023 um 11:18 schrieb Adriaan van Os via fpc-pascal:
> >>
> >>>
> >>> - In the released compiler, if you remove all visibility specifiers,
> >>> you can
> >>>   get a list by specifying {$M+} on your base object and then list all
> >>>   published methods using the RTTI.
> >>
> >> My understanding is that I have to explicitely specify public for
> >> class fields, otherwise the compiler will issue an error.
> >
> > What exactly do you mean here? Do you have an example?
>
> {$mode macpas}
> {$M+}
> program testrtti;
> type
>T = object( TObject)
>  i: integer;
>  procedure A;
>end;
> procedure T.A;
>begin end;
> begin
> end.
>
> Free Pascal Compiler version 3.0.4 [2018/09/30] for x86_64
> Copyright (c) 1993-2017 by Florian Klaempfl and others
> Target OS: Darwin for x86_64
> Compiling testrtti.pas
> testrtti.pas(6,5) Error: Symbol cannot be published, can be only a class
> testrtti.pas(13) Fatal: There were 1 errors compiling module, stopping
>

Ah, yes, only classes and interfaces can be used for published fields. For
properties anything is allowed.

Regards,
Sven

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Am 10.10.2023 um 11:18 schrieb Adriaan van Os via fpc-pascal:




- In the released compiler, if you remove all visibility specifiers, 
you can

  get a list by specifying {$M+} on your base object and then list all
  published methods using the RTTI.


My understanding is that I have to explicitely specify public for 
class fields, otherwise the compiler will issue an error.


What exactly do you mean here? Do you have an example?

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Am 10.10.2023 um 11:01 schrieb Adriaan van Os via fpc-pascal:

Sven Barth via fpc-pascal wrote:

No. Only those in the published section are part of the vMethodTable. 
And when compiled with $M+ the default visibility is changed from 
public to published. 


Also, I can get a list of the interfaces inherited from by a class, by 
looking at the vIntfTable of the VMT of the class. But is there also a 
way to get the method names from a CORBA interface ?


CORBA or raw interfaces don't have RTTI generation enabled. And even 
then the (COM) interfaces also need to have been parsed with $M enabled.


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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Am 10.10.2023 um 02:04 schrieb Adriaan van Os via fpc-pascal:

Sven Barth via fpc-pascal wrote:

No. Only those in the published section are part of the vMethodTable. 
And when compiled with $M+ the default visibility is changed from 
public to published. 


OK, but that means that by explicitely specifying 
public/private/protected for fields and published for methods, a 
method list can be generated when compiling with {$M+}.


Only for the class that is parsed while $M is enabled and all that 
inherit from that class. It does not affect any parent classes that 
don't have $M enabled.


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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 9. Okt. 2023, 15:44:

> > Is there a trick to make (in mode macpas) all class methods implicitely
> virtual ? I mean, without
> > adding the virtual keyword to all of them ? The reason is that I want to
> create a tree view of the
> > class hierarchy with all the method names (not just those that are
> normally in the VMT because they
> > are overridden).
>
> Hm, looking somewhat further, it seems that the vMethodTable of the class
> VMT does list all
> methods, not just the virtual methods, provided the code was compiled with
> type info {$M+}
>
> is that correct ?
>

No. Only those in the published section are part of the vMethodTable. And
when compiled with $M+ the default visibility is changed from public to
published.

Regards,
Sven

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

Re: [fpc-pascal] All methods vitrual ?

[Sven Barth via fpc-pascal]

Adriaan van Os via fpc-pascal  schrieb am
Mo., 9. Okt. 2023, 14:29:

> Is there a trick to make (in mode macpas) all class methods implicitely
> virtual ? I mean, without
> adding the virtual keyword to all of them ? The reason is that I want to
> create a tree view of the
> class hierarchy with all the method names (not just those that are
> normally in the VMT because they
> are overridden).
>

No, there is no such way.

Regards,
Sven

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

Re: [fpc-pascal] Barriers semantics

[Sven Barth via fpc-pascal]

Jonas Maebe via fpc-pascal  schrieb am
Mo., 14. Aug. 2023, 21:02:

> On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote:
> > Now we have "volatile" intrinsic for assignments in place, I'd like to
> ask for another clarification.
>
> Just to make sure given your questions below: using volatile in the
> context of multithreaded code is completely wrong in 99.9% of the cases,
> and when it's not in the best case it's usually just highly inefficient.
> volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect.
>
> > Documentation states we have following barriers - ReadBarrier,
> WriteBarrier, ReadDependencyBarrier, ReadWriteBarrier.
> >
> > I'd like to get an idea how those related to more common / standard
> terms - Acquire/Release & their combinations?
>
> Read/Write barriers are terms used in cpu architecture manuals.
> Acquire/Release are high level parallel programming terms.
>

Doesn't Aarch64 use acquire/release instructions for locking? 🤔


> > Is it safe to assume that:
> >
> > ReadBarrier - Acquire
> > WriteBarrier - Release
> > ReadWriteBarrier - Acquire+Release
> > ReadDependencyBarrier - which one is that?
>
> You cannot express a ReadDependencyBarrier in terms of acquire/release.
> See e.g. the explanation of "data dependency barrier" at
> https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In
> practice, I don't think any currently used cpu architectures still
> require such barriers though.
>

It depends on the use case. When working with external hardware onm Aarch64
(e.g. with DMA) they are very much a necessity.

Regards,
Sven

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

Re: [fpc-pascal] Pointer question

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 10. Aug. 2023, 18:30:

>
>
> > On Aug 10, 2023, at 5:43 AM, Bernd Oppolzer via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > PTRADD (p, i) - p is type ANYPTR, i is integer, result is of type ANYPTR
> > PTRDIFF (p1, p2) - two pointers, the result is integer
> > ANYPTR is a predefined type, compatible with every (typed pointer)
> > ADDR (x) is a function (borrowed from PL/1), which returns an ANYPTR ...
> and it is allowed for all types of variables
> > PTRCAST is the same as PTRADD (p, 0) - and is used to cast pointers
> between incompatible pointers (not type safe)
> >
>
> Not a bad idea to clarify this. Besides p + 1 the pointer math operators
> are difficult to understand and feel antiquated.
>

Then you simply aren't using them often enough. E.g. the RTTI internal code
is full of them and additional typecasts would simply muddle up otherwise
relatively clear code.

Regards,
Sven

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

Re: [fpc-pascal] Pointer question

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Mi., 9. Aug. 2023, 04:59:

> I just noticed this by accident and I don't understand. Why does " x :=
> @r; " compile? I would expect it to fail like the next line where I cast to
> the explicit type.
>
> type
>   TMyRec = record end;
>   PMyRec = ^TMyRec;
> var
>   x: PByte;
>   r: TMyRec;
> begin
>   x := @r;// works
>   x := PMyRec(@r);  // fails
> end.


By default @ returns a *untyped* pointer that can be assigned to any
pointer type. Thus is compatible with Delphi and can be controlled with the
$TypedAddress directive (there's a slight exception to this when you assign
a pointer to a function to a function variable (etc) or pass it to such a
parameter, because the compiler has to pick the correct overload if there
are multiple functions with the same name in scope).

Regards,
Sven

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

Re: [fpc-pascal] $IMPLICITEXCEPTIONS vs early function return

[Sven Barth via fpc-pascal]

Am 14.07.2023 um 18:41 schrieb Hairy Pixels via fpc-pascal:

Question is, how is this different from early function returns? Does the 
compiler still need to wrap the whole function body in try..finally to capture 
any places the function could return?


There is no difference between early return or not, because if the early 
return isn't taken any other path needs to be protected as well. Thus 
the whole function is wrapped which deals with all of that - and also 
simplifies the implementation.


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

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

[Sven Barth via fpc-pascal]

Mattias Gaertner via fpc-pascal  schrieb
am Sa., 24. Juni 2023, 13:12:

> Hi,
>
> With development fpc I get a lot of messages like:
>
> fgl.pp(1112,1) Note: (3123) "inherited" not yet supported inside inline
> procedure/function
>
> Since most users can't do anything about the fgl inline modifier, this
> message dilutes the output.
>
> IMO such a message should be off by default.
>
> What do you think?
>

They are a reminder for us devs that these need to be fixed in the long
term. If the messages are off by default *no one* will care about them.
This way I least am reminded regularly that I want to give fixing them a
try.

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Michael Van Canneyt via fpc-pascal 
schrieb am Sa., 24. Juni 2023, 14:18:

>
>
> On Sat, 24 Jun 2023, Mattias Gaertner via fpc-pascal wrote:
>
> > Hi,
> >
> > With development fpc I get a lot of messages like:
> >
> > fgl.pp(1112,1) Note: (3123) "inherited" not yet supported inside inline
> > procedure/function
> >
> > Since most users can't do anything about the fgl inline modifier, this
> > message dilutes the output.
> >
> > IMO such a message should be off by default.
> >
> > What do you think?
>
> The simplest solution is to remove the inline modifier, since it is clearly
> superfluous for that routine.
>
> According to Florian, inline should not be used to begin with, since the
> compiler should be able to decide autonomously to inline a routine or not.
>

I don't agree with Florian here cause the compiler detecting an inlineable
routine that's declared in the interface section means an interface change
after the interface section was already parsed and thus leading to the
necessity to do recompilations which are already not working that well.

Regards,
Sven

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

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

[Sven Barth via fpc-pascal]

Am 18.06.2023 um 19:28 schrieb Travis Siegel via fpc-pascal:


On 6/18/2023 1:04 AM, Hairy Pixels via fpc-pascal wrote:
I don't remember break NOT being in Pascal. How did you exit a loop 
otherwise, goto? Break is common in basically all languages now. 
Can't think of a language I've used without it.


Use a variable, set the variable when you hit an exit criteria, then 
before repeating the loop, check the variable, if it's true, exit the 
loop (exit does this), or just craft the loop (easy to do if it's a 
loop until construct) so it exits the loop automatically.  Probably 
not as efficient as break, but since I didn't know it was a valid 
command, 


“Exit” leaves the surrounding *function*, not the surrounding *loop*.

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

Re: [fpc-pascal] Non-initialized member access warning

[Sven Barth via fpc-pascal]

Am 07.06.2023 um 10:44 schrieb Hairy Pixels via fpc-pascal:

I'm curious, why doesn't the following code give a warning? Shouldn't the compiler know 
you're assigning to "r" which hasn't been initialized yet?

type
TMyClass = class
x: integer;
end;

procedure MyProcedure;
var
r: TMyClass;
begin
r.x := 1;
end;


Please report a bug with a complete example.

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

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

[Sven Barth via fpc-pascal]

Martin Frb via fpc-pascal  schrieb am So.,
4. Juni 2023, 18:10:

> On 04/06/2023 17:49, Martin via fpc-pascal wrote:
> > On 04/06/2023 15:04, Juha Manninen via fpc-pascal wrote:
> >> Why the following code fails to compile?
> >> MyObj.RecInstance.ii := 123;
> > Technically you can modify the members of the temp record (just to
> > have the work thrown away afterwards).
> >
> > So I guess the compiler forbids it, because the only case it would
> > ever be done is: by mistake.
>
> Btw, this works (or actually not, it works wrong)
>
>with  MyObj.RecInstance do {begin} ii := 123; {end;}
>
> Now you could do some work with the temp result, and have it trashed at
> the end of the "with" block.
>
> However, fpc incorrectly changes the value in the original record.
> Yet, don't use it. It will (likely) change, and stop working. (or work
> correctly, changing the temp value only).
>

Correct. This *will* be fixed also. There already is a bug report about it.

Regards,
Sven

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

Re: [fpc-pascal] Make a distinct pointer type

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 1. Juni 2023, 03:16:

>
>
> > On May 31, 2023, at 9:20 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > Type aliases are always assignment compatible.
>
> btw, what does the "type" prefix do then? I thought that made them
> non-aliases or distinct types.
>

It only makes a difference for the RTTI as well as overloading.

Regards,
Sven

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

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Steve Litt via fpc-pascal  schrieb am Di.,
30. Mai 2023, 21:57:

> I don't know about other operating systems, but on Linux a crashed
> program gives up all its memory, even leaked memory, upon termination,
> so I'm not sure why this attention to memory leak on abnormal
> termination is even necessary.
>

An exception does not have to end with the program's termination. And if
the program does not terminate due to an exception it makes sense to avoid
memory leaks as the program might be long running.

Regards,
Sven

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

Re: [fpc-pascal] Compile time -> processor benchmark values

[Sven Barth via fpc-pascal]

Am 29.05.2023 um 15:23 schrieb Rainer Stratmann via fpc-pascal:

Now I have a i7-3770S

cpubenchmark says:
Average CPU Mark: 6175
Single Thread Rating: 2043
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-3770S+%40+3.10GHz

I expect to buy a new computer with a i5-13400F or similar
cpubenchmark says:
Average CPU Mark: 25969
Single Thread Rating: 3702
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-13400

What is important for the compile time?
The average CPU Mark that means more than 4 times faster?
Or the single thread rating that means 1,8 times faster?

Besides faster memory, ssd, etc.


FPC itself is single threaded. So for that the single thread rating is 
more important. However Lazarus (and fpmake) can parallelize the 
building of packages if they don't depend on each other. On the other 
hand this is only really important when rebuilding and not when doing 
normal builds.


So in my opinion I'd keep an eye on the single thread rating.

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

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Mattias Gaertner via fpc-pascal  schrieb
am Do., 25. Mai 2023, 08:23:

> On Thu, 25 May 2023 07:55:39 +0200
> Sven Barth via fpc-pascal  wrote:
>
> >[...]
> > But this is what "managed type" *means*: that the compiler and RTL
> > will make sure that it's correctly freed as long as nothing
> > unexpected happens.
>
> ... and exceptions are expected.
>

Depends on the circumstances: in code with disabled implicit exception
frames, but managed types exceptions are to be considered unexpected. But
otherwise they are indeed expected.


> Maybe better: As long as the user does not break the rules.
>

Agreed.

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

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 25. Mai 2023, 04:32:

>
>
> > On May 24, 2023, at 8:46 PM, Michael Van Canneyt via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > I see no problem, I am used to this.
> >
> > This is Pascal, you need to manage your memory and hence your
> references, this is true even in the absence of exceptions: In your example
> you would
> > also need to remember to remove your instance from the list after you
> free
> > it, even if there are no exceptions.
>
> My example is still not good. The problem I have is that once exceptions
> are used in a program calling any function now has a side effect of
> completely exiting the calling function so you need to be paranoid and wrap
> everything in try blocks just in case. A new added burden for manual memory
> management.
>

I'd say you're over thinking things. The main part is that you protect
locally allocated memory (be it class instances or plain pointers) using
"try... finally" and make sure other memory is for example deallocated in a
destructor. If that's ensured then you can have exceptions bubble up as far
as you're comfortable. E.g. in a LCL application if an exception is raised
somewhere inside an event handler and it isn't explicitly handled there it
will in the end result in a shown error dialog. Assuming all resources
along the way were guarded by resource protection blocks life can just go
on then when the user closes the dialog.

In essence: always protect the resources and only handle an exception
explicitly if you can provide the user with a better error message than
what the exception already provides or have can give them the ability to
correct something.

Why is this better than handling errors as values like a normal function
> result?
>

This would mean that every function (and procedure) that can fail or calls
a routine that can fail would have to provide some kind of error channel
and the user would then have to check this, cluttering their code with
error checks (just look at how correctly error checked code with classic
Pascal I/O looks with all the checks for IOResult).
With exceptions you can simply concentrate on the meaty parts of your
algorithms or business logic and let the language itself deal with the
exceptional (pun intended).

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

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Hairy Pixels via fpc-pascal  schrieb am
Do., 25. Mai 2023, 04:26:

>
>
> > On May 24, 2023, at 10:11 PM, Sven Barth via fpc-pascal <
> fpc-pascal@lists.freepascal.org> wrote:
> >
> > You must have $H+ on and those are AnsiStrings? Why is there exception
> handling involved with AnsiString? I guess it needs this just in case an
> exception is thrown somewhere in the call stack?
> >
> > Because Ansi- and UnicodeString are managed types. *All* managed types
> managed string types, interfaces, Variants, managed records) must be
> finalized correctly even if an exception occurs.
> >
>
> That's a problem with exceptions then, they are baked into the language
> and impose a cost on all managed types now even if we use them or not. Even
> disabling the implicit stack frames (forgot what it's called) doesn't get
> around this right?
>

Disabling implicit exception frames does exactly what it says in the tin
and removes these automatically generated frames. This however opens you to
potential memory leaks if an exception occurs, so one should think twice
whether one uses this option.
Thankfully it's a local directive, so one can make this choice for every
function.

But this is what "managed type" *means*: that the compiler and RTL will
make sure that it's correctly freed as long as nothing unexpected happens.

Regards,
Sven

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

Re: [fpc-pascal] Freeing memory with exceptions

[Sven Barth via fpc-pascal]

Benito van der Zander via fpc-pascal 
schrieb am Do., 25. Mai 2023, 00:15:

> Hi
>
>
> Then also run FPC/win32 in wine for a real comparison.
>
>
> Or perhaps against modern C++ on Linux would also be a real comparison
>

It wouldn't be, because that would compare two different languages. C++
doesn't have a concept of resource protection blocks like Object Pascal
has.

Regards,
Sven

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