Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2019-08

Compatibility problems with fpc > 3.3.1 rev 42375

27 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

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 ;-)

Reply by email

Michael Van Canneyt
to fredvs
fredvs wrote 11 lines
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.

Reply by email

fredvs
to Michael Van Canneyt

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 ;-)

Reply by email

Michael Van Canneyt
to fredvs
fredvs wrote 13 lines
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.

Reply by email

fredvs
to Michael Van Canneyt
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 ;-)

Reply by email

Michael Van Canneyt
to fredvs
fredvs wrote 8 lines
> 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.

Reply by email

Sven Barth
to fredvs: Hello everybody and specially Sven Barth. With last trunk of fpc, msegui is no more…
fredvs wrote 17 lines
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

Reply by email

fredvs
to Michael Van Canneyt: Yes, but that does not tell me why a change in RTTI info would stop this from working. Do…
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 ;-)

Reply by email

fredvs
to Sven Barth: https://wiki.freepascal.org/User_Changes_Trunk#Type_information_contains_reference_to_attr…

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 ;-)

Reply by email

fredvs
to fredvs

Hello.

Show quoted text 15 lines
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).

Show quoted text 5 lines
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 ;-)

Reply by email

Sven Barth
to fredvs
fredvs wrote 25 lines
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

Reply by email

Sven Barth
to fredvs

fredvs schrieb am Sa., 31. Aug. 2019, 22:00:

Show quoted text 9 lines
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

Reply by email

Unknown author
to fredvs: from working. Same for me, I absolutely dont understand why a change in RTTI info would…
fredvs wrote 6 lines
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.*

Reply by email

fredvs
to 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 ;-)

Reply by email

fredvs
to 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 ;-)

Reply by email

Sven Barth
to fredvs

fredvs 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.

Show quoted text 13 lines
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

Reply by email

Sven Barth
to fredvs: Hello everybody (included Sven). It seems that the problems come from…

fredvs schrieb am Fr., 6. Sep. 2019, 22:23:

Show quoted text 14 lines
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

Reply by email

fredvs
to Sven Barth

Hello Sven.

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.

Ha, we are going forward. so maybe TReader is not the problem.

Ok, I will try to investigate a different way.

Thanks Sven.

Fre;D

PS: If you see some other things that could be the guilty, dont hesitate to say it.

-----
Many thanks ;-)

Reply by email

fredvs
to fredvs

Hello everybody.

Good time to go back with that problem and fix it forever the right way! The problem is isolated and is fixed "hardcoded".

From rev 42375, in msegui function dynarrayelesize(const typinfo:
pdynarraytypeinfo): sizeint; inline;
the result is always = 0.

This function is used in additempo() function, used mainly in the msestat.pas file.
This is used to restore, for example, the position and size of windows.

To fix with a turn-around, I did first compile mseide with fpc 3.2.0 to know what is the value of dynarrayelesize(typeinfo).
It is always 16 and then I use that constant instead of dynarrayelesize(typeinfo).

It works like charm and can use now fpc 3.3.1 without problems.

Great but, for the Champions, would it be somebody that can explain why the result is always = 0 from rev 42375 ?

Here the problematic function:

function dynarrayelesize(const typinfo: pdynarraytypeinfo): sizeint; inline;
var
 ti: pdynarraytypeinfo;
begin
 ti:= typinfo;
{$ifdef FPC}
 inc(pointer(ti),ord(pdynarraytypeinfo(ti)^.namelen)+2);
 ti:= aligntoptr(ti);
 result:= psizeint(ti)^;
{$else}
 inc(pchar(ti),length(ti^.name));
 result:= ti^.elsize;
{$endif}
end;

-----
Many thanks ;-)

Reply by email

Martin Frb
to fredvs
fredvs wrote 9 lines
Hello everybody. Good time to go back with that problem and fix it forever the right way! The problem is isolated and is fixed "hardcoded". From rev 42375, in msegui function dynarrayelesize(const typinfo: pdynarraytypeinfo): sizeint; inline; the result is always = 0.

I do not know if fpc has an official way to get the size of an array element from the typeinfo.

But comparing the internals:
{$ifdef VER3_0}
       typeInfo:=aligntoptr(typeInfo+2+PByte(typeInfo)[1]);
{$else VER3_0}
       typeInfo:=aligntoqword(typeInfo+2+PByte(typeInfo)[1]);
{$endif VER3_0}

So alignment changed, which is why the old code no longer works

mse always does

  ti:= aligntoptr(ti);

Reply by email

fredvs
to Martin Frb

Hello Martin.

Wow.

Indeed, I did a check in mse code and only exists, in msearrayutils.pas:

function aligntoptr(p: pointer): pointer; inline;
begin
{$ifdef FPC_REQUIRES_PROPER_ALIGNMENT}
 result:= align(p,sizeof(p));
{$else FPC_REQUIRES_PROPER_ALIGNMENT}
 result:=p;
{$endif FPC_REQUIRES_PROPER_ALIGNMENT}
end;

And nothing about aligntoqword()

I dont know if a function aligntoqword(p: pointer): pointer; inline;
must be added in msearrayutils.pas.
I will try using aligntoqword() of fpc and adapting mse code for it (ti:=
aligntoqword(ti);

If you see a other way, please advice.

Many, many, many thanks.

Fre;D

-----
Many thanks ;-)

Reply by email