Use SynDbZeos instead.
]]>In fact, for FPC, I guess the standard FPC functions of exception interception and stack trace should be used.
Someone has to take a little time and include the features already available within the FPC RTL, and described at
http://wiki.freepascal.org/Logging_exceptions
After reading the "#Handling thread exceptions" section, I really hope that you, who know every detail of mORMot threading, could do the work ...
]]>Someone has to take a little time and include the features already available within the FPC RTL, and described at
http://wiki.freepascal.org/Logging_exceptions
Exception logging and Stack trace do work now on Linux with Kylix/CrossKylix!!!!
I took inspiration from the code you supplied!
Thanks!
Could you help to comment whether you would provide built-in "Exception logging and Stack trace" for mORMot with FPC/(Win32,Linux) ?
If not, could you help to comment on the best alternative to enable "Exception logging and Stack trace" for mORMot with FPC/(Win32,Linux) ?
1. It is a dead project, but an alive product. It still works!
2. You can not buy it any more.
3. The debugger and IDE is unusable, but it is still perfect for cross-building server executable for Linux from the Delphi IDE, and thanks to SynLog.pas, you can debug it easily remotely.
We are adding CrossKylix support for several reasons:
1. We use it since years, with great success, so we know it better than FPC.
2. It has still a better compiler than FPC, e.g. for the RTTI we need on interfaces, or even for executable size and memory use.
3. Its compilation is instant - whereas FPC is long to compile.
4. It supports FastMM4, which performs better than the FPC memory manager, from our tests.
5. Resulting executables, for mORMot purpose, are faster than FPC - based on the regression tests.
6. If the code works with Delphi 7, it will certainly work with Kylix (since it shares the same compiler and RTL), whereas FPC is compatible, but not the same. So it sounds safer to be used on production than FPC, today.
7. There is not a lot of IFDEF, but in SynCommons. Then there is a SynKylix.pas unit for several functions. User code would be the same than Delphi.
8. There is a Linux compiler in the official Embarcadero roadmap (for next year?): so we can hope that this one will be closer to Kylix than FPC... so it sounds more like a "back to the future" work...
]]>I might be wrong, but I assume supports also Kylix will cause a lot of IDEF's, is there a reason to still support a project that's dead for ten years?
]]>Exception logging and Stack trace do work now on Linux with Kylix/CrossKylix!!!!
I took inspiration from the code you supplied!
Thanks!
It is excellent, excellent work ! Thank you for your efforts very much !
]]>I took inspiration from the code you supplied!
Thanks!
I've added a reference to this forum thread to the corresponding ticket.
See http://synopse.info/fossil/tktview/b07ceddab631
2014-07-28
[50208921410a] now SynCommons unit compiles with Kylix - but not tested, and exception interception for logging and stack trace are disabled (user: User, tags: trunk)
Really nice work ! Kudos for your efforts ! Nevertheless, when "exception interception for logging and stack trace" are disabled, it seems that one cannot expect line number from TSynLog ?
Hi Arnaud,
Please find in the zip archive an example of handling exception stack trace using Kylix (Linux) . In short, it uses JclDebug & JclHookException compatible with Kylix (Linux) .
As shown in the quoted post, JclDebug & JclHookException that is compatible with Kylix (Linux) can be used to handle exception stack trace using Kylix (Linux). However, the workflow seems different from what SynCommons does.
Furthermore, the MultiLog has a SendException that gives stack trace (only when compiled with Free Pascal). https://code.google.com/p/luipack/ The workflow also relies on API different from the above one or the SynCommons one. Would you think it is feasible to enable SynCommons to handle exception stack trace for Delphi (on Windows), Kylix (on Linux), and Free Pascal in a unified way ?
]]>Now how much money are we talking about ? If the amount is beyond me then I just have to forget about the idea for the moment.
]]>It may be done in the close future only if someone dedicates some time (or money) to implement it.
]]>