Re: [fpc-devel] RTTI module and "IsManaged" critical problem

[Sven Barth]

On 09.12.2016 22:57, Maciej Izak wrote:
> Hi,
> 
> thanks Sven, finally we have initial RTTI.pas version on trunk. Let me
> start with first serious issue and eventually patch:
> 
> function IsManaged(TypeInfo: PTypeInfo): boolean;
> 
> IsManaged can't work with records because we need know managed fields
> count (in Delphi when ManagedFldCount is bigger than 0 it means that
> record has managed fields and problem is solved). Two possible (and IMO
> correct) solutions:
> 
> 1. I think it's time to new position in "User Changes" wiki page. We can
> fix that by new behavior (a more Delphi compatible, more logical, more
> proper and a little incompatible with old code, but the risk is
> minimal): ManagedFldCount should be fixed/corrected as mentioned in
> http://bugs.freepascal.org/view.php?id=29767 (so it should count *real*
> managed field as the name "ManagedFldCount" suggests. Otherwise we can't
> implement this function. Btw. old behavior for ManagedFldCount will be
> not usefully anymore with RTTI module/improved TypInfo for counting all
> fields. 

We rename ManagedFldCount to TotalFieldCount, add a field
ManagedFieldCount and a property ManagedFldCount that returns
TotalFieldCount for backwards compatibility (and maybe marked as
deprecated).

Regards,
Sven

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

Re: [fpc-devel] RTTI module and "IsManaged" critical problem

[Maciej Izak]

5. Super slowly checking for each field in ManagedFields, and eventually
new checking for each record in ManagedFields... I am so sad that I need to
post this point :\

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

[fpc-devel] RTTI module and "IsManaged" critical problem

[Maciej Izak]

Hi,

thanks Sven, finally we have initial RTTI.pas version on trunk. Let me
start with first serious issue and eventually patch:

function IsManaged(TypeInfo: PTypeInfo): boolean;

IsManaged can't work with records because we need know managed fields count
(in Delphi when ManagedFldCount is bigger than 0 it means that record has
managed fields and problem is solved). Two possible (and IMO correct)
solutions:

1. I think it's time to new position in "User Changes" wiki page. We can
fix that by new behavior (a more Delphi compatible, more logical, more
proper and a little incompatible with old code, but the risk is minimal):
ManagedFldCount should be fixed/corrected as mentioned in
http://bugs.freepascal.org/view.php?id=29767 (so it should count *real*
managed field as the name "ManagedFldCount" suggests. Otherwise we can't
implement this function. Btw. old behavior for ManagedFldCount will be not
usefully anymore with RTTI module/improved TypInfo for counting all fields.

2. http://bugs.freepascal.org/view.php?id=30687#c96093 PART 2 of reworked
patch for Management Operators should be accepted. With this path we have
access to Init RTTI table. Anyway solution 1 is strongly recommended.

Other "solutions" (IMO totally wrong):

3. New compiler intrinsic routine:

function IsManagedType(T: Type): Boolean;

which is no real alternative because IsManaged from RTTI.pas is more
run-time dedicated and is impossible to replace IsManaged by IsManagedType
for all scenarios. Generally new intrinsic IsManagedType is not wrong but
in our context is useless...

 4. New additional RTTI generated for records, for example new field for
TTypeData:

ThisIsRealAndNotFakeManagedFldCount: Integer;

with additional list declared after ManagedFields:
array[1..ManagedFldCount] of TManagedField:

ThisIsRealAndNotFakeManagedFields:
array[1..ThisIsRealAndNotFakeManagedFldCount] of TRealAndNotFakeManagedField

Or some flag in TTypeData for records:

YesIamManagedRecordAndIHaveRealManagedFieldsAndYesPleaseIgnoreManagedFldCountWhichIsLying:
boolean;

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] FPC black list details

[Maciej Izak]

2016-12-08 13:04 GMT+01:00 Jonas Maebe :

>
> The problem is that the bug report is about resolving calls specific to
> Objective-Pascal, which is only supported (and hence tested) on
> Darwin-based platforms by FPC (Mac OS X/OS X/macOS, iOS). So your testing
> probably did not cover this. If Alf confirms it works fine with trunk, I'll
> check your patch.


You were right... I was so close :\. Now I need to find some mac for better
testing experience. Thanks for improved version.

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Improved RTTI compromise

[Maciej Izak]

2016-12-09 21:53 GMT+01:00 Sven Barth :

> Also when you have extended the unit and provide your changes: please
> use baby steps, not one big patch to rule them all ;)
>

Thanks for tips for tests. I will start new topic - we need to discuss one
critical aspect...

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Improved RTTI compromise

[Sven Barth]

On 07.12.2016 11:31, Maciej Izak wrote:
> Okay then, maybe I'll manage that this week (no promise though ;) ).
> I personally think that removing TRttiContext for now is the better
> choice, so people will know not to use it while they might expect valid
> values in the other case...
> 
> 
> I am waiting :P. Sure, feel free to remove TRttiContext. IMO almost
> empty TRttiContext has not many sense yet. 

So, the unit is committed. If you extend it, please also extend the
FPCUnit test in $fpcdir/packages/rtl-objpas/tests/tests.rtti.pas.

You can compile it like this after a "make all" at the toplevel:

./compiler/ppcx64 -n -Furtl/units/x86_64-linux -viwn -FEwhatever
-Fupackages/fcl-fpcunit/units/x86_64-linux
-Fupackages/rtl-objpas/units/x86_64-linux
-Fupackages/fcl-base/units/x86_64-linux
./packages/rtl-objpas/tests/testrunner.rtlobjpas.pp

And then you simply execute the resulting testrunner.rtlobjpas binary.
It will print its results on StdOut.

Also when you have extended the unit and provide your changes: please
use baby steps, not one big patch to rule them all ;)

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

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Sven Barth]

Am 09.12.2016 10:32 schrieb "Maciej Izak" :
>
>
> 2016-09-18 2:31 GMT+02:00 Benjamin Rosseaux :
>>
>> i've noticed a weakness of the FPC internal linker at static-linking .a
libraries on the Win64 target, which're generated by GCC newer than 4.8.1,
due to the new refptr.* and .refptr.* symbols-can-be-multiple-defined stuff
(inside one single .a library file), which was introduced in newer GCC
versions.
>
>
> I don't have the real patch for this yet but I have my inner tool to
rename all duplicated symbols for statically linking FPC with C++ code (I
have improved cppclass type). My tool uses objconv :
http://www.agner.org/optimize/#objconv . Rename for symbols is simple with
few commands for objconv ("-dfhs" to list symbols and "-nr" to rename).

Improvements for cppclass are definitely welcome :)

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

Re: [fpc-devel] FPC internal linker issues with Win64 .a startic-link libraries by GCC newer than 4.8.1

[Maciej Izak]

2016-09-18 2:31 GMT+02:00 Benjamin Rosseaux :

> i've noticed a weakness of the FPC internal linker at static-linking .a
> libraries on the Win64 target, which're generated by GCC newer than 4.8.1,
> due to the new refptr.* and .refptr.* symbols-can-be-multiple-defined
> stuff (inside one single .a library file), which was introduced in newer
> GCC versions.
>

I don't have the real patch for this yet but I have my inner tool to rename
all duplicated symbols for statically linking FPC with C++ code (I have
improved cppclass type). My tool uses objconv :
http://www.agner.org/optimize/#objconv . Rename for symbols is simple with
few commands for objconv ("-dfhs" to list symbols and "-nr" to rename).

Anyway your temporary patch might be better for statically linking with
SDL2...

-- 
Best regards,
Maciej Izak
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel