On 14-02-13 21:34, Michael Ring wrote:
I did a grep through the fpc sourcecode and found a reference in
./compiler/systems/t_linux.pas in an arm related ifdef section
add(' .note.gnu.build-id : { *(.note.gnu.build-id) }');
so perhaps this is really missing in arm-embedded target.
The patch f
On 2/13/13, Sven Barth wrote:
> We could maybe adjust the string list in so far that at the beginning of
> QuickSort we determine whether ExchangeItem was overridden, if it was we
> call the now virtual, protected ExchangeItem and if it was not overriden
> we call a private non virtual version (w
On Fri, 15 Feb 2013, Bart wrote:
On 2/13/13, Sven Barth wrote:
We could maybe adjust the string list in so far that at the beginning of
QuickSort we determine whether ExchangeItem was overridden, if it was we
call the now virtual, protected ExchangeItem and if it was not overriden
we call a
If multiple, related, programs running on unix (Linux, Solaris etc.)
refer to the same configuration file accessed via a TIniFile, is there
any recommended "good practice" to ensure that they don't try to update
it simultaneously?
In the case that I'm thinking of, I don't anticipate e.g. multi
I would not use INI if the systems are writing data. While I've had
plenty of success reading INI files in parallel - I seem to recall that
the file is just streamed out without regard to which version is on
disk. I think the file is completely refreshed.
I recommend using a DBMS system of s
This is a minor issue, just a question of design...
I understand that by design abstract methods cannot be called and that
doing so is an error.
However FPC used to allow an abstract method to be called from an
overriding descendant method without any error (and without doing
anything useful, of
