You mention something for viewing the log in-image. Dumb question: can it be left running and safely forgotten, or does it suffer under high load? Is there a way to view the log from outside of a running image? The latter is less important in proportion to the robustness of the in-image viewer. One thing that I often miss is DebugView; it would be really nice to find an equivalent on Linux.
Bill ________________________________________ From: [email protected] [[email protected]] On Behalf Of Dale Henrichs [[email protected]] Sent: Wednesday, September 08, 2010 3:58 PM To: [email protected] Subject: Re: [Pharo-project] simpleLog in pharo? Stéphane Ducasse wrote: > I will chekc I would like an object that represent wht is logged. > do you have that? > I do not want strings strings strings. > > On Sep 8, 2010, at 12:39 PM, Göran Krampe wrote: > >> On 09/08/2010 11:45 AM, Stéphane Ducasse wrote: >>> + 1 >>> If someone could look at simpleLog (because we need to change this >>> situation and get a good logging mechanism) >>> We need much better infrastructure.... and we will build them. >> I wrote SimpleLog (in the Gjallar project) and feel free to pick/use it - it >> is small and maps easily to Syslog (I copied the levels that syslog has) and >> also has a syslog emitter which is *very* nice when you build Seaside apps >> and want to run multiple images with a load balancer in front for example. >> >> There are several logging libs but... well, I think SimpleLog strikes a nice >> balance of functionality and simplicity. >> >> regards, Göran >> >> _______________________________________________ >> Pharo-project mailing list >> [email protected] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project In GLASS we have the ObjectLog ... the implementation is based upon RCQueue's (so that multiple vm's can concurrently add entries), but it is can be thought of as an OrderedCollection ObjectLogEntry instances: Object subclass: 'ObjectLogEntry' instVarNames: #( pid stamp label priority object tag) classVars: #( ObjectLog ObjectQueue) classInstVars: #() poolDictionaries: #[] inDictionary: '' category: 'Bootstrap-Gemstone' The pid and ObjectQueue are GemStone-specific ... - stamp DateAndTime - label String - priority Integer - object Object - tag Object GLASS has an ObjectLog component for viewing the object log ... inspector for in-image-viewing. There are currently 7 priorities defined: fatal - 1 error - 2 warn - 3 info - 4 debug - 5 trace - 6 transcript - 7 Yes Transcript messages are added to the ObjectLog ... very convenient ... Entries are added to the log via something like the following: (ObjectLogEntry info: 'label string' object: #( #hello 'world') addToLog. For GLASS I have a handful of subclasses of ObjectLogEntry that store things like a continuation and/or the url that caused the error... Dale _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
