Re: [fpc-devel] JWA 64-bit struct packing

[Henry Vermaak via fpc-devel]

On Thu, 14 May 2020 at 22:48, Marco van de Voort
 wrote:
> Those are probably the exceptions then. But jwa* is delphi compat, so
> can't use $PUSH/$POP, so changing defaults is less useful, since it will
> be undone at the first exception

What's even worse is that SetEntriesInAcl() was still crashing with
{$packrecords c} because Jedi used packed records for EXPLICIT_ACCESS
and TRUSTEE.  Remove packed and it works fine (with {$packrecords c}
that is).

So I'm going to conclude that most of this is unusable and cumbersome
to fix on 64-bit.  It probably warrants a compiler error or warning at
least when any jwa* unit is compiled for 64-bit.

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

Re: [fpc-devel] JWA 64-bit struct packing

[Henry Vermaak via fpc-devel]

On Thu, 14 May 2020 at 16:03, Henry Vermaak  wrote:

> So why is rtl/win*/* full of packrecords c?  These pages say that the
> Windows API expect 8:
>
> https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers#controlling-structure-packing
> https://docs.microsoft.com/en-gb/cpp/build/reference/zp-struct-member-alignment

If I do something like `echo '#include ' | gcc -E -dMD -P -
| grep -i pack` I get this:

#undef _CRT_PACKING
#define _CRT_PACKING 8
#pragma pack(push,_CRT_PACKING)
#pragma pack(pop)

Before any of wincred.h gets defined, so the packing gets popped and
it'll use the natural packing for the structs in wincred.h, which is
why packrecords c works in my code.  How does one know which header
uses 8 bytes and which uses natural packing?  (Apart from checking
mingw like this, which to be fair has never let me down with winapi
programming).

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

Re: [fpc-devel] JWA 64-bit struct packing

[Henry Vermaak via fpc-devel]

On Thu, 14 May 2020 at 15:22, Marco van de Voort
 wrote:
> The original headers only did 32-bit. Over the years some 64-bit
> corrections have been added. This process is ongoing, so please make
> sure you use the newest version.

Grepping for align|packrecords give exactly the same results in trunk,
afaics.  jwawindows.pas explicitly sets align 4.

> I'm a bit loath to try to fix this with big, overarching $packrecords,
> because the winapi actually sometimes uses packrecords C and sometimes
> packrecords 8.

So why is rtl/win*/* full of packrecords c?  These pages say that the
Windows API expect 8:

https://docs.microsoft.com/en-us/windows/win32/winprog/using-the-windows-headers#controlling-structure-packing
https://docs.microsoft.com/en-gb/cpp/build/reference/zp-struct-member-alignment

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

[fpc-devel] JWA 64-bit struct packing

[Henry Vermaak via fpc-devel]

I'm having some crashes and errors from 64-bit Windows builds that use
the JWA units.  I've tracked it down to record alignment (the 32-bit
version works fine, so it's the first place I looked).  I notice that
there's no {$packrecords c} anywhere (or alternatively {$align 8} for
64-bit).  Am I missing something?  I'm having trouble believing that
no one has found this before.

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

Re: [fpc-devel] i386-linux switched to a 16 byte aligned stack

[Henry Vermaak]

On Mon, 16 Sep 2019 at 14:58, Ben Grasset  wrote:
> On Sun, Sep 15, 2019 at 1:36 PM Florian Klämpfl  
> wrote:
>> In r43005 to 43014 I committed a couple of patches so FPC generates
>> stack frames aligned to 16 byte boundaries on i386-linux
>
> Good change! Means, for example, the long-standing issues with popular 
> libraries like SDL2 on 32-bit Linux won't be a problem anymore.

Wow, I almost forgot about this train wreck.  For us it was opencv and
we luckily had our own library between fpc and opencv so we could add
-mstackrealign.

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Henry Vermaak]

On Wed, Feb 20, 2019 at 09:47:20AM -0300, Marcos Douglas B. Santos
wrote:
> On Wed, Feb 20, 2019 at 8:32 AM Henry Vermaak
>  wrote:
> > I'm mostly more interested in limiting the scope to prevent
> > accidental use, like you.  It can also offer more fine grained
> > control of where managed variables get freed.
> 
> Try to see restrictions as a good thing.  In this case, which Pascal
> doesn't allow to declare inline variables, you must split big
> functions, which has many local variables, in others to have a better
> understanding of the algorithm. At the end, you might have a better
> design and reuse of the code. Everybody wins: you, your code, Pascal
> team - as they don't need to change the compiler - and Niklaus Wirth
> might not throw a curse in us.

I don't have many big functions and I've missed scoped variables in
Pascal since the early 1990s.  It's been standard good practice in
software engineering for decades and all the languages I work with
support it because it's a good idea, not because it's some newfangled
fad.

But big functions happen in the real world.  The fpc compiler source has
dozens of extremely long functions.  Lazarus too.  I think the windproc
function in the win32 interface is more than 700 lines (look at
TWindowProcHelper.DoWindowProc).

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

Re: [fpc-devel] "Blank slate" next version of FPC

[Henry Vermaak]

On Wed, Feb 20, 2019 at 02:26:20PM +0300, Nikolai Zhubr wrote:
> 20.02.2019 13:21, Sven Barth via fpc-devel:
> [...]
> >And we don't agree here. For us inline variables is one of the most
> >horrid if not *the* most horrid thing Embarcadero could have done to
> >Object Pascal.
> 
> Could you elaborate a bit about it?
> While I'm not really sure what they have done exactly (not using latest
> Delphi and probably not going to), I've somehow got very used to (and
> confortable with) Java's inline declarations, especially "for (int i = 0;
> )" and similar constructs, and now I find myself doing this way all the
> time, because:
> 
> 1. it makes it easier to see the whole picture just looking at the loop
> body, no need to scroll up; (The loop body might be just 10 lines of code,
> whereas the whole containing function sometimes has 1000s)
> 
> 2. it isoltates the scope of such variable(s), therefore preventing some
> sorts of accidental misuse outside of e.g. the containing loop (which still
> do happen to me ocasionally in Pascal).

I've already tried to make these points, nobody seems to buy it.  IIRC
Michael (vC) said that functions shouldn't be that long, so then it's
not a problem (perhaps his world is perfect, but mine certainly isn't).

I'm mostly more interested in limiting the scope to prevent accidental
use, like you.  It can also offer more fine grained control of where
managed variables get freed.

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

Re: [fpc-devel] Cannot trap divide by zero in xmm register

[Henry Vermaak]

On Tue, Jun 20, 2017 at 04:12:18PM +0100, Henry Vermaak wrote:
> On Tue, Jun 20, 2017 at 10:53:32AM -0400, Anthony Walter wrote:
> > Some progress ... Since this is an OpenGL app I had been
> > setting Set8087CW($133F) to prevent FPU errors from showing as exceptions.
> > When I omit Set8087CW I get EDivByZero an exception, but my program is
> > still in an unusable state.
> > 
> > Since this error occurs in the SSE XMM registers, I think I should also be
> > using the SetSSECSR function. Does anyone have any details about how this
> > function works in relation to XMM registers and rounding or divide by zero
> > errors and how it could be applied in my situation?
> 
> I use this for all my programs that use C libraries:
> 
> {$if defined(cpui386) or defined(cpux86_64)}
>   SetExceptionMask(GetExceptionMask + [exZeroDivide, exInvalidOp]);
> {$ifend}
> 
> Works fine with libs like OpenCV, etc.

Sorry, meant to add that this will also set the flags in MXCSR if you
look at the implementation of SetExceptionMask().

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

Re: [fpc-devel] Cannot trap divide by zero in xmm register

[Henry Vermaak]

On Tue, Jun 20, 2017 at 10:53:32AM -0400, Anthony Walter wrote:
> Some progress ... Since this is an OpenGL app I had been
> setting Set8087CW($133F) to prevent FPU errors from showing as exceptions.
> When I omit Set8087CW I get EDivByZero an exception, but my program is
> still in an unusable state.
> 
> Since this error occurs in the SSE XMM registers, I think I should also be
> using the SetSSECSR function. Does anyone have any details about how this
> function works in relation to XMM registers and rounding or divide by zero
> errors and how it could be applied in my situation?

I use this for all my programs that use C libraries:

{$if defined(cpui386) or defined(cpux86_64)}
  SetExceptionMask(GetExceptionMask + [exZeroDivide, exInvalidOp]);
{$ifend}

Works fine with libs like OpenCV, etc.

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

[fpc-devel] Standard in/out/error of Windows GUI apps

[Henry Vermaak]

Hello,

Recently a customer asked whether he could get a GUI version of one of
our console apps because the flashing console is annoying him.  Fair
enough, I thought, this should be easy.  We do it with our C utilities
already.

I know that a writeln() in a GUI app crashes, from when someone left a
stray writeln() in FPC 3.0.x and our app started crashing when looking
for updates online.  Can someone explain to me what the use of this is?
If you know that a handle doesn't exist, why not just redirect the
output to 'nul'?

I set out to do this myself, when I discovered that fpc tries to show
anything that you write to stdout/stderr in a messagebox.  It does this
even when the handles are being redirected (to e.g. pipes) by the
calling application.  Relevant code in syswin.inc (procedure
SysInitStdIO):

if not IsConsole then
 begin
  AssignError(stderr);
  AssignError(StdOut);
  Assign(Output,'');
  Assign(Input,'');
  Assign(ErrOutput,'');
 end
...
...

Showing writeln output in a messagebox is questionable, but it doesn't
even do it for Output and ErrOutput.  The documentation says they are
aliases for stdout/stderr?  So not only does it ignore whichever
possibly valid handles in Std{Output|Input|Error}Handle, but it also
leaves ErrOutput pointing to StdOutputHandle.

For anyone interested, this is what I had to do so that a command like
"app > stdout.txt 2> stderr.txt" behaves as expected:

{$ifdef windows}
function CanOpenHandle(AHandle: THandle): Boolean;
begin
  Result := GetFileType(AHandle) in [FILE_TYPE_DISK, FILE_TYPE_PIPE, 
FILE_TYPE_CHAR];
end;

procedure RedirectStdIO(var AFile: Text; AHandle: THandle);
var
  CanOpen: Boolean;
begin
  CanOpen := CanOpenHandle(AHandle);
  AssignFile(AFile, IfThen(CanOpen, '', 'nul'));

  if AHandle = StdOutputHandle then begin
Rewrite(AFile);
  end else if AHandle = StdErrorHandle then begin
Rewrite(AFile);
{ Rewriting a file with a '' name will use StdOutputHandle, but we want
  StdErrorHandle, so hack it in. }
if CanOpen then
  TextRec(AFile).Handle := AHandle;
  end else if AHandle = StdInputHandle then begin
Reset(AFile);
  end;
end;

procedure RedirectWinGUIStdIO;
begin
  if IsConsole then
Exit;

  RedirectStdIO(StdOut, StdOutputHandle);
  RedirectStdIO(Output, StdOutputHandle);

  RedirectStdIO(StdErr, StdErrorHandle);
  RedirectStdIO(ErrOutput, StdErrorHandle);

  RedirectStdIO(Input, StdInputHandle);
end;
{$endif}

Then call RedirectWinGUIStdIO at the start.  I hope it works for all
possibilities, my Windows skills are lacking.

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

Re: [fpc-devel] NowUTC in FPC

[Henry Vermaak]

On Thu, Jul 21, 2016 at 10:24:02AM +0100, Henry Vermaak wrote:
> On Thu, Jul 21, 2016 at 11:04:15AM +0200, Ondrej Pokorny wrote:
> > On 21.07.2016 10:37, Denis Kozlov wrote:
> > >I've uploaded a patch to mantis:
> > >http://bugs.freepascal.org/view.php?id=30394
> > 
> > Why does your client ignore mailing list threads? (Or why does my
> > Thunderbird email client ignore threads on messages sent from you?)
> 
> His client doesn't set References: or Reply-to: headers.  I have to keep
> joining the messages to the thread, it's annoying.

Sorry, meant In-Reply-To:
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] NowUTC in FPC

[Henry Vermaak]

On Thu, Jul 21, 2016 at 11:04:15AM +0200, Ondrej Pokorny wrote:
> On 21.07.2016 10:37, Denis Kozlov wrote:
> >I've uploaded a patch to mantis:
> >http://bugs.freepascal.org/view.php?id=30394
> 
> Why does your client ignore mailing list threads? (Or why does my
> Thunderbird email client ignore threads on messages sent from you?)

His client doesn't set References: or Reply-to: headers.  I have to keep
joining the messages to the thread, it's annoying.

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

Re: [fpc-devel] NowUTC in FPC

[Henry Vermaak]

On Wed, Jul 20, 2016 at 03:26:56PM +0100, Denis Kozlov wrote:
> On 20 July 2016 at 14:47, Marco van de Voort  wrote:
> 
> > In our previous episode, Denis Kozlov said:
> > > I'm not sure why you say there is no guarantee, because in example of
> > > Windows implementation GetSystemTime API is explicitly expressed in UTC
> > > according to MSDN.
> >
> > I was looking at the Unix implementation.
> >
> 
> Unix implementation also returns UTC time, i.e. fpgettimeofday returns
> seconds since Epoch, which gets converted to TDateTime.
> 
> Don't mind another poorly chosen name "EpochToLocal", which in reality is
> more like "UnixToDateTime".
> 
> Is there an issue I'm just not seeing?

I thought the same.  Maybe the implementation predates UnixToDateTime()?
Worth a bug report, I think.

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

Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error

[Henry Vermaak]

On Wed, Jun 29, 2016 at 05:09:54PM +0100, Henry Vermaak wrote:
> On Tue, Jun 28, 2016 at 10:56:30AM +0200, Michael Van Canneyt wrote:
> > FPC 3.0 indeed contains a bug. This has meanwhile been fixed.
> > 
> > If I compile the program with trunk, I get:
> > 
> > home: >fpc tt.pp
> > home: >./tt
> > Offset :-120
> > Local Time :10:53:16
> > UTC:08:53:16
> > home: >date --utc
> > Tue Jun 28 08:53:25 UTC 2016
> > home: >date Tue Jun 28 10:53:29 CEST 2016
> > 
> > So the output is correct in trunk, and the bug has been fixed. I expect the
> > fix to be in 3.0.2.
> 
> It doesn't look like this fix (r31356) has been merged into fixes_3_0,
> or am I missing something?

Thanks Marco for merging it last night.

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

Re: [fpc-devel] FPC V3.0.0 LocalTimeToUniversal() error

[Henry Vermaak]

On Tue, Jun 28, 2016 at 10:56:30AM +0200, Michael Van Canneyt wrote:
> FPC 3.0 indeed contains a bug. This has meanwhile been fixed.
> 
> If I compile the program with trunk, I get:
> 
> home: >fpc tt.pp
> home: >./tt
> Offset :-120
> Local Time :10:53:16
> UTC:08:53:16
> home: >date --utc
> Tue Jun 28 08:53:25 UTC 2016
> home: >date Tue Jun 28 10:53:29 CEST 2016
> 
> So the output is correct in trunk, and the bug has been fixed. I expect the
> fix to be in 3.0.2.

It doesn't look like this fix (r31356) has been merged into fixes_3_0,
or am I missing something?

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

Re: [fpc-devel] TProcess empty parameter

[Henry Vermaak]

On Thu, May 07, 2015 at 02:15:07PM +0200, Marco van de Voort wrote:
> In our previous episode, Michael Van Canneyt said:
> > >
> > > Since NIL is a termination of an array of pchar in C that is not ok.
> > 
> > if that were the case, argc would not have been introduced, 
> > which is why I doubt the use of this argument ?
> 
> Where is argc on the calling side? In the parameters of ExecVE ? Right.
>  
> > C code that regards nil as the last element of the argv array is just
> > wrong.
> 
> IMHO *nix is not terribly well designed. Probably the multitude of versions
> and being interwoven with C prohibited doing massive cleanups.

The (redundant) argv[argc] == NULL thing was added because of common
practice, I think.  It's pretty common  to see while (*argv) {...}.

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

Re: [fpc-devel] TProcess empty parameter

[Henry Vermaak]

On Thu, May 07, 2015 at 01:55:37PM +0200, Michael Van Canneyt wrote:
> On Thu, 7 May 2015, Henry Vermaak wrote:
> >On Thu, May 07, 2015 at 12:59:52PM +0200, Michael Van Canneyt wrote:
> >>if that were the case, argc would not have been introduced, which is
> >>why I doubt the use of this argument ?
> >>
> >>C code that regards nil as the last element of the argv array is just wrong.
> >
> >The C standard says that argv[argc] shall be a null pointer.
> 
> So if argc is 15, there should be no problem to have a Nil at position 5 ?

The standard also says that argv[0] to argv[argc-1] shall contain
pointers to strings.  NULL is not a pointer to a string, so that would
be a problem.

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

Re: [fpc-devel] TProcess empty parameter

[Henry Vermaak]

On Thu, May 07, 2015 at 12:59:52PM +0200, Michael Van Canneyt wrote:
> 
> 
> On Thu, 7 May 2015, Marco van de Voort wrote:
> 
> >In our previous episode, Michael Van Canneyt said:
> >
> >(on rereading the whole thread)
> >
> >>That is only if you use the CommandLine property.
> >>If you use the stringlist (Parameters), no parsing is done.
> >
> >The mentioned routine is the tstringlist to array of pchar conversion, and
> >afaik also applies to the separated part.
> >
> >Since NIL is a termination of an array of pchar in C that is not ok.
> 
> if that were the case, argc would not have been introduced, which is
> why I doubt the use of this argument ?
> 
> C code that regards nil as the last element of the argv array is just wrong.

The C standard says that argv[argc] shall be a null pointer.

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

Re: [fpc-devel] Building 2.7.1 on current Raspbian fails

[Henry Vermaak]

On Fri, Oct 17, 2014 at 11:09:17AM +0100, Paul Michell wrote:
> I'm currently trying to build 2.7.1 from SVN on the latest Raspbian 
> (2014-09-09).
> I've previously built this with either 2.6.0 from the repository, or with 
> Thaddy de Koning's build from March 2014.
> 
> Currently, neither of these will build 2.7.1 on a Raspberry Pi.  So I have 
> also tried with the generic arm-linux
> release archive (fpc-2.6.4.arm-linux.tar).  This installed without error and 
> I can compile projects on the Pi with it.
> 
> However, when trying to build 2.7.1 (make all) it creates a compiler binary, 
> but fails whilst compiling fpmake.  
> This looks similar to the bug 0024056 which is flagged as resolved.  The 
> solution suggested there is to install 
> build-essential, but this is installed by default on Raspbian, so I think 
> there must be something else wrong? 
> 
> Could anyone suggest what I could try now?
> 
> --8<--
> 
> /home/pi/Projects/FreePascal/fpctmp/compiler/ppcarm fpmake.pp  
> -Fu/home/pi/Projects/FreePascal/fpctmp/packages/fpmkunit/units_bs/arm-linux 
> -Fu/home/pi/Projects/FreePascal/fpctmp/rtl/units/arm-linux  
> Free Pascal Compiler version 2.7.1 [2014/10/17] for arm
> Copyright (c) 1993-2014 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling fpmake.pp
> fpmake.pp(16,3) Note: Local variable "T" is assigned but never used
> Assembling fpmake
> Linking fpmake
> fpmake.pp(46) Warning: "crti.o" not found, this will probably cause a linking 
> failure
> fpmake.pp(46) Warning: "crtbegin.o" not found, this will probably cause a 
> linking failure
> fpmake.pp(46) Warning: "crtend.o" not found, this will probably cause a 
> linking failure
> fpmake.pp(46) Warning: "crtn.o" not found, this will probably cause a linking 
> failure

Where are these files on your system?  I remember after multiarch
happened on debian I had to add some library paths to get fpc to link.
This sounds like a similar issue.

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

Re: [fpc-devel] TThread extensions

[Henry Vermaak]

On Fri, Jun 27, 2014 at 09:30:52AM +0200, Michael Schnell wrote:
> The released rtl version does not have TThread.Queue and for timing
> only fpgettimeofday() is provided, which is not a "permanent
> ticker"-source but jumps back and foreword when the UTC system time
> is updated.

The latest release (2.6.4) has clock_gettime() in unit linux.

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

Re: [fpc-devel] ARM FP calling convention

[Henry Vermaak]

On Thu, Mar 06, 2014 at 12:09:25PM -0500, Vsevolod Alekseyev wrote:
> Please, is there a way to make Free Pascal on ARM use floating point
> registers for passing floating point parameter?

Yes, the armhf target does this.  You'll have to build it from trunk,
there are several mailing list threads that show you how.

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

Re: [fpc-devel] pthread scheduler attributes

[Henry Vermaak]

On Tue, Dec 10, 2013 at 02:39:12PM +0100, Sven Barth wrote:
> Am 10.12.2013 12:51 schrieb "Henry Vermaak" :
> > I thought Windows threads always start with the same priority as the
> > process?
> 
> Yes and no. On windows processes have a process class and threads have a
> priority level. Threads inherit the priority class from the process (and
> this can not be changed on a per thread level) and are created with
> priority level THREAD_PRIORITY_NORMAL *within* that priority class.
> Changing the priority level then only changes the priority level *inside*
> the priority class.
> Don't know how good this Windows behavior is approximated on cthreads
> systems though... (and I don't really know wether it's good to approximate
> it :/ )

OK, thanks.  I can't think of a straight forward way to abstract the
policies and priorities.  Since it's quite a specialised thing to do and
the policy/priority (at least on linux) depends on the system and what
else is running on it, perhaps it's not unreasonable to let the user
write platform specific code for their use case.

Not inheriting the policy/priority on linux is definitely unexpected,
though, I only found out after reading the code in cthreads.  Does
anyone agree with me here?  Shall I file a bug report?

I'll file a bug report for the leak.

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

Re: [fpc-devel] pthread scheduler attributes

[Henry Vermaak]

On Tue, Dec 10, 2013 at 12:27:00PM +0100, Michael Van Canneyt wrote:
> On Tue, 10 Dec 2013, Henry Vermaak wrote:
> 
> >Hello everyone
> >
> >Could anyone tell me why threads are set to not inherit scheduling
> >parameters from the calling thread?
> >
> >http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/cthreads.pp?view=markup#l339
> 
> No particular reason. Probably because it tries to mimic windows behaviour.

I thought Windows threads always start with the same priority as the
process?

I also just noticed that this code probably leaks memory, since
pthread_attr_destroy() is never called for thread_attr.

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

[fpc-devel] pthread scheduler attributes

[Henry Vermaak]

Hello everyone

Could anyone tell me why threads are set to not inherit scheduling
parameters from the calling thread?

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/cthreads.pp?view=markup#l339

This is a bit of a pain, since I can easily set the main thread
scheduling parameters by using command line options to
`start-stop-daemon` or `chrt`, but then need to use
pthread_setschedparam() manually for each thread I create.

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

Re: [fpc-devel] FPC 2.6.2.

[Henry Vermaak]

On Wed, Nov 27, 2013 at 09:35:16AM +0100, Michael Schnell wrote:
> (I had hoped for somebody else to ask this silly question, and
> waited some weeks but as nobody did, I need to do it myself)
> 
> The svn sources request to be compiled by a v2.6.2 compiler, which I
> don't have, as I only "work" with the svn results, which I compiled
> with a v2.6.0 fpc up to recently. I have the "starting compiler" in
> a dedicated folder  and don't have an installed package for same.
> 
> Can I just copy some files in there to get the starting compiler
> v2.6.2 ? Where can I find them ? (Searching the wiki for  "starting
> compiler" does not find a page containing this text.)
> (This is a 32 Bit x86 Linux desktop.)

There are bootstrap compiler for 2.6.2 here:

ftp://ftp.freepascal.org/pub/fpc/dist/2.6.2/bootstrap/

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

Re: [fpc-devel] TCustomApplication

[Henry Vermaak]

On Mon, Aug 19, 2013 at 04:43:52PM +0200, Michael Schnell wrote:
> On 08/19/2013 04:31 PM, Henry Vermaak wrote:
> >How do you suppose that a mutex in linux will wake up an event loop?
> 
> The mutex gets taken before the loop is started. Now the loop blocks
> when taking it. It is freed whenever an event is scheduled.

So, only one event can ever wake up your even loop?  I usually use
select() or epoll().  I'm looking forward to seeing your implementation,
though.  However, judging by how long you've been talking about this, I
think I'll be retired by then.

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

Re: [fpc-devel] TCustomApplication

[Henry Vermaak]

On Mon, Aug 19, 2013 at 03:49:53PM +0200, Michael Schnell wrote:
> On 08/19/2013 02:27 PM, Henry Vermaak wrote:
> >A simple way to do this is with the self-pipe trick.
> I suppose in Windows we would use a message. In Linux I would prefer
> a semaphore or - supposedly best if really usable here -
> pthread.mutex as same uses FUTEX whenever the underlying arch allows
> for and thus the overhead is as small as possible, because there is
> no OS call necessary when scheduling an event and when an event is
> already scheduled at the time the previous is done.

That makes no sense.  How do you suppose that a mutex in linux will wake
up an event loop?

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

Re: [fpc-devel] TCustomApplication

[Henry Vermaak]

On Mon, Aug 19, 2013 at 02:03:11PM +0200, Michael Schnell wrote:
> On 08/19/2013 01:47 PM, Michael Van Canneyt wrote:
> >
> >YOU DO NOT NEED TO DO THIS.
> >
> >Just implement the loop and let it call CheckSynchronize at
> >regular intervals.
> >All the rest will be done for you.
> >
> Did you ever do embedded software ?
> 
> The result of the event in the main queue is not having something
> displayed to a human, but may be a command to the attached
> "machine", which might be really fast.
> 
> Thus regular polling is an absolute no-go here.
> 
> Doing the polling "slow" results in huge latency regarding the events.
> 
> Doing the polling "fast" results in a huge processor overhead and
> thus in a huge overhead regarding anything else that the CPU is
> supposed to do.

You don't need to poll.  Just make sure that you assign and implement
WakeMainThread (classes.pp).  When Synchronize() is called, it will
check if WakeMainThread is assigned and call it.  This will wake up your
main loop and you can then call CheckSynchronize().

How you implement WakeMainThread will depend on your event loop
mechanism.  A simple way to do this is with the self-pipe trick.

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

Re: [fpc-devel] Re: TThread.WaitFor delay

[Henry Vermaak]

On Wed, Jun 19, 2013 at 04:05:19PM +0200, Ludo Brands wrote:
> On 06/19/2013 12:10 PM, Henry Vermaak wrote:
> > On Thu, May 30, 2013 at 03:54:08PM +0100, Henry Vermaak wrote:
> >> Hi list
> >>
> >> When I call TThread.WaitFor, I almost always get a 100ms delay,
> >> presumably due to the CheckSynchronize(100) here:
> >>
> >>
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/tthread.inc?view=markup#l296
> >>
> >> Is it feasible to add an extra check so that this doesn't happen when
> >> FOnTerminate isn't assigned and DoSynchronizeMethod is false?
> >>
> >> Also, it looks like spinning on FFinished like this can get you into
> >> trouble with cpu re-ordering, or am I missing something?
> >
> > Anyone have thoughts on this?
> 
> WaitForThreadTerminate(FHandle, 0) blocks the main thread and skipping
> the spin on FFinished would block all threads that call synchronize
> until the thread that is waited for finishes. You can only test
> assignment of FOnTerminate for the current thread and not for other
> threads.

Ah, right.  I thought the spin on FFinished was only needed to prevent
deadlock if the current thread has an OnTerminate event.  Why worry
about other threads synchronising at that point?

> DoSynchronizeMethod doesn't exist anymore in 2.7.1.

Right, sorry, I'm not really familiar with the internals.

> I agree the current implementation is not very satisfactory when you
> don't use synchronize. You could be better off using
> WaitForThreadTerminate yourself instead of WaitFor.

This is what I ended up doing, was just wondering if there's a way to
remove this penalty somehow.

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

[fpc-devel] Re: TThread.WaitFor delay

[Henry Vermaak]

On Thu, May 30, 2013 at 03:54:08PM +0100, Henry Vermaak wrote:
> Hi list
> 
> When I call TThread.WaitFor, I almost always get a 100ms delay,
> presumably due to the CheckSynchronize(100) here:
> 
> http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/tthread.inc?view=markup#l296
> 
> Is it feasible to add an extra check so that this doesn't happen when
> FOnTerminate isn't assigned and DoSynchronizeMethod is false?
> 
> Also, it looks like spinning on FFinished like this can get you into
> trouble with cpu re-ordering, or am I missing something?

Anyone have thoughts on this?

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

[fpc-devel] TThread.WaitFor delay

[Henry Vermaak]

Hi list

When I call TThread.WaitFor, I almost always get a 100ms delay,
presumably due to the CheckSynchronize(100) here:

http://svn.freepascal.org/cgi-bin/viewvc.cgi/trunk/rtl/unix/tthread.inc?view=markup#l296

Is it feasible to add an extra check so that this doesn't happen when
FOnTerminate isn't assigned and DoSynchronizeMethod is false?

Also, it looks like spinning on FFinished like this can get you into
trouble with cpu re-ordering, or am I missing something?

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Wed, Mar 06, 2013 at 10:50:10AM +0100, Daniël Mantione wrote:
> 
> 
> Op Tue, 5 Mar 2013, schreef Henry Vermaak:
> 
> >Damn.  My custom config kernel compiles stable kernels in 3-5 minutes on
> >a quad core Xeon, which isn't bad.  Did you build with the standard
> >config?
> 
> What is the standard config? As the operating system is Scientific
> Linux 6, I'm using the config for the standard 2.6.32 kernel with as
> little modifications as possible to use it for 3.3.2.

Sorry, meant something like standard distro config, i.e. not
localmodconfig or customised.

> I don't have a 4 core Xeon system, but I tried to simulate it on a
> dual Xeon 2670 system by only using 4 cores:
> 
> [root@node037 src]# time numactl --physcpubind=0-3 make -j 4
> 
> ...
> 
> real11m45.748s
> user38m30.405s
> sys 4m48.634s

3.8.2 with standard debian config on 4 core xeon:

real28m19.009s
user84m16.092s
sys 7m18.327s

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

Re: [fpc-devel] Delphi anonymous methods

[Henry Vermaak]

On Tue, Mar 05, 2013 at 09:56:21AM -0800, Boian Mitov wrote:
> Hi Henry,
> 
> Interesting that you consider me a Delphi fanboy :-D .
> I don't like it much, but I surely love the anonymous methods :-D .
> I love the C++11 implementation of anonymous methods more however,
> but I hate the lack of extensive RTTI in C++ (and FPC).
> I am hard to please, and no fan of any specific language. I hate
> them, and love them equally with only one exception, well maybe 2. I
> highly dislike Java, and I hate Scheme! :-D .
> And BTW: I hate my products too, so that is why I keep working to
> improve them all the time :-D, they are never good enough for me! I
> am equal opportunity hater!

You sure have a lot of smiley faces for a person so full of hate :)

In all seriousness, what were you thinking when you used all the latest
features of a language that's closed source?  I can understand that it
makes your code better (arguably, perhaps), but you've locked yourself
into the Delphi world now, and it's unlikely that freepascal will ever
satisfy you if you chase after the latest features, since it will take
too long to implement and stabilise.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Tue, Mar 05, 2013 at 07:26:19PM +0100, Daniël Mantione wrote:
> 
> 
> Op Tue, 5 Mar 2013, schreef Mark Morgan Lloyd:
> 
> >I've not had an opportunity to try this, but my understanding is
> >that on a Sun E10K with something like 256 400MHz processors the
> >Linux kernel built in around 20 seconds. I've had it build in
> >about 3 minutes on a system with 16x 80MHz processors, but that
> >was in the days of kernel 2.2 and there was probably less than
> >half today's number of files involved.
> 
> Well... I put that into question. I don't have a 256 core system,
> but I have a quad Opteron 6376 system, 64 cores @ 2.4 GHz is quite a
> bit of compute power. Compiling kernel 3.3.2:
> 
> [root@node016 linux-3.3.2]# time make -j 64
> 
> ...
> 
> real1m54.823s
> user77m14.178s
> sys 11m32.109s

Damn.  My custom config kernel compiles stable kernels in 3-5 minutes on
a quad core Xeon, which isn't bad.  Did you build with the standard
config?

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Tue, Mar 05, 2013 at 11:44:37AM +0100, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > >>But on the other hand, if an application programmer could
> > > >>disable FPC's unit handling and use  make -j  instead, choosing
> > > >>to pay the price of difficult maintenance, it might defuse the
> > > >>criticism coming from certain quarters.
> > > >>
> > > >Make can not figure out the dependencies between units by itself
> > > >as it would need to parse them.
> > > 
> > > That's for the user to do, if he thinks he can do a better job than FPC.
> > 
> > Or implement an option that spits out the dependencies for make, so that
> > the user doesn't have to do this.
> 
> That does't work, since in FPC an unit is an interface AND an
> implementation. And inline functions are in the implementation, not the 
> interface.
> 
> The only way is to simply toss the modular system (units) out, and work with
> $i, declare functions as externals in headers, let the compiler spit out
> dependencies.

OK, I'll drop this line of enquiry then :)  Thanks for the information
(and the patience).

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Tue, Mar 05, 2013 at 11:09:39AM +0100, Michael Van Canneyt wrote:
> 
> There is a new tool "pas2fpm.pp" which can easily be adapted to do this.
> It already calculates the dependencies, but outputs them in fpmake form.

Ah, I remember that fpmake can build with multiple threads, so perhaps
this is a better solution than to do it with make.  I'll investigate.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Tue, Mar 05, 2013 at 11:05:22AM +0100, Sven Barth wrote:
> Am 05.03.2013 10:58, schrieb Henry Vermaak:
> >On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
> >>Sven Barth wrote:
> >>>Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
> >>>>But on the other hand, if an application programmer could
> >>>>disable FPC's unit handling and use  make -j  instead, choosing
> >>>>to pay the price of difficult maintenance, it might defuse the
> >>>>criticism coming from certain quarters.
> >>>>
> >>>Make can not figure out the dependencies between units by itself
> >>>as it would need to parse them.
> >>That's for the user to do, if he thinks he can do a better job than FPC.
> >Or implement an option that spits out the dependencies for make, so that
> >the user doesn't have to do this.
> As this is something we (as in the FPC developers) don't need:
> patches are welcome.

I'm trying to ascertain if this is even possible (the c-style,
file-at-a-time compilation, using make to handle multiple processes).
Do you think it's possible, then?

I'm not ordering anyone to implement features, I'm exploring solutions
to the depressing fact that my c projects compile quicker than my fpc
projects (simply because my build system can launch parallel jobs).  I
don't think that turning fpc into a multi-threaded compiler is a sane
thing to do.

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

Re: [fpc-devel] Delphi anonymous methods

[Henry Vermaak]

On Tue, Mar 05, 2013 at 10:12:04AM +0100, Michael Van Canneyt wrote:
> You may think that Delphi is the best thing since sliced bread,
> but not everyone thinks so.

And with the attitude of, e.g. Boian, we see that it's simply too hard
to please hard-core delphi fanboys.  They're all "take" and no "give".
I look forward to the day when the fpc developers will realise that
playing eternal catch-up is never going to work.

> There are several people on the list that do not like what Delphi is doing to
> the pascal language. The way Embarcadero treats the Pascal Language
> I am more and more going to this camp. More so with every release of
> Delphi.

Much kudos to Sven for really trying to keep the language sane.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Tue, Mar 05, 2013 at 09:41:37AM +, Mark Morgan Lloyd wrote:
> Sven Barth wrote:
> >Am 05.03.2013 10:14, schrieb Mark Morgan Lloyd:
> >>
> >>But on the other hand, if an application programmer could
> >>disable FPC's unit handling and use  make -j  instead, choosing
> >>to pay the price of difficult maintenance, it might defuse the
> >>criticism coming from certain quarters.
> >>
> >Make can not figure out the dependencies between units by itself
> >as it would need to parse them.
> 
> That's for the user to do, if he thinks he can do a better job than FPC.

Or implement an option that spits out the dependencies for make, so that
the user doesn't have to do this.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Mon, Mar 04, 2013 at 09:25:02PM +0100, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > > I just add all the objects to a variable in a Makefile.
> > > > 
> > > > The result is that I have a 27000 line c library that compiles in *half*
> > > > the time it takes to compile a 4000 line lazarus program because my c
> > > > lib can be built with make -j 9.
> > > 
> > > I'm not exactly sure what this proves. The C situation is not equivalent 
> > > to
> > > the Pascal situation, the latter trying to make sure all (Pascal level
> > > symbols) are there before the linker.
> > 
> > What I'm trying to say is that gcc is going 3 times faster on my quad
> > core machine because of the build system, not because they've turned
> > their compiler into a multi-threaded clusterfsck.
> 
> IMHO a threading clusterfsck is preferable to a forking clusterfck :-)

My gut feeling would be that the complexity and potential bugs/races
don't make up for the speed, but maybe a threaded compiler gains a lot
more than I imagine.  Are there any multi-threaded compilers around for
comparison?

> Yes. But is that incremental? It is fun to speed up a full build, but in
> reality developers are more likely to do a partial one. Ever pressed F9
> after a small change in Delphi? The app starts nearly immediately, if
> the change wasn't too deep in the hierarchy of dependencies.
> 
> But compilation units in C have weaker(no) coherence than in (modular) 
> Pascal, and C does
> not have an auto build system. All dependencies are done manually.
> (sometimes assisted with semi automated tools)
> 
> This means you need to manually specify in the build system which
> compilation unit depends on which headers. And this is also why in C/C++
> inline functions are in the header, so that this model is persistent, since
> most builds are not full, but incremental.

As you probably know, you can use -MD and variants with gcc, which
outputs dependency files for make, that you then include in the
Makefile.  If you add, e.g. -MMD to the CFLAGS, these dependencies are
generated as a side effect of the compilation process, so it's not a
separate step.  As a result, partial builds work really well, and can be
parallelized as usual.  No manual work involved.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Mon, Mar 04, 2013 at 11:19:38AM +0100, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > Manually maintaining dependencies between compilation units is stone-age.
> > 
> > I just add all the objects to a variable in a Makefile.
> > 
> > The result is that I have a 27000 line c library that compiles in *half*
> > the time it takes to compile a 4000 line lazarus program because my c
> > lib can be built with make -j 9.
> 
> I'm not exactly sure what this proves. The C situation is not equivalent to
> the Pascal situation, the latter trying to make sure all (Pascal level
> symbols) are there before the linker.

What I'm trying to say is that gcc is going 3 times faster on my quad
core machine because of the build system, not because they've turned
their compiler into a multi-threaded clusterfsck.  In my ignorance, I'm
assuming that the same can't be achieved with pascal, then (without
making the compiler itself multi-threaded)?

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Sat, Mar 02, 2013 at 05:26:02PM +0100, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > I don't see why there would be more synchronization overhead than make?
> > 
> > So why not keep it simple and let the build system handle parallel jobs?
> 
> I like autobuilding. IMHO that is a core attraction of unit based (modular)
> languages.
> 
> Manually maintaining dependencies between compilation units is stone-age.

I just add all the objects to a variable in a Makefile.

The result is that I have a 27000 line c library that compiles in *half*
the time it takes to compile a 4000 line lazarus program because my c
lib can be built with make -j 9.

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

Re: [fpc-devel] Comparison FPC 2.6.2 - Delphi 7

[Henry Vermaak]

On Sat, Mar 02, 2013 at 04:23:32PM +0100, Marco van de Voort wrote:
> In our previous episode, Florian Klaempfl said:
> > >> Better parallize the building using some build units. Then it will be
> > >> probably compiled in less than 10 sec on a modern CPU.
> > >
> > > Better paralellize the compiler :-)
> > 
> > In theory yes but I still fear that the threadvars and synchronization 
> > eats much of the advantage in this case.
> 
> I don't see why there would be more synchronization overhead than make?

So why not keep it simple and let the build system handle parallel jobs?

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

Re: [fpc-devel] Summer of code collaboration

[Henry Vermaak]

On Sun, Feb 10, 2013 at 11:04:59PM +0100, Marco van de Voort wrote:
> In our previous episode, Henry Vermaak said:
> > > Sven already replied, but roughly  in the coreutils package. (the former
> > > findutils and diffutils iirc)
> > 
> > Sorry if this is a daft question, but can't you use the msys coreutils?
> > Or do they have some limitation?
> 
> IIRC they were less adapted to windows. I got a cygwin vibe there, the state
> within a state principle, with shared memory space and all.
> 
> A quick test seemed to not really be a substitution, but probably would need
> a whole process to support them and get it stable enough.
> 
> That also means that other cygwin problems (multiple versions conflict due
> to clashing shared version) could reappear too.
> 
> I never spent more than an evening on the test though, since I rather get
> rid of all the mingw parts instead (think fpmake here)

This would indeed be the best solution, thanks for the background.

> > Last time I built fpc in windows, I didn't use the tools shipped with
> > fpc at all.  I built it inside an msys terminal (with patched fpc
> > Makefiles).
> 
> If you need to patch makefiles, doesn't that say enough ? :)

I already had a full mingw/msys installation with up to date binutils
and coreutils and didn't want to install fpc's bundled outdated tools.
Patching the Makefiles was the only sane thing to do, since I spend most
of my time in windows working with the msys terminal (mintty, actually).

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

Re: [fpc-devel] Summer of code collaboration

[Henry Vermaak]

On Sun, Feb 10, 2013 at 10:08:29PM +0100, Marco van de Voort wrote:
> In our previous episode, Jonas Maebe said:
> > > Note though that one of the reasons why FPC tools are old is because they
> > > are the most up to date mingw versions. Before they abandonned the tools
> > > we were using, and set up everything in MSYS.
> > 
> > At least the mingw binutils are still maintained:
> > http://sourceforge.net/projects/mingw/files/MinGW/Base/binutils/binutils-2.22.
> >  
> > The same goes for "make" (FPC 2.6.x has problems with make 3.82 though,
> > not specific to Windows/mingw) and gdb at least.  Which abandoned tools do
> > you mean?
> 
> Sven already replied, but roughly  in the coreutils package. (the former
> findutils and diffutils iirc)

Sorry if this is a daft question, but can't you use the msys coreutils?
Or do they have some limitation?

Last time I built fpc in windows, I didn't use the tools shipped with
fpc at all.  I built it inside an msys terminal (with patched fpc
Makefiles).

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

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Henry Vermaak]

On Thu, Feb 07, 2013 at 02:43:11PM +, Henry Vermaak wrote:
> On Thu, Feb 07, 2013 at 03:11:00PM +0100, Jonas Maebe wrote:
> > The interlocked* routines only guarantee that that particular value
> > is updated in atomic way across multiple cores. It does not
> > guarantee anything about memory access performed before or after
> > that interlocked* call. The memory barriers are to ensure that all
> > memory accesses before the lock-primitive (such as Enter/
> > LeaveCriticalSection) are also synchronized across all cores.
> 
> It may be a good idea for the documentation to explicitly say which
> functions do/do not imply memory barriers, since the linux kernel
> atomic_cmpxchg() and the Windows API guarantees full memory barriers, so
> people may expect that.

Most of the gcc __sync_* builtins guarantee a full barrier, too.

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

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Henry Vermaak]

On Thu, Feb 07, 2013 at 03:11:00PM +0100, Jonas Maebe wrote:
> The interlocked* routines only guarantee that that particular value
> is updated in atomic way across multiple cores. It does not
> guarantee anything about memory access performed before or after
> that interlocked* call. The memory barriers are to ensure that all
> memory accesses before the lock-primitive (such as Enter/
> LeaveCriticalSection) are also synchronized across all cores.

It may be a good idea for the documentation to explicitly say which
functions do/do not imply memory barriers, since the linux kernel
atomic_cmpxchg() and the Windows API guarantees full memory barriers, so
people may expect that.

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

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Henry Vermaak]

On Thu, Feb 07, 2013 at 01:01:47PM +0100, Jonas Maebe wrote:
> 
> On 07 Feb 2013, at 12:52, Jonas Maebe wrote:
> 
> >It doesn't belong in our manuals. Anyone who wants to manually
> >create low level thread synchronisation primitives will have to
> >know a lot more about cpu architecture and memory consistency
> >models then we could ever describe in our documentation.
> 
> In case anyone is interested, some good documents on this topic are:
> * 
> http://www.rdrop.com/users/paulmck/scalability/paper/ordering.2007.09.19a.pdf
> * http://www.kernel.org/doc/Documentation/memory-barriers.txt

Paul McKenney has written quite a lot about this, I find his "Memory
Barriers: a Hardware View for Software Hackers" very useful.

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

Re: [fpc-devel] Feature announcement: Type helpers

[Henry Vermaak]

On Wed, Feb 06, 2013 at 01:12:59PM +0100, Sven Barth wrote:
> Am 06.02.2013 12:13, schrieb Henry Vermaak:
> >Thanks for pointing out the advantages.  I can see the point, but can't
> >help to think that I'll be reading code like this soon:
> >
> >s := '(' + x.ToString + ', ' + y.ToString + ')';
> >
> >Instead of
> >
> >s := Format('(%d, %d)', [x, y]);
> I suppose there are quite some people (especially newbies ^^) who
> write it like this:
> 
> s := '(' + IntToStr(x) + ', ' + IntToStr(y) + ')';
> 
> And here I would prefer the "ToString" variant (but my personal
> favorit is the "Format" one :) )

No, you miss my point.  Let me put it this way: You're trading one type
of discoverability for another.

With type helpers, it becomes easy to discover that I can type
x. and immediately see ToString.  But I'll never learn of
Format(), Trim(), etc. this way.

With IntToStr, the initial discoverability is hard, since I need to know
about IntToStr in the first place.  But when I  on IntToStr,
I immediately see Format(), Trim(), AdjustLineBreaks(), etc.

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

Re: [fpc-devel] Feature announcement: Type helpers

[Henry Vermaak]

