[Pharo-project] simpleLog in pharo?
+ 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. this is on my todo but this is a long one.
On Sep 8, 2010, at 10:09 AM, Simon Denier wrote:
I have no idea whether this issue has been discussed before, and perhaps even solved, but is there an easy way to configure Metacello logging? Right now in Pharo, it goes into the Transcript, and consequently mixes with Compiler warning and other stuff. When we load ConfigurationOfMoose, there are so many items in the Transcript that we lost the first ones. We have to hack the Transcript to dump the interesting info into a file.
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
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs [dhenrich@vmware.com] Sent: Wednesday, September 08, 2010 3:58 PM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
The inspector is currently used to view the object log in the development vm...for large object logs it makes sense to filter the log before viewing. For external viewing I have a Seaside Component that allows one to filter and sort the object log entries as well as delete entries from the ObjectLog ... Since GemStone runs with multiple vms, you can use a separate vm to look at the shared object log ... .. The RCQueue (and OrderedCollections for that matter) in GemStone don't incur performance hits as the collection grows over time (unlike growing OrderedCollections in a normal client Smalltalk), but then GemStone was designed with very large collections in mind:)... GemStone was designed to handle collections and object graphs that can be larger than available memory, so you can forget about the object log until start running out of repository space (basically disk space) ... For the Pharo, I would think that the fact that an Object log could accumulate a whole lot of stuff is real limiting factor...there'd need to be a process that continuously pruned objects from the object log over time .... so a thread safe linked list might be a better choice for the Object log collection ... Dale Schwab,Wilhelm K wrote:
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: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Dale Henrichs [dhenrich@vmware.com] Sent: Wednesday, September 08, 2010 3:58 PM To: Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr 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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Dale Henrichs wrote:
For the Pharo, I would think that the fact that an Object log could accumulate a whole lot of stuff is real limiting factor...there'd need to be a process that continuously pruned objects from the object log over time .... so a thread safe linked list might be a better choice for the Object log collection ...
How about a circular queue, with removed entries written to a file.
We should think about that and identify a good solution. Thanks for the information and discussion. Stef
The inspector is currently used to view the object log in the development vm...for large object logs it makes sense to filter the log before viewing.
For external viewing I have a Seaside Component that allows one to filter and sort the object log entries as well as delete entries from the ObjectLog ...
Since GemStone runs with multiple vms, you can use a separate vm to look at the shared object log ... ..
The RCQueue (and OrderedCollections for that matter) in GemStone don't incur performance hits as the collection grows over time (unlike growing OrderedCollections in a normal client Smalltalk), but then GemStone was designed with very large collections in mind:)...
GemStone was designed to handle collections and object graphs that can be larger than available memory, so you can forget about the object log until start running out of repository space (basically disk space) ...
For the Pharo, I would think that the fact that an Object log could accumulate a whole lot of stuff is real limiting factor...there'd need to be a process that continuously pruned objects from the object log over time .... so a thread safe linked list might be a better choice for the Object log collection ...
Dale
On 09/08/2010 10:50 PM, Schwab,Wilhelm K wrote:
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
SimpleLog has a LogMorph, I didn't write it but it registers itself as an emitter. Not sure what it does if it is "left running" :) It could probably use a "max backlog" or something, if it doesn't have that already. Viewing the log from outside: There are two "ways". First there is a logfile emitter - which writes to a log file and also does log file rotation after a max size etc. So you could always "tail" that file. Second is to use the syslog emitter - which IMHO is the best. That emitter uses syslog UDP standard messages to the local syslog port and then - on a normal linux box - your stuff will end up in the system log. From there you have TONS of tools. regards, Göran
Göran, I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees. On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think. On Linux, you mention lots of tools: any recommendations? Thanks! Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Göran Krampe [goran@krampe.se] Sent: Wednesday, September 08, 2010 6:57 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? On 09/08/2010 10:50 PM, Schwab,Wilhelm K wrote:
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
SimpleLog has a LogMorph, I didn't write it but it registers itself as an emitter. Not sure what it does if it is "left running" :) It could probably use a "max backlog" or something, if it doesn't have that already. Viewing the log from outside: There are two "ways". First there is a logfile emitter - which writes to a log file and also does log file rotation after a max size etc. So you could always "tail" that file. Second is to use the syslog emitter - which IMHO is the best. That emitter uses syslog UDP standard messages to the local syslog port and then - on a normal linux box - your stuff will end up in the system log. From there you have TONS of tools. regards, Göran _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi! On 09/09/2010 01:18 AM, Schwab,Wilhelm K wrote:
Göran,
I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees.
First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small. Secondly - my impression of Pharo so far is not really "robust", and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop. It seems to me that "progress" (new shiny stuff!) has been put in favor of robustness, which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release? Sorry for that little rant, don't really "mean" anything with it, just curious to see if I am the only one with this feeling.
On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think.
On Linux, you mention lots of tools: any recommendations?
No :). But there are lots of syslog related tools, just google it. :) regards, Göran
Göran,
I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees.
First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small.
Secondly - my impression of Pharo so far is not really "robust", and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop.
Where are your feedback? When did you mention that? And yes the system should change because I can list a lot of skeletons and paper tape that make the system believe it is working but is brittle.
It seems to me that "progress" (new shiny stuff!) has been put in favor of robustness,
Apparently all the bugs we close do not count? Come on goran...
which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release?
Sorry for that little rant, don't really "mean" anything with it, just curious to see if I am the only one with this feeling.
On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think.
Göran, Re "left running," while it is not my intention to throw up the knee-jerk "NO" that has been so common in other projects, I do think we should demand a torture test of any logging system that we adopt. If it can't be started and safely forgotten, it isn't ready. Is the code base small because it is simple and elegant (good) or because it is missing a lot of functionality to let it pass the set and forget test? I don't know the answer, but the question must be asked, and my vote is to adopt only after the answer is favorable. Your observation about new tools is well taken. Your experience on an old laptop is very interesting. If you really want to watch a struggle, compare Pharo to Dolphin running across a remote desktop connection. I am no Morphic expert, but it makes me wonder just how much of the screen is being redrawn and whether a lot of that could be avoided. Good performance on modest hardware is of value. You mention "shiny new stuff," but that is largely in the IDE or parallel systems (e.g. Nile, Ocean). The alternative is to continue to languish with Squeak's streams, sockets, file system, etc. Parts of Squeak are the way they are because they predate structured exception handling. Pharo is catching up on 15 years of refactoring to take advantage of 25 years of advancing technology. There will be some instability along the way, but the released versions have been pretty good so far. No doubt we can and should do better as Pharo evolves. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Göran Krampe [goran@krampe.se] Sent: Wednesday, September 08, 2010 7:34 PM To: pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] simpleLog in pharo? Hi! On 09/09/2010 01:18 AM, Schwab,Wilhelm K wrote:
Göran,
I think before we adopt anything, it should have the "left running" scenario addressed in some way. Pharo is supposed to be robust. That mean losing the silent failures, and doing so in a way that the new information does not bring the system to its knees.
First - I did not bring this up, so feel free to fix any flaws you see/find :). The code base is very small. Secondly - my impression of Pharo so far is not really "robust", and don't get me wrong here - it is not criticism, but my feeling every time I have used Pharo is that it is smack full of new stuff (completion, OB browsers etc etc) which quite often seems to break and also makes it painful to develop on my old trusty kinda slow Dell laptop. It seems to me that "progress" (new shiny stuff!) has been put in favor of robustness, which probably is why Pharo is attractive to a lot of people. Perhaps Pharo changed focus for next release? Sorry for that little rant, don't really "mean" anything with it, just curious to see if I am the only one with this feeling.
On Windows, OutputDebugString() is probably good enough. Since I am doing everything I can to ditch said platform, I might not be the best person to ask. Certainly, it is where I would go for a live view, and a file-based log would then cover everything else - I think.
On Linux, you mention lots of tools: any recommendations?
No :). But there are lots of syslog related tools, just google it. :) regards, Göran _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (5)
-
Dale Henrichs -
Göran Krampe -
Schwab,Wilhelm K -
Stéphane Ducasse -
Yanni Chiu