[fpc-devel] Questions about TEventLog
Hi, I use logging a lot. It is my primary method of debugging FPC-based code. 99% of the time I use the logging features of tiOPF project. I have never used TEventLog, but took a quick look last night after I read Joost's message about Application.Log(). Here are some questions: 1) I see TEventLog can log to a file. In Linux's case a file to '/tmp/*.log'. Does TEventLog implement cached logging? At first glance I couldn't see anything in TEventLog that indicates that. If not, this will slow down the application a lot. 2) Is TEventLog thread safe? Again, at first glance I couldn't see anthyngi that indicates that it is. Thread safety is a critical feature for me. If none of these are supported, that seriously limits the usefulness of TEventLog in real-world applications. I double checked in the unit documentation, and there is no mention about thread safety or cached logging support. :-/ I don't have time at the moment, but can add it to my todo list to implement such features. Not all my project will be based on tiOPF, so having an alternative to help with my debugging will be well worth the effort. :) Of course somebody else can also take a look at tiOPF and implement those features sooner. ;-) Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TCustomApplication.Log(?)
On Mon, 15 Feb 2010, Joost van der Sluis wrote: Hi all, I want to add (abstract) logging functionality to TCustomApplication. I see three options: One: Add a public TEventLog property to TCustomApplication. Then deratives of TCustumApplication can return a TEventLog or a derivate of it. I can leave the TEventLog property nil for TCustomApplication, or let it return an instance TEventLog. That way you can adda log-message as follows: Application.Eventlog.Log(EtInfo); Two: Add an abstract (or maybe better, an empty) procedure to TCustomApplication, procedure Log(AType: TEventType; Message: string); virtual; (abstract); I can leave out the AType parameter, but I think it's useful for all cases. Classes derived from TCustomApplication can implement their own handling. Three: Same as two, but also add a real implementation using TEventLog. So that by default everything is logged to the system log, or when the user wants to to a file. Don't add the eventlog unit to customapplication, because eventlog has a dependency on the C library, and custapp does not need that. But it would be good if the 2 implementations use the same TEventType type for easy re-routing, so that would need to be moved 'up' somewhere. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] TCustomApplication.Log(?)
Hi all, I want to add (abstract) logging functionality to TCustomApplication. I see three options: One: Add a public TEventLog property to TCustomApplication. Then deratives of TCustumApplication can return a TEventLog or a derivate of it. I can leave the TEventLog property nil for TCustomApplication, or let it return an instance TEventLog. That way you can adda log-message as follows: Application.Eventlog.Log(EtInfo); Two: Add an abstract (or maybe better, an empty) procedure to TCustomApplication, procedure Log(AType: TEventType; Message: string); virtual; (abstract); I can leave out the AType parameter, but I think it's useful for all cases. Classes derived from TCustomApplication can implement their own handling. Three: Same as two, but also add a real implementation using TEventLog. So that by default everything is logged to the system log, or when the user wants to to a file. I think option two is the best one. Then I can use the TEventLog for daemon and web applications. But I'm really interested in the opinion of the Lazarus and MseIDE people. Although I think that MseIDE doesn't use the TCustomApplication? Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In Lazarus fpweb action procedure names no longer include the action name
On Sun, 2010-02-14 at 12:52 -0800, ABorka wrote: > When creating a web application, for example CGI Application in Lazarus, > and adding an action to the web module, the automatically generated > procedure name only contains a number and not the given action name. > If memory serves, this has worked before properly (even changing the > source code when one changed the action name in the object inspector). Changing the name still works. So what I do is create the procedure with the wrong name, and then rename it in the object-inspector. But that's just a work-around. Joost. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc listing supported Interfaces in class docs
Michael Van Canneyt wrote: > > It is not supported, please create a feature request. Thank you. Reported in Mantis as #15774. http://bugs.freepascal.org/view.php?id=15774 Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpdoc listing supported Interfaces in class docs
On Mon, 15 Feb 2010, Graeme Geldenhuys wrote: Hi, Is there a parameter or something in fpdoc that can output in the generated help the supported interfaces of a class? For example: Something like the output generated by JavaDoc in the section "All Implemented Interfaces" http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Container.html I looked at fpdoc supported parameters can can't immediately spot something like that. I also looked at the class documentation of a class that I know implements an interface (eg: TInterfacedObject). http://www.freepascal.org/docs-html/rtl/system/tinterfacedobject.html The only reference to what Interfaces that class implements, has been manually added to the short description or SeeAlso section. I don't see any automatic generated "all implemented interfaces" section similar to the "Inheritance" section. If it's not supported, anybody know if there is a todo list or feature request for this? It is not supported, please create a feature request. Michael. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] fpdoc listing supported Interfaces in class docs
Hi, Is there a parameter or something in fpdoc that can output in the generated help the supported interfaces of a class? For example: Something like the output generated by JavaDoc in the section "All Implemented Interfaces" http://java.sun.com/j2se/1.5.0/docs/api/java/awt/Container.html I looked at fpdoc supported parameters can can't immediately spot something like that. I also looked at the class documentation of a class that I know implements an interface (eg: TInterfacedObject). http://www.freepascal.org/docs-html/rtl/system/tinterfacedobject.html The only reference to what Interfaces that class implements, has been manually added to the short description or SeeAlso section. I don't see any automatic generated "all implemented interfaces" section similar to the "Inheritance" section. If it's not supported, anybody know if there is a todo list or feature request for this? Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc 14894 svn does not compile
On Sat, February 13, 2010 22:16, Marco van de Voort wrote: > In our previous episode, Jonas Maebe said: >> > Thanks Jonas, using 2.4.0 for the 1st compile worked. >> > I guess I shouldn't wait months before recompiling the latest SVN :) >> >> Even if you subsequently recompile every new svn revision it may >> sometimes suddenly not work anymore with your previously compiled svn >> trunk version. As mentioned before: only compiling using the latest >> release is guaranteed to work at all times! > > I added linux/i386 and /x86_64 compilers to bootstrap: > > ftp://freepascal.stack.nl/pub/fpc/dist/2.4.0/bootstrap/ BTW, the base.zip located in directory 'separate' within the respective target directory are appropriate alternatives for OS/2 & GO32v2 (it isn't exactly the same because also the compiled RTL units are included in that package, but it gives most benefits without any effort) - just in case if you intend to put information about these bootstrap version somewhere to the Wiki or the main WWW page. Tomas ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug Tracker & Wiki server is down
Hi, Could somebody give the server hosting the Bug Tracker & Wiki a kick in the butt. It's not responding. I can access any other websites, so it's not my internet connection. Regards, - Graeme - -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://opensoft.homeip.net/fpgui/ ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Re: GetHeapStatus.TotalAllocated
14.02.2010 6:04, Seth Grover: As for the negative numbers (possible overflow) from the heap status, I logged a bug on that, with an example program, quite some time ago. http://bugs.freepascal.org/view.php?id=14315 Ah, so negative numbers are in bugtracker already, ok. But still I think the issue with threads is maybe different because it happens immediately at the very first allocation+deallocation. I'll fill a separate bugreport. Thank you! Nikolai -SG -- This email is fiction. Any resemblance to actual events or persons living or dead is purely coincidental. Seth Grover sethdgrover[at]gmail[dot]com ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] In Lazarus fpweb action procedure names no longer include the action name
On Sun, 14 Feb 2010 12:52:16 -0800 ABorka wrote: > When creating a web application, for example CGI Application in Lazarus, > and adding an action to the web module, the automatically generated > procedure name only contains a number and not the given action name. > > For example, creating an action with a name ABC will generate a > OnRequest procedure (by double clicking in the object inspector on the > Events -> OnRequest) like: > > TFPWebActions0Request(Sender: TObject; >ARequest: TRequest; AResponse: TResponse; var Handled: Boolean); > > instead of > > TFPWebActionsABCRequest(Sender: TObject; >ARequest: TRequest; AResponse: TResponse; var Handled: Boolean); > > If memory serves, this has worked before properly (even changing the > source code when one changed the action name in the object inspector). > Right now, if someone has 50 actions, it takes a while to match the > Action ID numbers with the actual functionality within the event handler. > > Latest FPC SVN and latest Lazarus SVN, Win XP 32bit > > Should I create a bug report on this? Yes, please attach an example. BTW, this is a mailing list about fpc, not about lazarus. Mattias ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] In Lazarus fpweb action procedure names no longer include the action name
When creating a web application, for example CGI Application in Lazarus, and adding an action to the web module, the automatically generated procedure name only contains a number and not the given action name. For example, creating an action with a name ABC will generate a OnRequest procedure (by double clicking in the object inspector on the Events -> OnRequest) like: TFPWebActions0Request(Sender: TObject; ARequest: TRequest; AResponse: TResponse; var Handled: Boolean); instead of TFPWebActionsABCRequest(Sender: TObject; ARequest: TRequest; AResponse: TResponse; var Handled: Boolean); If memory serves, this has worked before properly (even changing the source code when one changed the action name in the object inspector). Right now, if someone has 50 actions, it takes a while to match the Action ID numbers with the actual functionality within the event handler. Latest FPC SVN and latest Lazarus SVN, Win XP 32bit Should I create a bug report on this? AB ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel