Recent

Author Topic: Best practice for using h2pas on a "clever" kernel interface binding  (Read 900 times)

PascalDragon

  • Hero Member
  • *****
  • Posts: 2747
  • Compiler Developer
Re: Best practice for using h2pas on a "clever" kernel interface binding
« Reply #15 on: February 23, 2021, 09:09:49 am »
https://github.com/WouterVanNifterick/C-To-Delphi

I suspect that's probably deceptively flashy, and that a full language translator is probably overkill. But the obvious question is whether anybody's succeeded in compiling it with Lazarus/FPC.

With just a quick look I can see that it uses some functionality (both features and classes) that FPC does not yet support so that would have to be ported...

MarkMLl

  • Hero Member
  • *****
  • Posts: 2061
Re: Best practice for using h2pas on a "clever" kernel interface binding
« Reply #16 on: February 23, 2021, 09:22:09 am »
https://github.com/WouterVanNifterick/C-To-Delphi

I suspect that's probably deceptively flashy, and that a full language translator is probably overkill. But the obvious question is whether anybody's succeeded in compiling it with Lazarus/FPC.

With just a quick look I can see that it uses some functionality (both features and classes) that FPC does not yet support so that would have to be ported...

Much my suspicion. That's not something I can realistically do: I'm quite simply not sufficiently up-to-speed on what Delphi's doing these days, and I've got my hands full with- among other things- trying to sort out details of GPIO naming convention (the gpiod API fails to report the base of a group of lines).

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

MarkMLl

  • Hero Member
  • *****
  • Posts: 2061
Re: Best practice for using h2pas on a "clever" kernel interface binding
« Reply #17 on: February 23, 2021, 11:38:38 am »
I've got a substantial number of entry points named like

Code: Pascal  [Select][+][-]
  1.   function gpiod_is_gpiochip_device(path:Pchar):boolean; CDECL__ GPIODLIB__
  2.   function gpiod_chip_open(path:Pchar):pgpiod_chip; CDECL__ GPIODLIB__
  3.   procedure gpiod_chip_close(chip:Pgpiod_chip); CDECL__ GPIODLIB__
  4.   function gpiod_chip_name(chip:Pgpiod_chip):Pchar; CDECL__ GPIODLIB__
  5.  

That's from an include file which is incorporated into automatically-generated units for static and dynamic linkage.

The objective is that these will always be accessed using either a unit name or an object reference, i.e. like

Code: Pascal  [Select][+][-]
  1.   chipHandle := Gpiod.gpiod_chip_open(PChar('/dev/gpiochip' + guiTestForm.PortName));
  2.   gpios := Gpiod.gpiod_chip_num_lines(chipHandle);
  3.  

In principle I could trim the leading gpiod_ in each function name as redundant, but in order to avoid ambiguity is there any way that I could mark the static unit as always requiring fully-qualified references, i.e. so that

Code: Pascal  [Select][+][-]
  1.   chipHandle := chip_open(PChar('/dev/gpiochip' + guiTestForm.PortName));
  2.   gpios := chip_num_lines(chipHandle);
  3.  

was not accepted by the compiler?

MarkMLl



Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

PascalDragon

  • Hero Member
  • *****
  • Posts: 2747
  • Compiler Developer
Re: Best practice for using h2pas on a "clever" kernel interface binding
« Reply #18 on: February 23, 2021, 01:17:42 pm »
In principle I could trim the leading gpiod_ in each function name as redundant, but in order to avoid ambiguity is there any way that I could mark the static unit as always requiring fully-qualified references, i.e. so that

Code: Pascal  [Select][+][-]
  1.   chipHandle := chip_open(PChar('/dev/gpiochip' + guiTestForm.PortName));
  2.   gpios := chip_num_lines(chipHandle);
  3.  

was not accepted by the compiler?

No, you can't.

avra

  • Hero Member
  • *****
  • Posts: 2101
    • Additional info
Re: Best practice for using h2pas on a "clever" kernel interface binding
« Reply #19 on: February 23, 2021, 03:18:26 pm »
https://github.com/WouterVanNifterick/C-To-Delphi

I suspect that's probably deceptively flashy, and that a full language translator is probably overkill. But the obvious question is whether anybody's succeeded in compiling it with Lazarus/FPC.

It is Delphi application and I did not suggest that you need to compile it under Lazarus. On the right side of the site you can see Releases link. Press it and download executable. Nothing more, nothing less. I use it mostly for quick translations because of it's live feature which translates on idle, and as an alternative translation to choose from.
ct2laz - Conversion between Lazarus and CodeTyphon
bithelpers - Bit manipulation for standard types
pasettimino - Siemens S7 PLC lib

MarkMLl

  • Hero Member
  • *****
  • Posts: 2061
Re: Best practice for using h2pas on a "clever" kernel interface binding
« Reply #20 on: February 26, 2021, 03:18:51 pm »
I'm taking another look at the varargs aspect of this, and would appreciate a reality check.

The documentation of class helpers says that a class helper can't define a (new) field or as a consequence a property referring to a field... Does this apply to fields defined in the base class, or it it only stating the obvious that since fields can't be defined in a helper a property referring to a newly-defined field can't be created?

MarkMLl
Turbo Pascal v1 on CCP/M-86, multitasking with LAN and graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.

 

TinyPortal © 2005-2018