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

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

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

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.micr

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

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

[fpc-devel] JWA 64-bit struct packing

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

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

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

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

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 > >

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

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

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

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

Re: [fpc-devel] NowUTC in FPC

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 > >

Re: [fpc-devel] NowUTC in FPC

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

Re: [fpc-devel] NowUTC in FPC

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

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

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: > > > >

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

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

Re: [fpc-devel] TProcess empty parameter

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

Re: [fpc-devel] TProcess empty parameter

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

Re: [fpc-devel] TProcess empty parameter

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

Re: [fpc-devel] TThread extensions

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

Re: [fpc-devel] ARM FP calling convention

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

Re: [fpc-devel] pthread scheduler attributes

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

Re: [fpc-devel] pthread scheduler attributes

On Tue, Dec 10, 2013 at 02:39:12PM +0100, Sven Barth wrote: Am 10.12.2013 12:51 schrieb Henry Vermaak henry.verm...@gmail.com: 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

Re: [fpc-devel] FPC 2.6.2.

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

Re: [fpc-devel] TCustomApplication

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

Re: [fpc-devel] TCustomApplication

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

Re: [fpc-devel] TCustomApplication

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

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

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

[fpc-devel] TThread.WaitFor delay

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

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

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

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

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

Re: [fpc-devel] Delphi anonymous methods

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

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

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

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

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

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

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

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

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

Re: [fpc-devel] Delphi anonymous methods

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

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

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

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

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

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

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

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

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

Re: [fpc-devel] Summer of code collaboration

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

Re: [fpc-devel] Summer of code collaboration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Re: [fpc-devel] Catch a signal

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

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

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

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

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

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

Re: [fpc-devel] Unhelpful error message

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

Re: [fpc-devel] Unhelpful error message

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

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

On 05/11/12 13:16, Vincent Snijders wrote: 2012/10/27 Florian Klämpfl flor...@freepascal.org mailto:flor...@freepascal.org 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

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

On Oct 27, 2012 9:18 AM, Florian Klämpfl flor...@freepascal.org 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

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

On 19 June 2012 14:17, Jonas Maebe jonas.ma...@elis.ugent.be 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     :

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

On 19 June 2012 18:04, Stefan Fischer sfisc...@basis.biz 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

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

On 19 June 2012 18:20, Henry Vermaak henry.verm...@gmail.com 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

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

On 19 June 2012 18:37, Ludo Brands ludo.bra...@free.fr 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 -

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

On 19 June 2012 19:02, Ludo Brands ludo.bra...@free.fr 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

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

On 19 June 2012 19:42, Ludo Brands ludo.bra...@free.fr 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

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

On 19 June 2012 14:21, Henry Vermaak henry.verm...@gmail.com 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

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

On 20 March 2012 22:42, peter green plugw...@p10link.net 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

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

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

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

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

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

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

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

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

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

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

Re: [fpc-devel] Stack alignment on i386

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

Re: [fpc-devel] NowUTC in the RTL

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

Re: [fpc-devel] NowUTC in the RTL

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

Re: [fpc-devel] NowUTC in the RTL

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

Re: [fpc-devel] NowUTC in the RTL

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,

Re: [fpc-devel] NowUTC in the RTL

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

[fpc-devel] crti.o problem

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

[fpc-devel] Re: crti.o problem

On 8 November 2011 13:56, Henry Vermaak henry.verm...@gmail.com 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

[fpc-devel] Re: crti.o problem

On 8 November 2011 14:38, Henry Vermaak henry.verm...@gmail.com 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

[fpc-devel] Re: crti.o problem

On 8 November 2011 14:51, Henry Vermaak henry.verm...@gmail.com wrote: On 8 November 2011 14:38, Henry Vermaak henry.verm...@gmail.com 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

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

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

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

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).

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

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

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

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(),

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

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

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

On 1 November 2011 21:07, Marco van de Voort mar...@stack.nl 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

Re: [fpc-devel] alignment warnings

On 1 October 2011 09:24, Florian Klämpfl flor...@freepascal.org 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

[fpc-devel] alignment warnings

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.

Re: [fpc-devel] alignment warnings

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

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

On 22/09/11 08:28, Sven Barth wrote: Am 21.09.2011 22:45, schrieb Henry Vermaak: On 20 September 2011 12:18, Henry Vermaakhenry.verm...@gmail.com wrote: On 20 September 2011 11:55, Sash0kvodka_pl...@mail.ru wrote: So, what can I do next? My goal is get stable fpc + mseide for Toshiba AC100

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

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

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

On 22 September 2011 10:28, Sven Barth pascaldra...@googlemail.com 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

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

On 22 September 2011 10:26, Mark Morgan Lloyd markmll.fpc-de...@telemetry.co.uk 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

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

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

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

On 20 September 2011 12:18, Henry Vermaak henry.verm...@gmail.com wrote: On 20 September 2011 11:55, Sash0k vodka_pl...@mail.ru wrote: So, what can I do next? My goal is get stable fpc + mseide for Toshiba AC100 device. I've built fpc trunk successfully on my AC100.  I will check which

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

On 20 September 2011 11:55, Sash0k vodka_pl...@mail.ru wrote: So, what can I do next? My goal is get stable fpc + mseide for Toshiba AC100 device. I've built fpc trunk successfully on my AC100. I will check which revision worked tonight. Henry ___

Re: [fpc-devel] bounty: FPC based debugger

On 12/09/11 12:00, Martin Schreiber wrote: And a FPC only debugger can not debug linked c libraries which we can do Good point. I've found this very handy in the past. currently with gdb. And think of the remote debugging options gdb provides with many targets. Another one very handy for

Re: [fpc-devel] Building without the fp IDE

On 09/09/11 13:34, Mark Morgan Lloyd wrote: Is there a correct way of telling the build process to skip the fp IDE? I'm trying to build trunk for SPARC so I can test the two recent FPC fixes plus another in Lazarus and am getting an error when building fp which I'd rather not stop to look at

Re: [fpc-devel] serial under linux, SerOpen blocks

On 18/08/11 10:34, Armin Diehl wrote: Hi Peter, that is the same as in the standard serial.pp: Result := fpopen(DeviceName, O_RDWR or O_NOCTTY); and this fpopen will block as long as minicom is not started on that device. Try to add O_NONBLOCK to the flags with fpopen. Then set CLOCAL like

Re: [fpc-devel] serial under linux, SerOpen blocks

On 18/08/11 11:21, Marco van de Voort wrote: In our previous episode, Armin Diehl said: should that be changed in the standard serial.pp ? I'm not sure, since this leaves nonblocking behaviour on by default, moreover serial is pan unix, and non linuxes might react differently. No it

Re: [fpc-devel] serial under linux, SerOpen blocks

On 18/08/11 12:00, Armin Diehl wrote: Hi Marco, minicom calls open with O_NONBLOCK and resets O_NONBLOCK directly after the open call: open(/dev/ttyUSB0, O_RDWR|O_NOCTTY|O_NONBLOCK) = 3 fcntl(3, F_GETFL) = 0x8802 (flags O_RDWR|O_NONBLOCK|O_LARGEFILE) fcntl(3, F_SETFL, O_RDWR|O_LARGEFILE) = 0

Re: [fpc-devel] serial under linux, SerOpen blocks

On 18/08/11 14:11, Mark Morgan Lloyd wrote: But why have I not seen this problem on Debian despite having used this unit extensively? And why have I not seen it when testing the modified unit on Solaris with the SerOpen() function being unchanged? Some serial ports seem to have clocal unset,

  1   2   3   >