Re: [fpc-pascal] lnet for TCP daemon
Conclusion: Thus we could draft a "living noGUI" TCustomApplication sibling (aka "LCL WidgetType"), that allows for firing MainThread Events triggered from (a newly implemented) TTimer, TThread.Queue(), TThread.Synchronize(), TApplication.QueueAsyncCall() and the legacy windowish PostMessage() -> "procedure..message" mechanism in a low latency and low processor-overhead way: - The Application Object contains a MainLoop simply calling CheckSynchronize() - TTimer is implemented including defining the timeout constant for calls to CheckSynchronize() as the greatest common denominator of the "Time" property of all enabled TTimer instances in the project (i.e. a simple timer that accumulates delays imposed by MainThread activities) - TThread.Queue() and TThread.Synchronize() seemingly just work - TApplication.QueueAsyncCall() and PostMessage() could be implemented using "NotifyMainThread()" (and maybe slightly enhancing the queuing and de-queuing mechanism provided in the RTL for additionally allowing for this type of Events, containing procedure pointer, self-pointer and an Integer that can be pointer to a parameter or holds the Windows-Message parameters. ) This would provide the mechanism for porting "embedded" (thus without GUI - or with the GUI configured as "disabled" at compile time) Delphi applications to non-GUI Linux gadgets. It is really frustrating to see, that this now seems to solves the issue I am hunting for since some five years. Over the time, there had been multiple discussions on this, initially in the fpc devel mailing list and later in the Lazarus devel mailing list. Up till now, I never was told "this already works" or "this is easy" (followed by a decent description - such as yours - of CheckSynchronize() and WakeMainThread(). Instead I was told that I should look at the LCL source code and that "in Windows, the Event queuing mechanism is done by Windows itself and in Linux it is done by a queue in the LCL that is managed by the underlying Widget Set". This (some years ago) misled me to invest a considerable amount of time in unsuccessfully trying to strip off the GUI binding from an existing LCL Widget Type. Unfortunately until end of this year I will am busy with a complicated (non pascal and not even Linux) project and I'll be not able to do some other programming work (and hopefully provide a patch enabling the functionality described above). But If somebody wants we can go on discussing the issue here, at "fpc devel" or at "lazarus devel". Thanks for listening, -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 18.09.2013 09:32, Michael Schnell wrote: - TTimer is implemented including defining the timeout constant for calls to CheckSynchronize() as the greatest common denominator of the "Time" property of all enabled TTimer instances in the project (i.e. a simple timer that accumulates delays imposed by MainThread activities) I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 09:53 AM, Sven Barth wrote: I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Right you are. (I just wanted to keep this as simple as possible for a starter.) You simply could use a sleep in the timer loop,. This would be arch independent out of the box. But it would impose accumulative delays depending on the CPU performance. An more advanced timer implementation would use arch depending OS-based timers. This would allow for a much more exact timing. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013 09:32:54 +0200 Michael Schnell wrote: >[...] > It is really frustrating to see, that this now seems to solves the issue > I am hunting for since some five years. Has it ever come to your mind that "hunting" might not be sufficient to create code? > Over the time, there had been > multiple discussions on this, initially in the fpc devel mailing list > and later in the Lazarus devel mailing list. Up till now, I never was > told "this already works" or "this is easy" (followed by a decent > description - such as yours - of CheckSynchronize() See for example: http://lists.lazarus.freepascal.org/pipermail/lazarus/2012-August/075593.html > and > WakeMainThread(). Instead I was told that I should look at the LCL > source code and that "in Windows, the Event queuing mechanism is done by > Windows itself and in Linux it is done by a queue in the LCL that is > managed by the underlying Widget Set". This is true for PostMessage. > This (some years ago) misled me > to invest a considerable amount of time in unsuccessfully trying to > strip off the GUI binding from an existing LCL Widget Type. There are many ways to implement timers and queues. But if you want the whole event system of the LCL then you need do more. Have you ever asked how to program a timer in a console application on this list? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 18.09.2013 10:00, Michael Schnell wrote: On 09/18/2013 09:53 AM, Sven Barth wrote: I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Right you are. (I just wanted to keep this as simple as possible for a starter.) You simply could use a sleep in the timer loop,. This would be arch independent out of the box. But it would impose accumulative delays depending on the CPU performance. I would not use Sleep as you need to be able to cancel the timer (e.g. Timer.Enabled := False or the application terminating). At least on *nix based systems you'd need to artificially send a signal which is why I'd prefer the event way which you can simply set in SetEnabled and Free. An more advanced timer implementation would use arch depending OS-based timers. This would allow for a much more exact timing. Of course. The timer component should be written in a way that it can be implemented in a platform specific way as well. Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013, Sven Barth wrote: On 18.09.2013 09:32, Michael Schnell wrote: - TTimer is implemented including defining the timeout constant for calls to CheckSynchronize() as the greatest common denominator of the "Time" property of all enabled TTimer instances in the project (i.e. a simple timer that accumulates delays imposed by MainThread activities) I wouldn't use the timeout constant for this. If you have two timers of which the greatest common denominator is 1, but nevertheless rather large (e.g. two primes) then you'd loop unnecessarily (I know this is a constructed example, but nevertheless one should care for this!). I'd instead suggest to implement the timerloop of each timer as a thread that waits its timeout time on a event (so that it can also be stopped) and then notifies the mainthread using Queue(). Preferably, a standard timer implementation does not use a thread at all. The fptimer unit implements a timer with a thread, but this forces the use of threads on your application which is not always desirable. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:05 AM, Mattias Gaertner wrote: On Wed, 18 Sep 2013 09:32:54 +0200 Michael Schnell wrote: [...] Instead I was told that I should look at the LCL source code and that "in Windows, the Event queuing mechanism is done by Windows itself and in Linux it is done by a queue in the LCL that is managed by the underlying Widget Set". This is true for PostMessage. (and supposedly for Application.QueueAsyncCall) Of course I do know this and this is what makes it impossible to port the Delphi applications, my colleagues did, to a non-GUI environment. The new idea now is, that implementing PostMessage (and supposedly Application.QueueAsyncCall) might be done using the existing RTL Event queue (which only recently came to my full awareness), instead of creating (or in Windows attaching to) an additional queuing mechanism. There are many ways to implement timers and queues. But if you want the whole event system of the LCL then you need do more. What non-GUI events - additionally to the events I mentioned - would be needed for "the whole event system of the LCL" ? Have you ever asked how to program a timer in a console application on this list? Of course I do know that this is doable (and I already did it several times). But (as I mentioned multiple times) I don't need this for any concrete application, but for creating an "SDK" that allows for porting existing Delphi applications in a way as easy to use as possible. Thus an "Application" and "Postmessage" (thus an LCL Widget Type implementation) is necessary. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:09 AM, Sven Barth wrote: I would not use Sleep as you need to be able to cancel the timer A decent point ... -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:20 AM, Michael Van Canneyt wrote: The fptimer unit implements a timer with a thread, but this forces the use of threads on your application which is not always desirable. Should be doable, as well. AFAIK, mse (for Linux) uses signals on that behalf. We might want to steal some ideas there. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013 10:25:43 +0200 Michael Schnell wrote: > On 09/18/2013 10:05 AM, Mattias Gaertner wrote: > > On Wed, 18 Sep 2013 09:32:54 +0200 > > Michael Schnell wrote: > > > >> [...] > >> Instead I was told that I should look at the LCL > >> source code and that "in Windows, the Event queuing mechanism is done by > >> Windows itself and in Linux it is done by a queue in the LCL that is > >> managed by the underlying Widget Set". > > This is true for PostMessage. > > (and supposedly for Application.QueueAsyncCall) No. QueueAsyncCall is implemented in the LCL without widgetset code. >[...] > What non-GUI events - additionally to the events I mentioned - would be > needed for "the whole event system of the LCL" ? For example PostMessage can send messages to other applications on Windows. >[...] I don't need this for any > concrete application, but for creating an "SDK" that allows for porting > existing Delphi applications in a way as easy to use as possible. Really? Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic TFPGList gives me compiler error: Operator is not overloaded
Sven, I am still using fpc 2.6.2. May I know whether the generics bugs for 2.6.2 are catchable at compiler times or I only get to find out at run time? Dennis Sven Barth wrote: On 17.09.2013 17:39, Dennis Poon wrote: Sven, Thanks a lot. It worked. Generics, advanced record, customized operator ... all these new features are so cool. I am impressed that Free Pascal has become so powerful. At least generics and operator overloads aren't that new. What's new is that generics contain less bugs (at least in 2.7.1 compared to earlier versions) and that operators can be used inside records (together with normal methods). Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal - No virus found in this message. Checked by AVG - www.avg.com Version: 2013.0.3408 / Virus Database: 3222/6673 - Release Date: 09/17/13 ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 10:38 AM, Mattias Gaertner wrote: On Wed, 18 Sep 2013 10:25:43 +0200 Michael Schnell wrote: What non-GUI events - additionally to the events I mentioned - would be needed for "the whole event system of the LCL" ? For example PostMessage can send messages to other applications on Windows. Of course this is true but is has noting to do with "the event system of the LCL". -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Generic TFPGList gives me compiler error: Operator is not overloaded
On 18.09.2013 10:51, Dennis Poon wrote: Sven, I am still using fpc 2.6.2. May I know whether the generics bugs for 2.6.2 are catchable at compiler times or I only get to find out at run time? I'm currently not aware of any runtime bugs so all should be noticable by the compiler complaining about your code :) (and these complains can be very strange compile or link errors) Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Error linking with C code
Hi All, I am writing pascal wrapper for a C library called "CTP", which is used in future trading. My project is here: https://github.com/xrfang/CTPas Compiling the interface file along is successful. While linking, fpc complains: ./thostmduserapi.so, needed by ./libthost.so, not found (try using -rpath or -rpath-link) while libthost.so is my wrapper writting in C, which uses thostmduserapi.so, provided by the vendor (no source code). Full error output is: Free Pascal Compiler version 2.6.2 [2013/03/17] for x86_64 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling demo.pas Linking demo /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/bin/ld: warning: ./thostmduserapi.so, needed by ./libthost.so, not found (try using -rpath or -rpath-link) ./libthost.so: undefined reference to `CThostFtdcMdApi::CreateFtdcMdApi(char const*, bool, bool)' demo.pas(4,1) Error: Error while linking demo.pas(4,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Could you please explain how to solve this problem? Thanks! Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error linking with C code
On Wed, 18 Sep 2013, Xiangrong Fang wrote: Hi All, I am writing pascal wrapper for a C library called "CTP", which is used in future trading. My project is here: https://github.com/xrfang/CTPas Compiling the interface file along is successful. While linking, fpc complains: ./thostmduserapi.so, needed by ./libthost.so, not found (try using -rpath or -rpath-link) while libthost.so is my wrapper writting in C, which uses thostmduserapi.so, provided by the vendor (no source code). where is thostmduserapi.so ? Michael. Full error output is: Free Pascal Compiler version 2.6.2 [2013/03/17] for x86_64 Copyright (c) 1993-2012 by Florian Klaempfl and others Target OS: Linux for x86-64 Compiling demo.pas Linking demo /usr/bin/ld: warning: link.res contains output sections; did you forget -T? /usr/bin/ld: warning: ./thostmduserapi.so, needed by ./libthost.so, not found (try using -rpath or -rpath-link) ./libthost.so: undefined reference to `CThostFtdcMdApi::CreateFtdcMdApi(char const*, bool, bool)' demo.pas(4,1) Error: Error while linking demo.pas(4,1) Fatal: There were 1 errors compiling module, stopping Fatal: Compilation aborted Error: /usr/bin/ppcx64 returned an error exitcode (normal if you did not specify a source file to be compiled) Could you please explain how to solve this problem? Thanks! Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error linking with C code
> > > where is thostmduserapi.so ? > > Michael. This file is under libthost folder, I copied it to pasintf folder then use fpc to compile demo.pas. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error linking with C code
On Wed, 18 Sep 2013, Xiangrong Fang wrote: where is thostmduserapi.so ? Michael. This file is under libthost folder, I copied it to pasintf folder then use fpc to compile demo.pas. I think you should try to pass the name of the folder where libthost is to the linker. -FL/path/to/libthost Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Error linking with C code
> I think you should try to pass the name of the folder where libthost is to > the linker. > -FL/path/to/libthost > > Michael. > > This does not work, same error message. I also tried to copy libthost.so to current dir, but leave thostmduserapi.so in ../libthost, same result. Regards, Xiangrong ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
Al 18/09/13 09:32, En/na Michael Schnell ha escrit: > It is really frustrating to see, that this now seems to solves the issue > I am hunting for since some five years. Perhaps if you spent your time actually using fpc instead of hunting for non-problems you'd have realized that this worked five (and more) years ago as it does now. Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 12:05 PM, Luca Olivetti wrote: Perhaps if you spent your time actually using fpc instead of hunting for non-problems ... As already pointed out, I have no intention to do a Project of such kind myself. I am just trying to construct a toolbox to help my colleagues to port their Delphi applications. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013 10:55:34 +0200 Michael Schnell wrote: > On 09/18/2013 10:38 AM, Mattias Gaertner wrote: > > On Wed, 18 Sep 2013 10:25:43 +0200 > > Michael Schnell wrote: > > > >> What non-GUI events - additionally to the events I mentioned - would be > >> needed for "the whole event system of the LCL" ? > > For example PostMessage can send messages to other applications on > > Windows. > > > Of course this is true but is has noting to do with "the event system of > the LCL". Says who? Some users asked about messages from/to other applications for nogui LCL applications on Windows. Mattias ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Michael Schnell said: > > The fptimer unit implements a timer with a thread, but this forces the > > use of threads on your application which is not always desirable. > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that > behalf. We might want to steal some ideas there. While there is sigalarm, but can you have multiple independent timers in an application that way? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 01:19 PM, Mattias Gaertner wrote: Some users asked about messages from/to other applications for nogui LCL applications on Windows. OK. In fact to me it has been a completely silly concept of Borland's that in early Delphi versions TThread.Queue was not documented (or in very early versions maybe not even implemented) and thus the users were forced to "by hand" use Windows messages to schedule asynchronous Main Thread events. By that the concepts of Thread to Mainthread signaling has been mixed with the concept of inter-Application signaling (and even the decently ugly windowish Application to GUI Widget signaling). But this is not your or my fault ;-) . Maybe when implementing PostMessage for Thread to Mainthread signaling for windows OS we could take care of inter application messages. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 01:26 PM, Marco van de Voort wrote: While there is sigalarm, but can you have multiple independent timers in an application that way? I don't know. We would need to ask mse. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, Sep 18, 2013 at 01:26:46PM +0200, Marco van de Voort wrote: > In our previous episode, Michael Schnell said: > > > The fptimer unit implements a timer with a thread, but this forces the > > > use of threads on your application which is not always desirable. > > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that > > behalf. We might want to steal some ideas there. > > While there is sigalarm, but can you have multiple independent timers in an > application that way? I think Martin used setitimer and handles multiple timers by calculating which one expires first, and subtracting that amount from the other timers, etc. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, 18 Sep 2013, Michael Schnell wrote: On 09/18/2013 01:26 PM, Marco van de Voort wrote: While there is sigalarm, but can you have multiple independent timers in an application that way? I don't know. We would need to ask mse. mse inverts the problem. The timer implementation relies on an external 'tick' routine. How this tick is delivered depends entirely on the event loop. Michael. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Henry Vermaak said: > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals on that > > > behalf. We might want to steal some ideas there. > > > > While there is sigalarm, but can you have multiple independent timers in an > > application that way? > > I think Martin used setitimer and handles multiple timers by calculating > which one expires first, and subtracting that amount from the other > timers, etc. That's a trick commonly done on embedded platforms with limited timers (I actually did it once as part of a course that created a small RTOS for 8051 chips), but on *nix systems where libraries might also reserve certain itimers, that could fail miserably. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] StrUtils.RomanToInt oddities
Hi,
RomanToInt acceps rather ludicrous values:
RomanToInt('MDCLXVIVXLDM') = 2209
RomanToInt('M') = 1002 //calculated as 3 + (1000-1)
Both examples represent invalid roman numbers by any standard.
Also I do not think Roman numerals can be negative...
Feature or bug?
Bart
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 18.09.2013 13:33, Michael Schnell wrote: On 09/18/2013 01:19 PM, Mattias Gaertner wrote: Some users asked about messages from/to other applications for nogui LCL applications on Windows. OK. In fact to me it has been a completely silly concept of Borland's that in early Delphi versions TThread.Queue was not documented (or in very early versions maybe not even implemented) and thus the users were forced to "by hand" use Windows messages to schedule asynchronous Main Thread events. TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So that's definitely not "very early". Regards, Sven ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
In our previous episode, Sven Barth said: > > forced to "by hand" use Windows messages to schedule asynchronous Main > > Thread events. > > TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So > that's definitely not "very early". D2006 afaik. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On 09/18/2013 05:03 PM, Sven Barth wrote: TThread.Queue is a rather new addition. Delphi 2009 if I'm correct. So that's definitely not "very early". OK, at least four years ;-) . I have "Turbo Delphi". Here it is implemented but not to be found in the help. -Michael ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPC 2.6.2 for DOS/Go32V2 FP.EXE cannot run a second time
I am running pure DOS 7 from Windows 98 US, no drivers, no TSR programs. Just COMMAND.COM, no AUTOEXEC.BAT and CONFIG.SYS. Run CWSDPMI -p -x DPMI stays in memory, start FP.EXE - again SIGSEGV. But I found an interesting thing. When I run FP.EXE from FPC 1.0.11 (it started always O.K.), nothing done, just exit program, and then try run IDE from FPC 2.6.2 - the program starts! *Further attempts to start IDE from FPC 2.6.2 causes an exception SIGSEV.* * * *If previously run IDE from FPC 1.0.11, then IDE from FPC 2.6.2 starts.* It is really funny... Can you tell me where can I download source for IDE from FPC 2.6.2 and how to compile it? I will try it when I have a free weekend. Thank you. On Wed, Sep 18, 2013 at 8:52 AM, Tomas Hajny wrote: > On Tue, September 17, 2013 20:57, Lubomír Čabla wrote: > > FPC 2.6.2 for DOS/Go32V2 > > > > There is the fatal IDE unstability in FPC 2.6.2 under pure DOS. > > > > IDE almost always starts only first time (after installation or reboot). > > I start the IDE, compile and run the program (e.g. Hello.pas) and close > > IDE. But when I want to start IDE again it crashes with SIGSEGV message. > > > > Exiting due to signal SIGSEGV > > FPC General Protection Fault at eip=006EDE95 > > eax=65672D6C ebx=002A ecx=0088 edx= esi=008E91F8 > > edi=0083B504 > > ebp=008C0CA0 esp=008C0C90 program=C:\PP\BIN\GO32V2\FP.EXE > > cs: sel=00A7 base=0040 limit=008E > > ds: sel=00AF base=0040 limit=008E > > es: sel=00AF base=0040 limit=008E > > fs: sel=00C7 base= limit=0010 > > gs: sel=00C7 base= limit=0010 > > ss: sel=00AF base=0040 limit=008E > > > > Call frame traceback EIPs: > > $006EDE95 > > $005BD905 > > $005BCD84 > > $005BC83D > > $005BC7F8 > > $00308AF8 > > $0030B9F4 > > $0002DB50 > > $0002DC5A > > $2040 > > > > To be able to start IDE again in DOS I have to reboot the computer. > > I think IDE set something in memory and warm restart does not erase the > > memory contents. > > > > Compilation from command prompt with FPC.EXE works everywhere. > > But IDE is good for debugging and help. > > > > Can someone please help me or advise what I'm doing wrong. > > > > The main problem is running IDE in pure DOS. > > Which DOS version is it? Is there any DPMI provider running before > starting the IDE (some DOS versions include DPMI host themselves)? > > If there is no other DPMI host (running) and thus CWSDPMI.EXE is used, I'd > recommend starting with a check whether there is just one (the latest) > CWSDPMI.EXE and just for test purposes try loading it into memory as TSR > with options "-p -x" (see cwsdpmi.txt included in directory doc\fpc) to > see if it makes any difference. > > Obviously, the next step would be compiling the IDE with debug information > (including -gl) to see where exactly it fails. > > Tomas > > > ___ > fpc-pascal maillist - fpc-pascal@lists.freepascal.org > http://lists.freepascal.org/mailman/listinfo/fpc-pascal > ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] FPCUnit test + raise E;
On Tue, Sep 17, 2013 at 2:41 PM, Sven Barth wrote: > On 17.09.2013 17:27, Marcos Douglas wrote: >> >> On Tue, Sep 17, 2013 at 12:18 PM, Marcos Douglas wrote: Another thing you could try (just for testing): change your exception handler procedure to a function that returns bool and use it like this: === code begin === procedure TghSQLConnector.Connect; begin try FLib.Connect; except on E: Exception do if not DoOnException(E) then raise; end; end; === code end === Regards, Sven >>> >>> >>> The only difference is the use of raise; instead raise E; right? >>> >>> Marcos Douglas >> >> >> In project in attachment before, if you change the line 50 >> from: >> raise E; >> >> to: >> raise Exception.Create(E.Message); >> >> Will work... but is this correct? > > > So this seems to be indeed a problem of freeing exceptions. Whether you > misuse the exception system or you encountered a bug needs to be > determined... If this is a bug I can register in bug tracker. >> Lazarus 1.1 r42461 FPC 2.6.2 i386-win32-win32/win64 > > > Could you test your original one with 2.7.1 as well? I can't compile Lazarus with FPC 2.7.1 (as you saw in lazarus-list) so, I can't test... :( >> PS: Sorry for my late, Sven. > > > No problem. :) Thanks, Marcos Douglas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] lnet for TCP daemon
On Wed, Sep 18, 2013 at 03:57:36PM +0200, Marco van de Voort wrote: > In our previous episode, Henry Vermaak said: > > > > Should be doable, as well. AFAIK, mse (for Linux) uses signals > > > > on that behalf. We might want to steal some ideas there. > > > > > > While there is sigalarm, but can you have multiple independent > > > timers in an application that way? > > > > I think Martin used setitimer and handles multiple timers by > > calculating which one expires first, and subtracting that amount > > from the other timers, etc. > > That's a trick commonly done on embedded platforms with limited timers > (I actually did it once as part of a course that created a small RTOS > for 8051 chips), but on *nix systems where libraries might also > reserve certain itimers, that could fail miserably. Yes, the POSIX interval timers are a much better solution for this. Dealing with signals are still a bit annoying, but things like timerfd and signalfd are linux specific. Henry ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
