Re: [fpc-pascal] Function to create a record ?

[Henry Vermaak via fpc-pascal]

On Fri, 2 Jun 2023 at 01:36, Steve Litt via fpc-pascal
 wrote:
> fillchar(junkvar, junkvar_size, 'b');
> person := modperson(person, 'Martin');
> person := modperson(person2, 'Maria');

Maybe a typo? (E.g. person2 := modperson(person2, 'Maria'))

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

Re: [fpc-pascal] I am offering a $100 reward for linking static libraries

[Henry Vermaak via fpc-pascal]

On Thu, 25 Aug 2022 at 04:08, Anthony Walter via fpc-pascal
 wrote:
> I've written a utility to extract mingw64 static library exports into a 
> searchable database. This allows me to search for possible missing functions 
> (see the screenshot below)
>
> https://cache.getlazarus.org/images/desktop/raylib-static.png

Note for anyone with msys2, you can make a file containing all defined
external symbols like this:

# find /mingw64/lib -name "*.a" -exec nm -pogC --defined-only '{}' \;
2>/dev/null >> symbs.txt

Then search it with grep:

hcv@hcv-l14 MINGW64 ~
# grep -w atexit symbs.txt
C:/msys64/mingw64/lib/libmsvcr120.a:libmsvcr120_defs01591.o:
T atexit
C:/msys64/mingw64/lib/libmsvcr120_app.a:libmsvcr120_app_defs01268.o:
T atexit
C:/msys64/mingw64/lib/libmsvcr120d.a:libmsvcr120d_defs01654.o:
T atexit

hcv@hcv-l14 MINGW64 ~
# grep -w sincos symbs.txt
C:/msys64/mingw64/lib/libmingwex.a:lib64_libmingwex_a-cossin.o:
T sincos

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

Re: [fpc-pascal] I am offering a $100 reward for linking static libraries

[Henry Vermaak via fpc-pascal]

On Mon, 22 Aug 2022 at 22:42, Pierre Muller via fpc-pascal
 wrote:
> Le 22/08/2022 à 18:18, Henry Vermaak via fpc-pascal a écrit :
> > On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal
> >  wrote:
> >> I am also able to use mingw32 gcc to compile this same C source into a 
> >> static library for Windows using these two commands while inside the 
> >> folder containing the Chipmunk2D sources:
> >>
> >> x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 -ffast-math 
> >> src/*.c -Iinclude -c
> >
> > -static and -static-libgcc are linking options, so they won't do
> > anything here.  You'll have to link libgcc in manually in your pascal
> > source.
>
>You can always pass option to the external linker using '-k' option:
> Use -k-static (without space)
> or -k-lc
> or -k-L -k/DIR/

Without -static-libgcc you'll still have to figure out which archives
make up libgcc.  ld won't do that for you.

Either way I think that unless fpc can be built with the same
toolchain as the C libs you're linking with there may be too many
things that can go wrong.  E.g. I'm getting 0-bit reloc in dll errors
with the external linker.

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

Re: [fpc-pascal] I am offering a $100 reward for linking static libraries

[Henry Vermaak via fpc-pascal]

On Sun, 21 Aug 2022 at 18:34, Anthony Walter via fpc-pascal
 wrote:
> I am also able to use mingw32 gcc to compile this same C source into a static 
> library for Windows using these two commands while inside the folder 
> containing the Chipmunk2D sources:
>
> x86_64-w64-mingw32-gcc-win32 -static -static-libgcc -std=gnu99 -ffast-math 
> src/*.c -Iinclude -c

-static and -static-libgcc are linking options, so they won't do
anything here.  You'll have to link libgcc in manually in your pascal
source.

> {$ifdef windows}
>   {$linklib mingw32}
>   {$linklib mingwex}
>   {$linklib kernel32}
>   {$linklib msvcrt}
>   {$linklib chipmunk-win}
> {$endif}
>
> I get many errors similar to these below:
>
> Verbose: Compiling resource 
> C:\Development\Projects\physics\lib\x86_64-win64\Physics.obj
> Verbose: Linking C:\Development\Pascal\Projects\physics\Physics.exe
> Physics.lpr(30,1) Error: Undefined symbol: ___chkstk_ms
> Physics.lpr(30,1) Error: Undefined symbol: __mingw_raise_matherr
> Physics.lpr(30,1) Error: Undefined symbol: __imp_WideCharToMultiByte
> Physics.lpr(30,1) Error: Undefined symbol: __imp_IsDBCSLeadByteEx
> Physics.lpr(30,1) Error: Undefined symbol: __imp_MultiByteToWideChar
> Physics.lpr(30,1) Verbose: There were 5 errors compiling module, stopping
> Verbose: Compilation aborted

The order of the linklib entries make a difference.  I can get the
undefined symbols down to nothing by using this order:

{$linklib libchipmunk.a}
{$linklib libmingwex.a}
{$linklib libmingw32.a}
{$linklib libgcc.a}
//{$linklib libmsvcrt.a}
{$linklib libmsvcr120.a}
{$linklib libkernel32.a}

But then I get an internal error (200603061).  It may be down to the
toolchain/libraries I used (recent msys2 x64), which would be a lot
newer than fpc (I should really try to package it for msys2 when I
have some free time).

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

Re: [fpc-pascal] Option type

[Henry Vermaak via fpc-pascal]

On Tue, 1 Jun 2021, 23:39 Ryan Joseph via fpc-pascal, <
fpc-pascal@lists.freepascal.org> wrote:

>
>
> > On Jun 1, 2021, at 12:56 PM, denisgolovan 
> wrote:
> >
> > That would limit supported types to class instances.
> > I'll like to avoid that.
> > Ideally TOption type should allow any type (primitives, strings,
> objects, class instances, etc).
>
> What are you trying to make that requires a variant record? I don't know
> what "TOption" is.


https://en.wikipedia.org/wiki/Option_type

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

Re: [fpc-pascal] How to find where my app consumes CPU?

[Henry Vermaak via fpc-pascal]

On Wed, 19 May 2021 at 14:36, Travis Siegel via fpc-pascal
 wrote:
>
> No doubt your sleep code works just fine.
>
> I'm not saying the sleep command doesn't work.
>
> I'm saying the sleep command doesn't release unused cpu cycles for other
> threads/programs to use.

No, fpc uses nanosleep() inside sysutils.sleep() which is documented
to suspend execution (i.e. no busy waiting) so the kernel will switch
to another thread/process.

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

Re: [fpc-pascal] FTP support gone - switch to HTTP ?

[Henry Vermaak via fpc-pascal]

On Tue, 18 May 2021 at 11:50, Sven Barth via fpc-pascal
 wrote:

> I don't think we need to mention any specific clients (and why did your list 
> not include Filezilla? :P )

Because FileZilla bundles adware when you download from the homepage?
Would actually be good to warn _against_ using it.

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

Re: [fpc-pascal] OpenCV

[Henry Vermaak via fpc-pascal]

On Thu, 13 Feb 2020 at 13:26, Adriaan van Os  wrote:
>
>
> I looked around on the web for OpenCV Pascal bindings. What I found, seems to 
> be based (mostly) on
> the OpenCV C interfaces, which covers only part of OpenCV.
>
> Alternatives are:
>8---
> 2. Hook into the Python wrapper/bindings generator >

I think using the python/java generator is the only way to make
anything that resembles a complete binding.  As an intermediate step I
hoped that the generated C bindings could be run through h2pas, but
h2pas has never worked without manual tinkering for me.  In the long
run a class-based binding would be great to have.  I've been meaning
to look into this, but digging through thousands of lines of python is
not my idea of fun.

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

Re: [fpc-pascal] Detecting console close with red X on windows

[Henry Vermaak]

On Sun, 19 May 2019 at 14:33, James Richters
 wrote:
>
> Could I please get an example of this?  I see lots of examples of how to do 
> it in C but when I try to translate to pascal I always struggle a quite a bit.

Have a look at the fpc source in packages/fv/src/w32msg.inc and search
for SetConsoleCtrlHandler and then HandleConsoleCtrl.  There's nothing
to it, really.

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

Re: [fpc-pascal] Detecting console close with red X on windows

[Henry Vermaak]

On Sun, 19 May 2019, 13:23 James Richters, 
wrote:

> Is there a way I can detect that a user has pushed the red X in the upper
> right corner to close the console window in a free pascal console
> application so I can save some files before the program terminates?
>
You can do that with SetConsoleCtrlHandler() and catching  CTRL_CLOSE_EVENT
in the handler.

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

Re: [fpc-pascal] Unbuffering I/O

[Henry Vermaak]

On Thu, Aug 30, 2018 at 10:57:21AM +, Mark Morgan Lloyd wrote:
> Ah yes, that's it, thanks very much.
> 
>   WriteLn(StdErr, Format('# Socket %s, clock resolution %8.6f uSec',
> [socketName, ts.tv_nsec / 1000]));
> ttextrec(StdErr).flushfunc:= ttextrec(StdErr).inoutfunc;
> while true do begin
>   ttextrec(Output).flushfunc:= ttextrec(Output).inoutfunc;
>   i := fprecv(client, @buff, 1024, 0);

You only need to set flushfunc once at startup (for standard handles) or
just after opening a file.  The whole output vs stdout thing has
confused me in the past, too.

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

Re: [fpc-pascal] Unbuffering I/O

[Henry Vermaak]

On Thu, Aug 30, 2018 at 09:45:00AM +, Mark Morgan Lloyd wrote:
> On 30/08/18 09:00, Henry Vermaak wrote:
> >On Thu, Aug 30, 2018 at 07:52:54AM +0200, Martin Schreiber wrote:
> 
> >In order to flush textfiles automatically I use> ">  
> >ttextrec().flushfunc:= ttextrec().inoutfunc;> "> after it 
> >is opened.
> 
> >Reading text.inc this morning lead me to believe this is the correctway.  
> >This is what the RTL does when opening serial devices inFileOpenFunc(), for 
> >example.  There's a comment inside Flush() that saysthat InOutFunc() should 
> >be used to flush, since the FlushFunc() may notbe assigned.
> 
> I've just checked this and unfortunately it doesn't do very much for the
> standard device (?) used by WriteLn() etc., i.e. as would be used for a
> quick-and-dirty program.

It definitely works for me.  I made a program flush.pas that looks like this:

begin
ttextrec(output).flushfunc := ttextrec(output).inoutfunc;
writeln('hi there');
sleep(1000);
end.

Running `./flush > out.txt` and `tail -F out.txt` shows the output
immediately, while removing the flushfunc assignment causes a delay of a
second before the output appeared in the file.

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

Re: [fpc-pascal] Unbuffering I/O

[Henry Vermaak]

On Thu, Aug 30, 2018 at 07:52:54AM +0200, Martin Schreiber wrote:
> On Wednesday 29 August 2018 17:01:54 Mark Morgan Lloyd wrote:
> > I think I've seen this question asked before, my apologies if this was
> > recently.
> >
> > I've got two programs intended to be functionally identical, one in Perl
> > and the other in FPC. They read a unix-domain datagram, decode the
> > message, and emit output; if this goes to a file then it's reasonable to
> > monitor it using  tail -f
> >
> > Perl has a variable that you can set to force output to be unbuffered,
> > with the result that as soon as a message is output it's in the file in
> > its entirety.
> >
> > Is there an equivalent for Pascal, or should I be using something like
> > fpSync(stdout) at opportune times?
> 
> In order to flush textfiles automatically I use
> "
>  ttextrec().flushfunc:= ttextrec().inoutfunc;
> "
> after it is opened.

Reading text.inc this morning lead me to believe this is the correct
way.  This is what the RTL does when opening serial devices in
FileOpenFunc(), for example.  There's a comment inside Flush() that says
that InOutFunc() should be used to flush, since the FlushFunc() may not
be assigned.

Thanks for this, Martin.

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

Re: [fpc-pascal] Unbuffering I/O

[Henry Vermaak]

On Wed, Aug 29, 2018 at 03:01:54PM +, Mark Morgan Lloyd wrote:
> I think I've seen this question asked before, my apologies if this was
> recently.
> 
> I've got two programs intended to be functionally identical, one in Perl and
> the other in FPC. They read a unix-domain datagram, decode the message, and
> emit output; if this goes to a file then it's reasonable to monitor it using
> tail -f
> 
> Perl has a variable that you can set to force output to be unbuffered, with
> the result that as soon as a message is output it's in the file in its
> entirety.
> 
> Is there an equivalent for Pascal, or should I be using something like
> fpSync(stdout) at opportune times?

Does SetTextBuf() with a buffer of size 1 work?  I don't think there is
anything equivalent to setvbuf().  Otherwise you'll have to Flush() them
manually, which is a pain.

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 12:07:10PM +0200, Michael Van Canneyt wrote:
> >On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> If you need to "reduce the scope of variables", your routines are too long to
> begin with.
> 
> If of course you write routines of several hundreds of lines (or thousands),
> then you probably would need to have such a feature.
> 
> But I would fire any programmer that writes such code anyway, since it
> indicates he cannot think structured.

And I'd fire any programmer that doesn't properly scope their variables,
just as you'd (hopefully) fire a programmer for using global instead of
function level variables.

> But probably this whole answer is again too hyperbole :-)

It's not the hyperbole that really worries me too much, I like a bit of
that myself.  I'm worried about the knee-jerk reactions to good ideas.
Badly written responses like "reduces readability" is extremely
uncharitable without proper motivation and projects the image that
everyone on this list will just shoot down any improvement to their
beloved Pascal.

Anyway, not much to add to the subject without repeating myself.

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 12:07:42PM +0200, Martin wrote:
> On 17/07/2018 12:02, Henry Vermaak wrote:
> >On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> >>*you* might do this, but there are enough developers that won't. I
> >>already
> >By not having this feature you're not giving anyone a choice.
> >
> By having this feature you are forcing everyone to use it.

No, why would you think that?  Nobody is forcing you to move your
variables into a block, just carry on as before if you don't like it.
Var sections for functions are optional, you can use global variables
for everything if you like.  No different to this.

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:45:26AM +0200, Sven Barth via fpc-pascal wrote:
> Henry Vermaak  schrieb am Di., 17. Juli 2018,
> 11:05:
> 
> > On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> > > Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> > >
> > > > I have some suggestions of change to freepascal syntax, just to debate
> > > >
> > > > (All are backward compatible)
> > > >
> > > > - Declaring variables inside blocks, and loop variables
> > > >
> > > -> reduces readability -> no interest
> >
> > How can it reduce readability?  You move variables closer to where they
> > are used, therefore reducing clutter in the main "var" section.
> >
> 
> *you* might do this, but there are enough developers that won't. I already

By not having this feature you're not giving anyone a choice.

> don't like looking at such C code, so why would I want that in Pascal which
> avoided that problem?

What problem?  I'm not saying I want to mix declarations with code, the
var section should be at the top of the block/scope.  I don't even know
any C programmers that mix declarations with code.  This isn't the 80s.

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Tue, Jul 17, 2018 at 11:14:31AM +0200, Michael Van Canneyt wrote:
> On Tue, 17 Jul 2018, Henry Vermaak wrote:
> >On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> >>Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> >>
> >>> I have some suggestions of change to freepascal syntax, just to debate
> >>>
> >>> (All are backward compatible)
> >>>
> >>> - Declaring variables inside blocks, and loop variables
> >>>
> >>-> reduces readability -> no interest
> >
> >How can it reduce readability?  You move variables closer to where they
> >are used, therefore reducing clutter in the main "var" section.
> 
> Pascal separates declaration from implementation. This proposal changes
> that, it mixes implementation with declaration.

No, it will still separate the declaration, but just on the block level.
For example:

for i := 0 to n - 1 do
var
  foo: integer = 0;
begin
  // ...
end;

> When you look for a variable, you know it is in the declaration block.
> If you need to start scanning the code, this is a major nuisance.

If you're in a block, you look at the "var" section of the block first,
then move up a block and repeat.  Calling it "a major nuisance" is
needless hyperbole.  In the above code, why do I want to see foo in the
main "var" block of the function?  It's just noise there, reducing
readability.

> I can't count the misunderstandings in Javascript due to this 'feature'.

This feature makes you properly reduce scope of variables, I seriously
haven't met anyone that thinks this is a bad idea.  It's standard
programming practise in every language I've worked.

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

Re: [fpc-pascal] Syntax changes suggestions

[Henry Vermaak]

On Mon, Jul 16, 2018 at 03:02:42PM +0200, Sven Barth via fpc-pascal wrote:
> Santiago A.  schrieb am Mo., 16. Juli 2018, 13:41:
> 
> > I have some suggestions of change to freepascal syntax, just to debate
> >
> > (All are backward compatible)
> >
> > - Declaring variables inside blocks, and loop variables
> >
> -> reduces readability -> no interest

How can it reduce readability?  You move variables closer to where they
are used, therefore reducing clutter in the main "var" section.
Limiting variable scope is definitely a good thing, I sure hope you're
not arguing against that.  That's why almost all languages encourage it.

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

Re: [fpc-pascal] Libxml2 - How to get messages on Linux?

[Henry Vermaak]

On Fri, May 25, 2018 at 12:48:20PM +0200, Gabor Boros wrote:
> 2018. 05. 24. 9:37 keltezéssel, Michael Van Canneyt írta:
> >Are these functions callbacks ? If so, is the calling convention correct ?
> 
> I used xmlSchemaSetValidErrors and the documentation say "Set the error and
> warning callback informations". Tried with and without cdecl.

These functions use varargs, so the calling convention is different:

https://www.freepascal.org/docs-html/ref/refsu87.html

I thought it only works with external code, though.  Would be useful if
the documentation mentioned anything.

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

Re: [fpc-pascal] GetLocaleInfo returns ZZZ

[Henry Vermaak]

On Wed, Feb 28, 2018 at 01:36:31PM +0100, Bart wrote:
> On Wed, Feb 28, 2018 at 10:58 AM, Henry Vermaak <henry.verm...@gmail.com> 
> wrote:
> > The Windows implementation of GetLanguageIDs() in gettext.pp is not
> > right.  It uses GetLocaleInfo() with LOCALE_SABBREVLANGNAME and
> > LOCALE_SABBREVCTRYNAME where it should probably be using
> > LOCALE_SISO639LANGNAME and LOCALE_SISO3166CTRYNAME, respectively.  The
> > *_SISO* constants work on Windows 98 and later, maybe that was the
> > reason for using *_SABBREV* originally.
> 
> Results of GetLocaleInfo with different parameters on my Win10 machine:
> 
> LOCALE_SABBREVLANGNAME -> NLD
> LOCALE_SABBREVCTRYNAME -> NLD
> LOCALE_SISO639LANGNAME -> nl
> LOCALE_SISO3166CTRYNAME -> NL
> LOCALE_SISO639LANGNAME2 -> nld
> LOCALE_SISO3166CTRYNAME2 -> NLD

Yes, it makes no difference for nl, that's why I posted a link that
contains a table that shows where the differences are.

Note that I don't have an answer for the zzz problem, it works fine for
me.  I was addressing the second paragraph of Darius's mail.

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

Re: [fpc-pascal] GetLocaleInfo returns ZZZ

[Henry Vermaak]

On Wed, Feb 21, 2018 at 12:11:10PM +0100, Darius Blaszyk wrote:
> On my machine getlocaleinfo returns ZZZ when requesting the abbrev
> langname. The country code is correctly set to NL. This makes
> gettext.GetLanguageIDs return zz_NL. What could be causing this?
> 
> Also the behavior of GetLocaleInfoIDs does not seem to be according to
> the gettext manual. On windows the locale is determined by the Win API
> and on all other platforms the environment variables are checked as
> they are described in the manual but the first LANGUAGE env var is not
> probed and followed. This env var gives the preferred order of
> translations.

The Windows implementation of GetLanguageIDs() in gettext.pp is not
right.  It uses GetLocaleInfo() with LOCALE_SABBREVLANGNAME and
LOCALE_SABBREVCTRYNAME where it should probably be using
LOCALE_SISO639LANGNAME and LOCALE_SISO3166CTRYNAME, respectively.  The
*_SISO* constants work on Windows 98 and later, maybe that was the
reason for using *_SABBREV* originally.

I guess the fix belongs in FPC, but it can also be fixed in lazarus,
which overrides GetLanguageIDs() for darwin already.  Have a look at
LazGetLanguageIDs() in lazutf8.pas.  I override the lot of them and then
call SetDefaultLang() in LCLTranslator.pas.

For reference, the reason I had to fix it was because of the language
codes for Chinese don't agree (CHS/CHT vs zh) and I didn't want to
duplicate the locale directories.  There's a table here:

http://archives.miloush.net/michkap/archive/2005/02/17/375235.html

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

Re: [fpc-pascal] Linux udev messages

[Henry Vermaak]

On 7 Feb 2018 09:54, "Mark Morgan Lloyd" 
wrote:

Has anybody used NETLINK_KOBJECT_UEVENT on linux to get messages relating
to device hotplugging and removal? It seems like the sort of thing that
could be monitored by a TIdleTimer event handler for at least cosmetic
purposes.


This is what libudev is for. I've used it successfully to monitor USB
hotplugging for many years now.

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

Re: [fpc-pascal] Defining sonames?

[Henry Vermaak]

On 17 Aug 2017 21:21, "Graeme Geldenhuys" 
wrote:

On 2017-08-17 16:52, Martin Schreiber wrote:

> Exactly. So why not use the SONAME in the Pascal binding unit instead to
> use
> the base name as Free Pascal currently does in xlib.pp for example?
>

I forked the xlib, xutils and x units from FPC and tried just that. It made
no difference. When I compiled the project with the -Cn command line
parameter I reviewed the ppas.sh and .res file. The .res file has
a INPUT section near the end listing all dependent libraries. They are
translated to the same as when you use GCC's -l command line parameter.
Only the base name of the library is used. Also, apparently the Unix/Linux
linker (FPC doesn't have it's own - only for Windows) doesn't support
versioned library names as command line parameters. So I don't think there
is much FPC can do - unless I'm still not understanding the whole compiling
and linking process, unless FPC implements their own linker under Unix-type
OSes too.


You can use -l:libgreat.so.1 with gcc to link to a specific library version
(iirc).

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

Re: [fpc-pascal] Size of program vs library ?

[Henry Vermaak]

On Tue, May 16, 2017 at 01:15:34AM -0700, fredvs wrote:
> It works for all situations, so I propose that fpc add --gc-sections
> as parameter for the linker if the user has used -XX parameter to
> compile a library.

Does it work for all situations?  I remember a bug for the rust compiler
that broke libraries when --gc-sections was used, because it removed the
metadata that rust needed to load the library.  One of the fpc devs can
probably say whether fpc may have a similar problem.

I know with gcc you will need -ffunction-sections and -fdata-sections if
you want --gc-sections to do anything, and there are warnings attached
to those (see the gcc man page).

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

Re: [fpc-pascal] GUI multithreaded Win32 program sometimes freeze when quitting

[Henry Vermaak]

On Tue, Apr 18, 2017 at 07:32:21PM +0800, Dennis wrote:
> Since this freezing behavour does not happen during debugging, I have spent
> months trying to fix it but failed.
> 
> Any suggestions are welcome.

Try using a data race detector to see if it's a deadlock.  I don't know
about Windows, but I've used the helgrind tool in valgrind to
successfully fix thread errors in a lazarus program.  If you're lucky,
the problem will manifest itself on a platform that valgrind is
available on.

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

Re: [fpc-pascal] Call function in shared library from multiple threads

[Henry Vermaak]

On Fri, Mar 31, 2017 at 08:42:24AM -0700, fredvs wrote:
> > Z:\home\fred\uos\examples\uos.pas(7438,29) Warning: (4046) Constructing a
> > class "TThread" with abstract method "Execute"
> 
> Huh, is it Is it serious doctor?

I use this:

function DummyThread(param: pointer): ptrint;
begin
  Result := 0;
  EndThread(Result);
end;

begin
  BeginThread(@DummyThread);
  ...
  ...
end.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Henry Vermaak]

On Wed, Mar 22, 2017 at 01:50:45PM +0100, Karoly Balogh (Charlie/SGR) wrote:
> The usual way to work this problem around on Linux systems at least, is to
> write a new file, then do an overwriting rename to the old file name.
> There rename is an "atomic" operation, which will be either committed to
> the disk or not, but if it was unsuccessful, you won't end up with
> half-written files. But IIRC Windows didn't support atomic renames. Maybe
> someone with more Windows knowledge will fix me. You definitely don't want
> to implement a copy though, and that's anything but atomic.

I remember discussions about atomic rename for go and python (you can
still find the bug reports online).  The consensus seems to be that
MoveFileEx with MOVEFILE_REPLACE_EXISTING and MOVEFILE_WRITE_THROUGH
flags will be atomic if the file is on the same volume, and if that
volume supports changing the metadata in one transaction (which most do,
afaik).

MSDN recommends ReplaceFile() instead of TxF:

https://msdn.microsoft.com/en-us/library/windows/desktop/hh802690(v=vs.85).aspx

But I _think_ this is just a convenience function that uses
MoveFileEx().

So you can basically follow the same strategy as on POSIX, but with
MoveFileEx().

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Henry Vermaak]

On Tue, Mar 21, 2017 at 06:01:17PM -0700, Ralf Quint wrote:
> On 3/21/2017 11:58 AM, James Richters wrote:
> >I have not tried FlushFileBuffers() yet, so I just tried it now,  I am 
> >getting the same results.
> Well, that is expected, as the issue has nothing to do with your program,
> it's the caching of the operating system that is responsible for the actual
> physical write to the disk.

No, FlushFileBuffers() flushes the OS cache - see the MSDN page.  The
problem here seems to be that the SSD has its own cache (in the FTL).

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Henry Vermaak]

On 21 Mar 2017 18:59, "James Richters" 
wrote:

I have not tried FlushFileBuffers() yet, so I just tried it now,  I am
getting the same results.   I have also tried disabling write caching in
disk management and STILL have the same results.   I am now thinking this
is some caching being done on the SSD that is ignoring FlushFileBuffers()
Probably a 'feature' designed to help extend the life of the SSD, but
making it useless to store data that needs to survive a power failure.


Can you turn off the drive write cache in device manager? You'll have to
double click on the ssd and look around in there.

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

Re: [fpc-pascal] FreePascal Windows - Force files to write to disk

[Henry Vermaak]

On Tue, Mar 21, 2017 at 10:39:23AM -0400, James Richters wrote:
> I am still having this issue.  I've managed to narrow down what is happening
> some.   The problem is my data is not actually being written all the way to
> disk.   I now have a repeatable proven method to reproduce the issue.  Here
> is the sequence.
> 
> In my freepascal console application, I create the file
> Assign file
> Rewrite file
> Writeln file 
> Writeln file
> Writeln file ...
> Flush file

Have you tried using the FlushFileBuffers() Windows API?  Something like
this:

FlushFileBuffers(TextRec(AFile).Handle);

Add "windows" to the uses clause, obviously.

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

Re: [fpc-pascal] Missing messages

[Henry Vermaak]

On Mon, Oct 31, 2016 at 09:12:12PM +0100, Florian Klämpfl wrote:
> Am 30.10.2016 um 19:11 schrieb Graeme Geldenhuys:
> > On 2016-10-30 17:24, Sven Barth wrote:
> >> Same here...
> > 
> > First Lazarus, now FPC. Can we not switch fpc-pascal to a NNTP newsgroup
> 
> I used NNTP years ago the last time. How does marking read messages work when 
> reading a group with
> multiple devices (mobile, tablet, notebook, pc)?

This is why I don't use NNTP.  I use multiple devices and on most of
them my mail client fires up my favourite editor.  Using a crappy
browser interface doesn't cut it.

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

Re: [fpc-pascal] what is the correct way to write {$IFDEF FPC Version > 3.0}

[Henry Vermaak]

On Fri, Jul 08, 2016 at 06:47:19PM +0800, Dennis wrote:
> what is the correct way to write {$IFDEF FPC Version > 3.0}

{$if FPC_FULLVERSION > 3}

See: http://www.freepascal.org/docs-html/current/prog/progap7.html

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

Re: [fpc-pascal] What is the difference between TThread.Queue(aMethod: TThreadMethod) and Application.QueueAsyncCall(AMethod: TDataEvent; Data: PtrInt);

[Henry Vermaak]

On Fri, Jul 01, 2016 at 05:47:58PM +0200, Michael Van Canneyt wrote:
> On Fri, 1 Jul 2016, Dennis wrote:
> >Apart from the TThreadMethod and TDataEvent, what are the major
> >differences?  Are both of them thread safe to call from non-main
> >thread?  Will both of them overwrite some queue or buffer if the
> >queues are full?
> >
> >I tried to study the source code but I cannot find the implementation
> >parts.  I only find the interface parts of TThread classesh.inc
> 
> To the best of my knowledge:
> 
> Application.QueueAsyncCall has nothing to do with threads. This is an
> LCL method which can be used to insert a callback in the message loop.
> I think it unlikely that this is thread-safe, I suspect it is only for
> the main thread.

It should be thread safe (see lazarus r31143).  Works OK for me when
called from threads.

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

Re: [fpc-pascal] Bug in FPC 3.0.0 (was: Bug in FPC 3.0.0?)

[Henry Vermaak]

On Tue, Feb 23, 2016 at 02:13:52PM +0100, Jonas Maebe wrote:
> It would probably be useful if we added support to the compiler to
> generate a warning (or even error) in case a with statement hides an
> existing symbol in scope though.

Yes, please.  Something like -Wshadow would be very useful.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Henry Vermaak]

On Tue, Feb 02, 2016 at 01:12:25PM +0100, Michael Van Canneyt wrote:
> On Tue, 2 Feb 2016, Henry Vermaak wrote:
> >So you are saying that relying on all function arguments being
> >evaluated is bad?
> 
> I am saying that the difference between this behaviour and the
> behaviour where they may not all be evaluated is so subtle that many
> (I am tempted to say most) programmers will never even know the
> difference.

I'm sure most programmers will know that in foo(doa(), dob()) both doa()
and dob() will be executed.  I agree with what you said about the order
of evaluation (it's undefined behaviour), but you said that your points
still stand for whether arguments are evaluated at all.  This doesn't
make any sense, how would the compiler decide what to evaluate and what
not?

> It is simply over their heads.
> 
> Even Graeme - who has a lot of mileage in programming - was confused
> as to "why all the fuss" till I explained with a simple example.

I think there may be a misunderstanding.  I'm very confident Graeme
knows that all the arguments to a function gets evaluated and that a
branch of an if statement won't be evaluated.  Maybe he was confused by
wrapping up the behaviour of an if statement into something that looks
like a function?

> I'm just trying to to put any foaming-at-the-mouth argumentation using
> this particular argument in perspective.

I've tried to express my concerns about this in a civil way, but I
apologise if anything I've said came across otherwise.

> For a correct understanding: The compiler must behave predictable at
> all times, no arguing there. But I don't think that iif() having
> different semantics than all other functions, is a problem. It just
> needs to be documented properly. It is a non-issue for me.
> 
> To give more perspective: The same is true for Writeln() and Assert(),
> which also have are different semantics, but this difference is simply
> documented (if at all).  I didn't hear anyone protesting that. The
> fact that it is so in the pascal standard doesn't make a iota of
> difference; the standard was most likely simply made after the facts.

Exceptions to standard behaviour is bad, just because there are
exceptions doesn't mean that we need to create more of them.
Documenting something doesn't make the behaviour intuitive.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Henry Vermaak]

On Tue, Feb 02, 2016 at 10:49:03AM +0100, Michael Van Canneyt wrote:
> So the iif in either functional or expression form has my vote.

I'm surprised that you support iif in function call form.  Making
something that looks like a function call but may not behave as a
function call (short cut eval) seems like a recipe for disaster.  Say
what you will about the C ternary operator, but at least it didn't
introduce ambiguity.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Henry Vermaak]

On Tue, Feb 02, 2016 at 11:24:57AM +0100, Michael Van Canneyt wrote:
> On Tue, 2 Feb 2016, Henry Vermaak wrote:
> 
> >On Tue, Feb 02, 2016 at 10:49:03AM +0100, Michael Van Canneyt wrote:
> >>So the iif in either functional or expression form has my vote.
> >
> >I'm surprised that you support iif in function call form.  Making
> >something that looks like a function call but may not behave as a
> >function call (short cut eval) seems like a recipe for disaster.
> 
> Would you mind explaining why ?

When you call a function all the arguments get evaluated before the
function gets called.  iif will look exactly like a function call, but
all the arguments may not be evaluated (that's the point, right).  This
is inconsistent and ambiguous, two things that pascal tries to eschew.

Even worse is that it's not a reserved symbol, so it can still be
overridden.  A call to iif in one unit may evaluate all its arguments,
while it may not in another unit.

Pascal is not a language full of programmer traps, let's try not to add
any!

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Henry Vermaak]

On Tue, Feb 02, 2016 at 12:03:14PM +0100, Michael Van Canneyt wrote:
> On Tue, 2 Feb 2016, Henry Vermaak wrote:
> >When you call a function all the arguments get evaluated before the
> >function gets called.  iif will look exactly like a function call,
> >but all the arguments may not be evaluated (that's the point, right).
> >This is inconsistent and ambiguous, two things that pascal tries to
> >eschew.
> >
> >Even worse is that it's not a reserved symbol, so it can still be
> >overridden.  A call to iif in one unit may evaluate all its
> >arguments, while it may not in another unit.
> >
> >Pascal is not a language full of programmer traps, let's try not to
> >add any!
> 
> Well, see my reply about 'robust' code for an observation about these
> details.

There you talk about order of evaluation, which is irrelevant to what
I'm trying to say.  Maybe I'll try an example to explain what I'm on
about.

Say you have code like this:

IfThen(IsSomething, MungeA(A), MungeB(B));

Currently MungeA(A) and MungeB(B) are called, irrespective of the value
of IsSomething.  The order is irrelevant (I always assumes that it was
undefined, like in C) and I agree that it's wrong to rely on.

If you replace it with the new IfThen (or iif), only MungeA(A) _or_
MungeB(B) will be called.  This is exactly what you want from a
conditional operator.

The conditional operator shouldn't look like a function call, because it
doesn't act like a function call: it will not evaluate all its
arguments.  Again:  nothing to do with order, it's whether they actually
get evaluated in the first place.

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

Re: [fpc-pascal] New feature: IfThen() intrinsic

[Henry Vermaak]

On Tue, Feb 02, 2016 at 12:34:17PM +0100, Michael Van Canneyt wrote:
> On Tue, 2 Feb 2016, Jonas Maebe wrote:
> >Michael Van Canneyt wrote on Tue, 02 Feb 2016:
> >>On Tue, 2 Feb 2016, Henry Vermaak wrote:
> >>>On Tue, Feb 02, 2016 at 11:24:57AM +0100, Michael Van Canneyt
> >>>wrote:
> >>>>On Tue, 2 Feb 2016, Henry Vermaak wrote:
> >>>Pascal is not a language full of programmer traps, let's try not to
> >>>add any!
> >>
> >>Well, see my reply about 'robust' code for an observation about
> >>these details.
> >
> >You only talked about the order of evaluation in that mail, while
> >Henry is talking about whether the arguments are evaluated at all.
> 
> I am aware of that (I knew I should have mentioned it explicitly, this
> is a programmers list!), but the exact same observation applies.

So you are saying that relying on all function arguments being evaluated
is bad?

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

Re: [fpc-pascal] changes in TThread.OnTerminate in fcp-3.0?

[Henry Vermaak]

On Thu, Dec 10, 2015 at 10:26:29AM +0100, Luca Olivetti wrote:
> Hello,
> 
> in a couple of programs I'm using this idiom:
> 
> 
> FMyThread:=TMyTread.Create;
> FMyThread.FreeOnTerminate:=false;
> FMyThread.OnTerminate:=@MyThreadTerminate
> 
> procedure TMyForm.MyThreadTerminate(Sender:TObject);
> begin
>   //do something with FMyThread then
>   FreeAndNil(FMyThread);
> end;

This is why FreeOnTerminate exists.  Set that to True and set FMyThread
to nil here, and the thread will free itself after this function
returns.

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

Re: [fpc-pascal] changes in TThread.OnTerminate in fcp-3.0?

[Henry Vermaak]

On Thu, Dec 10, 2015 at 05:23:41PM +0100, Sven Barth wrote:
> Am 10.12.2015 15:06 schrieb "Henry Vermaak" <henry.verm...@gmail.com>:
> > Is it worthwhile mentioning that OnTerminate gets called with
> > Synchronize()?  I had to dig into the source to verify this.
> 
> That would indeed be worth mentioning, but that would belong in the
> documentation then. Would you file a bug report, please?

Sure: http://bugs.freepascal.org/view.php?id=29166

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

Re: [fpc-pascal] changes in TThread.OnTerminate in fcp-3.0?

[Henry Vermaak]

On Thu, Dec 10, 2015 at 02:49:50PM +0100, Sven Barth wrote:
> Am 10.12.2015 12:15 schrieb "Luca Olivetti" :
> > It's obvious that you cannot free the thread from inside a "normal"
> Synchronize call, it's no so obvious you cannot do it in the
> OnTerminate method, so maybe a note could be added in
> >
> > http://wiki.freepascal.org/User_Changes_3.0
> >
> > The new implementation is clearly betteronce you know *not* to
> > free
> the thread inside OnTerminate.
> 
> In all honesty it was never documented either that you *can* free the
> object from within OnTerminate and in other occurrences you wouldn't
> free the object that invoked the handler either, right? So why for
> TThread then?  => no need to mention as a change

Is it worthwhile mentioning that OnTerminate gets called with
Synchronize()?  I had to dig into the source to verify this.

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

Re: [fpc-pascal] using eventfd

[Henry Vermaak]

On Wed, Oct 21, 2015 at 06:43:41PM +0200, Andreas Klausmann wrote:
> Hi,
> 
> which unit(s) do I have to include to use eventfd() under Linux?

I don't think anyone has added it to the linux unit, unfortunately.
You'll have to call it directly with Do_SysCall() in unit syscall.

> Is this function used internally by TEvent? Or where does TEvent end up on
> Linux level to create the event handle?

TEvent uses a mutex and a condition variable from pthreads on unix.

> I'm looking for a way to wait for >=2 events without polling. A thread
> should yield until one of them has been set.

eventfd() is nice and lightweight, but if you don't have an incredibly
low latency requirement, you can use pipes to accomplish the same thing,
with the benefit that you'll be portable to other Unix OS'es.

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

Re: [fpc-pascal] Access GPIO pins on RPi2 without root?

[Henry Vermaak]

On Wed, Oct 07, 2015 at 01:09:58PM +0200, Bo Berglund wrote:
> On Wed, 07 Oct 2015 10:05:03 +0200, Jonas Maebe
>  wrote:
> >Bo Berglund wrote on Wed, 07 Oct 2015:
> >
> >> How can one control the GPIO outputs on a Raspberry Pi2 without
> >> needing the program to run as root? I am using Raspbian Wheezy and I
> >> need to add two relays controls to my program.
> >
> >This really has nothing to do with either FPC or Pascal programming in  
> >general. Please ask such questions on the fpc-other list in the future.
> >
> I think that it really does because there must be some interface
> between the FPC system and the underlying operating system managing
> the hardware.

You access the GPIOs via the kernel's sysfs interface.  The files are
all under /sys/class/gpio.  I'd be pretty amazed if your distro doesn't
already have a udev rule to set a certain group for those files.  You
probably just have to add your user to that group.

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

Re: [fpc-pascal] How to use serial or usb-ports in linux

[Henry Vermaak]

On Sun, Sep 06, 2015 at 12:16:31PM +0200, P. vanderWal wrote:
> Hello all,
> 
> I wrote a program to control a hobby milling machine.(Profiler, see
> Elektor-forum). The programm is written in fpc-pascal and using
> synaser in the windows version for control of the serial port(s).  Now
> I want to use the program in Debian 8... and or Ubuntu 15... Compiling
> and running the present version gives "no permission" for the
> serial/usb ports.  Please advise how to get the program running with
> these ports. (lazarus 1.2.4 fpc 2.6.4).

For Debian you usually have to be part of the "dialout" group to have
access to the serial ports.

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

Re: [fpc-pascal] Issue with Linking

[Henry Vermaak]

On Thu, Aug 20, 2015 at 07:03:11AM -0700, Chris Moody wrote:
 Assembling dentist
 Linking Dentist
 /usr/bin/ld: warning: link.res contains output sections; did you forget -T?
 /home/pi/fpc-2.6.4/lib/fpc/2.6.4/units/arm-linux/rtl/cprt0.o: In
 function `_haltproc_eabi':
 (.text+0x88): undefined reference to `_fini'
 /home/pi/fpc-2.6.4/lib/fpc/2.6.4/units/arm-linux/rtl/cprt0.o: In
 function `_haltproc_eabi':
 (.text+0x90): undefined reference to `_init'
 Dentist.pas(106) Error: Error while linking
 Dentist.pas(106) Fatal: There were 1 errors compiling module, stopping
 Fatal: Compilation aborted
 Error: /usr/bin/ppcarm returned an error exitcode
 
 That is the result of: fpc Dentist.pas -Fusource/lib
 -Fu/usr/lib/fpc/2.6.4/units/arm-linux

Those symbols (_fini and _init) are defined in crti.o.  Try `locate
crti.o`, you'll get something like /usr/lib/{arch-triplet}/crti.o.  Add
this directory to your fpc options with -Fl.  E.g. fpc
-Fl/usr/lib/arm-linux-gnueabi

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

Re: [fpc-pascal] Issue with Linking

[Henry Vermaak]

On Thu, Aug 20, 2015 at 04:19:33PM +0200, Jonas Maebe wrote:
 On 20/08/15 16:15, Henry Vermaak wrote:
  Those symbols (_fini and _init) are defined in crti.o.  Try `locate
  crti.o`, you'll get something like /usr/lib/{arch-triplet}/crti.o.  Add
  this directory to your fpc options with -Fl.  E.g. fpc
  -Fl/usr/lib/arm-linux-gnueabi
 
 Please do not do that. The compiler looks for that file in the correct
 location.

I'm glad that's fixed then.  I've had to do this on all my (Debian
based) embedded systems, since the compiler never looked in the right
place.

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

Re: [fpc-pascal] IsATTY

[Henry Vermaak]

On Fri, Apr 17, 2015 at 09:55:26AM -0400, David Copeland wrote:
 This function is a part the unit oldlinux. Is there a replacement for it
 somewhere? I have looked in the Linux, Unix, etc units but didn't see it.

It's in termio.

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

Re: [fpc-pascal] fpGetTimeOfDay

[Henry Vermaak]

On Mon, Mar 09, 2015 at 01:30:28PM +0100, Marco van de Voort wrote:
 In our previous episode, Mark Morgan Lloyd said:
  Are there any known issues with this sort of thing  fpGetTimeOfDay 
  (@TimeVal, nil)  on various platforms? FPC 2.6.4 and 2.7.1 seem to be OK 
  on x86, but on x64 (and FWIW SPARC, haven't tested others) it appears to 
  be returning a fixed TimeVal plus a result of zero even if there are 
  several seconds between calls.
 
 My FreeBSD manpage says:
 
 ... If tp or tzp is NULL, the associated time
  information will not be returned or set.
 
 The Linux manpage words it differently:
 
   If either tv or tz is NULL, the corresponding structure is not  set  or
returned.  (However, compilation warnings will result if tv is NULL.)

Well that's obvious, you can't dereference a NULL so there's nothing to
set.  The tz parameter is obsolete, it should normally be NULL.

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

Re: [fpc-pascal] Use sleep in thread

[Henry Vermaak]

On Thu, Feb 26, 2015 at 09:23:33PM +0800, Xiangrong Fang wrote:
 ​I use rtlevent, but only meant to maintain a pool of threads, while there
 is no task for a thread it is blocked waiting for an event.
 
 BUT, that cannot be used to prioritize a thread. While you block a thread
 using rtlevent, it can only be unblocked from another thread. While you use
 sleep(), it still get time share of the CPU, only that it does nothing
 until sleep finishes, right?  That way, it only consume a tiny amount of
 computing power while sleeping. This, in my view, is the price I have to
 pay to achieve my purpose?

How can a thread decide how it should be scheduled, without any
knowledge about the number of other threads and the load of the system?

I still think that doing the scheduling yourself, you'll be fighting
against the operating system.  If you have threads that are more urgent
than others, use the operating system specific method to help the
scheduler decide how much CPU time to give a thread.

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

Re: [fpc-pascal] Use sleep in thread

[Henry Vermaak]

On Thu, Feb 26, 2015 at 11:20:41AM +0100, Michael Schnell wrote:
 On 02/26/2015 11:14 AM, Michael Schnell wrote:
 I don't know what this does.
 With stepping in ASM I verified that (after some calculation) it
 does just a single syscall (via a sysenter Assembler instruction).
 
 so the overhead is minimal.

Blocking with an even will sleep until someone wakes you up, it's very
efficient.  Using sleep() you will have to wake up, check if someone
needs you, go to sleep again, etc.  This is obviously more inefficient.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Use sleep in thread

[Henry Vermaak]

On Thu, Feb 26, 2015 at 11:40:44AM +0100, Michael Schnell wrote:
 On 02/26/2015 11:33 AM, Henry Vermaak wrote:
 Blocking with an even will sleep until someone wakes you up, it's
 very efficient. Using sleep() you will have to wake up, check if
 someone needs you, go to sleep again, etc. This is obviously more
 inefficient.
 
 We were talking about the overhead of a sleep for n milliseconds
 functionality itself, and not about waiting for some event.
 
 Abusing it for polling of course is not what sleep is meant for.
 
 Sleep is for granting the CPU for other processes for (at least) a
 predefined time.
 
 See the mail of the original poster: this is what he asked for.

The message you replied to was regarding pausing a thread, let me quote
you back to yourself:

===

On 02/25/2015 09:17 PM, fredvs wrote: 
 Hello.

 You may use RTLEvents to pause a thread. =

Obviously CPU the overhead is a lot greater than with just calling sleep.

-Michael

===

This is incorrect, since if you pause a thread with sleep(), you'll have
to loop to check when you're supposed to wake up.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Use sleep in thread

[Henry Vermaak]

On Wed, Feb 25, 2015 at 06:17:17PM +0300, hinsta...@yandex.ru wrote:
 I mean T.Suspend, so u resume it then suspend it 

TThread.Suspend and TThread.Resume are deprecated (since 2.4.4), don't
use them.

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

Re: [fpc-pascal] Use sleep in thread

[Henry Vermaak]

On Wed, Feb 25, 2015 at 10:41:58PM +0800, Xiangrong Fang wrote:
 Hi All,
 
 Can I use Sleep() in a thread to give up cpu time to other threads running
 at the same time, so as to adjust the relative niceness of a group of
 workers working on the same subject (in which each thread take part of the
 whole task).

Use ThreadSwitch to yield CPU.  Having said that, it may be better to
look into platform specific thread scheduling rather than trying to do
it yourself.  For instance, with pthreads, you can do this:

procedure TYourThread.SetPriority;
{$ifdef unix}
var
sp: sched_param;
begin
sp.sched_priority := 10;
{ SCHED_FIFO = 1 }
pthread_setschedparam(ThreadID, 1, @sp);
end;
{$else}
begin
// TODO
end;
{$endif}

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

Re: [fpc-pascal] linux ACL

[Henry Vermaak]

On Fri, Jan 23, 2015 at 11:33:51AM +, Mark Morgan Lloyd wrote:
 Henry Vermaak wrote:
 On Fri, Jan 23, 2015 at 11:37:05AM +0100, Koenraad Lelong wrote:
 Hi,
 
 I need to set ACL's on files on Linux. Is there something ready-made
 in fpc ? Or should I use a TProcess and execute a setfacl that way ?
 
 Easiest would be to create a binding for libacl.  ACL is specified by
 POSIX, so there's nothing stopping fpc from implementing it natively,
 though.
 
 Would this require root access?

Only if you don't own the file, I guess.  I can use setfacl on files I
own.

 As an aside, I've used capabilities to allow a program to listen to a
 low-numbered TCP port and found that setting it uid root was
 incompatible with GTK (Qt was fine).

I'm using capabilities to allow an fpc daemon running as non-root to set
the time and it's working OK.

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

Re: [fpc-pascal] linux ACL

[Henry Vermaak]

On Fri, Jan 23, 2015 at 11:37:05AM +0100, Koenraad Lelong wrote:
 Hi,
 
 I need to set ACL's on files on Linux. Is there something ready-made
 in fpc ? Or should I use a TProcess and execute a setfacl that way ?

Easiest would be to create a binding for libacl.  ACL is specified by
POSIX, so there's nothing stopping fpc from implementing it natively,
though.

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

Re: [fpc-pascal] TImage : how to avoid flickering when changing image

[Henry Vermaak]

On Tue, Aug 05, 2014 at 07:06:43PM +0800, Dennis Poon wrote:
 every few seconds, I want the same TImage  to load a different jpg
 file but now it flickers whenever
 TheImage.Picture.LoadFromFile('new.jpg');
 
 How do I avoid the flickering?

I assume you're on Windows.  Have you tried to set DoubleBuffered to
True?  I didn't use TImage, but I remember having to put the PaintBox
onto a panel and set panel.DoubleBuffered to True to stop the
flickering.

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

Re: [fpc-pascal] TImage : how to avoid flickering when changing image

[Henry Vermaak]

On Tue, Aug 05, 2014 at 12:19:22PM +0100, Henry Vermaak wrote:
 On Tue, Aug 05, 2014 at 07:06:43PM +0800, Dennis Poon wrote:
  every few seconds, I want the same TImage  to load a different jpg
  file but now it flickers whenever
  TheImage.Picture.LoadFromFile('new.jpg');
  
  How do I avoid the flickering?
 
 I assume you're on Windows.  Have you tried to set DoubleBuffered to
 True?  I didn't use TImage, but I remember having to put the PaintBox
 onto a panel and set panel.DoubleBuffered to True to stop the
 flickering.

P.S.  This is the wrong list for Lazarus questions.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] cthreads

[Henry Vermaak]

On Sun, Jul 27, 2014 at 02:39:58PM +0200, Sven Barth wrote:
 On 27.07.2014 11:39, Mark Morgan Lloyd wrote:
 Sven Barth wrote:
 On 26.07.2014 19:50, leledumbo wrote:
 Because then all apps are linked to it, also the ones that don't need
 threads. Same for clocale and cwstrings.
 
 If the widestring manager could be made by ourselves, is it possible for
 thread manager as well?
 
 Principiall yes, but the problem here would be external code that the
 program links to. E.g. Wine did something like this some time ago
 (before they switched to pthreads) and needed to simulate some
 structures so that libc switches to multithreaded mode... So if we
 have Pascal only code (like the compiler) this would work without big
 problems (if someone implements it of course ;) ), but if you have 3rd
 party code not written in FPC then problems might arise...
 
 On the other hand, if somebody's linking in alien code then he should
 make himself aware of aware of the prerequisites, particularly since the
 threads are more likely to be in the main program (i.e. stuff that he's
 written) than in the library he's pulling in.
 
 That's not true. E.g. the Qt libraries happily create threads for various
 background stuffs.

Ha, I had a library that started a thread and it took me ages to figure
out why my pascal program was crashing on callbacks from external
threads.  I had to start a dummy thread right at the start of the
program, even though I included cthreads.  Not a good experience all in
all.

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

Re: [fpc-pascal] EpikTimer v1.0.1 released

[Henry Vermaak]

On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
  In fact I do want the best possible stuff and not a fork. I am just 
  trying to help (as I would like to use it in the said current project). 
 
 In that case some attention points:
 - help implementing and testing fine grained timings on *nix. Now it only has 
 a special
   case for linux.
 - Seems high precision is not used on anything but x86.
 - Is rdtsc safe for CPUs that can vary clock of cores independently like
   Core Mono? What if the process changed  CPU to a different clocked core?

- The rdtsc instruction needs to be protected from out of order
  execution.  Some people use cpuid, which is expensive.  It looks like
  the linux kernel uses mfence or lfence/mfence depending on CPU type.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] EpikTimer v1.0.1 released

[Henry Vermaak]

On Wed, May 28, 2014 at 02:00:06PM +0200, Marco van de Voort wrote:
 - Is rdtsc safe for CPUs that can vary clock of cores independently like
   Core Mono? What if the process changed  CPU to a different clocked core?

I've read that on recent CPUs, the TSC is unaffected by the actual clock
rate of the CPU.  On linux, The TSC gets calibrated and the
synchronisation is tested, which may result in the TSC clock source
being marked as unstable and disabled.  In this case, it will fall back
to using other clock sources (HPET is next in line on my computer).

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

Re: [fpc-pascal] EpikTimer v1.0.1 released

[Henry Vermaak]

On Wed, May 28, 2014 at 05:41:08PM +0200, Marco van de Voort wrote:
 In our previous episode, Henry Vermaak said:
  On linux, The TSC gets calibrated and the synchronisation is tested, which
  may result in the TSC clock source being marked as unstable and disabled. 
  In this case, it will fall back to using other clock sources (HPET is next
  in line on my computer).
 
 I assume the same system underlies queryperformancecounter and family on
 Windows. But that means you need to use OS timing functions, and not ASM.

I assumed that, too.  All the clocksource calibration and selection
happens at startup, so by the time you call
clock_gettime()/QueryPerformanceCounter() it knows whether to query the
TSC/HPET/whatever.

Blindly making assumptions about TSC stability can get you into trouble.
Microsoft advises against this, too:

http://msdn.microsoft.com/en-gb/library/windows/desktop/ee417693%28v=vs.85%29.aspx

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

Re: [fpc-pascal] EpikTimer v1.0.1 released

[Henry Vermaak]

On Wed, May 28, 2014 at 04:31:53PM +0200, Michael Schnell wrote:
 On 05/28/2014 04:26 PM, Henry Vermaak wrote:
 
 - The rdtsc instruction needs to be protected from out of order
execution.  Some people use cpuid, which is expensive.  It looks like
the linux kernel uses mfence or lfence/mfence depending on CPU type.
 
 
 ... meaning the current version of incorrect ?!?!?

Indeed.  What's worse is that it _always_ uses the TSC on x86, without
knowing whether it's actually a reliable clock source for the particular
hardware configuration.

I can only recommend to never use this component, just use an ifdef to
call QueryPerformanceCounter/()clock_gettime() based on OS.

 Things like this is why I'd rather use dVSO.

Calling the vDSO will certainly make things faster.  I don't know what
the overhead of QueryPerformanceCounter() is.

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

Re: [fpc-pascal] Watching for file change

[Henry Vermaak]

On Sat, Apr 12, 2014 at 12:32:14AM +0100, Graeme Geldenhuys wrote:
 On 2014-04-11 20:06, Krzysztof wrote:
  idea how to do this in thread loop but maybe FPC has OS solution
 
 As the others have said, the OS solutions are very version/distro
 dependent - especially under Linux which changes underlying
 functionality every 6 months or so (so damn annoying).

No, the linux solution isn't distro dependent, since it's in the kernel.
inotify came in 2005-ish to deprecate dnotify, but even dnotify still
exists (read the man page for fcntl).  The kernel guys are pretty
serious about not breaking userspace interfaces.

If you're using some other userspace daemon to do this (like FAM), then
you're at their mercy.

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

Re: [fpc-pascal] Watching for file change

[Henry Vermaak]

On Sat, Apr 12, 2014 at 08:08:20PM +, Mark Morgan Lloyd wrote:
 Henry Vermaak wrote:
 On Sat, Apr 12, 2014 at 12:32:14AM +0100, Graeme Geldenhuys wrote:
 On 2014-04-11 20:06, Krzysztof wrote:
 idea how to do this in thread loop but maybe FPC has OS solution
 As the others have said, the OS solutions are very version/distro
 dependent - especially under Linux which changes underlying
 functionality every 6 months or so (so damn annoying).
 
 No, the linux solution isn't distro dependent, since it's in the kernel.
 inotify came in 2005-ish to deprecate dnotify, but even dnotify still
 exists (read the man page for fcntl).  The kernel guys are pretty
 serious about not breaking userspace interfaces.
 
 I've just been running a kernel build and note that there are explicit
 dnotify and inotify options, so what's built in is very much at the
 discretion of the distro maintainers.

Almost everything in the kernel is configurable at build time,
obviously.  I've never come across a kernel without inotify/dnotify,
even for old embedded ARM CPUs I've worked with (I guess no-one wants to
waste power scanning directories and fstat-ing all the time).  Distros
usually build pretty full featured kernels, so I'd be surprised to see a
distro without it.
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Watching for file change

[Henry Vermaak]

On 11 Apr 2014 20:07, Krzysztof dib...@wp.pl wrote:

 Hi,

 Does FPC have some file watching solution? I need this only for linux.
 I need notifications:
 - File/folder changed / removed / added in watched directory. I have
 idea how to do this in thread loop but maybe FPC has OS solution

You can use the inotify* functions in linux unit. See the man pages or
Wikipedia for how they work.

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

Re: [fpc-pascal] Watching for file change

[Henry Vermaak]

On 11 Apr 2014 21:39, Mark Morgan Lloyd 
markmll.fpc-pas...@telemetry.co.uk wrote:

 waldo kitty wrote:

 On 4/11/2014 3:06 PM, Krzysztof wrote:

 Hi,

 Does FPC have some file watching solution? I need this only for linux.
 I need notifications:
 - File/folder changed / removed / added in watched directory. I have
 idea how to do this in thread loop but maybe FPC has OS solution


 i'm interested in this, as well... i have an app in perl that i'm
considering rewriting in FPC... in that app, i had to specifically grab the
attributes of the files the app watches and compare those values to
previously stored values...


 I believe Linux has dnotify, inotify and possibly File Alteration
Monitor, but that these are  version-dependant and extremely dependant on
distro policies. Because of this uncertainty it would be necessary to load
the support libraries dynamically.

inotify replaced dnotify many years ago (both are in kernel, so no
libraries needed). I don't know what FAM is useful for.

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

Re: [fpc-pascal] How to remove verbose compiler output

[Henry Vermaak]

On Fri, Apr 04, 2014 at 04:03:10AM +0100, Graeme Geldenhuys wrote:
 Hi,
 
 I'm trying to reduce the compiler output for cron jobs.
 
 I have tried to specify -v0  or even  -v- -v0   but still the compiler
 outputs loads of 'Hint' and 'Warning' message about unused parameters,
 unused units, deprecated methods etc.
 
 I made sure no -v is specified in my ~.fpc.cfg as well, but still the
 compiler seems to ignore my -v0 preference on the command line.

I use -vi-n-h- for my release builds, which removes info, notes and
hints, otherwise it becomes hard to see the wood from the trees!

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

Re: [fpc-pascal] cannot read /sys/class/net/eth1/address even as root user on linux

[Henry Vermaak]

On Thu, Dec 05, 2013 at 07:33:38PM +0800, Dennis Poon wrote:
 I tried to read the mac address in the captioned file path.
 In terminal, I can simply 'cat' and display the mac address.
 
 In FPC, when I tried to use TFileStream to read it,
 
   FS := TFileStream.Create('/sys/class/net/eth1/address',
 fmOpenRead+fmShareDenyWrite);
 
 it raised stream read error
 
 If I tried to use TextFile and readln, it even halted the program.
 
 My question is:
   Why 'cat' command can easily display this special file 'address'
 but TFileStream cannot.
 
 I was told to use this method to get the MAC address of a network
 card, what other methods are there?

While your method should work if that file actually exists, you probably
want to use libudev for enumerating and getting device information from
sysfs.  libudev will also enable you to get hotplug notification.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GUI confusion

[Henry Vermaak]

On Mon, Sep 30, 2013 at 11:25:34AM +0100, Graeme Geldenhuys wrote:
 On 29/09/13 23:33, Patrick wrote:
  BTW, Would it be correct to compare LCL to WxWidgets ? In the sense that 
  it is a meta-widget toolkit?
 
 Yes, that would be an accurate comparison. LCL and WxWidgets are a
 common front-end toolkit to other underlying GUI toolkits. This
 obviously has its pros and cons, because not all GUI toolkits have the
 same functionality. So you meta-widget toolkit, as you call it, often
 only uses functionality that all GUI toolkits have in common. Also if
 the underlying GUI toolkit has a bug, it is out of your control to fix
 it, so instead you need to find a way to work around it.
 
 A 100% custom drawn toolkit like fpGUI or MSEgui are probably more work
 to develop initially, but you gain much greater flexibility and
 consistency. All functionality works identical on all platforms, and you
 have full control over everything (like fixing a toolkit bug etc).

With the obvious drawback that it doesn't respond to theme/accessibility
changes.  If a user with impaired vision, for example, changes the GNOME
theme to high contrast with bigger default fonts, the custom drawn
toolkit doesn't know/respond, while an application that uses the GNOME
toolkit automatically adjusts itself.  The LCL, however, didn't respond
to font changes last time I checked.

This functionality can probably be built into the custom drawn toolkit.
Can fpgui pick up theme related changes from other widgetsets?

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] lnet for TCP daemon

[Henry Vermaak]

On Wed, Sep 18, 2013 at 01:26:46PM +0200, Marco van de Voort wrote:
 In our previous episode, Michael Schnell said:
   The fptimer unit implements a timer with a thread, but this forces the 
   use of threads on your application which is not always desirable.
  
  Should be doable, as well. AFAIK, mse (for Linux) uses signals on that 
  behalf. We might want to steal some ideas there.
 
 While there is sigalarm, but can you have multiple independent timers in an
 application that way?

I think Martin used setitimer and handles multiple timers by calculating
which one expires first, and subtracting that amount from the other
timers, etc.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] lnet for TCP daemon

[Henry Vermaak]

On Wed, Sep 18, 2013 at 03:57:36PM +0200, Marco van de Voort wrote:
 In our previous episode, Henry Vermaak said:
Should be doable, as well. AFAIK, mse (for Linux) uses signals
on that behalf. We might want to steal some ideas there.
   
   While there is sigalarm, but can you have multiple independent
   timers in an application that way?
  
  I think Martin used setitimer and handles multiple timers by
  calculating which one expires first, and subtracting that amount
  from the other timers, etc.
 
 That's a trick commonly done on embedded platforms with limited timers
 (I actually did it once as part of a course that created a small RTOS
 for 8051 chips), but on *nix systems where libraries might also
 reserve certain itimers, that could fail miserably.

Yes, the POSIX interval timers are a much better solution for this.
Dealing with signals are still a bit annoying, but things like timerfd
and signalfd are linux specific.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] DoDirSeparators and special filenames on Windows

[Henry Vermaak]

On Thu, Sep 12, 2013 at 12:01:30PM +0200, Reimar Grabowski wrote:
 On Thu, 12 Sep 2013 07:10:19 +0200 Jürgen Hestermann
 juergen.hesterm...@gmx.de wrote:
 
  Ahh, that's the reason: It's (another) sloppiness in Unix systems
  and has creeped into Windows from there.
 Unfortunately M$ hasn't implemented it correctly (like always) and
 enriched the experience with their common inconsistencies. Therefor
 you have the problems this thread is about only on windows systems and
 Unix-like systems don't have any problems at all.

Those who don't understand Unix are condemned to reinvent it, poorly.

SCNR :)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Any suggestion for raspberry pi ?

[Henry Vermaak]

On Fri, Aug 30, 2013 at 03:44:35PM +0200, Stefan Fischer wrote:
 Hi,
 a longer time ago, i've installed lazarus on my raspberry pi with
 wheezy. The fpc version was 2.6.0-xxx
 
 I could compile without any problem.
 
 Today I've downloaded fpc 2.6.2 and installed it.
 
 But now I have problems with the linker:
 
 Free Pascal Compiler version 2.6.2 [2013/02/15] for arm
 Copyright (c) 1993-2012 by Florian Klaempfl and others
 Target OS: Linux for ARMEL
 Compiling rfm.pas
 Assembling rfm
 Linking rfm
 /usr/bin/ld: warning: link.res contains output sections; did you forget
 -T?
 /usr/lib/fpc/2.6.2/units/arm-linux/rtl/cprt0.o: In function
 `_haltproc_eabi':
 (.text+0x88): undefined reference to `_fini'
 /usr/lib/fpc/2.6.2/units/arm-linux/rtl/cprt0.o: In function
 `_haltproc_eabi':
 (.text+0x90): undefined reference to `_init'

This sounds like it may be a multiarch thing biting you.  Those symbols
are in crti.o, and perhaps fpc isn't finding it.  I vaguely remember
getting a problem like this and fixing it by adding
-Fl/usr/lib/arch-triplet.  You can use `locate` to check where it is.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Library callback : how do I do that?

[Henry Vermaak]

On Fri, Aug 09, 2013 at 09:28:47AM +0200, Michael Schnell wrote:
 On 08/08/2013 02:41 PM, Lukasz Sokol wrote:
 Very well then, thanks :)
 
 I suggest that - to exclude problems that might be imposed by some
 external non-Lazarus and software not by yourself  - you do a test
 creating a combination of a Lazarus Application and a Lazarus-made
 dll (and/or so) that features a TThread in the dll and uses
 Application.QueuAsyncCall(Form1.DisplayCallFromDLL, NIL) to display
 some running counter or similar stuff.

You seem to think that Lukasz is making a library, but I can't see an
email where he says that.  He does say that he's making a wrapper for a
library, though.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Library callback : how do I do that?

[Henry Vermaak]

On Thu, Aug 08, 2013 at 12:15:44PM +0100, Lukasz Sokol wrote:
 but I would then need to make the wrapper object aware of the Application 
 or its forms then?
 
 I wanted the wrapper unit to be as self-contained as much as possible,
 (so the callback function is defined in a unit that only has Classes, 
 SysUtils and dynlibs as uses,
 i.e. no Forms. Controls or Graphics)
 but still be thread-safe w/r/t to where the wrapper object is created
 (within a GUI form or /not/)

Create an event in your wrapper class and make sure that it's documented
that this event will be called from a thread.  Then if you use this
wrapper class from a gui app, you can use Application.QueueAsyncCall or
PostMessage in the event handler.  If you use the wrapper from a command
line app, you'll have to use a thread-safe queue that you query from
time to time in the main thread of the app, or build it into your event
loop, if you have one.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] GetCurrentDir

[Henry Vermaak]

On Mon, Apr 22, 2013 at 09:57:06AM +0200, Michael Van Canneyt wrote:
 On Mon, 22 Apr 2013, Marco van de Voort wrote:
 In our previous episode, Mattias Gaertner said:
 The FPC code tries to work its way up from '.' in such a case.
 
 I just tried, but it gives a correct result in my case.
 
 Maybe as fallback it can use the environment variable PWD?
 
 No. That would only be valid right after startup, and doesn't change
 when you chdir in the program.
 
 +1

I think that readlink on /proc/self/cwd should work?

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Porting C macro

[Henry Vermaak]

On Mon, Mar 11, 2013 at 11:26:57PM +0100, Darius Blaszyk wrote:
  
 
 I'm stuck porting a macro from C. Below is the original define. The
 part I'm struggeling with is the right most part after the - sign.
 
 
 #define GETNEXT(x) ((LList *)(((char *) x) - ((char *)  (((LList
 *)0)^.next

I'm assuming that the ^. should be -, in which case the last bit is
doing the same as the offsetof() macro.  So the macro is subtracting the
offset in bytes of the next member of the LList struct from x, then
casting it to (LList *).

I'd wager that the GETNEXT() isn't actually doing what it says, but
something more like container_of() (because it's _subtracting_ the
offset).  I may be wrong, though, do you have an example of its usage?

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

[Henry Vermaak]

On Fri, Mar 01, 2013 at 09:23:29AM +, Mark Morgan Lloyd wrote:
 Sven Barth wrote:
 
 An llvm target will move the optimisation burden away from fpc, which
 would be very interesting.
 
 While we would welcome a LLVM backend it is basically a consent in
 the development team that this would only be an additional
 alternative to the normal backends FPC provides.
 
 LLVM's target list doesn't look particularly brilliant compared with
 FPC's :-/

How do you mean?  It supports more architectures than FPC, as far as I
can see (http://llvm.org/Features.html).  They also have a C backend
that you can use for targets that they don't support.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

[Henry Vermaak]

On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote:
 On 2013-02-28 09:28, Marc Pertron wrote:
  
  We need better optimisations at least as much as fancy 123.tostring.
 
 
 Bottom line optimisation work is just not as sexy and exciting as
 adding the latest Delphi/Java/C#/C language features. I guess we can't
 blame them for that.

An llvm target will move the optimisation burden away from fpc, which
would be very interesting.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Object pascal language compatiblity - was: Does FPC 2.8.0 can actually still be called Pascal ?

[Henry Vermaak]

On Thu, Feb 28, 2013 at 07:43:15AM -0600, Kenneth Cochran wrote:
 On Feb 28, 2013 5:23 AM, Henry Vermaak henry.verm...@gmail.com wrote:
 
  On Thu, Feb 28, 2013 at 10:45:08AM +, Graeme Geldenhuys wrote:
   On 2013-02-28 09:28, Marc Pertron wrote:
   
We need better optimisations at least as much as fancy 123.tostring.
  
  
   Bottom line optimisation work is just not as sexy and exciting as
   adding the latest Delphi/Java/C#/C language features. I guess we can't
   blame them for that.
 
  An llvm target will move the optimisation burden away from fpc, which
  would be very interesting.
 
  Henry
 
 Ironically this is the direction Embarcadero is moving. They've already
 made the transition with their C/C++ compiler and there have been hints
 that Delphi is next. In a way it makes sense. They get an instant boost in
 runtime performance and can focus more of their resources on the compiler
 front end, libraries and IDE.

Not just performance, they gain access to all the architectures that
llvm supports.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] differences between .pp and .pas files

[Henry Vermaak]

On Mon, Feb 25, 2013 at 11:00:25AM +, Graeme Geldenhuys wrote:
 On 2013-02-25 10:51, Sven Barth wrote:
  
  That's indeed a valid argument pro .pp
 
 And a large argument against .pp extensions is that NO editor out there
 (except for FP Text IDE and Lazarus) knows about .pp, so pascal syntax
 highlighting never works. You have to always manually force the pascal
 syntax highlighting, or if the editor allows, manually add the .pp
 extension for the Pascal highlighting.

It's not a large argument if I can fix it with a couple of lines in my
vimrc:

let pascal_fpc=1
au BufNewFile,BufRead *.pp setf pascal
au BufNewFile,BufRead *.lpr setf pascal
fix tabs, case sensitivity for pascal source
au FileType pascal set tabstop=2 shiftwidth=2 expandtab ignorecase

:)
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cross-compiler installation

[Henry Vermaak]

On Fri, Feb 22, 2013 at 10:52:09AM -0300, silvioprog wrote:
 Hello,
 
 What is cross-compiler installation mentioned in this article?:
 
 http://wiki.freepascal.org/Android (please see: http://imagebin.org/247728)
 
 And where do I download it?

The heading of that section is Building cross compiler, so that path
is where the cross compiler will be installed _after_ you've built it.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Cross-compiler installation

[Henry Vermaak]

On Fri, Feb 22, 2013 at 11:09:45AM -0300, silvioprog wrote:
 OK, but...
 
 I added the following paths on PATH env. variable:
 
 C:\lazarus\fpc\2.7.1\bin\i386-win32
 C:\Program Files (x86)\Android
 SDK\android-ndk-r8d\toolchains\arm-linux-androideabi-4.7\prebuilt\windows\bin
 
 And after:
 
 C:\Users\silvioprogmake crossall crossinstall OS_TARGET=android
 CPU_TARGET=arm
 INSTALL_PREFIX=C:\Develop\FPC\pp
 make: *** No rule to make target `crossall'.  Stop.
 
 How to solve it please? :(

You're not in the fpc source directory.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Changing variable in conditional

[Henry Vermaak]

On Wed, Jan 09, 2013 at 08:42:22AM +, Mark Morgan Lloyd wrote:
 But if you want an example of a very nasty bug caused by C/C++
 multiple assignment, there was a well-documented attempt to slip a
 privilege escalation into the Linux kernel based on this a few years
 ago.
 
 It's very easy to argue against multiple assignment. It's less easy
 to argue against implementing an equivalent of the C/C++
 conditional.

Are you talking about this one?

http://lwn.net/Articles/57135/

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Changing variable in conditional

[Henry Vermaak]

On Wed, Jan 09, 2013 at 10:46:54AM +, Mark Morgan Lloyd wrote:
 I've got a vague recollection that since that episode the kernel
 maintainers have mandated a use of parentheses that helps the
 compiler pick up the distinction between an equality and an

Assignment inside if statements are usually frowned upon in the kernel.
gcc warns if you don't use parentheses, but I usually use parentheses
for readability, so there's always a danger of making a typo and not
getting a warning.  Can't remember the last time I've had a bug of this
sort, but that's probably because I'm extra vigilant with conditionals.
I think the decision to keep this syntax out of pascal is a good one.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Changing variable in conditional

[Henry Vermaak]

On Wed, Jan 09, 2013 at 08:31:14PM +0100, Marco van de Voort wrote:
 I guess that is the bright side of it all. Sooner or later we can have an
 obfuscated Pascal contest, just like the other ones :-)

I'm sure we can already have a contest just with the careful application
of macros :)

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Changing variable in conditional

[Henry Vermaak]

On Tue, Jan 08, 2013 at 09:58:19AM +0100, Krzysztof wrote:
 I don't like a lot of C++ syntax but this one is interesting. You really
 don't like it? :)

Most C programmers I've dealt with (including myself) consider this bad
practise.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Changing variable in conditional

[Henry Vermaak]

On Tue, Jan 08, 2013 at 08:19:15AM -0300, Jorge Aldo G. de F. Junior wrote:
 C programmers are (usually, but there are a lot of exceptions) bad
 programmers who confuse the power of a language with the capability of
 decrease the ammount of typing needed to reach a certain goal.
 
 They despise pascal because pascal is somewhat verbose (ignoring that
 this is what makes pascal readable) because they think that the best
 language is the one wich allows to write a whole program in a single
 line of code.
 
 Thats because they dont usually think before writing, they think while
 they are implementing, and then the only thing between current momment
 and the momment when their program is ready is the ammount of
 typing.
 
 Pascal programmers tend to plan ahead, they think before they type. We
 type a lot because of Pascal verboseness, but usually our code is
 right from the start. We end up typing less because we fix less bugs.
 
 Pascal generally improves programmer productivity. Lets not break this
 by adding crazy ideas from C/C++ family of languages...

Better to keep your mouth closed and be thought a fool than to open it
and remove all doubt
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] wayland support for FPC

[Henry Vermaak]

On 09/11/12 11:06, Graeme Geldenhuys wrote:
 On 2012-11-09 10:42, Marco van de Voort wrote:
 IOW, I wouldn't desperately try to support Wayland native at this point.

 That can be done if the native api turns out to be stable, Wayland truely
 takes over X11, and all distros package it.

 Now it is just asking for pain IMHO.
 
 +1
 That's exactly how I feel. There has been too many attempts to displace
 X11 - and they all tanked. Wayland does seems to have more backing than
 its predecessors though.

Most of Wayland's developers are also X developers, so it looks quite
promising.  Qt 5 support for Wayland is pretty complete, afaik, so
widgetsets are taking it seriously.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Using flag field in Getopts

[Henry Vermaak]

On 30/10/12 10:05, luciano de souza wrote:
 Hello listers,
 Getopts offers very good features to process commandline arguments. As
 far as I could understand, I used it successfully. But it remains one
 unknown aspect for me. What is the field flag of TOption record?
 How to use it?
 
   TOption = Record
 Name: String;
 Has_arg : Integer;
 Flag: PChar;
 Value   : Char;
   end;

I think the man page for getopt explains best how this is supposed to work:

flag specifies how results are returned for a long option.  If flag is
NULL, then getopt_long() returns val.  (For example, the calling program
may set val to the equivalent short option character.)  Otherwise,
getopt_long() returns 0, and flag points to a variable which is set to
val if the option is found, but left unchanged if the option is not found.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: problems compiling FPC

[Henry Vermaak]

On 30/10/12 14:04, Mattias Gaertner wrote:
 Rich Cook
 Programming today is a race between software engineers striving to build 
 bigger
 and better idiot-proof programs, and the Universe trying to produce bigger and
 better idiots. So far, the Universe is winning.

Ah, you beat me to it :)

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] libusb header translation and OOP wrapper

[Henry Vermaak]

On 25 September 2012 20:57, Christo christo.cra...@gmail.com wrote:
 Any ideas on how to define the calling convention in the import unit so
 that it is either stdcall or cdecl depending on the target OS?

I've used a macro for this in the past.  E.g. :

{$macro on}
{$ifdef windows}
  {$define CCONV:=stdcall}
{$else}
  {$define CCONV:=cdecl}
{$endif}

Then use CCONV where you would specify the calling convention.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] libusb header translation and OOP wrapper

[Henry Vermaak]

On 24 September 2012 14:39, Christo christo.cra...@gmail.com wrote:
 Unfortunately the master branch appears to be 2 months old. Any idea how
 I can clone the libusb-1.0 branch?  I'm new to using git so it may be
 something trivial I'm missing.

Try to clone git://github.com/hansiglaser/pas-libusb.git

Then you can checkout the 1.0 branch.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Malformed email messages

[Henry Vermaak]

On 16/08/12 13:53, microc...@zoho.com wrote:
 Is anybody else receiving mailformed emails from the list? 

The only weirdness I get is Ludo's subject header.  The subject of the
first message in the thread was:

[fpc-pascal] linux: should we hard-code versioned or unversioned shared
libraries in our apps?

One of Ludo's later messages gives me:

RE : RE : RE : RE : RE : [fpc-pascal] Re: linux:
shouldwehard-codeversionedorunversioned shared libraries in our apps?

In gmail's web client, the conversation view only shows the original
subject at the top, but it's still visible in the header.  When using
icedove (thunderbird), it's pretty annoying, though.  Anyone else having
this problem?  Is gmail screwing around with this somehow?

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?

[Henry Vermaak]

On 15/08/12 12:37, Mark Morgan Lloyd wrote:
 Jonas Maebe wrote:
 
 In both these cases, I manually created unversioned symlinks to those
 libraries, and that got my applications working again. This is not
 ideal, but I don't know how else to handle this.

 The official way to get the unversioned symbolic links is to install
 the -dev or -devel package for that library. Of course, you're not
 supposed to require end-users to do that.
 
 Does not always work, e.g. in the case of Debian. -dev will install the
 .h and .a files, but won't necessarily set up unversioned symlinks.

I've never found a -dev package that doesn't set up symlinks in many
years of using Debian for development.  (Except if only static versions
of a specific library exists, obviously).  Could you give an example?

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?

[Henry Vermaak]

On 15/08/12 13:43, Mark Morgan Lloyd wrote:
 
 I do agree with Graeme's position though: a -dev is described as
 containing files for developers, and it should not be necessary for a
 non-developer user to start encumbering his system with .h files etc.
 What's more, part of the reason that I've had to create symlinks
 manually in the past is because things like (if I recall correctly)
 OpenOffice's interface to PostgreSQL require libpq.so without declaring
 -dev as a prerequisite... which rather reinforces my position that this
 is a distro issue even if they prefer to disclaim it.

I'd say that it's the OpenOffice interface that's broken.  They
shouldn't link to a library that doesn't specify a version.  They need
to link to a specific version by using the naming conventions as Jonas
explained.  This is to protect yourself from api/feature breakage.
Linking directly to, e.g. libpq.so, is only o.k. if you can check the
version by means of some api, which the library needs to supply in all
the versions that exist - past, present and future.  Which is probably
what they're doing.  This isn't very good practice, in my opinion, but
can work.

If they really support multiple versions of libpq, then they will have
to try to dynamically link against all the versions they support.  This
won't be much more effort than checking the version in the first place.

Even on Windows some libraries are using names that reflect the version,
e.g. I link to some opencv libs, which are named
libopencv_{module}231.dll.  I suspect this is much less of a problem in
the Windows world, since library reuse isn't that common.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Inline bytes

[Henry Vermaak]

On 09/08/12 14:25, Rainer Stratmann wrote:
 Am Thursday 09 August 2012 15:14:29 schrieb Jonas Maebe:
 Rainer Stratmann wrote on Thu, 09 Aug 2012:
 How is it possible to put some inline bytes in the code like the former
 inline( $1f , $ef , $1A );
 instruction?

 {$asmmode att}
 asm
.byte $0x1f, $0xef, $0x1a
 end;

 {$asmmode intel}
 asm
db $1a, $ef, $1a
 end;
 
 Thanks, the next problem then is: I wanted to do that in an inline procedure 
 but if the compiler detects an asm statement then inline is disabled(!).

Maybe a macro?

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal

Re: [fpc-pascal] Re: Runs correctly when debugging.

[Henry Vermaak]

On 07/05/12 12:35, Guillermo Martínez Jiménez wrote:
 Thanks, Henry,
 
 Can you give any more information about how it fails?
 
 It's a SIGSEGV.  The library is the Allegro library version 5.0.6.
 
 The error is inside an internal procedure that uploads a texture to
 OpenGL context, and it is used by other Allegro functions (i.e.
 loading pictures from file, building text fonts, etc.).
 
 Initially I suspected that I didn't use the right data types, but
 after revisiting and fixing some of them it I'm pretty sure I'm using
 the right ones.
 
 I don't know what can I say. :-/

It's hard to say without seeing your function/type declarations.

Henry
___
fpc-pascal maillist  -  fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal