Re: [fpc-pascal] Here is real time graphics and physics simulation, library

[Marco van de Voort via fpc-pascal]

On 1-8-2022 11:12, Michael Van Canneyt via fpc-pascal wrote:


Hence my proposal to refactor it in sysutils, so at least the 
exception handling

can be kept common to all units.


His main objection seems to be the IFDEFING, which is hard to avoid in a 
20 targets + compiler.


Also, the browsability is doable with lazarus (which processes %MAINUNIT 
etc for navigation), and the OP doesn't explain what he used where 
source navigation failed.

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

Re: [fpc-pascal] Here is real time graphics and physics simulation, library

[Michael Van Canneyt via fpc-pascal]

On Mon, 1 Aug 2022, Ingemar Ragnemalm via fpc-pascal wrote:



Den 2022-08-01 kl. 09:40, skrev fpc-pascal-requ...@lists.freepascal.org:

Date: Sun, 31 Jul 2022 09:05:56 -0400
From: Anthony Walter 

Michael, it's the same logic behind my now 12 year old Bare game system
that did the exact same thing. I am creating a small lPascal ibrary that
removes a lot of cruft and depends minimally on SDL for creating windows,
managing input, handling sound, threads / mutexes. and move most of the
core of what you need into a single unit (Tiny.System). In to browsable and
organized uint replaced all string handling with much more efficient and
powerful functions (see my FTP client and other socket protocols, my JSON
parser, ), I also add in multicast delegates for events, path handling,
file handling, file search, stream handling, and better threads (my simple
threads were copied into ).


I have exactly the same principle for all code I create for my teaching. I 
maximize transparency and keep the size down. For graphics, I go even further 
and only depend on OpenGL and the underlying window system.


There are big libraries with lots of bells and whistles. They can be useful, 
but not to get started with. I see myself replacing 100 files with one, 
megabytes of code with kilobytes.


It is pretty hard to balance usability and minimum size but I think I am 
doing fairly well.


So, reimplementing to something smaller and more transparent is not a bad 
thing at all. It is a matter of goals.


I agree, and I don't argue with the desire to have a set of separate
routines which suits someones goals better.

But the exception handling is a real problem, because it affects ALL units,
regardless of whether it uses your 'better API' or not: 
as said it renders the code inoperable with all other code.


Hence my proposal to refactor it in sysutils, so at least the exception handling
can be kept common to all units.

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

Re: [fpc-pascal] Here is real time graphics and physics simulation, library

[Ingemar Ragnemalm via fpc-pascal]

Den 2022-08-01 kl. 09:40, skrev fpc-pascal-requ...@lists.freepascal.org:

Date: Sun, 31 Jul 2022 09:05:56 -0400
From: Anthony Walter 

Michael, it's the same logic behind my now 12 year old Bare game system
that did the exact same thing. I am creating a small lPascal ibrary that
removes a lot of cruft and depends minimally on SDL for creating windows,
managing input, handling sound, threads / mutexes. and move most of the
core of what you need into a single unit (Tiny.System). In to browsable and
organized uint replaced all string handling with much more efficient and
powerful functions (see my FTP client and other socket protocols, my JSON
parser, ), I also add in multicast delegates for events, path handling,
file handling, file search, stream handling, and better threads (my simple
threads were copied into ).


I have exactly the same principle for all code I create for my teaching. 
I maximize transparency and keep the size down. For graphics, I go even 
further and only depend on OpenGL and the underlying window system.


There are big libraries with lots of bells and whistles. They can be 
useful, but not to get started with. I see myself replacing 100 files 
with one, megabytes of code with kilobytes.


It is pretty hard to balance usability and minimum size but I think I am 
doing fairly well.


So, reimplementing to something smaller and more transparent is not a 
bad thing at all. It is a matter of goals.


/Ingemar


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

Re: [fpc-pascal] UBER H3 API working/partially converted

[Marco van de Voort via fpc-pascal]

On 31-7-2022 15:55, Skybuck Flying via fpc-pascal wrote:
(I mainly write this second e-mail to prevent you from wasting time on 
the previous e-mail, cause the conversion was already quite 
successfull with a different tool, read below)



IIRC h2pas doesn't like calling convention modifiers, nor extern C {} 
blocks, and some postediting to simplify them can help get it through.

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

[fpc-pascal] UBER H3 API working/partially converted

[Skybuck Flying via fpc-pascal]

(I mainly write this second e-mail to prevent you from wasting time on the 
previous e-mail, cause the conversion was already quite successfull with a 
different tool, read below)

The in Delphi written tool CHET was used to convert the C api for UBER H3 
library.

https://github.com/neslib/Chet
[https://opengraph.githubassets.com/b39cf935c557cba4185d6776c2195f5790769b08f096256d01ca89b5ab57a40c/neslib/Chet]
GitHub - neslib/Chet: C Header Translator for 
Delphi
Chet - C Header Translator for Delphi. Chet is a .h-to-.pas translator powered 
by libclang for Delphi.. Features. Unlike some other header translators, Chet 
uses the Clang compiler to parse header files, resulting in more accurate 
translations that require fewer manual adjustments.
github.com


CHET uses LIBClang for Delphi. Which can be found at: 
https://github.com/neslib/Neslib.Clang
[https://opengraph.githubassets.com/fc65d8cd6fa05f844e7d52fe10a26ddaa1814241a437d1e8c101db34bce19f7b/neslib/Neslib.Clang]
GitHub - neslib/Neslib.Clang: libclang for 
Delphi
Neslib.Clang - libclang for Delphi. Libclang is the C Interface to Clang's C 
family of compilers. It provides a relatively small API that exposes facilities 
for parsing source code into an abstract syntax tree (AST), loading 
already-parsed ASTs, traversing the AST, associating physical source locations 
with elements within the AST, and other facilities that support Clang-based 
development tools.
github.com


I don't know if LIBClang for Free Pascal Exist.

But this chet tool in combination with this LibClang was pretty awesome !

Especially cause this was quite a complex/bitch of an api, with crazy painfull 
macros, but the tool performed pretty well and did it's best and produced 
something useable.
I had to only disable/comments 5 lines of code.

The api was briefly tested and it seems to work !

Some improvements can be made by using properties to access H3Indexes directly 
etc.

This will be done/attempted in the near future.

For now for what it's worth here is the unit code, ofcourse it kinda sucks to 
have it in e-mail format.

Maybe later I uploaded it somewhere...

unit UBER_H3_API;
{ This unit is automatically generated by Chet:
  https://github.com/neslib/Chet }

{$MINENUMSIZE 4}

interface

const
  {$IF Defined(WIN64)}
  UBER_H3 = 'h3_release_64_bit.dll';
  _PU = '';
  {$ELSE}
{$MESSAGE Error 'Unsupported platform'}
  {$ENDIF}

const
  M_PI = 3.14159265358979323846;
  M_PI_2 = 1.5707963267948966;
  M_2PI = 6.28318530717958647692528676655900576839433;
  M_PI_180 = 0.017453292519943295769236907684886127;
  M_180_PI = 57.29577951308232087679815481410517033240547;
  EPSILON = 0.0001;
  M_SQRT3_2 = 0.8660254037844386467637231707529361834714;
  M_SIN60 = M_SQRT3_2;
  M_AP7_ROT_RADS = 0.333473172251832115336090755351601070065900389;
  M_SIN_AP7_ROT = 0.3273268353539885718950318;
  M_COS_AP7_ROT = 0.9449111825230680680167902;
  EARTH_RADIUS_KM = 6371.007180918475;
  RES0_U_GNOMONIC = 0.3819660112501053;
  MAX_H3_RES = 15;
  NUM_ICOSA_FACES = 20;
  NUM_BASE_CELLS = 122;
  NUM_HEX_VERTS = 6;
  NUM_PENT_VERTS = 5;
  NUM_PENTAGONS = 12;
  H3_CELL_MODE = 1;
  H3_DIRECTEDEDGE_MODE = 2;
  H3_EDGE_MODE = 3;
  H3_VERTEX_MODE = 4;
  { TODO : Unable to convert function-like macro: }
  (* H3_EXPORT ( name ) name *)
  H3_NULL = 0;
  H3_VERSION_MAJOR = 4;
  H3_VERSION_MINOR = 0;
  H3_VERSION_PATCH = 0;
  MAX_CELL_BNDRY_VERTS = 10;
  EPSILON_DEG = 0.1;
  EPSILON_RAD = (EPSILON_DEG*M_PI_180);
  NORMALIZATION_SUCCESS = 0;
  NORMALIZATION_ERR_MULTIPLE_POLYGONS = 1;
  NORMALIZATION_ERR_UNASSIGNED_HOLES = 2;
  { TODO : Macro probably uses invalid symbol "currentCoord": }
  (* INIT_ITERATION_LINKED_LOOP LinkedLatLng * currentCoord = NULL ; 
LinkedLatLng * nextCoord = NULL *)
  { TODO : Unable to convert function-like macro: }
  (* GET_NEXT_COORD ( loop , coordToCheck ) coordToCheck == NULL ? loop -> 
first : currentCoord -> next *)
  { TODO : Unable to convert function-like macro: }
  (* ITERATE_LINKED_LOOP ( loop , vertexA , vertexB ) currentCoord = 
GET_NEXT_COORD ( loop , currentCoord ) ; if ( currentCoord == NULL ) break ; 
vertexA = currentCoord -> vertex ; nextCoord = GET_NEXT_COORD ( loop , 
currentCoord -> next ) ; vertexB = nextCoord -> vertex *)
  { TODO : Unable to convert function-like macro: }
  (* IS_EMPTY_LINKED_LOOP ( loop ) loop -> first == NULL *)
  { TODO : Unable to convert function-like macro: }
  (* H3_MEMORY ( name ) name *)
  IJ = 1;
  KI = 2;
  JK = 3;
  INVALID_FACE = -1;
  INVALID_BASE_CELL = 127;
  MAX_FACE_COORD = 2;
  INVALID_ROTATIONS = -1;
  H3_NUM_BITS = 64;
  H3_MAX_OFFSET = 63;
  H3_MODE_OFFSET = 59;
  H3_BC_OFFSET = 45;
  H3_RES_OFFSET = 52;
  H3_RESERVED_OFFSET = 56;
  H3_PER_DIGIT_OFFSET = 3;
  { TODO : Macro probably uses invalid symbol "uint64_t": }
  (* H3_HIGH_BIT_MASK ( ( uint64_t ) ( 1 ) <<