Discussion:
Patch #31249 and objects
(too old to reply)
Maciej Izak
2017-01-31 11:36:59 UTC
Permalink
Raw Message
Hi,

Somehow my patch #31249 was ignored. Could someone from core team look at :

http://bugs.freepascal.org/view.php?id=31249
http://bugs.freepascal.org/view.php?id=31305

patch and reported bug is very important. I can't update mORMot for newest
FPC RTTI without changing all objects to records (which is possible in this
case but still we have serious bug)... -,-.

Thanks.
--
Best regards,
Maciej Izak
Sven Barth
2017-01-31 13:56:19 UTC
Permalink
Raw Message
Post by Maciej Izak
Hi,
http://bugs.freepascal.org/view.php?id=31249
http://bugs.freepascal.org/view.php?id=31305
patch and reported bug is very important. I can't update mORMot for
newest FPC RTTI without changing all objects to records (which is possible
in this case but still we have serious bug)... -,-.

I "ignored" it, cause up to now it was merely a performance improvement. If
you had added your info from 31305 to 31249 instead of creating a new
report then I might have reacted faster.

Anyway, I'll try to get it applied tonight.

PS: If you adjust mORMot then I highly suggest you not to use custom
records/objects, but the typinfo ones as much as possible as they deal with
alignment issues correctly (especially the new types of the interface
RTTI). Or at least use the typinfo types to retrieve pointers to the
correct parts of the RTTI and store those instead of using inc()s to
navigate the RTTI.

Regards,
Sven
Alfred
2017-01-31 14:30:37 UTC
Permalink
Raw Message
The inc()s were needed due to alignment issues with the previous RTTI
implementation !
I indeed also wish for them to be not necessary anymore.


------ Origineel bericht ------
Van: "Sven Barth" <***@googlemail.com>
Aan: "FPC developers' list" <fpc-***@lists.freepascal.org>
Verzonden: 31-1-2017 14:56:19
Onderwerp: Re: [fpc-devel] Patch #31249 and objects
Post by Sven Barth
Post by Maciej Izak
Hi,
Somehow my patch #31249 was ignored. Could someone from core team
http://bugs.freepascal.org/view.php?id=31249
http://bugs.freepascal.org/view.php?id=31305
patch and reported bug is very important. I can't update mORMot for
newest FPC RTTI without changing all objects to records (which is
possible in this case but still we have serious bug)... -,-.
I "ignored" it, cause up to now it was merely a performance
improvement. If you had added your info from 31305 to 31249 instead of
creating a new report then I might have reacted faster.
Anyway, I'll try to get it applied tonight.
PS: If you adjust mORMot then I highly suggest you not to use custom
records/objects, but the typinfo ones as much as possible as they deal
with alignment issues correctly (especially the new types of the
interface RTTI). Or at least use the typinfo types to retrieve pointers
to the correct parts of the RTTI and store those instead of using
inc()s to navigate the RTTI.
Regards,
Sven
Sven Barth
2017-01-31 16:12:49 UTC
Permalink
Raw Message
Post by Alfred
The inc()s were needed due to alignment issues with the previous RTTI
implementation !
Post by Alfred
I indeed also wish for them to be not necessary anymore.
The typinfo unit should take care of all that in my opinion. Also please
note that the alignment differs between platforms so the inc()s can even be
completely wrong if not protected by ifdefs.

Regards,
Sven
Maciej Izak
2017-01-31 17:45:39 UTC
Permalink
Raw Message
Post by Sven Barth
I "ignored" it, cause up to now it was merely a performance improvement.
If you had added your info from 31305 to 31249 instead of creating a new
report then I might have reacted faster.
Very sad info. 31305 costed me additional time. 31305 is separate problem
so has separate ticket. I didn't knew about 31305 until today.
Post by Sven Barth
Anyway, I'll try to get it applied tonight.
PS: If you adjust mORMot then I highly suggest you not to use custom
records/objects, but the typinfo ones as much as possible as they deal with
alignment issues correctly (especially the new types of the interface
RTTI). Or at least use the typinfo types to retrieve pointers to the
correct parts of the RTTI and store those instead of using inc()s to
navigate the RTTI.
Not that simple, almost impossible to use only TypInfo. mORMot has support
for very large range of compilers: FPC >= 2.6.4 and Delphi >= 5... Custom
records/objects are often the only way to keep sensible code base... mORMot
has own aligntoptr implementation (which is different for each compiler and
platform if needed). aligntoptr is used together with inc()s. TypInfo is
generally incompatible in many ways between Delphi and FPC so we have a lot
of $IFDEFs for low level RTL / RTTI and own structures.

Thanks to mORMot and NewPascal initiative ("fork" is wrong word - NewPascal
exist like more stable predictable trunk with few additional
features/previews) we can keep real single code base between Delphi and FPC.
--
Best regards,
Maciej Izak
Sven Barth
2017-01-31 18:35:43 UTC
Permalink
Raw Message
Post by Sven Barth
I "ignored" it, cause up to now it was merely a performance
improvement. If you had added your info from 31305 to 31249 instead
of creating a new report then I might have reacted faster.
Very sad info. 31305 costed me additional time. 31305 is separate
problem so has separate ticket. I didn't knew about 31305 until today.
I've applied the patch now (with adjustments to the changes that had
happened in trunk).

A little sidenote: the "day unique" part of an internal error is
supposed to be two digits and to start from 1, so your internal error
should have been 2017011801 instead of 201701180 (I've corrected that
already).
Post by Sven Barth
Anyway, I'll try to get it applied tonight.
PS: If you adjust mORMot then I highly suggest you not to use custom
records/objects, but the typinfo ones as much as possible as they
deal with alignment issues correctly (especially the new types of
the interface RTTI). Or at least use the typinfo types to retrieve
pointers to the correct parts of the RTTI and store those instead of
using inc()s to navigate the RTTI.
Not that simple, almost impossible to use only TypInfo. mORMot has
support for very large range of compilers: FPC >= 2.6.4 and Delphi >=
5... Custom records/objects are often the only way to keep sensible code
base... mORMot has own aligntoptr implementation (which is different for
each compiler and platform if needed). aligntoptr is used together
with inc()s. TypInfo is generally incompatible in many ways between
Delphi and FPC so we have a lot of $IFDEFs for low level RTL / RTTI and
own structures.
I still can't recommend the way it's done in mORMot. This will break
each time the binary format of the RTTI changes. Take my adjustment of
TProcedureParam.Flags (now .ParamFlags) for example which I changed from
Byte to TParamFlags which not much later changed its size from Byte to
Word due to newly added elements. You might not catch such a change
especially if it should be used in a seldomly used code branch.

My suggestion would be an RTTI abstraction that makes use of inline
methods/properties as part of objects/records to access the Delphi and
FPC RTTI.

For example another change that will come up in the near future will be
a link from the TTypeData to the unit its contained in which will again
lead to a shift in fields.

Regards,
Sven
_______________________________________________
fpc-devel maillist - fpc-***@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
Maciej Izak
2017-01-31 19:18:37 UTC
Permalink
Raw Message
Post by Sven Barth
A little sidenote: the "day unique" part of an internal error is
supposed to be two digits and to start from 1, so your internal error
should have been 2017011801 instead of 201701180 (I've corrected that
already).
Ok. Another sidenote to remember. :)
Post by Sven Barth
I still can't recommend the way it's done in mORMot. This will break
each time the binary format of the RTTI changes. Take my adjustment of
TProcedureParam.Flags (now .ParamFlags) for example which I changed from
Byte to TParamFlags which not much later changed its size from Byte to
Word due to newly added elements. You might not catch such a change
especially if it should be used in a seldomly used code branch.
...and that is why we have NewPascal also as "buffer". When someone is
using NewPascal instead of pure FPC trunk, can be sure that he has right
version of FPC trunk for mORMot. My every day starts from checking what is
new in ncgrtti and typinfo :) so don't worry. Anyway I am just human, so
maybe more detailed test suite for RTTI binary consistency is good idea.
Whatever we discuss here I can't make such decision. IMO only main author
of mORMot (Arnaud Bouchez) has rights for such important changes.
Post by Sven Barth
My suggestion would be an RTTI abstraction that makes use of inline
methods/properties as part of objects/records to access the Delphi and
FPC RTTI.
And we have that abstraction too (!)... The most painfully part is
collecting the data in optimal way (also part of data lands into cache) and
we need to keep single code base as possible with many versions of Delphi
which is not trivial task.
Post by Sven Barth
For example another change that will come up in the near future will be
a link from the TTypeData to the unit its contained in which will again
lead to a shift in fields.
We have a lot of "breaking changes" behind us. We will take the challenge.
;)
--
Best regards,
Maciej Izak
Maciej Izak
2017-01-31 18:07:00 UTC
Permalink
Raw Message
Post by Sven Barth
Anyway, I'll try to get it applied tonight.
Thanks :)
--
Best regards,
Maciej Izak
Loading...