Compatibility problems with fpc > 3.3.1 rev 42375

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
Hello everybody and specially Sven Barth.

With last trunk of fpc, msegui is no more compatible with fpc.
After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev
42375 breaks compatibility --->
"as attributes can be part of any type they are best suited in a common part
of TTypeData"

Could you give some light what to change to restore compatibility?

The problems are with loading files, some structure are no more recognized.

Note that there are no error message at compilation, nor when loading the
files (so difficult to debug).

Do you have a plan to give some infos of all what is changed in fpc and how
to restore compatibility?

Thanks.

Fre;D





-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Michael Van Canneyt


On Sat, 31 Aug 2019, fredvs wrote:

> Hello everybody and specially Sven Barth.
>
> With last trunk of fpc, msegui is no more compatible with fpc.
> After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev
> 42375 breaks compatibility --->
> "as attributes can be part of any type they are best suited in a common part
> of TTypeData"
>
> Could you give some light what to change to restore compatibility?
>
> The problems are with loading files, some structure are no more recognized.

Can you be more precise ?
Directly loading files of such data is not supposed to be supported.
They are internal data structures, subject to change at any time.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
Hello Michael.

> Can you be more precise ?

I would like!

It appends when reading mse sta files.
with that types:
 tstatreader = class;
 tstatwriter = class;

With rev 42375, some sections of the sta-file are no more recognized, like
"layout" section.

I have to confess that I am in the dark here, I do not see where to look,
what was changed, is it about variable assigned as pointer now, or something
else in data structure...?

The only concrete thing that I can see is that mseide compiled with last fpc
trunk dont load the layouts as wanted.

By the way, is there a plan to release fpc 3.2.0. and when?

Thanks.

Fe;D





-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Michael Van Canneyt


On Sat, 31 Aug 2019, fredvs wrote:

> Hello Michael.
>
>> Can you be more precise ?
>
> I would like!
>
> It appends when reading mse sta files.
> with that types:
> tstatreader = class;
> tstatwriter = class;
>
> With rev 42375, some sections of the sta-file are no more recognized, like
> "layout" section.

What is a sta file ? I know nothing of mse.

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
> What is a sta file ?

"sta" file is a stat-like file that contains some infos about msegui widget
behavior (and much more if you want).
For example you may use mse-sta file as ini (or json) file, used to store
parameters of layout of forms of your mse application.
You may use also mse-sta files to store db data, it is fast, has seek
feature and the mse-sta file is very light in size.

>  I know nothing of mse.

Hum, you should try it, mse is the best mirror of what fpc can do.
;-)


Fre;D





-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Michael Van Canneyt


On Sat, 31 Aug 2019, fredvs wrote:

>> What is a sta file ?
>
> "sta" file is a stat-like file that contains some infos about msegui widget
> behavior (and much more if you want).
> For example you may use mse-sta file as ini (or json) file, used to store
> parameters of layout of forms of your mse application.
> You may use also mse-sta files to store db data, it is fast, has seek
> feature and the mse-sta file is very light in size.

Yes, but that does not tell me why a change in RTTI info would stop this
from working. Do you get a compile error, or do the files no longer
read/write properly ?

Michael.
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Free Pascal - General mailing list
In reply to this post by fredvs
Am 31.08.2019 um 14:31 schrieb fredvs:

> Hello everybody and specially Sven Barth.
>
> With last trunk of fpc, msegui is no more compatible with fpc.
> After big fight, it appears that commit of Sven Barth on Jul 13 2019, rev
> 42375 breaks compatibility --->
> "as attributes can be part of any type they are best suited in a common part
> of TTypeData"
>
> Could you give some light what to change to restore compatibility?
>
> The problems are with loading files, some structure are no more recognized.
>
> Note that there are no error message at compilation, nor when loading the
> files (so difficult to debug).
>
> Do you have a plan to give some infos of all what is changed in fpc and how
> to restore compatibility?
https://wiki.freepascal.org/User_Changes_Trunk#Type_information_contains_reference_to_attribute_table

I assume your code in msegui directly accesses the RTTI instead of using
the types provided by the TypInfo unit. This is bound to break here and
then when the RTTI is extended.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
In reply to this post by Michael Van Canneyt
> Yes, but that does not tell me why a change in RTTI info would stop this
from working.

Same for me, I absolutely dont understand why a change in RTTI info would
stop this from working.
It is why I did the "explorer" way to debug the problem: doing regression
from last fpc trunk until a revision without error appears.

And rev 42375 was the guilty, before that rev, all is working ok.

> Do you get a compile error, or do the files no longer read/write properly
> ?

No, no compile error, it is only he files no longer read/write properly.

Fre;D




-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
In reply to this post by Free Pascal - General mailing list
Hello Sven.

> I assume your code in msegui directly accesses the RTTI instead of using
> the types provided by the TypInfo unit.

Ha, ok, I will jump into mse + TypInfo and see what it says.
Thanks.

Fre;D




-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
In reply to this post by Free Pascal - General mailing list
Hello Sven.

> I assume your code in msegui directly accesses the RTTI instead of using
> the types provided by the TypInfo unit.

IMHO, after check, it seems that msegui uses the types provided by the
TypInfo unit.
In each "uses" section of a msegui unit was added "typinfo".

So maybe it should be something there that was changed.
But if so I do not understand why your commit 42375 breaks compatibility
because you did not change anything in typinfo.

Fre;D



-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
Hello.

> Type information contains reference to attribute table
> Old behavior: The first field of the data represented by TTypeData is
> whatever the sub branch
> of the case statement for the type contains.
> New behavior: The first field of the data represented by TTypeData is a
> reference to
> the custom attributes that are attributed to the type, only then the type
> specific fields follow.

> Reason: Any type can have attributes, so it make sense to provide this is
> a common
> location instead of having to parse the different types.

> Remedy:
>If you use the records provided by the TypInfo unit no changes should be
necessary (same for the Rtti unit).
> If you directly access the binary data you need handle an additional
> Pointer field
> at the beginning of the TTypeData area and possibly correct the alignment
> for platforms that have
> strict alignment requirements (e.g. ARM or M68k).

Aaargh, it seems that msegui uses direct access so the second remedy is
needed.
Every advice how to use that remedy, tips where to look, how to do, is, of
course, very welcome.

Fre;D




-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Free Pascal - General mailing list
Am 31.08.2019 um 18:24 schrieb fredvs:

> Hello.
>
>> Type information contains reference to attribute table
>> Old behavior: The first field of the data represented by TTypeData is
>> whatever the sub branch
>> of the case statement for the type contains.
>> New behavior: The first field of the data represented by TTypeData is a
>> reference to
>> the custom attributes that are attributed to the type, only then the type
>> specific fields follow.
>> Reason: Any type can have attributes, so it make sense to provide this is
>> a common
>> location instead of having to parse the different types.
>> Remedy:
>> If you use the records provided by the TypInfo unit no changes should be
> necessary (same for the Rtti unit).
>> If you directly access the binary data you need handle an additional
>> Pointer field
>> at the beginning of the TTypeData area and possibly correct the alignment
>> for platforms that have
>> strict alignment requirements (e.g. ARM or M68k).
> Aaargh, it seems that msegui uses direct access so the second remedy is
> needed.
> Every advice how to use that remedy, tips where to look, how to do, is, of
> course, very welcome.
Just look at the changes:
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/typinfo.pp?r1=42373&r2=42375
If you have code that tries to access the type information you need to
take that field into account.
Same for properties, where especially this one is important:
https://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/objpas/typinfo.pp?r1=42358&r2=42365
When you iterate from one PPropInfo you need to take that into account
or use the appropriate functions of the TypInfo unit.

Regards,
Sven
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
Hello Sven.

> Just look at the changes: ...

OK, but before I have to check my stock of aspirin.
I think I'm going to need a lot this time.

Many thanks Sven to help me in that complete darkness.

Fre;D



-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Free Pascal - General mailing list
fredvs <[hidden email]> schrieb am Sa., 31. Aug. 2019, 22:00:
Hello Sven.

> Just look at the changes: ...

OK, but before I have to check my stock of aspirin.
I think I'm going to need a lot this time.

Many thanks Sven to help me in that complete darkness.

Alternatively try alcohol. ;) 

And I suggest you to extract code into small test programs so that you can test them independently of msegui and play around more easily.
Maybe try to retrieve the necessary information yourself without using the msegui code to get a feeling for the RTTI - you'll need it. ;) 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

wkitty42
In reply to this post by fredvs
On 8/31/19 11:15 AM, fredvs wrote:
> And rev 42375 was the guilty, before that rev, all is working ok.
>
>> Do you get a compile error, or do the files no longer read/write properly
>> ?
>
> No, no compile error, it is only he files no longer read/write properly.


sounds like you need a copy of the files before and after so you can easily diff
them and see where the difference is... then you can adjust the code as needed...


--
  NOTE: No off-list assistance is given without prior approval.
        *Please keep mailing list traffic on the list unless*
        *a signed and pre-paid contract is in effect with us.*
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
> sounds like you need a copy of the files before and after so you can easily
diff them and see where the difference is...

Are you talking about the .sta file?
Good, idea, I will see if it is different at saving.
But I have doubt because using a fpc < rev 42375 all is ok, even after
saving the .sta file with fpc >= rev 42375.

Anyway many thanks for the tip, I will check it.

Fre;D



-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
Hello everybody (included Sven).

It seems that the problems come from
/mseide-msegui/lib/common/fpccompatibility/mclasses.pas.

In procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo:
Pointer), IMHO there is something not compatible with rev 42375.

It would be wonderful if somebody could detect what is wrong with typinfo (I
did not find it yet).

Here the code (I guess) with problem:

-----------------

procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo: Pointer);
const
  NullMethod: TMethod = (Code: nil; Data: nil);
var
  PropType: PTypeInfo;
  Value: LongInt;
{  IdentToIntFn: TIdentToInt; }
  Ident: String;
  Method: TMethod;
  Handled: Boolean;
  TmpStr: String;
  TmpStr8: utf8String;
begin
  if not Assigned(PPropInfo(PropInfo)^.SetProc) then
    raise EReadError.Create(SReadOnlyProperty);

{$ifdef FPC}
  PropType := PPropInfo(PropInfo)^.PropType;
{$else}
  PropType := PPropInfo(PropInfo)^.PropType^;
{$endif}
  case PropType^.Kind of
    tkInteger:
      if FDriver.NextValue = vaIdent then
      begin
        Ident := ReadIdent;
        if GlobalIdentToInt(Ident,Value) then
          SetOrdProp(Instance, PropInfo, Value)
        else
          raise EReadError.Create(SInvalidPropertyValue);
      end else
        SetOrdProp(Instance, PropInfo, ReadInteger);
{$ifdef FPC}
    tkBool:
      SetOrdProp(Instance, PropInfo, Ord(ReadBoolean));
{$endif}
    tkChar:
      SetOrdProp(Instance, PropInfo, Ord(ReadChar));
    tkWChar{$ifdef FPC},tkUChar{$endif}:
      SetOrdProp(Instance, PropInfo, Ord(ReadWideChar));
    tkEnumeration:
      begin
       ident:= ReadIdent;
       Value := GetEnumValue(PropType, ident);
       if Value = -1 then begin
        if assigned(fonenumerror) then begin
         fonenumerror(self,proptype,ident,value);
        end;
       end;
       if Value = -1 then begin        
        raise EReadError.Create(SInvalidPropertyValue);
       end;
       SetOrdProp(Instance, PropInfo, Value);
      end;
{$ifndef FPUNONE}
    tkFloat:
      SetFloatProp(Instance, PropInfo, ReadFloat);
{$endif}
    tkSet:
      begin
        CheckValue(vaSet);
        SetOrdProp(Instance, PropInfo,
        {$ifdef FPC}
          FDriver.ReadSet(GetTypeData(PropType)^.CompType));
        {$else}
          FDriver.ReadSet(GetTypeData(PropType)^.CompType^));
        {$endif}
      end;
    tkMethod:
      if FDriver.NextValue = vaNil then
      begin
        FDriver.ReadValue;
        SetMethodProp(Instance, PropInfo, NullMethod);
      end else
      begin
        Handled:=false;
        Ident:=ReadIdent;
        if Assigned(OnSetMethodProperty) then
          OnSetMethodProperty(Self,Instance,PPropInfo(PropInfo),Ident,
                              Handled);
        if not Handled then begin
          Method.Code := FindMethod(Root, Ident);
          Method.Data := Root;
          if Assigned(Method.Code) then
            SetMethodProp(Instance, PropInfo, Method);
        end;
      end;
    {$ifdef FPC}
    tkSString, tkLString, tkAString:
    {$else}
    tkString, tkLString:
    {$endif}
      begin
       if proptype = typeinfo(utf8string) then begin
        TmpStr8:=Readutf8String;
        if Assigned(FOnReadStringProperty) then begin
          tmpstr:= tmpstr8;
          FOnReadStringProperty(Self,Instance,PropInfo,TmpStr);
          tmpstr8:= tmpstr;
        end;
        SetStrProp(Instance, PropInfo, TmpStr8);
       end
       else begin
        TmpStr:=ReadString;
        if Assigned(FOnReadStringProperty) then
          FOnReadStringProperty(Self,Instance,PropInfo,TmpStr);
        SetStrProp(Instance, PropInfo, TmpStr);
       end;
      end;
    {$ifdef FPC}
    tkUstring:
      SetUnicodeStrProp(Instance,PropInfo,ReadUnicodeString);
    {$endif}
    tkWString:
      SetWideStrProp(Instance,PropInfo,ReadWideString);
    tkVariant:
      begin
        SetVariantProp(Instance,PropInfo,ReadVariant);
      end;
    tkClass:
      case FDriver.NextValue of
        vaNil:
          begin
            FDriver.ReadValue;
            SetOrdProp(Instance, PropInfo, 0)
          end;
        vaCollection:
          begin
            FDriver.ReadValue;
            ReadCollection(TCollection(GetObjectProp(Instance, PropInfo)));
          end
        else begin
          If Not Assigned(FFixups) then begin
//            FFixups:=TLinkedList.Create(TLocalUnresolvedReference);
           FFixups:= tlocalfixups.create;
          end;
//          With tfixups(FFixups).newreference(instance,propinfo) do begin
          With TLocalUnresolvedReference(tlocalfixups(FFixups).add) do begin
           FInstance:= Instance;
           FRoot:= Root;
           FPropInfo:= PropInfo;
           FRelative:= ReadIdent;
          end;
        end;
      end;
    tkInt64{$ifdef FPC}, tkQWord{$endif}:
     SetInt64Prop(Instance, PropInfo, ReadInt64);
    else
      raise EReadError.CreateFmt(SUnknownPropertyType,
[Ord(PropType^.Kind)]);
  end;
end;

------------------------

Fre;D



-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

fredvs
Hello everybody.

Sorry to come back with this but I am lost (and all my stock of Aspirina is
dead).

Could it be possible to simplify the life of rtl-users and add methods with
same parameters as previous version and make it compatible with new
features?

Other wishes:

It seems that the updates done to rtl were necessary because of some
arm-compatibility.

OK, but now, for the same code, the binary-result compiled program is +- 30
% bigger that same code compiled with fpc 3.0.4  or fp 3.2.0 (on the
contrary fpc 3.2.0 gives binary 10 % less big than with fpc 3.0.4).

Would it not be better to play with "{$ifdef cpuarm}" and so not make things
heavier for all others cpu that do not need those arm-extension?

Fre:D




-----
Many thanks ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Many thanks ;-)
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Free Pascal - General mailing list
fredvs <[hidden email]> schrieb am Mi., 9. Okt. 2019, 12:00:
Could it be possible to simplify the life of rtl-users and add methods with
same parameters as previous version and make it compatible with new
features?

Working with the RTTI simply is *not* simple, because you're interfacing with binary data that is represented by Pascal records. 


Other wishes:

It seems that the updates done to rtl were necessary because of some
arm-compatibility.

OK, but now, for the same code, the binary-result compiled program is +- 30
% bigger that same code compiled with fpc 3.0.4  or fp 3.2.0 (on the
contrary fpc 3.2.0 gives binary 10 % less big than with fpc 3.0.4).

Would it not be better to play with "{$ifdef cpuarm}" and so not make things
heavier for all others cpu that do not need those arm-extension?

This size increase is not ARM related, but related to a new feature.
The alignment fixes you mention are in fact necessary for all non-x86 targets. 

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Reply | Threaded
Open this post in threaded view
|

Re: Compatibility problems with fpc > 3.3.1 rev 42375

Free Pascal - General mailing list
In reply to this post by fredvs
fredvs <[hidden email]> schrieb am Fr., 6. Sep. 2019, 22:23:
Hello everybody (included Sven).

It seems that the problems come from
/mseide-msegui/lib/common/fpccompatibility/mclasses.pas.

In procedure TReader.ReadPropValue(Instance: TPersistent; PropInfo:
Pointer), IMHO there is something not compatible with rev 42375.

It would be wonderful if somebody could detect what is wrong with typinfo (I
did not find it yet).

Here the code (I guess) with problem:

I can't see any difference in that procedure to the one in Classes.TReader except for the ifdefs and a few extensions for events and UTF-8 strings, so the problem must be somewhere else.

Regards, 
Sven 

_______________________________________________
fpc-pascal maillist  -  [hidden email]
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
12