Re: [fpc-pascal] Threads and runtime errors
On Friday 22 June 2007 06:27, Carsten Bager wrote: > In the small threads program below I force a runtime error in a > thread. How do I get access to the output from the thread when it > stops? This program does not write anything to the terminal when the > thread stops. In case a runtime error occurs, the thread object stores the exception which occured, so before destroying the threads try something like: |if Assigned (t1.FatalException) do | WriteLn (StdErr, t1.FatalException.ClassName, |t1.FatalException.Message); Alternatively you can embrace the Execute method with a try-except statement. Regards, Vinzent. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] TFPTimer component.
On Friday 22 June 2007 07:28, Michael Van Canneyt wrote:
> - Don't use synchronize to fire the timer, because that limits
> the use of timers to the main thread.
> This one is harder, and I must confess I don't have a clue
> on how to implement this in a platform independent manner...
Well, independently from Graeme I implemented something like that
already, closely resembling the Ada2005 Ada.Real_Time.Timing_Events
package. Implemented targets would be Win32 and Unix (tested for Linux,
but as I am only using POSIX-functionality it should run on any other
Unix, too).
Problems are:
1) All fired events are currently executed in a single thread, meaning,
the can quite easily block out each other. Could be easily changed,
although starting thousand of threads may turn out to be a bad idea. ;)
Currently I am thinking about getting away from a global scheduler and
setting up several ones, this would cut down the number of threads in
case of many timing events being active and could be used to implement
a sort of user defined priorization (fast executing/important vs. slow
executing/less important events).
2) Event execution is always independent (outside) of the main thread,
so a user must take care of all the multi-threading hassles.
3) With the current implementation you can't use "Destroy" on such a
Timing_Event, because those objects are used in another thread, so
instead of calling Destroy you'd have to used "Finalize" to mark such
an event as done. It will be freed later from the "scheduling" loop.
4) On Unix it uses a signal to wake up the thread on changes in the
timing event queue, so someone must ensure that this signal is blocked
in all other threads and may not be used otherwise.
6) It uses some more modules (especially some Calendar unit which uses
integers for duration types to avoid drifting issues you'd have if
you'd used the floating point TDateTime).
7) As I am currently rewriting the stuff for the priority queue I am
going to be using, I won't post any sourcecode yet, apart from the
interface:
-- 8< --
//-- @abstract(Provides a (crude) scheduling object to install handlers
//-- to be executed at some future point in time.)
//-- It closely resembles the @code(Ada2005 Ada.Real_Time.Timing_Events)
//-- package, so for the correct semantics of the operations (which are
//-- currently not 100% guaranteed in this implementation) you may also
//-- refer to the Ada2005 language reference manual.
unit
Timing_Events;
interface
uses
Calendar,
SyncObjs;
type
Timing_Event = class; // Forward declaration for criss-cross type
// dependency.
type
//-- @abstract(Type for the event handler @italic(callback).)
Timing_Event_Handler =
procedure (const Event : Timing_Event) of object;
type
//-- @abstract(The base type indicating a timing event.)
//-- It stores the next scheduled execution and the handler to be
//-- executed.
Timing_Event = class (tObject)
public
{/= Create =\}
{}
{\==/}
//-- @abstract(The usual constructor. Initializes all the needed
//-- internals.)
constructor Create;
{/= Destroy \}
{}
{\==/}
//-- @abstract(Cleans up object internals.)
//-- Due to its inherent asynchronous usage, DO NOT call @code(
//-- Free) or even @code(Destroy) directly. Leave the freeing up
//-- to the @link(Finalize) subroutine.)
destructor Destroy; override;
{/= Finalize ===\}
{}
{\==/}
//-- @abstract(Marks the object for finalization.)
//-- This is a replacement for @code(Free) which can not be used
//-- in this asynchronous context. Instead if you call @code(
//-- Finalize) the event will be marked for deletion and @code(
//-- Free) will then be called on the next run of the scheduler.
//-- Basically this just means that the freeing will be deferred
//-- an indefinite time. In case the event in currently scheduled
//-- to run in a moment, this subroutine will not return until the
//-- run is over.
//--
//-- @bold(Do NOT) call any methods of the instance after having
//-- called @code(Finalize)!
procedure Finalize; virtual;
{/= Set_Handler \}
{
[fpc-pascal] Using interfaces for compile time testing
Hi,
I'm pretty new to using interfaces... I want to use interfaces so that
I can spot problems at compile time and not runtime. For example: If
I used a base class with abstract methods and then created descendant
classes and forget to implement one of the abstract methods which gets
called somewhere... I'll only find the problem at runtime and not
compile time.
I'm hoping that Interfaces will solve this issue. Am I allowed to do
the following?
This seems to work. As soon as I leave out one of the IWindowImpl
interface methods from the TX11Window class, the compiler complains.
Also can I let my base class descend from TComponent instead of
TInterfacedObject? Looking at the declaration of the TComponent class,
it implements IUnknown, so I guess I am allowed to add more interfaces
in descendant classes.
Is there any things I need to watch out for?
type
IWindowImpl = interface;
IWindowImpl = interface(IInterface)
['{BDBC9BE7-77E0-4EA1-B40B-282CE06A32B3}']
procedure DoAllocateWindowHandle(AParent: IWindowImpl);
procedure DoSetWindowTitle(const ATitle: string);
end;
TBaseImpl = class(TComponent)
private
FHeight: integer;
FWidth: integer;
procedure SetHeight(const AValue: integer);
procedure SetWidth(const AValue: integer);
public
property Width: integer read FWidth write SetWidth;
property Height: integer read FHeight write SetHeight;
end;
TX11Window = class(TBaseImpl, IWindowImpl)
protected
procedure DoAllocateWindowHandle(AParent: IWindowImpl);
procedure DoSetWindowTitle(const ATitle: string);
end;
Regards,
- Graeme -
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] fpc in cpp mode
> is it possible to tell fpc to only replace macros in the code and > store/show the generated file? > Like Running "cpp myfile.c > myfile.preprocessed.c"? Not that I know. If it is really macro's you care about, you are out of luck. If you just want to get rid of conditionals, try the pascal preprocessor in the jedi jcl (on sourceforge) ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re: [fpc-pascal] Documentation for sqldb
On Fri, 2007-06-22 at 10:43 +1000, John wrote: > Joost van der Sluis wrote: > > > IN principle you can set ReadOnly to false and ParseSQL to true. That > > way sqldb tries to parse your query. If it's a simple 'select * from > > table' the TSQLQuery will be updateable. It automatically generates > > update/delete and insert queries. For the 'where' clause is uses by > > default the primary key of the table. (That's a setting, upWhereKeyOnly) > > > > For example: 'delete * from table where pk=:old_pk' > > > > If you edit some data, those changes will be stored in an updatebuffer. > > With TSQLQuery.CancelUpdates all those changes are lost. But if you > > call .ApplyUpdates, it will execute one query for every changed record. > > (That could be a insert, update or delete query) > > > So if I change some field values and post the record, that changed data > goes into the update buffer - of TBufDataset ? I should then be able to > accumulate a few changes of these, and then, in code, call > TSQLQuery.ApplyUpdate, and it should be sent to the database ? Should > this also commit at the database level, or do I have to do this ? > (I think I tried this, but didn't pursue it very far, because I wasn't > sure if it even should work) You have still to commit the database-transaction. (SQLQuery.Transaction.commit(retaining)) And yes, the buffer is handled by TBufDataset. > Would it be feasible / sensible to call ApplyUpdate from an AfterPost > event handler ? Yes, you could do that. But that could generate a lot of sql-traffic. Maybe in an after-scroll is a better idea. > > Those are the basics. If you have questions, ask them here. And if you > > have any time, please document it somewhere on the wiki. ;) > I will, if I get to the point of thinking I understand it enough to not > make a fool of myself! Just start it, others will correct mistakes if needed. Joost ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
En/na Jonas Maebe ha escrit: On 14 jun 2007, at 19:04, Luca Olivetti wrote: No suggestions? Is there some special option (apart from -g) that I should specify to compile/link my program? No. But the garbage backtrace means that either your gdb cannot parse the signal handler frame, or that your program corrupted the call stack. Well, I'm starting to get desperate, I cannot debug where the sigsev occurs, I put a bazillion writeln and still I cannot see where the problem is. I can reproduce the sigsev at will, only I cannot see where it happens. I suspect it's one of the threads in the c library (linphonecore, http://www.linphone.org) I'm using (since in all of my threads I put writeln in the critical places, as well as in all the callbacks from said library), alas there's no sigsev when the same library is driven by the c console program that comes with it (linphonec). At one point I though the problem was in CheckSynchronize (since the last writeln before the sigsev was right before calling it), but it was just a timing coincidence (I was calling it with 1000, then when I tried with 0 I saw the sigsev right in the middle of a debugging printf in the library). Maybe it's not a good idea to mix c multithreaded libraries and pascal code? Any special unit I should use? (I already tried cmem and it made no difference). If I cannot solve it I think I'll have to write a small backend program in c that communicates with pascal either through stdin/stdout redirection or with a socket. Bye -- Luca ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
Luca Olivetti wrote: En/na Jonas Maebe ha escrit: On 14 jun 2007, at 19:04, Luca Olivetti wrote: No suggestions? Is there some special option (apart from -g) that I should specify to compile/link my program? No. But the garbage backtrace means that either your gdb cannot parse the signal handler frame, or that your program corrupted the call stack. Well, I'm starting to get desperate, I cannot debug where the sigsev occurs, I put a bazillion writeln and still I cannot see where the problem is. I can reproduce the sigsev at will, only I cannot see where it happens. I suspect it's one of the threads in the c library (linphonecore, http://www.linphone.org) I'm using (since in all of my threads I put writeln in the critical places, as well as in all the callbacks from said library), alas there's no sigsev when the same library is driven by the c console program that comes with it (linphonec). At one point I though the problem was in CheckSynchronize (since the last writeln before the sigsev was right before calling it), but it was just a timing coincidence (I was calling it with 1000, then when I tried with 0 I saw the sigsev right in the middle of a debugging printf in the library). Maybe it's not a good idea to mix c multithreaded libraries and pascal code? Any special unit I should use? (I already tried cmem and it made no difference). If I cannot solve it I think I'll have to write a small backend program in c that communicates with pascal either through stdin/stdout redirection or with a socket. Bye IIRC, it is 'gcc -c ' TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] How to analyze a core dump?
Luca Olivetti wrote: En/na Jonas Maebe ha escrit: On 14 jun 2007, at 19:04, Luca Olivetti wrote: No suggestions? Is there some special option (apart from -g) that I should specify to compile/link my program? No. But the garbage backtrace means that either your gdb cannot parse the signal handler frame, or that your program corrupted the call stack. Well, I'm starting to get desperate, I cannot debug where the sigsev occurs, I put a bazillion writeln and still I cannot see where the problem is. I can reproduce the sigsev at will, only I cannot see where it happens. I suspect it's one of the threads in the c library (linphonecore, http://www.linphone.org) I'm using (since in all of my threads I put writeln in the critical places, as well as in all the callbacks from said library), alas there's no sigsev when the same library is driven by the c console program that comes with it (linphonec). At one point I though the problem was in CheckSynchronize (since the last writeln before the sigsev was right before calling it), but it was just a timing coincidence (I was calling it with 1000, then when I tried with 0 I saw the sigsev right in the middle of a debugging printf in the library). Maybe it's not a good idea to mix c multithreaded libraries and pascal code? Any special unit I should use? (I already tried cmem and it made no difference). If I cannot solve it I think I'll have to write a small backend program in c that communicates with pascal either through stdin/stdout redirection or with a socket. Bye Nope, it is 'gdb -c '. Sorry :-( TomW -- Tom Walsh - WN3L - Embedded Systems Consultant http://openhardware.net http://cyberiansoftware.com http://openzipit.org "Windows? No thanks, I have work to do..." ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
