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.
>>


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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:


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse wrote:
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Dale Henrichs [[hidden email]]
Sent: Wednesday, September 08, 2010 3:58 PM
To: [hidden email]
Subject: Re: [Pharo-project] simpleLog in pharo?

Stéphane Ducasse wrote:
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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:

_______________________________________________
Pharo-project mailing list
[hidden email]
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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Göran Krampe [[hidden email]]
Sent: Wednesday, September 08, 2010 6:57 PM
To: [hidden email]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

>> 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.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

We should think about that and identify a good solution.
Thanks for the information and discussion.

Stef



_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Göran Krampe [[hidden email]]
Sent: Wednesday, September 08, 2010 7:34 PM
To: [hidden email]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project