Re: [fpc-pascal] docs
Also, I think that Michalis Kamburelis' introduction is a must-read for newcomers nowadays: https://castle-engine.io/modern_pascal Best regards, Rafael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Sub-millisecond time measuring
Hi everyone. I am sharing some cross-platform timing I have done, it would
be great to hear from you.
For mac I translated this python implementation to free pascal:
https://github.com/pupil-labs/pyuvc/blob/master/pyuvc-source/darwin_time.pxi
):
```
unit timestamps.machtime;
{$mode objfpc}{$H+}
{$modeswitch objectivec1}
{$linkframework CoreFoundation}
interface
type
mach_timebase_info_data_t = record
numer: UInt32;
denom: UInt32;
end;
mach_timebase_info_t = ^mach_timebase_info_data_t;
function mach_absolute_time: UInt64; cdecl; external name
'mach_absolute_time';
function mach_timebase_info(info: mach_timebase_info_t): Integer; cdecl;
external name 'mach_timebase_info';
implementation
end.
```
However, I could not test it extensively. But here is some sample code:
```
uses ctypes, timestamps.machtime;
{...}
var
timeConvert: Float = 0.0;
//function get_sys_time_monotonic: Float;
function ClockMonotonic : Float;
var
timeBase: mach_timebase_info_data_t;
begin
if timeConvert = 0.0 then begin
mach_timebase_info(@timeBase);
timeConvert :=
(Float(timeBase.numer) / Float(timeBase.denom) / Float(10.0);
end;
Result := mach_absolute_time() * timeConvert;
end;
```
For linux, I am used to clock_gettime (
https://linux.die.net/man/3/clock_gettime):
```
unit timestamps.gnulinux;
uses Linux, UnixType, Math;
{...}
function ClockMonotonic: Float;
var
tp: timespec;
a, b : Float;
begin
clock_gettime(CLOCK_MONOTONIC, @tp);
a := Float(tp.tv_sec);
b := Float(tp.tv_nsec) * 1e-9;
Result := a+b;
end;
```
_
For windows I am used to QueryPerformanceCounter:
```
unit timestamps.windows;
uses Windows, Math;
{...}
var
PerSecond : TLargeInteger;
function ClockMonotonic: Float;
var
Count : TLargeInteger;
begin
QueryPerformanceCounter(Count);
Result := Float(Count) / Float(PerSecond);
end;
initialization
QueryPerformanceFrequency(PerSecond);
```
Of course, you don't need any "ToSeconds" conversion if you don't want to.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
> Why (re-invent the wheel)?
> Why not use Math.Float?
> IIRC then this is Extended, double or Single depending on CPU type.
> And always the largest precision the CPU supports.
Thanks Bart. Math.Float is really great, I will start using it today.
On Tue, Feb 6, 2024 at 2:51 PM Bart wrote:
> On Tue, Feb 6, 2024 at 6:13 PM Rafael Picanço via fpc-pascal
> wrote:
>
>
> > type
> > {$IFDEF CPU86}{$IFDEF CPU32}
> > TLargerFloat = Extended;
> > {$ENDIF}{$ENDIF}
> >
> > {$IFDEF CPUX86_64}
> > TLargerFloat = Double;
> > {$ENDIF}
>
> Why (re-invent the wheel)?
> Why not use Math.Float?
> IIRC then this is Extended, double or Single depending on CPU type.
> And always the largest precision the CPU supports.
>
> --
> Bart
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question
> I’m afraid I don’t qualify for the bonus, because I don’t know what
LargerFloat is.
I am a little bit embarrassed here. The TLargerFloat is a type I wrote for
a simple test some time ago and I forgot about it. I was following the
TLargeInteger convention (from struct.inc in my current windows system):
After realizing that the Extended type was not made for cross-platform, my
point with TLargerFloat was to have a central place to test some types. I
decided to use Double for everything, following the equivalence with
pythonic doubles for timestamp synchronization in the systems I use.
unit timestamps.types;
{$mode ObjFPC}{$H+}
interface
type
{$IFDEF CPU86}{$IFDEF CPU32}
TLargerFloat = Extended;
{$ENDIF}{$ENDIF}
{$IFDEF CPUX86_64}
TLargerFloat = Double;
{$ENDIF}
implementation
end.
___
So, I guess I finally found why precision was better for explicitly
typecasts in Linux (despite the higher granularity of clock_monotonic):
I guess {$MINFPCONSTPREC 64} would avoid explicit typecasting in the
following code, is it correct?
unit timestamps;
{$mode objfpc}{$H+}
// {$MINFPCONSTPREC 64}
interface
uses
SysUtils, timestamps.types
{$IFDEF LINUX}
, Linux
, UnixType
{$ENDIF}
{$IFDEF DARWIN}
, ctypes
, MachTime
{$ENDIF}
{$IFDEF WINDOWS}
, Windows
{$ENDIF}
;
function ClockMonotonic : TLargerFloat;
implementation
{$IFDEF LINUX}
function ClockMonotonic: TLargerFloat;
var
tp: timespec;
a, b : TLargerFloat;
begin
clock_gettime(CLOCK_MONOTONIC, @tp);
a := TLargerFloat(tp.tv_sec);
b := TLargerFloat(tp.tv_nsec) * 1e-9;
Result := a+b;
end;
{$ENDIF}
{$IFDEF DARWIN}
{credits:
https://github.com/pupil-labs/pyuvc/blob/master/pyuvc-source/darwin_time.pxi
}
var
timeConvert: TLargerFloat = 0.0;
function ClockMonotonic : TLargerFloat;
var
timeBase: mach_timebase_info_data_t;
begin
if timeConvert = 0.0 then begin
mach_timebase_info(@timeBase);
timeConvert :=
(TLargerFloat(timeBase.numer) / TLargerFloat(timeBase.denom) /
TLargerFloat(10.0);
end;
Result := mach_absolute_time() * timeConvert;
end;
{$ENDIF}
{$IFDEF WINDOWS}
var
PerSecond : TLargeInteger;
function ClockMonotonic: TLargerFloat;
var
Count : TLargeInteger;
begin
QueryPerformanceCounter(Count);
Result := TLargerFloat(Count) / TLargerFloat(PerSecond);
end;
initialization
QueryPerformanceFrequency(PerSecond);
{$ENDIF}
end.
On Tue, Feb 6, 2024 at 12:52 PM James Richters <
james.richt...@productionautomation.net> wrote:
> This is my opinion from my testing, but others may have something else to
> say.
>
>
>
> 1) Does it affects constants only?
>
> Not really, if you set a variable with constant terms, it is affected, if
> you set a variable with other variables, it is not affected.
>
> Cont
>
>Mycontant := 8432+33/1440.0;//Is affected;
>
> Var
>
>MyDoubleVariable:Double;
>
>
>
> MyDoubleVariable := 8432+33/1440.0; //Is affected
>
>
>
>
>
> Var
>
>MyInteger : Ineger;
>
>MyByte : Byte
>
>MySingle : Single;
>
>MyDouble : Double;
>
>
>
> MyInteger := 8432;
>
> MyByte := 33;
>
> MySingle := 1440.0;
>
> MyDouble := MyInteger + MyByte / MySingle; // is NOT affected;
>
>
>
>
>
> 2) Does it affects the LargerFloat type?
>
> I don’t know what you mean by LargerFloat, but Double an d Extended are
> affected, and even Real if your platform defines Real as a Double.
>
> Anything that is not Single precision is affected.
>
>
>
> 3) Should I use {$MINFPCONSTPREC 64} in {$mode objfpc} too to avoid it?
>
> Everyone should use {$MINFPCONSTPREC 64} in all programs until the bug is
> fixed, unless you use extended, then you have no good solution. Because you
> can’t set it to 80.
>
> 4) BONUS: Is the LargerFloat type really the larger, or should one do
> something else?
>
> I’m afraid I don’t qualify for the bonus, because I don’t know what
> LargerFloat is.
>
>
>
> James
>
>
>
>
>
>
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Floating point question (Rafael Picanço)
I have some questions about {$MINFPCONSTPREC 64} and the mentioned change
introduced by FPC 2.2 (the "it" from here after).
1) Does it affects constants only?
2) Does it affects the LargerFloat type?
3) Should I use {$MINFPCONSTPREC 64} in {$mode objfpc} too to avoid it?
4) BONUS: Is the LargerFloat type really the larger, or should one do
something else?
Best regards,
Rafael
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Division by zero when running SDL program on GPU (NVIDIA)
Thank you Hairy, I will try to ask on the SDL forums. Best, Rafael Picanço On Tue, Jan 30, 2024 at 8:48 AM Hairy Pixels wrote: > I don't think this has anything to do with the compiler. You should > probably ask on the SDL forums. They've been helpful for me before. > > > On Jan 30, 2024, at 6:45 PM, Rafael Picanço via fpc-pascal < > fpc-pascal@lists.freepascal.org> wrote: > > > > Hi everyone, how are you doing? > > > > I am receiving an "FLT divide by zero" error when creating a renderer > with > > > > // will default to Direct3d renderer > > DL_CreateRenderer(FSDLWindow, -1, > > // error > > // SDL_RENDERER_ACCELERATED or SDL_RENDERER_PRESENTVSYNC > > SDL_RENDERER_SOFTWARE > > ); > > > > So, my notebook have two GPUs, an on-board Intel and a discrete NVIDIA , > and the error happens only on NVIDIA. > > > > Here (https://forum.lazarus.freepascal.org/index.php/topic,66042.0.html) > Jamie suggests that I may need to: > > > > Set8087CW($133f) > > > > and Tron suggests: > > > > SetExceptionMask > > > > Calling these functions during the OnCreate in the main form did not > solve the problem. > > > > Can you shed some light on this? > > > > ___ > > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > Regards, > Ryan Joseph > > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Division by zero when running SDL program on GPU (NVIDIA)
Hi everyone, how are you doing? I am receiving an "FLT divide by zero" error when creating a renderer with // will default to Direct3d renderer DL_CreateRenderer(FSDLWindow, -1, // error // SDL_RENDERER_ACCELERATED or SDL_RENDERER_PRESENTVSYNC SDL_RENDERER_SOFTWARE ); So, my notebook have two GPUs, an on-board Intel and a discrete NVIDIA , and the error happens only on NVIDIA. Here (https://forum.lazarus.freepascal.org/index.php/topic,66042.0.html) Jamie suggests that I may need to: Set8087CW($133f) and Tron suggests: SetExceptionMask Calling these functions during the OnCreate in the main form did not solve the problem. Can you shed some light on this? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error: compilation raised exception internally (Rafael Picanço)
It is really not related to specific lines. But sometimes the error will repeat a lot on some lines. Please, can you confirm if a zip file containing the project it self is a minimal valid example? (I am afraid that changing the trying to simplify the project will "solve" the error). With some more specific instructions, I can try to figure out how to build an as minimal as possible example. Best, R Em dom., 22 de out. de 2023 07:00, escreveu: > 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: Error: compilation raised exception internally (Thomas Kurz) >2. Re: Error: compilation raised exception internally (Sven Barth) > > > -- > > Message: 1 > Date: Sat, 21 Oct 2023 19:18:55 +0200 > From: Thomas Kurz > To: FPC-Pascal users discussions > Subject: Re: [fpc-pascal] Error: compilation raised exception > internally > Message-ID: <1201074545.20231021191...@smtp.mailbox.org> > Content-Type: text/plain; charset=us-ascii > > > An exception or an internal error during compilation should *always* be > > reported. > > Please also provide a minimal, self contained example that shows the > > problem. > > This is not always trivial because the internal errors are sometimes quite > fiddly. I have a project in which an internal error occurs sometimes. When > I do a "cleanup and build" (in Lazarus), it works well. There seems to be > an influence of the order in which units are compiled, because I can change > code in many places without getting the internal error again. But when I > change code in other units, I get the internal error, but it's clearly > uncorrelated to the line at which it occurs. > > > > -- > > Message: 2 > Date: Sat, 21 Oct 2023 22:25:45 +0200 > From: Sven Barth > To: FPC-Pascal users discussions > Subject: Re: [fpc-pascal] Error: compilation raised exception > internally > Message-ID: > fuw3hpbkm...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Thomas Kurz via fpc-pascal schrieb am > Sa., 21. Okt. 2023, 19:22: > > > > An exception or an internal error during compilation should *always* be > > > reported. > > > Please also provide a minimal, self contained example that shows the > > > problem. > > > > This is not always trivial because the internal errors are sometimes > quite > > fiddly. I have a project in which an internal error occurs sometimes. > When > > I do a "cleanup and build" (in Lazarus), it works well. There seems to be > > an influence of the order in which units are compiled, because I can > change > > code in many places without getting the internal error again. But when I > > change code in other units, I get the internal error, but it's clearly > > uncorrelated to the line at which it occurs. > > > > Without a way to reproduce and debug the issue it's very unlikely to get > solved especially if it's a problem that only occurs in very specific > circumstances. > > Regards, > Sven > > > > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20231021/18bacdcf/attachment-0001.htm > > > > -- > > Subject: Digest Footer > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > -- > > End of fpc-pascal Digest, Vol 232, Issue 12 > *** > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] Error: compilation raised exception internally
Hi everyone, I am getting a strange error when compiling a project. I am really not sure what is going on, because it occurs sometimes, consistently in some lines of the code with calls to this static variable: ... function NextID(ID : word) : word; ... NextID(ContainerClass.SomeTypeInstance.ID) ... type TSomeType = class(TSomeBaseClass) public ID : TTrialID; static; end; I hit F9 again and then the project compiles with error. Any suggestions? Should I care about this error and report it?? Best, R ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] ideas for using a speech-to-text model with a fpc program
Hi guys, I am looking for some advice on how to use a speech-to-text model with a fpc program designed to teach reading of invented words composed from 8 brazilian portuguese phonemes (four consonants and fours vowels). So, right now ( https://github.com/cpicanco/stimulus-control-sdl2/blob/hanna/src/sdl.app.audio.recorder.devices.pas) the program uses SDL2 to record short 4-5s audio streams and save each recording to a wav file using fpwavwriter. Each audio stream/file is supposed to be a word spoken by a student during a recording/playback session of a word presented on screen. The participant will click a button to finish the session. Then, the program will start a speech-to-text routine and give some feedback. There will be two speech-to-text routines. The first one will be a human transcription (nothing new here for me). The second one will be an IA transcription. I am looking for an approach to read the raw stream (or the saved file if no direct stream support) and pass it to a speech IA model (for example, whisper) and then return some text output for further processing. Using python, Whisper Medium (multilanguage), I got some good (although slow) results without any fine tuning. However, I am considering using Transformers if any fine tuning turns out to be necessary. So, in this context, what would be "the way to go" for using the final model with free pascal? Calling a script with TProcess? Please, can you shed some light on here? Best regards, R ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TStringHelper not found
Thank you Michael, worked like a charm. On Mon, Jul 24, 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. TStringHelper not found (Rafael Pican?o) >2. Re: TStringHelper not found (Michael Van Canneyt) > > > -- > > Message: 1 > Date: Mon, 24 Jul 2023 00:39:11 -0300 > From: Rafael Pican?o > To: fpc-pascal@lists.freepascal.org > Subject: [fpc-pascal] TStringHelper not found > Message-ID: > < > cagpuci76_sr3qfrchuu9vryjta6s2jsmm44keaygxme-4a1...@mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > I just updated to trunk (Lazarus 3.99 4ed7ff9b1c, FPC > 3.3.1-13378-gceddc2aec3) and I am getting an "Identifier not found" error > for TStringHelper: > -- next part -- > An HTML attachment was scrubbed... > URL: < > http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230724/a6268bb9/attachment-0001.htm > > > > -- > > Message: 2 > Date: Mon, 24 Jul 2023 08:34:54 +0200 (CEST) > From: Michael Van Canneyt > To: FPC-Pascal users discussions > Subject: Re: [fpc-pascal] TStringHelper not found > Message-ID: > Content-Type: text/plain; charset="utf-8"; Format="flowed" > > > > On Mon, 24 Jul 2023, Rafael Pican?o via fpc-pascal wrote: > > > I just updated to trunk (Lazarus 3.99 4ed7ff9b1c, FPC > > 3.3.1-13378-gceddc2aec3) and I am getting an "Identifier not found" error > > for TStringHelper: > > I introduced an alias. > > Michael. > > -- > > Subject: Digest Footer > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal > > > -- > > End of fpc-pascal Digest, Vol 229, Issue 18 > *** > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] TStringHelper not found
I just updated to trunk (Lazarus 3.99 4ed7ff9b1c, FPC 3.3.1-13378-gceddc2aec3) and I am getting an "Identifier not found" error for TStringHelper: ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Microsoft SAPI on Freepascal
Hi James,
I am not familiar with variants and Ole objects, sorry about that. I found
some people using code with Ole objects and it that seems to work, can you
chack if it applies to your case?
https://stackoverflow.com/questions/17970573/using-word-ole-in-lazarus-freepascal
Best,
R
On Sun, Jun 25, 2023 at 2:25 PM
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: Microsoft SAPI on Freepascal (Rafael Pican?o)
>2. Re: SDL2 Event Registration (and case statements)
> (Rafael Pican?o)
>3. Re: Microsoft SAPI on Freepascal (Rafael Pican?o)
>4. Re: Microsoft SAPI on Freepascal (James Richters)
>
>
> --
>
> Message: 1
> Date: Sun, 25 Jun 2023 13:33:24 -0300
> From: Rafael Pican?o
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Microsoft SAPI on Freepascal
> Message-ID:
> h9m...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi James,
>
> > SpVoice : Variant;
> > SpVoice := CreateOleObject('SAPI.SpVoice')
>
> The Free Pascal Variant type does not handle interfaces by default. Take a
> look:
>
> https://wiki.freepascal.org/Variant
>
> Best,
> R
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230625/ae39a571/attachment-0001.htm
> >
>
> --
>
> Message: 2
> Date: Sun, 25 Jun 2023 13:42:00 -0300
> From: Rafael Pican?o
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] SDL2 Event Registration (and case
> statements)
> Message-ID:
> hsjvo9...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Thanks Guilhermo,
>
> Just to clarify, I do have a limited number of events. Lets say, 2 events.
> So, using the SDL_RegisterEvents function, is it possible to define these
> two new events as normal constants so they will be known at compile time
> and will make Free Pascal case statements happy?
>
> Best,
> R
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230625/c9a4b1e9/attachment-0001.htm
> >
>
> --
>
> Message: 3
> Date: Sun, 25 Jun 2023 13:52:17 -0300
> From: Rafael Pican?o
> To: fpc-pascal@lists.freepascal.org
> Subject: Re: [fpc-pascal] Microsoft SAPI on Freepascal
> Message-ID:
> <
> cagpuci4jaaqdqnrvjgonezaos61mvuf-okabx92bm9stjo2...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi James,
>
> Sorry, I missed the following reference:
>
> "Remark Dispatch interface support for variants is currently broken in the
> compiler." (https://www.freepascal.org/docs-html/ref/refsu20.html)
>
> Best,
> R
>
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230625/08ee32d3/attachment-0001.htm
> >
>
> --
>
> Message: 4
> Date: Sun, 25 Jun 2023 13:24:46 -0400
> From: "James Richters"
> To: , "'FPC-Pascal users discussions'"
>
> Subject: Re: [fpc-pascal] Microsoft SAPI on Freepascal
> Message-ID: <015d01d9a789$f1097fb0$d31c7f10$@productionautomation.net>
> Content-Type: text/plain; charset="utf-8"
>
> So it?s broken? It seems like the link you provided is trying to show a
> workaround, but I don?t know how I could apply that.
>
> >"Remark Dispatch interface support for variants is currently broken in
> the compiler." (https://www.freepascal.org/docs-html/ref/refsu20.html)
>
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230625/c33bf375/attachment.htm
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> fpc-pascal maillist - fpc-pascal@lists.freepascal.org
> https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
>
>
> --
>
> End of fpc-pascal Digest, Vol 228, Issue 30
> ***
>
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Microsoft SAPI on Freepascal
Hi James, Sorry, I missed the following reference: "Remark Dispatch interface support for variants is currently broken in the compiler." (https://www.freepascal.org/docs-html/ref/refsu20.html) Best, R > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] SDL2 Event Registration (and case statements)
Thanks Guilhermo, Just to clarify, I do have a limited number of events. Lets say, 2 events. So, using the SDL_RegisterEvents function, is it possible to define these two new events as normal constants so they will be known at compile time and will make Free Pascal case statements happy? Best, R ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Microsoft SAPI on Freepascal
Hi James,
> SpVoice : Variant;
> SpVoice := CreateOleObject('SAPI.SpVoice')
The Free Pascal Variant type does not handle interfaces by default. Take a
look:
https://wiki.freepascal.org/Variant
Best,
R
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] EyeLink-for-Pascal
Hi everyone! I am sharing my free pascal bindings for eyelink headers. https://github.com/cpicanco/EyeLink-for-Pascal If you find it useful, please let me know. Best, R ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
[fpc-pascal] SDL2 Event Registration (and case statements)
Hi, The SDL2 documentation recommends you to register constants with: Uint32 SDL_RegisterEvents(int numevents); numevents = the number of events to be allocated. Returns the beginning event number, or (Uint32)-1 if there are not enough user-defined events left. https://wiki.libsdl.org/SDL2/SDL_RegisterEvents The SDL_RegisterEvents result is not known at compile time, so one can't use them as case conditions. So, Is there a workaround for building these constants at compile time? Best, R ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc-pascal Digest, Vol 228, Issue 17
Hi Tomas,
On top of your suggestion, the only way to make FPC happy is to assign nil
to the type constants and then assign the corresponding pointers to them
somewhere:
unit eyelink.constants
interface
const
EXTERNAL_DEV_NONE : TGetExButtonStatesFunction = nil;
EXTERNAL_DEV_CEDRUS : TGetExButtonStatesFunction = nil;
EXTERNAL_DEV_SYS_KEYBOARD : TGetExButtonStatesFunction = nil;
implementation
initialization
EXTERNAL_DEV_NONE := TGetExButtonStatesFunction(Pointer(0));
EXTERNAL_DEV_CEDRUS := TGetExButtonStatesFunction(Pointer(1));
EXTERNAL_DEV_SYS_KEYBOARD := TGetExButtonStatesFunction(Pointer(2));
end.
program godcastsucks;
uses eyelink.constants;
function enable_external_calibration_device(
buttonStatesfcn: TGetExButtonStatesFunction
{other arguments removed for simplicity}): Int32; cdecl;
var
Statesfcn : TGetExButtonStatesFunction;
begin
if buttonStatesfcn = nil then
begin
WriteLn('Function is nil');
end else begin
WriteLn('Function is not nil');
end;
Result := Int32(buttonStatesfcn);
case Result of
0 : { do something };
1 : { do something };
2 : { do something }
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(TGetExButtonStatesFunction(EXTERNAL_DEV_CEDRUS)));
WriteLn(enable_external_calibration_device(@ExButtonStatesFunction));
ReadLn;
end.
Best,
R
PS. If you find a better solution, please make me known!
___
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)
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 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 W
Re: [fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)
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. (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.
>
>
> --
>
> Subject: Digest Footer
>
>
[fpc-pascal] Free Pascal bindings for EyeLink C code (with a god-cast)
Hi everyone,
First of all, I am sorry if this is not the best place for this
interoperability issue.
The problem I want to solve is how to make a Free Pascal binding for to the
following piece of C code:
typedef struct _CCDBS {
void *userdata;
char buttons[256];
void *internal;
}CCDBS;
typedef int (ELCALLBACK *getExButtonStates)(CCDBS *);
#define EXTERNAL_DEV_NONE ((getExButtonStates)0)
#define EXTERNAL_DEV_CEDRUS ((getExButtonStates)1)
#define EXTERNAL_DEV_SYS_KEYBOARD ((getExButtonStates)2)
int ELCALLTYPE enable_external_calibration_device(getExButtonStates
buttonStatesfcn, const char * config, void *userData);
Questions
(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.
(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?
type
PCCDBS = ^TCCDBS;
TCCDBS = record
userdata: Pointer;
buttons: array[0..255] of Char;
internal: Pointer;
end;
TGetExButtonStatesFunction = function (accdbs: PCCDBS): Int32; ELCALLTYPE
function enable_external_calibration_device(
buttonStatesfcn: TGetExButtonStatesFunction;
config: PChar; userData: Pointer): Int32; ELCALLTYPE ELDLL
(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:
{$ifndef ELCALLTYPE}
{$IFDEF Windows}
{$DEFINE ELCALLTYPE := stdcall;}
{$ELSEIF Linux}
{$DEFINE ELCALLTYPE := cdecl;}
{$ELSE}
{$DEFINE ELCALLTYPE := cdecl;}
{$ENDIF}
{$endif}
(4) I can send the code and soon will release it on my GitHub (cpicanco).
Best.
R
PS.: You can find a related discussion here
https://stackoverflow.com/questions/76427311/free-pascal-bindings-for-a-typedef-function-inside-a-define-macro-and-a-number-o
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
