Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)

2023-06-14 Thread Tomas Hajny via fpc-pascal
On 14 June 2023 20:59:41 +0200, "Rafael Picanço via fpc-pascal" 
 wrote:


Hi Rafael,

>I am trying to follow your advice and use units instead:
>
>const
>  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction = Pointer(0);
>
>However I am receiving an error:
>
>Error: Incompatible types: got "Pointer" expected "of function(PCCDBS):LongInt;CDecl>"
>
>Please, can you shed some light on this?

I can't test it right now, but I believe that 

const
  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction =
   
TGetExButtonStatesFunction (Pointer(0));

(i.e. with an explicit typecast to the required type) should work.

Tomas

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)

2023-06-14 Thread Rafael Picanço via fpc-pascal
Hi Marco,

I am trying to follow your advice and use units instead:

const
  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction = Pointer(0);

However I am receiving an error:

Error: Incompatible types: got "Pointer" expected ""

Please, can you shed some light on this?

Best,
R

On Wed, Jun 14, 2023 at 7:00 AM 
wrote:

> Send fpc-pascal mailing list submissions to
> fpc-pascal@lists.freepascal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> or, via email, send a message with subject or body 'help' to
> fpc-pascal-requ...@lists.freepascal.org
>
> You can reach the person managing the list at
> fpc-pascal-ow...@lists.freepascal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fpc-pascal digest..."
>
>
> Today's Topics:
>
>1. Re:  fpc isn't optimised for tail recursion, is it?
>   (Jean SUZINEAU)
>2. Re:  Free Pascal bindings for EyeLink C code (with a
>   god-cast) (Rafael Pican?o)
>3. Re:  Free Pascal bindings for EyeLink C code (with a
>   god-cast) (Marco van de Voort)
>4. Re:  Non-initialized member access warning (Hairy Pixels)
>
>
> --
>
> Message: 1
> Date: Tue, 13 Jun 2023 15:25:59 +0200
> From: Jean SUZINEAU 
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] fpc isn't optimised for tail recursion, is
> it?
> Message-ID: <310a7c2b-a874-b5d3-f80f-f49290358...@wanadoo.fr>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Le 12/06/2023 ? 19:05, Steve Litt via fpc-pascal a ?crit?:
> > Busted! I used Pascal 1984-1993
> So I guess you are not familiar too with the "Result" variable which
> appeared with Delphi 1 in 1995 if I remember correctly.
>
> nextt:= num;
>
> can be written to as :
>
> Result:= num;
>
> https://www.freepascal.org/docs-html/ref/refse94.html
>
> I prefer Result because it reduces risks of confusion with recursive call
> and you can eventually take the address of Result with @Result (where
> @nextt would take the address of the function nextt),
> pass it by reference to another function ( e.g. FillChar( Result,
> SizeOf(Result), 0); ) ,
> it behaves like a normal variable.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230613/5a2bb3c5/attachment-0001.htm
> >
>
> --
>
> Message: 2
> Date: Tue, 13 Jun 2023 10:38:22 -0300
> From: Rafael Pican?o 
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code
> (with a god-cast)
> Message-ID:
>  mhrbm9kjf7r+brv6yrr3ydxt8njuht...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thank you Marco, I am elaborating on top of your suggestions.
>
> > The problem is that the logical solution, making it a macro, doesn't
> work, as macro definitions don't export through USES clauses.
>
> I think that pre-processor constants with $I would be a valid alternative
> for using the best solution. For example:
>
> // constants.pp
> 
> {$MACRO ON}
> {$ifndef EXTERNAL_DEV_NONE}
>   {$DEFINE EXTERNAL_DEV_NONE := TGetExButtonStatesFunction(Pointer(0))}
> {$endif}
> {$ifndef EXTERNAL_DEV_CEDRUS}
>   {$DEFINE EXTERNAL_DEV_CEDRUS := TGetExButtonStatesFunction(Pointer(1))}
> {$endif}
> {$ifndef EXTERNAL_DEV_SYS_KEYBOARD}
>   {$DEFINE EXTERNAL_DEV_SYS_KEYBOARD :=
> TGetExButtonStatesFunction(Pointer(2))}
> {$endif}
> 
>
> program godcastsucks;
>
> {$I constants}
>
> type
>
>   PCCDBS = ^TCCDBS;
>   TCCDBS = record
> userdata: Pointer;
> buttons: array[0..255] of AnsiChar;
> internal: Pointer;
>   end;
>
>   TGetExButtonStatesFunction = function (accdbs: PCCDBS): Int32; cdecl;
>
>   function enable_external_calibration_device(
> buttonStatesfcn: Pointer {other arguments removed for simplicity}):
> Int32; cdecl;
>   var
> Statesfcn : TGetExButtonStatesFunction;
>   begin
> Result := Int32(TGetExButtonStatesFunction(@buttonStatesfcn^));
> case Result of
>   0 : { do nothing };
> else
>   begin
> Statesfcn := TGetExButtonStatesFunction(buttonStatesfcn);
> Statesfcn(nil);
> Result := -1;
>   end;
> end;
>   end;
>
> function ExButtonStatesFunction(accdbs: PCCDBS): Int32; cdecl;
> begin
>   WriteLn('God casts s

Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)

2023-06-13 Thread Marco van de Voort via fpc-pascal


On 13-6-2023 15:38, Rafael Picanço via fpc-pascal wrote:

Thank you Marco, I am elaborating on top of your suggestions.

> The problem is that the logical solution, making it a macro, doesn't
work, as macro definitions don't export through USES clauses.

I think that pre-processor constants with $I would be a valid 
alternative for using the best solution. For example:


A matter of taste. I would have as less macros as possible. Moreover the 
typed const doesn't require including additional files at the usage 
site, so IMHO it is objectively a better solution

___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal


Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)

2023-06-13 Thread Rafael Picanço via fpc-pascal
Thank you Marco, I am elaborating on top of your suggestions.

> The problem is that the logical solution, making it a macro, doesn't
work, as macro definitions don't export through USES clauses.

I think that pre-processor constants with $I would be a valid alternative
for using the best solution. For example:

// constants.pp

{$MACRO ON}
{$ifndef EXTERNAL_DEV_NONE}
  {$DEFINE EXTERNAL_DEV_NONE := TGetExButtonStatesFunction(Pointer(0))}
{$endif}
{$ifndef EXTERNAL_DEV_CEDRUS}
  {$DEFINE EXTERNAL_DEV_CEDRUS := TGetExButtonStatesFunction(Pointer(1))}
{$endif}
{$ifndef EXTERNAL_DEV_SYS_KEYBOARD}
  {$DEFINE EXTERNAL_DEV_SYS_KEYBOARD :=
TGetExButtonStatesFunction(Pointer(2))}
{$endif}


program godcastsucks;

{$I constants}

type

  PCCDBS = ^TCCDBS;
  TCCDBS = record
userdata: Pointer;
buttons: array[0..255] of AnsiChar;
internal: Pointer;
  end;

  TGetExButtonStatesFunction = function (accdbs: PCCDBS): Int32; cdecl;

  function enable_external_calibration_device(
buttonStatesfcn: Pointer {other arguments removed for simplicity}):
Int32; cdecl;
  var
Statesfcn : TGetExButtonStatesFunction;
  begin
Result := Int32(TGetExButtonStatesFunction(@buttonStatesfcn^));
case Result of
  0 : { do nothing };
else
  begin
Statesfcn := TGetExButtonStatesFunction(buttonStatesfcn);
Statesfcn(nil);
Result := -1;
  end;
end;
  end;

function ExButtonStatesFunction(accdbs: PCCDBS): Int32; cdecl;
begin
  WriteLn('God casts sucks');
end;

begin
  WriteLn(enable_external_calibration_device(EXTERNAL_DEV_NONE));
  WriteLn(enable_external_calibration_device(@ExButtonStatesFunction));
  ReadLn;
end.


> Note that an alternative for this macro exists since FPC 3.2.0:

Thank you for the reference!

On Tue, Jun 13, 2023 at 7:00 AM 
wrote:

> Send fpc-pascal mailing list submissions to
> fpc-pascal@lists.freepascal.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
> or, via email, send a message with subject or body 'help' to
> fpc-pascal-requ...@lists.freepascal.org
>
> You can reach the person managing the list at
> fpc-pascal-ow...@lists.freepascal.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of fpc-pascal digest..."
>
>
> Today's Topics:
>
>1. Re:  Free Pascal bindings for EyeLink C code (with a
>   god-cast) (Marco van de Voort)
>
>
> --
>
> Message: 1
> Date: Tue, 13 Jun 2023 11:25:13 +0200
> From: Marco van de Voort 
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Free Pascal bindings for EyeLink C code
> (with a god-cast)
> Message-ID:
> <5a5a8eac-e91d-d9d7-4131-d7301ec3c...@pascalprogramming.org>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
>
> On 13-6-2023 05:19, Rafael Pican?o via fpc-pascal wrote:
> > (1) I have no idea on how to translate these god-casts, eg.,
> > ((getExButtonStates)0), to free pascal. Right now, I think that even
> > if I don't really need them, I just want?to understand and learn
> > in?the?process.
>
> The problem is that the logical solution, making it a macro, doesn't
> work, as macro definitions don't export through USES clauses.
>
> Defining it a proper constant would be the best solution, but FPC
> doesn't like it :
>
> const
>
>  ?EXTERNAL_DEV_NONE = TGetExButtonStatesFunction(pointer(0));
>
> so the next best is turning it into a type constant at the expense of
> sizeof(pointer) bytes in the binary:
>
> const
>
>  ? EXTERNAL_DEV_NONE : TGetExButtonStatesFunction= pointer(0);
>
> etc etc.
>
> >
> > (2) So, the whole point here is?binding the
> > "enable_external_calibration_device" function. It expects a
> > "getExButtonStates buttonStatesfcn". Can you check if my current
> > binding is right?
> >
> A purist would say it needs to be "ansichar" rather than char (because
> in future unicode modes char could be 2-byte, for the rest it seems ok.
>
> > (3) I am using the?ELCALLTYPE?macro just because?they were?using them
> > too,?I am assuming backward compatibility. But I am not sure if I
> > really need them. EyeLink code depends on custom SDL2 headers and I
> > am?running SDL2 Free Pascal related stuff just fine (and it has cdecl
> > in everything). What do you think about that? For reference, this is
> > the macro:
> >
> You must match the calling convention of the implementation. Some
> functions have target dependent calling conventions, some non native
> libraries force cdecl even on Windows. 

Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)

2023-06-13 Thread Marco van de Voort via fpc-pascal


On 13-6-2023 05:19, Rafael Picanço via fpc-pascal wrote:
(1) I have no idea on how to translate these god-casts, eg., 
((getExButtonStates)0), to free pascal. Right now, I think that even 
if I don't really need them, I just want to understand and learn 
in the process.


The problem is that the logical solution, making it a macro, doesn't 
work, as macro definitions don't export through USES clauses.


Defining it a proper constant would be the best solution, but FPC 
doesn't like it :


const

 EXTERNAL_DEV_NONE = TGetExButtonStatesFunction(pointer(0));

so the next best is turning it into a type constant at the expense of 
sizeof(pointer) bytes in the binary:


const

  EXTERNAL_DEV_NONE : TGetExButtonStatesFunction= pointer(0);

etc etc.



(2) So, the whole point here is binding the 
"enable_external_calibration_device" function. It expects a 
"getExButtonStates buttonStatesfcn". Can you check if my current 
binding is right?


A purist would say it needs to be "ansichar" rather than char (because 
in future unicode modes char could be 2-byte, for the rest it seems ok.


(3) I am using the ELCALLTYPE macro just because they were using them 
too, I am assuming backward compatibility. But I am not sure if I 
really need them. EyeLink code depends on custom SDL2 headers and I 
am running SDL2 Free Pascal related stuff just fine (and it has cdecl 
in everything). What do you think about that? For reference, this is 
the macro:


You must match the calling convention of the implementation. Some 
functions have target dependent calling conventions, some non native 
libraries force cdecl even on Windows. (where stdcall or fastcall is 
more conventional)


Note that an alternative for this macro exists since FPC 3.2.0:

https://wiki.freepascal.org/FPC_New_Features_3.2.0#Support_for_WinAPI_directive

Even though the naming is not "elegant" for crossplatform usage.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal