Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
On 02/02/2020 04:22, fredvs via fpc-pascal wrote:
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);
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Compatibility problems with fpc > 3.3.1 rev 42375
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 ;-)
--
Sent from: http://free-pascal-general.1045716.n5.nabble.com/
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom operator
Of course precedence of the operator also must be informed by the operator author to the compiler in some ways. Operator has different purpose and workflow from function/method. If not, then everything can be just a method, no operator needed. However, if this is not practically possible in FPC, it’s all right then. Thank you. –Mr Bee Pada Minggu, 2 Februari 2020 08.32.23 WIB, Sven Barth via fpc-pascal menulis: Mr Bee via fpc-pascal schrieb am So., 2. Feb. 2020, 02:11: Hi all, Besides overloading available operators, could we make our own custom operator(s) in FPC? For example, I want to use ∑ to sum array values? Also other Unicode characters such as ≥, ≤, ±, ≠, etc as custom operators? I think such feature is important in this unicode era. Is it possible? No, it is not (okay, technically, in theory it would be possible, but definitely not desired). The compiler would need to know such operators so that it can determine the precedence. You can just as well use methods/functions for that with the added benefit that they can be named in a way that explains their purpose. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Interface type error
Why doesn't this compile? IClassName2 descends from IClassName1 so shouldn't
TClassName be compatible with IClassName1?
{$mode objfpc}
{$interfaces corba}
program test;
type
IClassName1 = interface
end;
IClassName2 = interface(IClassName1)
end;
type
TClassName = class(IClassName2)
end;
procedure Pass(int: IClassName1);
begin
end;
var
c: TClassName;
begin
// Incompatible type for arg no. 1: Got "TClassName", expected "IClassName1"
Pass(c);
end.
Regards,
Ryan Joseph
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Custom operator
Mr Bee via fpc-pascal schrieb am So., 2. Feb. 2020, 02:11: > Hi all, > > Besides overloading available operators, could we make our own custom > operator(s) in FPC? > > For example, I want to use ∑ to sum array values? Also other Unicode > characters such as ≥, ≤, ±, ≠, etc as custom operators? I think such > feature is important in this unicode era. > > Is it possible? > No, it is not (okay, technically, in theory it would be possible, but definitely not desired). The compiler would need to know such operators so that it can determine the precedence. You can just as well use methods/functions for that with the added benefit that they can be named in a way that explains their purpose. Regards, Sven > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Custom operator
Hi all, Besides overloading available operators, could we make our own custom operator(s) in FPC? For example, I want to use ∑ to sum array values? Also other Unicode characters such as ≥, ≤, ±, ≠, etc as custom operators? I think such feature is important in this unicode era. Is it possible? Thank you. Regards, –Mr Bee ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Parameter Checking in fpjsonrpc
Hello Michael,
as the bugtracker is still not reachable, I'll send you my patch via the
mailing list.
As you suggested, there is a new option jroIgnoreExtraFields to ignore
extra fields in the parameter objets.
Objects in arrays are now validated against ParamDefs the same way a
single object is validated. You can force all array elements to be
objects, if you include both jroObjectParams and jroArrayParams in
options. If only jroArrayParams is given, the array may contain all JSON
types but only objects insided a mixed array are validated against
ParamDefs; simple types like numbers or strings are not checked.
Simon
packages/fcl-web/src/jsonrpc/fpjsonrpc.pp | 121
++
1 file changed, 105 insertions(+), 16 deletions(-)
diff --git a/packages/fcl-web/src/jsonrpc/fpjsonrpc.pp
b/packages/fcl-web/src/jsonrpc/fpjsonrpc.pp
index 47d0ecf5e6..dd70e63ada 100644
--- a/packages/fcl-web/src/jsonrpc/fpjsonrpc.pp
+++ b/packages/fcl-web/src/jsonrpc/fpjsonrpc.pp
@@ -54,7 +54,7 @@ Type
function GetP(AIndex : Integer): TJSONParamDef;
procedure SetP(AIndex : Integer; const AValue: TJSONParamDef);
Public
- Function AddParamDef(Const AName : TJSONStringType; AType :
TJSONType = jtString) : TJSONParamDef;
+ Function AddParamDef(Const AName : TJSONStringType; AType :
TJSONType = jtString; ARequired: Boolean = False) : TJSONParamDef;
Function IndexOfParamDef(Const AName : TJSONStringType) : Integer;
Function FindParamDef(Const AName : TJSONStringType) : TJSONParamDef;
Function ParamDefByName(Const AName : TJSONStringType) : TJSONParamDef;
@@ -63,7 +63,7 @@ Type
{ TCustomJSONRPCHandler }
TJSONParamErrorEvent = Procedure (Sender : TObject; Const E :
Exception; Var Fatal : boolean) of Object;
- TJSONRPCOption = (jroCheckParams,jroObjectParams,jroArrayParams);
+ TJSONRPCOption =
(jroCheckParams,jroObjectParams,jroArrayParams,jroIgnoreExtraFields);
TJSONRPCOptions = set of TJSONRPCOption;
{ TJSONRPCCallContext }
@@ -94,6 +94,8 @@ Type
Protected
function CreateParamDefs: TJSONParamDefs; virtual;
Procedure DoCheckParams(Const Params : TJSONData); virtual;
+ Procedure DoCheckParamDefsOnObject(Const ParamObject: TJSONObject);
virtual;
+ Procedure DoCheckParamArray(const ParamArray: TJSONArray); virtual;
Function DoExecute(Const Params : TJSONData; AContext :
TJSONRPCCallContext): TJSONData; virtual;
Property BeforeExecute : TNotifyEvent Read FBeforeExecute Write
FBeforeExecute;
Property AfterExecute : TNotifyEvent Read FAfterExecute Write
FAfterExecute;
@@ -332,8 +334,10 @@ Type
TJSONErrorObject = Class(TJSONObject);
// Raise EJSONRPC exceptions.
-Procedure JSONRPCError(Msg : String);
-Procedure JSONRPCError(Fmt : String; Args : Array of const);
+Procedure JSONRPCError(const Msg : String);
+Procedure JSONRPCError(const Fmt : String; const Args : Array of const);
+Procedure JSONRPCParamError(const Msg: String);
+Procedure JSONRPCParamError(const Fmt: String; const Args: array of const);
// Create an 'Error' object for an error response.
function CreateJSONErrorObject(Const AMessage : String; Const ACode :
Integer) : TJSONObject;
@@ -371,6 +375,10 @@ resourcestring
SErrParamsMustBeArrayorObject = 'Parameters must be passed in an
object or an array.';
SErrParamsMustBeObject = 'Parameters must be passed in an object.';
SErrParamsMustBeArray = 'Parameters must be passed in an array.';
+ SErrParamsRequiredParamNotFound = 'Required parameter "%s" not found.';
+ SErrParamsDataTypeMismatch = 'Expected parameter "%s" having type
"%s", got "%s".';
+ SErrParamsNotAllowd = 'Parameter "%s" is not allowed.';
+ SErrParamsOnlyObjectsInArray = 'Array elements must be objects, got
%s at position %d.';
SErrRequestMustBeObject = 'JSON-RPC Request must be an object.';
SErrNoIDProperty = 'No "id" property found in request.';
SErrInvalidIDProperty = 'Type of "id" property is not correct.';
@@ -402,13 +410,15 @@ implementation
uses dbugintf;
{$ENDIF}
-function CreateJSONErrorObject(Const AMessage : String; Const ACode :
Integer) : TJSONObject;
+function CreateJSONErrorObject(const AMessage: String; const ACode: Integer
+ ): TJSONObject;
begin
Result:=TJSONErrorObject.Create(['code',ACode,'message',AMessage])
end;
-function CreateJSON2ErrorResponse(Const AMessage : String; Const ACode
: Integer; ID : TJSONData = Nil; idname : TJSONStringType = 'id' ) :
TJSONObject;
+function CreateJSON2ErrorResponse(const AMessage: String; const ACode:
Integer;
+ ID: TJSONData; idname: TJSONStringType): TJSONObject;
begin
If (ID=Nil) then
@@ -418,7 +428,8 @@ begin
Result:=TJSONErrorObject.Create(['jsonrpc','2.0','error',CreateJSONErrorObject(AMessage,ACode),idname,ID]);
end;
-function CreateJSON2ErrorResponse(Const AFormat : String; Args : Array
of const; Const ACode : Integer; ID : TJSONData = Nil; idname :
TJSONStringType = 'id' ) : TJSONObject;
+function CreateJSON2ErrorResponse(const AFormat:
Re: [fpc-pascal] fpmmap arm-linux issue
Agreed, the rtl should definitely divide by pagesize if MMAP2 is defined. I've run into this discrepancy before on ARM at work Original message From: Jonas Maebe Date: Sat, 1 Feb 2020, 17:46To: Fabio Luis Girardi via fpc-pascal Subject: Re: [fpc-pascal] fpmmap arm-linux issueOn 31/01/2020 22:17, Fabio Luis Girardi via fpc-pascal wrote:> In C: > > CM_BaseAddr = mmap(NULL, 0x4000, PROT_READ | PROT_WRITE, > MAP_SHARED, devmemfd, *0x44e0*); > > to get the "same" code working in FPC I have to change some constants.> > CM_BaseAddr := Fpmmap(NULL, $4000, PROT_READ + PROT_WRITE, > MAP_SHARED, devmemfd, *$44e00*); > > I did a strace in the FPC executable, and the in line above, the base> address is "multiplied" by 4096 dec ($1000 hex) becoming back equal to> the C constant.> > The question is: this is intentional? Has some technical point that's> not mentioned on the fpmmap documentation? Or it's simply a bug?It sounds like a bug. I don't see anything in the RTL that intentiallydoes this.Jonas___fpc-pascal maillist - fpc-pascal@lists.freepascal.orghttps://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmmap arm-linux issue
Ok. I'll fill out a bug report. Em Sáb, 1 de fev de 2020 13:47, Jonas Maebe escreveu: > On 31/01/2020 22:17, Fabio Luis Girardi via fpc-pascal wrote: > > In C: > > > > CM_BaseAddr = mmap(NULL, 0x4000, PROT_READ | PROT_WRITE, > > MAP_SHARED, devmemfd, *0x44e0*); > > > > to get the "same" code working in FPC I have to change some constants. > > > > CM_BaseAddr := Fpmmap(NULL, $4000, PROT_READ + PROT_WRITE, > > MAP_SHARED, devmemfd, *$44e00*); > > > > I did a strace in the FPC executable, and the in line above, the base > > address is "multiplied" by 4096 dec ($1000 hex) becoming back equal to > > the C constant. > > > > The question is: this is intentional? Has some technical point that's > > not mentioned on the fpmmap documentation? Or it's simply a bug? > > It sounds like a bug. I don't see anything in the RTL that intentially > does this. > > > Jonas > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpmmap arm-linux issue
On 31/01/2020 22:17, Fabio Luis Girardi via fpc-pascal wrote: > In C: > > CM_BaseAddr = mmap(NULL, 0x4000, PROT_READ | PROT_WRITE, > MAP_SHARED, devmemfd, *0x44e0*); > > to get the "same" code working in FPC I have to change some constants. > > CM_BaseAddr := Fpmmap(NULL, $4000, PROT_READ + PROT_WRITE, > MAP_SHARED, devmemfd, *$44e00*); > > I did a strace in the FPC executable, and the in line above, the base > address is "multiplied" by 4096 dec ($1000 hex) becoming back equal to > the C constant. > > The question is: this is intentional? Has some technical point that's > not mentioned on the fpmmap documentation? Or it's simply a bug? It sounds like a bug. I don't see anything in the RTL that intentially does this. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
