[fpc-pascal] http://wiki.freepascal.org/ web site is totally blank
Does it only happen to me? Dennis ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] http://wiki.freepascal.org/ web site is totally blank
There was a thread yesterday about issues with the servers. This may be related. Jeff On Thu, Jun 6, 2019 at 4:58 AM Dennis wrote: > Does it only happen to me? > > Dennis > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] FReeBSD changing linker
Hi, some changes on FreeBSD 12 and up seem to affect FPC and Lazarus, see "Tasks" list at the end of the quotation. Maybe it is of special interest to the dev team. Re-posting a part of FreeBSDs Quarterly Status Report Q1 2019: " LLVM's lld as the FreeBSD system linker Links LLD on the FreeBSD Wiki URL: https://wiki.freebsd.org/LLD lld exp-run URL: https://bugs.freebsd.org/214864 Contact: Ed Maste In FreeBSD-HEAD and 12.0 the default FreeBSD system linker (i.e., /usr/bin/ld) is LLVM's lld, on amd64, arm64, and armv7. For i386 in 12.0 lld is used as the bootstrap linker (i.e., to build the kernel and base system) but it is not enabled as the system linker because of multiple issues building FreeBSD ports with it enabled. The primary issue affecting i386 with lld is that many ports build position-dependent code (i.e., non-PIC) for use in shared libraries. This either comes from omitting the -fPIC compiler flag, or using hand-written position-dependent assembly. Compared with other CPU architectures i386 position-independent code is rather inefficient, which may be responsible for port authors making an explicit decision to avoid PIC. By default lld does not allow position-dependent code in shared objects (in particular, it does not permit relocations against read-only segments - typically containing the`.text` section). Over the last quarter many commits were made to the ports tree to fix the build when the system linker is lld - either building PIC code, or adding the -znotext linker flag to permit relocations against read-only segments, or just switching the port to link with GNU ld if it is incompatible with lld in some other way. At this point there are only a few dozen open bug reports for issues linking ports with lld as the system linker, and I expect FreeBSD 12.1 to use lld as the system linker on i386 as well. Tasks: * Fix freepascal/Lazarus ports with lld * Triage and address remaining port failures * Holistic review of lld workarounds in the ports tree, to identify changes that are no longer needed, should be addressed in lld, or should be sent upstream This project was sponsored by The FreeBSD Foundation. " -- Marc Santhoff ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class field property access
> On Jun 3, 2019, at 11:13 AM, Sven Barth via fpc-pascal
> wrote:
>
> The b field could be Nil and the class might not provide any functionality to
> check for that. In addition to that it's an additional indirection while
> records/objects merely require an offset.
>
{ I’ve resubscribed to the list with a new email since the mail server wasn’t
liking my old one. Resending this message since it was rejected before. }
But my point is Pascal allows this kind of behavior so why are properties
different? Who cares if there is an additional level of indirection? This
appears to be a regression since 3.0.4 also. Did you specifically disable this
in 3.3.1? Sorry I’m not understanding this one.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Class field property access
On Thu, 6 Jun 2019, Ryan Joseph wrote:
On Jun 3, 2019, at 11:13 AM, Sven Barth via fpc-pascal
wrote:
The b field could be Nil and the class might not provide any functionality to check for that. In addition to that it's an additional indirection while records/objects merely require an offset.
{ I’ve resubscribed to the list with a new email since the mail server wasn’t
liking my old one. Resending this message since it was rejected before. }
But my point is Pascal allows this kind of behavior so why are properties
different?
What kind of behaviour are you referring to.
Who cares if there is an additional level of indirection?
Because the indirection may not be there.
The compiler cannot guarantee that, thus leading to access violations.
You can use a getter function to get the desired property. In the getter you
can decide what to do: create the b instance (sometimes a valid choice)
or raise an error.
But the compiler cannot take this decision for you, so b.x is not allowed.
This appears to be a regression since 3.0.4 also. Did you specifically
disable this in 3.3.1? Sorry I’m not understanding this one.
If it was allowed in previous versions, this was by accident allowed during
parsing and most likely simply didn't work in reality.
Michael.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