On Wed, Feb 06, 2013 at 11:52:27AM +0100, Michael Van Canneyt wrote:
> On Wed, 6 Feb 2013, Marco van de Voort wrote:
> 
> >In our previous episode, Michael Van Canneyt said:
> >>>Well, newbies are not to strong in knowing what is which unit either :-)
> >>
> >>If we're talking newbies and IDE:
> >>
> >>They don't need to, if the IDE puts the unit in the uses clause to start 
> >>with...
> >
> >That's completely new functionality. Afaik most unit adding of IDEs is
> >hardcoded?.
> 
> I know. The codetools need to recognize type helpers in the first
> place.
> 
> Then we can start thinking about changing the default unit uses clause.
> For instance in the package lazarusforeducation or so.
> 
> Anyway, I just wanted to point out which advantages I see (or do not see) in 
> type helpers.

Thanks for pointing out the advantages.  I can see the point, but can't
help to think that I'll be reading code like this soon:

s := '(' + x.ToString + ', ' + y.ToString + ')';

Instead of

s := Format('(%d, %d)', [x, y]);

What I'm trying to say with this (admittedly contrived) example is that
when you are forced to read the docs to find out which functions you can
use for converting numbers to strings, you'll probably discover
functions like Format.  At least in my case, the most useful tricks I
learn come from reading the documentation for something, then exploring
a bit.

I apologise if I come across as overly cynical and I do appreciate
Sven's work in the compiler!

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

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Henry Vermaak]

On Mon, Feb 04, 2013 at 02:54:10PM +0100, Sven Barth wrote:
> Am 04.02.2013 13:40, schrieb Henry Vermaak:
> >On Mon, Feb 04, 2013 at 11:47:48AM +, Graeme Geldenhuys wrote:
> >>Hi,
> >>
> >>I found another problem with Semaphores between FreeBSD and Linux.
> >>
> >>Attached is my test project. Again, it is similar code used in tiOPF.
> >>
> >>For some reason under FreeBSD, it *always* zeros the variable that holds
> >>the Max Pool Size value passed in to sem_init()'s third parameter. This
> >>means that if I try and us that variable anywhere after the sem_init()
> >>call, like when I want to destroy the semaphore, I can't because the
> >>variable now holds the value 0.
> >FPC's definition of the semaphore struct is probably wrong for FreeBSD.
> >Currently, it's:
> >
> >sem_t = cint;
> You are in so far right that the declaration is incorrect, but in
> trunk it looks like this:
> 
> === code begin ===
> 
> sem_t_rec = record end;
> sem_t = ^sem_t_rec;
> 
> === code end ===

Indeed, but trunk pthread.inc looks different from this:

sem_t = record
magic   : cuint32;
lock: pthread_mutex_t;
gtzero  : pthread_cond_t;
count   : cuint32;
nwaiters: cuint32;
semid   : semid_t;
sysse   : cint;
entry   : psem_t;
backpointer : ppsem_t;
spare : array[0..SEM_SAFE] of char;
end;

Since the definition of TSemaphore is in this file, this definition will
be used?

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

Re: [fpc-devel] Why FreeBSD sem_init() works different to Linux?

[Henry Vermaak]

On Mon, Feb 04, 2013 at 11:47:48AM +, Graeme Geldenhuys wrote:
> Hi,
> 
> I found another problem with Semaphores between FreeBSD and Linux.
> 
> Attached is my test project. Again, it is similar code used in tiOPF.
> 
> For some reason under FreeBSD, it *always* zeros the variable that holds
> the Max Pool Size value passed in to sem_init()'s third parameter. This
> means that if I try and us that variable anywhere after the sem_init()
> call, like when I want to destroy the semaphore, I can't because the
> variable now holds the value 0.

FPC's definition of the semaphore struct is probably wrong for FreeBSD.
Currently, it's:

sem_t = cint;

Whereas a quick google search got me here:

http://svnweb.freebsd.org/base/head/include/semaphore.h?revision=201546&view=markup

Which says sem_t should be:

struct _sem {
__uint32_t _magic;
struct _usem _kern;
};

This would explain your variable getting overwritten, I think.

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

Re: [fpc-devel] Catch a signal

[Henry Vermaak]

On Mon, Jan 28, 2013 at 12:20:30PM +0100, Michael Schnell wrote:
> So: Hot to catch a signal ?

Use FpSig* in unit BaseUnix.

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

Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries

[Henry Vermaak]

On Thu, Jan 24, 2013 at 11:07:25AM +0100, Michael Schnell wrote:
> FYI: This is the content of /opt/arm-linux-gnueabi/lib on this machine:
> 
> [/opt/lib] # ls -l

     is not the same as the path you added with -Fl.  And there
is no crti.o here.  There isn't even an "arm-linux-gnueabi" directory
here, so why did you add that path if it doesn't even exist?

Find crti.o on the device and add that path to -Fl.

> drwxr-xr-x2 adminadminist 4096 Jan  3 11:36 armv4t/
> -rwxr-xr-x1 adminadminist 7132 Feb 14  2012 e2initrd_helper*
> drwxr-xr-x3 adminadminist 4096 Jan  3 11:36 gcc/
> drwxr-xr-x3 adminadminist 4096 Jan  3 11:10 gio/
> drwxr-xr-x3 adminadminist 4096 Jan  3 11:10 glib-2.0/
> drwxr-xr-x4 adminadminist 4096 Jan  3 15:18 groff/
> drwxr-xr-x5 adminadminist 4096 Jan 21 22:52 ipkg/
> -rw-r--r--1 adminadminist  4407522 Feb 14  2012 libbfd.a
> -rwxr-xr-x1 adminadminist  937 Feb 14  2012 libbfd.la*
> lrwxrwxrwx1 adminadminist   13 Jan  3 11:10 libblkid.so
> -> libblkid.so.1*
> lrwxrwxrwx1 adminadminist   15 Jan  3 11:10
> libblkid.so.1 -> libblkid.so.1.0*
> -rwxr-xr-x1 adminadminist41080 Feb 14  2012 libblkid.so.1.0*
> -rw-r--r--1 adminadminist  209 Feb 14  2012 libc.so
> -rw-r--r--1 adminadminist20912 Feb 14  2012 libc_nonshared.a
> lrwxrwxrwx1 adminadminist   15 Jan  3 11:10
> libcom_err.so -> libcom_err.so.2*
> lrwxrwxrwx1 adminadminist   17 Jan  3 11:10
> libcom_err.so.2 -> libcom_err.so.2.1*
> -rwxr-xr-x1 adminadminist 8828 Feb 14  2012 libcom_err.so.2.1*
> -rwxr-xr-x1 adminadminist   721164 Feb 15  2012 libdb-4.2.so*
> lrwxrwxrwx1 adminadminist   12 Jan  3 11:24 libdb-4.so
> -> libdb-4.2.so*
> lrwxrwxrwx1 adminadminist   12 Jan  3 11:24 libdb.so ->
> libdb-4.2.so*
> lrwxrwxrwx1 adminadminist   11 Jan  3 11:10 libe2p.so ->
> libe2p.so.2*
> lrwxrwxrwx1 adminadminist   13 Jan  3 11:10 libe2p.so.2
> -> libe2p.so.2.3*
> -rwxr-xr-x1 adminadminist22796 Feb 14  2012 libe2p.so.2.3*
> lrwxrwxrwx1 adminadminist   14 Jan  3 11:10 libext2fs.so
> -> libext2fs.so.2*
> lrwxrwxrwx1 adminadminist   16 Jan  3 11:10
> libext2fs.so.2 -> libext2fs.so.2.4*
> -rwxr-xr-x1 adminadminist   163556 Feb 14  2012 libext2fs.so.2.4*
> lrwxrwxrwx1 adminadminist   12 Jan  3 10:29 libform.so
> -> libform.so.5*
> lrwxrwxrwx1 adminadminist   14 Jan  3 10:29 libform.so.5
> -> libform.so.5.7*
> -rwxr-xr-x1 adminadminist44884 Dec 24 06:48 libform.so.5.7*
> lrwxrwxrwx1 adminadminist   13 Jan  3 15:19 libformw.so
> -> libformw.so.5*
> lrwxrwxrwx1 adminadminist   15 Jan  3 15:19
> libformw.so.5 -> libformw.so.5.7*
> -rwxr-xr-x1 adminadminist52232 Dec 22 00:32 libformw.so.5.7*
> lrwxrwxrwx1 adminadminist   13 Jan  3 11:36 libgcc_s.so
> -> libgcc_s.so.1
> -rw-r--r--1 adminadminist   238932 Feb 15  2012 libgcc_s.so.1
> lrwxrwxrwx1 adminadminist   16 Jan  3 11:24 libgdbm.so
> -> libgdbm.so.3.0.0*
> lrwxrwxrwx1 adminadminist   16 Jan  3 11:24 libgdbm.so.3
> -> libgdbm.so.3.0.0*
> -rwxr-xr-x1 adminadminist18660 Feb 18  2012 libgdbm.so.3.0.0*
> lrwxrwxrwx1 adminadminist   23 Jan  3 11:24
> libgdbm_compat.so -> libgdbm_compat.so.3.0.0*
> lrwxrwxrwx1 adminadminist   23 Jan  3 11:24
> libgdbm_compat.so.3 -> libgdbm_compat.so.3.0.0*
> -rwxr-xr-x1 adminadminist 6188 Feb 18  2012
> libgdbm_compat.so.3.0.0*
> -rwxr-xr-x1 adminadminist 1063 Feb 14  2012 libgio-2.0.la*
> lrwxrwxrwx1 adminadminist   22 Jan  3 11:10
> libgio-2.0.so -> libgio-2.0.so.0.2000.4*
> lrwxrwxrwx1 adminadminist   22 Jan  3 11:10
> libgio-2.0.so.0 -> libgio-2.0.so.0.2000.4*
> -rwxr-xr-x1 adminadminist   415536 Feb 14  2012
> libgio-2.0.so.0.2000.4*
> -rwxr-xr-x1 adminadminist  986 Feb 14  2012 libglib-2.0.la*
> lrwxrwxrwx1 adminadminist   23 Jan  3 11:10
> libglib-2.0.so -> libglib-2.0.so.0.2000.4*
> lrwxrwxrwx1 adminadminist   23 Jan  3 11:10
> libglib-2.0.so.0 -> libglib-2.0.so.0.2000.4*
> -rwxr-xr-x1 adminadminist   842160 Feb 14  2012
> libglib-2.0.so.0.2000.4*
> -rwxr-xr-x1 adminadminist 1033 Feb 14  2012 libgmodule-2.0.la*
> lrwxrwxrwx1 adminadminist   26 Jan  3 11:10
> libgmodule-2.0.so -> libgmodule-2.0.so.0.2000.4*
> lrwxrwxrwx1 adminadminist   26 Jan  3 11:10
> libgmodule-2.0.so.0 -> libgmodule-2.0.so.0.2000.4*
> -rwxr-xr-x1 adminadminist 9960 Feb 14  2012
> libgmodule-2.0.so.0.2000.4*
> -rwxr-xr-x1 adminadminist 1028 Feb 14  2012 libgobject-2.0.la*
> lrwxrwxrwx1 adminadminist   26 Jan  3 11:10
> libgobject-2.0.so -> libgobject-2.0.so.0.2000.4*
> lrwxrwxrwx

Re: [fpc-devel] assumed bug in the RTL with ARM v5 regarding loading dynamic libraries

[Henry Vermaak]

On Wed, Jan 23, 2013 at 10:20:50AM +0100, Thomas Schatzl wrote:
> Compile with:
> 
> ppcarm -Fl/opt/arm-none-linux-gnueabi/lib test.pas

I had to do something similar when ubuntu moved to multiarch for arm,
but the path was later added in the compiler.

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

Re: [fpc-devel] "embedded" again

[Henry Vermaak]

On Tue, Jan 15, 2013 at 10:45:29AM +0100, Michael Schnell wrote:
> (c) seems the most appropriate way to allow for decent debugging
> performance, but seemingly nobody yet decently tried (or wrote
> instructions to) to get Lazarus running remote gdb via TCP/IP.

One of the options in the lazarus debugger settings is "GDB debugger
through SSH".  Remote debugging with gdb on the command line also works
well for many years.

> So I am still stuck here.

You're not "stuck".  I've been building lazarus apps natively on my arm
netbook for more than a year (first with armel, then armhf).  It's too
slow to use productively, but could be used to debug.  Modern arm
laptops (like the chromebook) should have no trouble at all.

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

Re: [fpc-devel] Feature announcement: Extension of TThread's interface

[Henry Vermaak]

On Thu, Dec 27, 2012 at 05:23:17PM +0100, Sven Barth wrote:
> - ProcessorCount (class):
> Returns the count of CPU cores detected by the RTL. This is
> based on the new global property System.GetCPUCount which needs to
> be implemented per target. Currently only a default implementation
> exists which returns "1".

On linux, this can be done with sched_getaffinity, which gives you the
number of processing units that the current process can run on.  I guess
this is the number we're looking for here?

If you need all the processors, you need to read the information under
/sys/devices/system/cpu (the topology subdirectory may be handy to
filter out HTT), possibly falling back to  /proc/stat and /proc/cpuinfo
if necessary.

Take a look at the `nproc` utility from gnu coreutils.

http://git.savannah.gnu.org/cgit/gnulib.git/tree/lib/nproc.c
http://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/getsysstats.c;h=22285f39f33bf26cd55f424ddf4f24300d0d9e72;hb=HEAD

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

Re: [fpc-devel] Forwarded message about FPC status

[Henry Vermaak]

On Mon, Dec 24, 2012 at 05:19:58PM +0100, Martin Schreiber wrote:
> BTW, I actually think about to fork Free Pascal. Not in the near future but 
> the primary goals are defined already:
> 
> - Back to the roots.

What are the roots?

> - Add the necessary to build the most productive universal programming 
> language.
> - Remove the not necessary.

Subjective, requirements differ.  I assume this definition of
"productive" and "necessary" will be dictated by you and drive other
people away from the project.  Just like e.g. your coding style has
previously.

> - Produce at least as good code as Delphi 7.
> - Compile at least as fast as Delphi 7.

You know that sacrifices need to be made to make a compiler cross
platform and easily portable.  You can't have it all.

It will be a shame to see your considerable talent wasted on another
project with a bus factor of approximately 1.

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

Re: [fpc-devel] Unhelpful error message

[Henry Vermaak]

On 03/12/12 01:19, Hans-Peter Diettrich wrote:
> message is sufficient. But a check for a third "<" definitely should be
> added to the scanner, so that a more specific error message can be issued.

Not worth the effort, in my opinion.  I understood the error message
immediately.

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

Re: [fpc-devel] Unhelpful error message

[Henry Vermaak]

On Dec 2, 2012 11:47 AM, "Mark Morgan Lloyd" <
markmll.fpc-de...@telemetry.co.uk> wrote:
>
> I've just had a slight problem compiling Lazarus where FPC was reporting
this:
>
> main.pp(5001,1) Fatal: Syntax error, "BEGIN" expected but "shl" found
>

<< is shl in c. I guess fpc accepts this syntax, too?

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

Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing

[Henry Vermaak]

On 05/11/12 13:16, Vincent Snijders wrote:
> 
> 
> 2012/10/27 Florian Klämpfl  >
> 
> 
> I added already several weeks ago the new multi-arch pathes as
> additional default search pathes to armhf-linux but since people didn't
> like this change I didn't add it for the other architectures.
> 
> How do I workaround it?
> 
> First I added -Fl/usr/lib/i386-linux-gnu to the fpc.cfg. But for
> building fpc that doesn't help, because of the -n parameter added by
> make all. So I did make all OPT="-Fl/usr/lib/i386-linux-gnu". That works
> for trunk, but not for fixes_2_6 because OPT is not passed when building
> fpmake.pp in the packages/fastcgi dir.

I remember having to add a library path to FPCMAKEOPT, for and early
debian arm multilib system.  Does this work?

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

Re: [fpc-devel] fp IDE and gdbint on Debian Wheezy/testing

[Henry Vermaak]

On Oct 27, 2012 9:18 AM, "Florian Klämpfl"  wrote:
> I added already several weeks ago the new multi-arch pathes as
> additional default search pathes to armhf-linux but since people didn't
> like this change I didn't add it for the other architectures.

Ah, this is why I didn't have to add the library path for armhf, I assumed
it was fixed for all architectures.

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

Re: [fpc-devel] Problems with fpioctl on ARM debian linux and FPC2.6

[Henry Vermaak]

On 19 June 2012 14:21, Henry Vermaak  wrote:
> Also, the buffers need to be u64.  Is the pointer type in pascal always 64 
> bit?

The answer to this is no, so you can't use pascal pointer types for the buffers.

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

Re: RE : RE : RE : [fpc-devel] Problems with fpioctl on ARM debian linuxandFPC2.6

[Henry Vermaak]

On 19 June 2012 19:42, Ludo Brands  wrote:
> So the struct should be translated as
>
> spi_ioc_transfer_t = record
>    tx_buf_ptr   : qword;
>    rx_buf_ptr   : qword;
>    len    : longword;
>    speed_hz     : longword;
>    delay_usec  : word;
>    bits_per_word : byte;
>    cs_change  : byte;
>    pad    : longword;
>  end;

Yes, or use ctypes to make it more clear.

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

Re: RE : RE : [fpc-devel] Problems with fpioctl on ARM debian linux andFPC2.6

[Henry Vermaak]

On 19 June 2012 19:02, Ludo Brands  wrote:
>
> And what is sizeof (struct spi_ioc_transfer) in c?

32.

> Because that would indicate that u64 needs to be indeed 64 bits. I have seen
> u64 defined as typedef unsigned long long for ARM.

"long" is 32 bits on my arm laptop, so that makes sense.

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

Re: RE : [fpc-devel] Problems with fpioctl on ARM debian linux and FPC2.6

[Henry Vermaak]

On 19 June 2012 18:37, Ludo Brands  wrote:
> Are you sure about the conversion (*SPI_IOC_MESSAGE(1)*) 1075866368? That is

I can confirm that a c program spits out this number for SPI_IOC_MESSAGE(1).

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

Re: [fpc-devel] Problems with fpioctl on ARM debian linux and FPC2.6

[Henry Vermaak]

On 19 June 2012 18:20, Henry Vermaak  wrote:
> Have you tried looking at errno?  Do any of the other ioctls succeed

Sorry, errno -> GetLastOSError()

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

Re: [fpc-devel] Problems with fpioctl on ARM debian linux and FPC2.6

[Henry Vermaak]

On 19 June 2012 18:04, Stefan Fischer  wrote:
> I've changed to following:
> added packrecord c
> flipped speed_hz and delay_usec fields
>
> same problem.
> I don't know whats really wrong.
> Is there any debug possibility?

Have you tried looking at errno?  Do any of the other ioctls succeed
(e.g. SPI_IOC_WR_MAX_SPEED_HZ)?  Do you have permissions to write to
this file?

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

Re: [fpc-devel] Problems with fpioctl on ARM debian linux and FPC2.6

[Henry Vermaak]

On 19 June 2012 14:17, Jonas Maebe  wrote:
>
> Stefan Fischer wrote on Tue, 19 Jun 2012:
>
>
>> My code snipet is below:
>>
>> spi_ioc_transfer_t = record
>>    tx_buf_ptr   : pointer;
>>    rx_buf_ptr   : pointer;
>>    len    : longword;
>>    delay_usec  : word;
>>    speed_hz     : longword;
>>    bits_per_word : byte;
>>    cs_change  : byte;
>>    pad    : longword;
>>  end;
>
>
> The speed_hz and delay_usec fields are switched around. Furthermore, make
> sure to add add {$packrecords C} to guarantee the same alignment as in a C
> compiler.

Also, the buffers need to be u64.  Is the pointer type in pascal always 64 bit?

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

Re: [fpc-devel] passing options for the build process.

[Henry Vermaak]

On 20 March 2012 22:42, peter green  wrote:
> The buildfaq claims that OPT= will add parameters to every compiler
> commandline. Unfortunately it doesn't seem to actually do that. The options
> are added when building the compiler and RTL but it seems they aren't added
> when building fpmake.
>
> This is a problem for me as to successfully build fpmake on a multiarch arm
> system I need to tell it where to find crti.o (it seems freepascal can
> successfully build stuff linked against c libraries without finding crti.o
> on some architectures but not others).
>
> For now i've created a symlink at /usr/lib/crti.o to
> /usr/lib/arm-linux-gnueabihf/crti.o to make things work but i'd rather not
> have to mess with my system in that way. Is there some way of specifying
> options so that they actually get passed to ALL compiler invocations in the
> build process?

I had to fiddle around like this, too, unfortunately.  Does the
compiler read fpc.cfg when it's building?  It may work when adding it
there.  Reading /etc/ld.so.conf needs to be fixed, too.  At the moment
the Makefile adds the contents to -Fl, which doesn't work when there
are wildcards.

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

Re: [fpc-devel] New less verbose compilation of trunk

[Henry Vermaak]

On 07/03/12 13:10, Jonas Maebe wrote:


On 07 Mar 2012, at 12:29, Henry Vermaak wrote:


Unfortunately, cycling the compiler is taking really long and -j 9
isn't helping much (or at all).


It can be sped up by adding proper unit dependency information in your
platform's RTL Makefile.fpc, and then removing the .NOTPARALLEL. Except
for the Darwin RTL, no RTL currently has proper dependency information.
It also won't work for the Windows RTLs, because they use build units
(which is another way to speed up things, although you can't take
advantage of any parallelism in that case without modifying the compiler).


Thanks for the information.  Do you have benchmarks of the Darwin RTL 
compilation before and after adding the dependency information?


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

Re: [fpc-devel] New less verbose compilation of trunk

[Henry Vermaak]

On 07/03/12 12:02, Marco van de Voort wrote:

In our previous episode, Henry Vermaak said:

PS:
Adding any more (if possible) parallel compilation support would be
awesome too. This already saves me over 1 minute in compile time on my
quad core. Yes, I hate it if CPU's just sit idle.


IIRC add  FPMAKEOPT='-T 3'   (3= number of paralel threads)


This makes a big difference for me:

Without FPCMAKEOPT: 1m48.056s
With FPCMAKEOPT="-T 9": 1m13.833s

Unfortunately, cycling the compiler is taking really long and -j 9 isn't
helping much (or at all).


fpmake only handles packages/.

fpmake (or make -j the way FPC used it in the past) can't really speed up
runs that are a single compiler invocation (like the compiler), unless it
can run two such runs in paralel.

In packages this is possible, in the compiler cycle compiler depends on RTL,
and the "next" rtl depends on the "previous" compiler, so nothing can be
done there.

To exploit paralellism in single compiler invocations, threading should be
brought into the compiler, but that is an huge and uncertain job.


With c, the compilation of .c -> .o  is isolated, so many of them can be 
run in parallel, which means that compiling e.g. the linux kernel, you 
get great performance from make -j %d.  Is it possible to have fpc do 
the same thing somehow?  Bringing threading into the compiler sounds 
very scary, indeed.


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

Re: [fpc-devel] New less verbose compilation of trunk

[Henry Vermaak]

On 07/03/12 10:27, Marco van de Voort wrote:

In our previous episode, Graeme Geldenhuys said:

PS:
Adding any more (if possible) parallel compilation support would be
awesome too. This already saves me over 1 minute in compile time on my
quad core. Yes, I hate it if CPU's just sit idle.


IIRC add  FPMAKEOPT='-T 3'   (3= number of paralel threads)


This makes a big difference for me:

Without FPCMAKEOPT: 1m48.056s
With FPCMAKEOPT="-T 9": 1m13.833s

Unfortunately, cycling the compiler is taking really long and -j 9 isn't 
helping much (or at all).


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

Re: [fpc-devel] Stack alignment on i386

[Henry Vermaak]

On 18/12/11 12:37, Den Jean wrote:

Hi,

to interface with c libraries containing SSE code,
the stack must be aligned to 16 bytes.

Currently the default -mpreferred-stack-boundary=num of gcc provides for this.

However current fpc 2.4.4 does not align the stack as such.
I do not know if this correct or not when reading things like:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838#c8
http://groups.google.com/group/ia32-abi/browse_thread/thread/4f9b3e5069943bf1



Ow, we hit this problem.  We are calling a library that uses opencv 
(where SSE instructions are used).  Luckily we can add -mstackrealign to 
the CFLAGS of our library.  People without an "interface" lib will be in 
trouble, though.


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

Re: [fpc-devel] Determin file size - how?

[Henry Vermaak]

On 19/12/11 10:40, Marco van de Voort wrote:

In our previous episode, Henry Vermaak said:

something I can maintain, advanced searching [which is super fast],


All that was available for CHM too, PLUS the generation facilities.


There seems to be some great tools for chm in the debian repo.  One of
the apps (archmage) can even serve chm contents on an http server
(standalone or apache).


I don't like using full browsers for help. They are relatively slow and
don't provide as convenient access to the parts that make a helpsystems
a helpsystem (index, TOC, search).


Yes, it's definitely not ideal.  I do like having tabs of multiple help 
topics open at the same time, though.


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

Re: [fpc-devel] Determin file size - how?

[Henry Vermaak]

On 19/12/11 10:12, Marco van de Voort wrote:

gave me full control: the programming language I know and love,
something I can maintain, advanced searching [which is super fast],


All that was available for CHM too, PLUS the generation facilities.


There seems to be some great tools for chm in the debian repo.  One of 
the apps (archmage) can even serve chm contents on an http server 
(standalone or apache).


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

Re: [fpc-devel] NowUTC in the RTL

[Henry Vermaak]

On 09/12/11 15:40, Marco van de Voort wrote:

In our previous episode, Henry Vermaak said:

them, instead of pulling this into the core. (iow, like the users package)


I don't understand.  Why link to libc for these?  They are syscalls, if


Are they? On any OS and arch that calls itself posix or unix?


That's a question, not an answer.  We have a linux unit, for instance.


Or maybe, the question should be the opposite, why not? Why shouldn't such
peripheral calls NOT be taken from libc?


Because you don't have to link to libc when you have a syscall?

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

Re: [fpc-devel] NowUTC in the RTL

[Henry Vermaak]

On 09/12/11 15:23, Marco van de Voort wrote:

In our previous episode, Michael Van Canneyt said:


No problem.
I will do it so, I was leaning to this anyway based on the mails of Zeljko some
weeks back where the OSX issue was already touched upon.

I just wanted to know the POSIX situation first, and now that's cleared up.


Btw, you'll need clock_getres too, to get the granularity of the relevant
timer. (and anything using these, should really use that function)

Still I think it is better to put this in a package, and link to libc for
them, instead of pulling this into the core. (iow, like the users package)


I don't understand.  Why link to libc for these?  They are syscalls, if 
I'm not missing something.


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

Re: [fpc-devel] NowUTC in the RTL

[Henry Vermaak]

On 09/12/11 15:15, Sven Barth wrote:

Am 09.12.2011 15:22, schrieb Michael Schnell:

On 12/09/2011 02:52 PM, Sven Barth wrote:


The description of Felipe mathes Windows' GetTickCount (number of
milliseconds since system start) and Linux' MONOTONIC_RAW time (or
however it is called exactly). So I don't see why this should rule out
OS time API calls...


He writes: " Ticks are time intervals and all of them have the same
duration "

So the counting is not allowed to stop or to jump forward in case a time
server access by daemon changing the system time is not allowed to
interfere in any way.

So I suppose "GetTickCount (number of milliseconds since system start)"
would be OK, but MONOTONIC_RAW time does not _sound_ correct.


I haven't found an entry for "MONOTONIC_RAW" (my system's manpage has
one, but I'm currently at work), but for MONOTONIC:

CLOCK_MONOTONIC
Clock that cannot be set and represents monotonic time since some
unspecified starting point.

So even if a deamon plays around with the time the MONOTONIC clock
should not be affected. That's the basic idea of the MONOTONIC clocks.


MONOTONIC can still be affected by NTP, MONOTONIC_RAW can't.

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

Re: [fpc-devel] NowUTC in the RTL

[Henry Vermaak]

On 09/12/11 14:22, Michael Schnell wrote:

On 12/09/2011 02:52 PM, Sven Barth wrote:


The description of Felipe mathes Windows' GetTickCount (number of
milliseconds since system start) and Linux' MONOTONIC_RAW time (or
however it is called exactly). So I don't see why this should rule out
OS time API calls...


He writes: " Ticks are time intervals and all of them have the same
duration "

So the counting is not allowed to stop or to jump forward in case a time
server access by daemon changing the system time is not allowed to
interfere in any way.

So I suppose "GetTickCount (number of milliseconds since system start)"
would be OK, but MONOTONIC_RAW time does not _sound_ correct.

On Linux, "get_jiffies_64()" seems to be a decent Kernel call.


You can't use this in userspace.

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

Re: [fpc-devel] NowUTC in the RTL

[Henry Vermaak]

On 09/12/11 14:02, Michael Van Canneyt wrote:



On Fri, 9 Dec 2011, Felipe Monteiro de Carvalho wrote:


Hello,

How can one call clock_gettime ? I couldn't find a fp prefixed routine
for it ...


I have this on my todo list.

The main problem is that I don't know yet if it is Linux-specific or Posix.
That will determine which unit it will be added to. Maybe Marco knows
more ?


The man page says it's POSIX:

http://www.kernel.org/doc/man-pages/online/pages/man2/clock_gettime.2.html#CONFORMING_TO

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

[fpc-devel] Re: crti.o problem

[Henry Vermaak]

On 8 November 2011 14:51, Henry Vermaak  wrote:
> On 8 November 2011 14:38, Henry Vermaak  wrote:
>> Sorry, bad assumption, it's not the compiler.  Fpcmake adds all the
>> entries in /etc/ld.so.conf, which gets added in turn to -Fl option(s).
>>  The problem is that the entries in /etc/ld.so.conf may contain
>> wildcards.  Using $(wildcard $var) won't work if the entry doesn't
>> contain a pattern, though, so each entry will have to be checked for
>> wildcards.
>
> Actually, a solution would be to add this to fpcmake.ini:
>
> OTHERLIBDIR += $(wildcard $(OTHERLIBDIR))
>
> This is a bit dirty, since the wildcard will still be passed to -Fl,
> which will ignore it, presumably.  A better solution would of course
> be to enable -Fl to accept wildcards.

Sigh, none of this will work, since, /etc/ld.so.conf here contains a
wildcard of files (with an "include" in front), which in turn contains
directories.  Fpcmake assumes that /etc/ld.so.conf contains
directories.  Is this already solved in fpmake?

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

[fpc-devel] Re: crti.o problem

[Henry Vermaak]

On 8 November 2011 14:38, Henry Vermaak  wrote:
> Sorry, bad assumption, it's not the compiler.  Fpcmake adds all the
> entries in /etc/ld.so.conf, which gets added in turn to -Fl option(s).
>  The problem is that the entries in /etc/ld.so.conf may contain
> wildcards.  Using $(wildcard $var) won't work if the entry doesn't
> contain a pattern, though, so each entry will have to be checked for
> wildcards.

Actually, a solution would be to add this to fpcmake.ini:

OTHERLIBDIR += $(wildcard $(OTHERLIBDIR))

This is a bit dirty, since the wildcard will still be passed to -Fl,
which will ignore it, presumably.  A better solution would of course
be to enable -Fl to accept wildcards.

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

[fpc-devel] Re: crti.o problem

[Henry Vermaak]

On 8 November 2011 13:56, Henry Vermaak  wrote:
> Hi list
>
> I've got a problem with crti.o not being found when compiling certain
> programs.  Here's an example:
>
> /usr/local/lib/fpc/2.6.0/ppcarm -gl  -Fu. -Fu../lcl/units/arm-linux
> -Fu../components/lazutils/lib/arm-linux -Fu../lcl/units/arm-linux/gtk2
> -Fu/usr/local/lib/fpc/2.6.0/units/arm-linux/rtl -FE. -FU.
> -Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -Flinclude
> -Fl/etc/ld.so.conf.d/*.conf -CfSOFT -darm svn2revisioninc.pas
> Free Pascal Compiler version 2.6.0rc1 [2011/11/08] for arm
> Copyright (c) 1993-2011 by Florian Klaempfl and others
> Target OS: Linux for ARMEL
> Compiling svn2revisioninc.pas
> Assembling svn2revisioninc
> Linking ./svn2revisioninc
> /usr/bin/ld: warning: ./link.res contains output sections; did you forget -T?
> /usr/local/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function
> `_haltproc_eabi':
> (.text+0x88): undefined reference to `_fini'
> /usr/local/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function
> `_haltproc_eabi':
> (.text+0x90): undefined reference to `_init'
>
> When I add -Fl/usr/lib/arm-linux-gnueabi, the linking succeeds.  It
> seems like the -Fl/etc/ld.so.conf.d/*.conf option that gets added by
> the compiler should work, since I've got the following under

Sorry, bad assumption, it's not the compiler.  Fpcmake adds all the
entries in /etc/ld.so.conf, which gets added in turn to -Fl option(s).
 The problem is that the entries in /etc/ld.so.conf may contain
wildcards.  Using $(wildcard $var) won't work if the entry doesn't
contain a pattern, though, so each entry will have to be checked for
wildcards.

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

[fpc-devel] crti.o problem

[Henry Vermaak]

Hi list

I've got a problem with crti.o not being found when compiling certain
programs.  Here's an example:

/usr/local/lib/fpc/2.6.0/ppcarm -gl  -Fu. -Fu../lcl/units/arm-linux
-Fu../components/lazutils/lib/arm-linux -Fu../lcl/units/arm-linux/gtk2
-Fu/usr/local/lib/fpc/2.6.0/units/arm-linux/rtl -FE. -FU.
-Fl/usr/lib/gcc/arm-linux-gnueabi/4.6.1 -Flinclude
-Fl/etc/ld.so.conf.d/*.conf -CfSOFT -darm svn2revisioninc.pas
Free Pascal Compiler version 2.6.0rc1 [2011/11/08] for arm
Copyright (c) 1993-2011 by Florian Klaempfl and others
Target OS: Linux for ARMEL
Compiling svn2revisioninc.pas
Assembling svn2revisioninc
Linking ./svn2revisioninc
/usr/bin/ld: warning: ./link.res contains output sections; did you forget -T?
/usr/local/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function
`_haltproc_eabi':
(.text+0x88): undefined reference to `_fini'
/usr/local/lib/fpc/2.6.0/units/arm-linux/rtl/cprt0.o: In function
`_haltproc_eabi':
(.text+0x90): undefined reference to `_init'

When I add -Fl/usr/lib/arm-linux-gnueabi, the linking succeeds.  It
seems like the -Fl/etc/ld.so.conf.d/*.conf option that gets added by
the compiler should work, since I've got the following under
/etc/ld.so.conf.d (among other files):

hcv@hcv-ac100:~/source/lazarus$ cat /etc/ld.so.conf.d/arm-linux-gnueabi.conf
# Multiarch support
/lib/arm-linux-gnueabi
/usr/lib/arm-linux-gnueabi

But perhaps this isn't working as expected.  Any ideas?

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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 02/11/11 13:38, zeljko wrote:



Please see results about Now() and something that I've mentioned about
deprecitation of gettimeofday().According to this test, current
fpgettimeofday() is crap when compared with clock_gettime() (kernel) or
libc calls (I've copied scenario from kylix sysutils).


*Kernel clock_gettime() NowReal() with 1000 calls = 4870 ms

**Libc gettimeofday()+localtime_r() with 1000 calls = 5085 ms

***RTL Now() with 1000 calls = 7659 ms ?!?!?!? Slowest !?!?


So fpc rtl is slower even _without_ the stat call in localtime.

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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 01/11/11 22:01, Marco van de Voort wrote:

But do you agree that _when_ it happens, the directory is rescanned in the same
thread as the gettime() call, outside programmer's control? And that that
breaks code for people that don't expect the runtime to access the harddisk
without they explicitely solicating that? (e.g. to preserve some realtime
behaviour(*))?


(I presume that the * here means "insert your definition here").  This 
is exactly your problem, _assuming_ that you can get any realtime 
behaviour out of this call.  If you need that, use performance counters.



If it's more important to you to be
fast than correct, then you can weigh up the risks yourself, just
don't force it upon all the users of the freepascal compiler.


That is an symmetrical argument. I could argue exactly the same about
correctness. I don't need it, so please don't force it on all users.


No, it's not balanced.  Most users would not like to go out of their way 
to make a broken implementation correct.  Most users are willing, 
however, to go out of their way to make something perform better if they 
need it.


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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 1 November 2011 21:07, Marco van de Voort  wrote:
> In our previous episode, Henry Vermaak said:
>> Also, how cheap is this on Windows?  Presumably they will also have to
>> deal with potential system services running while updates fix daylight
>> saving time changes?  If they don't use shared memory for this, I'd
>> wager that it's just as slow as libc localtime.
>
> I doubt Windows has a _file_ based concept of timezone.

Explain?

>> I don't think the definition of "acceptable" for the RTL should be "may
>> be wrong in corner cases, as long as it's fast".  I'm sure you'd agree.
>
> As Michael explained there are multiple usecases for gettime like
> functionality.
>
> And I agree with him (if only because my business app would break horribly.
> Worse, if my business app ran on Linux, rescanning the timezone files in
> a thread that called gettime would probably violate realtime constraints and
> our quality assurance app would eject valid products because of unexpected
> latency due to unforseen harddisk access.

Do you even understand how this works on linux?  'localtime' stats the
file to see if the timestamp has changed, only then does it reload
from the file.  It doesn't read the file every time.  If you're timing
things, you are doing it wrong.  If it's more important to you to be
fast than correct, then you can weigh up the risks yourself, just
don't force it upon all the users of the freepascal compiler.

I appear to be wasting my time if two rtl developers can even consider
that giving possible erroneous results is an option.

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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 01/11/11 12:51, Michael Van Canneyt wrote:

On Tue, 1 Nov 2011, Henry Vermaak wrote:

If you don't do this, daemons that were started before e.g. a daylight
savings update will report the wrong time after the update. Rather
solve this correctly than take short cuts because you want to keep the
time functions "fast". Someone can always add performance timing
helpers that use the correct functions on various OSes.


The problem with that is that a LOT of existing code contains many calls
to Now() and Date(), because these calls are very cheap on Windows. If
all these calls will suddenly cause a stat() of /etc/localtime, that's
simply not acceptable, since that will cause a noticeable error in your
reported time, as disk access is very slow and dependent on system load.


This is just speculation.  There will always be an error in the reported 
time, these calls are not atomic.  It would be slower doing a stat, yes, 
but saying that the error will be "noticeable" I will leave for you to 
prove.


Also, how cheap is this on Windows?  Presumably they will also have to 
deal with potential system services running while updates fix daylight 
saving time changes?  If they don't use shared memory for this, I'd 
wager that it's just as slow as libc localtime.


I don't think the definition of "acceptable" for the RTL should be "may 
be wrong in corner cases, as long as it's fast".  I'm sure you'd agree.


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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 01/11/11 11:08, Michael Van Canneyt wrote:



On Tue, 1 Nov 2011, Henry Vermaak wrote:


On 01/11/11 10:30, Michael Van Canneyt wrote:

We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If we decide to add some check for the timestamp of
the timezone file - that would make Date(), Time() and Now() VERY
expensive operations.


This seems to be what libc does (from looking at an strace of some gcc
binary).


Correct (I had checked as well), but the only purpose that serves is to
check whether the system timezone info has changed.

This is something that normally doesn't happen unless you move your
system from one timezone to another or during system setup, so I
question the desirability of this check.


If you don't do this, daemons that were started before e.g. a daylight 
savings update will report the wrong time after the update.  Rather 
solve this correctly than take short cuts because you want to keep the 
time functions "fast".  Someone can always add performance timing 
helpers that use the correct functions on various OSes.


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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 01/11/11 10:30, Michael Van Canneyt wrote:

We'll simply need to store the next moment when the DST correction
changes, compare the result of gettimeofday with that and re-base the
time calculation. If we decide to add some check for the timestamp of
the timezone file - that would make Date(), Time() and Now() VERY
expensive operations.


This seems to be what libc does (from looking at an strace of some gcc 
binary).


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

Re: [fpc-devel] Problem with Now() and time changed by ntpd

[Henry Vermaak]

On 01/11/11 10:01, Sven Barth wrote:

On 01.11.2011 09:41, zeljko wrote:

I don't believe that kernel have only gettimeofday() and that kernel
don't know accurate datetime. There's more functions in kernel which can
give you accurate result. gettimeofday() is deprecated, so maybe that's
main reason why it fails to give correct result with daylight changes.


Out of curiosity: Where did you get that gettimeofday is deprecated?


http://www.kernel.org/doc/man-pages/online/pages/man2/gettimeofday.2.html#CONFORMING_TO
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] alignment warnings

[Henry Vermaak]

On 1 October 2011 09:24, Florian Klämpfl  wrote:
> Am 30.09.2011 11:44, schrieb Henry Vermaak:
>>
>> Hi list
>>
>> Thinking more about the alignment problems on arm and elsewhere, I was
>> wondering how hard it would be to implement something like gcc's
>> -Wcast-align. Here's a description from the man page:
>>
>> Warn whenever a pointer is cast such that the required alignment of the
>> target is increased. For example, warn if a "char *" is cast to an "int
>> *" on machines where integers can only be accessed at two- or four-byte
>> boundaries.
>
> The problem with such warnings is that one cannot get easily rid of them.
> Maybe a hint would be more suitable.

Yes, probably, you would want to switch this off most of the time, I
guess.  Is this hard to implement?

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

Re: [fpc-devel] alignment warnings

[Henry Vermaak]

On 30/09/11 10:52, Martin wrote:

On 30/09/2011 10:44, Henry Vermaak wrote:

Hi list

Thinking more about the alignment problems on arm and elsewhere, I was
wondering how hard it would be to implement something like gcc's
-Wcast-align. Here's a description from the man page:

Warn whenever a pointer is cast such that the required alignment of
the target is increased. For example, warn if a "char *" is cast to an
"int *" on machines where integers can only be accessed at two- or
four-byte boundaries.


Why limit it to "on machines where ... can only be accessed at ...
boundaries".
If code is written for multiply platforms, then the implementor may be
on a machine where the cast is allowed, and needs no warning, but soon
as the code is compiled on a different architecture, the warnings come up.
It would be good, if one could also enable warnings for code, that may
have issues on other platforms


Because you may be writing code that's specific to a platform?  I guess 
you can have another option that will warn on all machines.


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

[fpc-devel] alignment warnings

[Henry Vermaak]

Hi list

Thinking more about the alignment problems on arm and elsewhere, I was 
wondering how hard it would be to implement something like gcc's 
-Wcast-align.  Here's a description from the man page:


Warn whenever a pointer is cast such that the required alignment of the 
target is increased.  For example, warn if a "char *" is cast to an "int 
*" on machines where integers can only be accessed at two- or four-byte 
boundaries.


This would really help to catch problematic code before things get out 
of hand and you have to wait for segfault/sigbus before you know where 
the problems are.


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

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

[Henry Vermaak]

On 22/09/11 11:23, Thomas Schatzl wrote:


That is a known issue with 2.4.4 that it does not compile trunk with
optimization turned on. There seems to be a bug that has been existing
for a long time that has been triggered by code changes in 18230; the
ARM compiler is not as well maintained as others.

I think 2.4.4 definitely builds when specifying -O- as extra build
options though. I am working on it, however I fear that -O- will need to
be set for some time.


I think it breaks for me even if optimizations are turned off, but I'll 
double check.



@henry: thanks for finding the revision when compilation broke.


The revision I gave is just my last known good compile.  I can try and 
bisect if that'll be useful.


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

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

[Henry Vermaak]

On 22/09/11 11:04, Florian Klaempfl wrote:

Am 22.09.2011 11:51, schrieb Henry Vermaak:

On 22 September 2011 10:26, Mark Morgan Lloyd
  wrote:

I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then
have moved it between local machines as a binary. I can confirm that 2.4.4
will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk.


I got 2.4.4 here:

ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/

Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without problems.


Toshiba AC100 is armel (arm eabi) while fpc arm-linux (arm oabi)? While
this might work under certain circumstances, I wouldn't bet on it.


2.4.4 ppcarm seems to be eabi:

hcv@technical09:~/Desktop$ readelf -h arm-linux-ppcarm | grep Flags
  Flags: 0x402, has entry point, 
Version4 EABI


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

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

[Henry Vermaak]

On 22 September 2011 10:26, Mark Morgan Lloyd
 wrote:
> I got from there to 2.4 via (I think) 2.5 with Jonas's help, and since then
> have moved it between local machines as a binary. I can confirm that 2.4.4
> will build FPC trunk (2.7.1) on ARM, and that that can build Lazarus trunk.

I got 2.4.4 here:

ftp://ftp.freepascal.org/pub/fpc/dist/2.4.4/bootstrap/

Maybe we should upload your 2.4.4 ppcarm if it compiles trunk without problems.

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

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

[Henry Vermaak]

On 22 September 2011 10:28, Sven Barth  wrote:
> Am 22.09.2011 11:26, schrieb Henry Vermaak:
>>
>> On 22/09/11 09:53, Sven Barth wrote:
>>>
>>> The second case is interesting indeed. It's a pity that we don't know
>>> what failed exactly in the compile... one would need a 2.4.4 with
>>> included debug information for that.
>>
>> If I were to build one, what can be done to remedy the problem? This is
>> what I meant by saying "I don't know how the fpc team deals with
>> this..."
>
> In that case the debug trace would contain the line information and thus the
> problematic code could be spotted and probably fixed (normally in 2.4.5, 2.6
> and trunk, if the error exists till today).

Yes, thanks, I know how line information works.  Maybe I should state
my question more bluntly:  What is the point of debugging and old
compiler?
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] ARM native compilation (Toshiba AC100)

[Henry Vermaak]

On 22/09/11 09:53, Sven Barth wrote:

The second case is interesting indeed. It's a pity that we don't know
what failed exactly in the compile... one would need a 2.4.4 with
included debug information for that.


If I were to build one, what can be done to remedy the problem?  This is 
what I meant by saying "I don't know how the fpc team deals with

this..."

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