[Pharo-project] about name for logging message
Hi guys I introduce log to replace Transcript show: ⦠logCr and crLog Now stupidly I did not notice that it will capture log on number :( and also on collection, So any suggestion of what would be a nice logging message? short and cool. Stef
Am 05.11.2011 um 12:50 schrieb Stéphane Ducasse:
Hi guys
I introduce log to replace Transcript show: ⦠logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace? Norbert
yes could be a good candidate. let us see if other suggestions arrive Stef On Nov 5, 2011, at 2:38 PM, Norbert Hartl wrote:
Am 05.11.2011 um 12:50 schrieb Stéphane Ducasse:
Hi guys
I introduce log to replace Transcript show: ⦠logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace?
Norbert
Stef, I'm not really sure what you are trying to do, but in Dolphin, I created a "runtime transcript" that would dump output into a file. My runtime session manager sub-classes all set the global Transcript to point to the (hopefully/intended-to-be thread-safe) file stream. I later built an application-specific logging facility that was configurable both in verbosity and in whether it went to the file or to the debug monitor (OutputDebugString()). Speaking of OutputDebugString(), I had so many uses of it, that I created something analogous in Pharo. It notes the OS and sends ouput to syslog() on Linux. Object Arts planned to remove Transcript>>show: at one point. IIRC, they did not actually remove it, which was fine with me, because it meant that I didn't have to be bothered adding it myself :) I *think* they added a new global stream, Trace, that wrote to the transcript, so one would use things like Trace print:someObject; cr. to log. And that stream could, of course, be connected to a file for deployed executables. Just some random thoughts... Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, November 05, 2011 10:35 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about name for logging message yes could be a good candidate. let us see if other suggestions arrive Stef On Nov 5, 2011, at 2:38 PM, Norbert Hartl wrote:
Am 05.11.2011 um 12:50 schrieb Stéphane Ducasse:
Hi guys
I introduce log to replace Transcript show: ⦠logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace?
Norbert
The idea is to remove Transcript so that we can plug another one if we want easily. We got a problem when the logging of the compiler was used while Transcript was changed. Ok we get self log: self logCr: ⦠and this is good. just the name sucks for log: Stef On Nov 5, 2011, at 3:50 PM, Schwab,Wilhelm K wrote:
Stef,
I'm not really sure what you are trying to do, but in Dolphin, I created a "runtime transcript" that would dump output into a file. My runtime session manager sub-classes all set the global Transcript to point to the (hopefully/intended-to-be thread-safe) file stream. I later built an application-specific logging facility that was configurable both in verbosity and in whether it went to the file or to the debug monitor (OutputDebugString()).
Speaking of OutputDebugString(), I had so many uses of it, that I created something analogous in Pharo. It notes the OS and sends ouput to syslog() on Linux.
Object Arts planned to remove Transcript>>show: at one point. IIRC, they did not actually remove it, which was fine with me, because it meant that I didn't have to be bothered adding it myself :) I *think* they added a new global stream, Trace, that wrote to the transcript, so one would use things like
Trace print:someObject; cr.
to log. And that stream could, of course, be connected to a file for deployed executables.
Just some random thoughts...
Bill
________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] on behalf of Stéphane Ducasse [stephane.ducasse@inria.fr] Sent: Saturday, November 05, 2011 10:35 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] about name for logging message
yes could be a good candidate. let us see if other suggestions arrive
Stef
On Nov 5, 2011, at 2:38 PM, Norbert Hartl wrote:
Am 05.11.2011 um 12:50 schrieb Stéphane Ducasse:
Hi guys
I introduce log to replace Transcript show: ⦠logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace?
Norbert
Hi: On 05 Nov 2011, at 15:54, Stéphane Ducasse wrote:
self log: self logCr:
Why is it a rather platform specific CR? Why not some platform independent NL (new line)? And in 1.3, I found the TranscriptModel with #addEntry: which looked like the new way of doing things since #show: has some comment which said it is deprecated/or not cool anymore. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
Hi stefan
self log: self logCr:
Why is it a rather platform specific CR? Why not some platform independent NL (new line)?
Indeed nl is better. I used Cr because people with Transcript show: 'foo' ; cr and not nl as far as I know
And in 1.3, I found the TranscriptModel with #addEntry: which looked like the new way of doing things since #show: has some comment which said it is deprecated/or not cool anymore.
AddEntry: is a low level api. Now I will check because there were some movements around transcript in 1.3 and may be some left over were not cleaned.
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
I like #trace: :). Other I do not like so should be #record: or #writeDown: (ugly, hehe) :P Why not just #newLine instead of #nl :(? Therer are 5 more characters but I'm happier :P... On Sat, Nov 5, 2011 at 6:37 PM, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Hi stefan
self log: self logCr:
Why is it a rather platform specific CR? Why not some platform
independent NL (new line)?
Indeed nl is better. I used Cr because people with Transcript show: 'foo' ; cr and not nl as far as I know
And in 1.3, I found the TranscriptModel with #addEntry: which looked like the new way of doing things since #show: has some comment which said it is deprecated/or not cool anymore.
AddEntry: is a low level api. Now I will check because there were some movements around transcript in 1.3 and may be some left over were not cleaned.
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On 05 Nov 2011, at 22:37, Stéphane Ducasse wrote:
AddEntry: is a low level api. Now I will check because there were some movements around transcript in 1.3 and may be some left over were not cleaned.
Ok, thanks, did not see the #log: the first time I looked at the class. Is probably already fixed, but in my #13281 image, TranscriptModel is not threadsafe. It seem to try to be threadsafe, but there is a problem when multiple processes do #log: and get interleaved while updating/redrawing the display. In my image, I just replaced the Semaphore with a Mutex (which is reentrant) and put a critical section in #log: Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
can you publish the code and I will fill a bug entry. May be log: was added after. On Nov 6, 2011, at 3:15 AM, Stefan Marr wrote:
On 05 Nov 2011, at 22:37, Stéphane Ducasse wrote:
AddEntry: is a low level api. Now I will check because there were some movements around transcript in 1.3 and may be some left over were not cleaned.
Ok, thanks, did not see the #log: the first time I looked at the class.
Is probably already fixed, but in my #13281 image, TranscriptModel is not threadsafe. It seem to try to be threadsafe, but there is a problem when multiple processes do #log: and get interleaved while updating/redrawing the display.
In my image, I just replaced the Semaphore with a Mutex (which is reentrant) and put a critical section in #log:
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On 06 Nov 2011, at 12:28, Stéphane Ducasse wrote:
can you publish the code and I will fill a bug entry. May be log: was added after.
This is nothing but a quick hack... I have not checked how that interacts all the stuff I am not using in the Transcript TranscriptModel>>#initialize initialize super initialize. showOnDisplay := false. innerRectangle := 20@20 extent: 300@500. logToFile := false. entries := Array new: self maxEntries. unfinishedEntry := '' writeStream. accessSemaphore := Mutex new. informDepedents := true. self clear. TranscriptModel>>#log: log: aString accessSemaphore critical: [ self addEntry: aString. self display ]. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
In 14217 there is no TranscriptModel (I thought that we removed it from 1.3 too). There is just ThreadSafeTranscript and no log: method there and it uses a Mutex too. So what I suggest is that if you want that we update the 1.3 version provide code that we can just load. LIke that we will integrate it in the next batch. Right now I'm trying to clean the back log of issues in 1.4 Stef
On 05 Nov 2011, at 22:37, Stéphane Ducasse wrote:
AddEntry: is a low level api. Now I will check because there were some movements around transcript in 1.3 and may be some left over were not cleaned.
Ok, thanks, did not see the #log: the first time I looked at the class.
Is probably already fixed, but in my #13281 image, TranscriptModel is not threadsafe. It seem to try to be threadsafe, but there is a problem when multiple processes do #log: and get interleaved while updating/redrawing the display.
In my image, I just replaced the Semaphore with a Mutex (which is reentrant) and put a critical section in #log:
Best regards Stefan
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525
On Sat, Nov 05, 2011 at 02:38:14PM +0100, Norbert Hartl wrote:
Am 05.11.2011 um 12:50 schrieb St?phane Ducasse:
Hi guys
I introduce log to replace Transcript show: ? logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace?
In OSProcess, #trace and #trace: are used for a similar purpose. This is intended for debugging with "transcript" output coming from the VM and therefore less dependent on process scheduling in the image. Dave
Thanks david I do not have OSProcess at hand, but where are these messages defined? On Object? Would it be a problem for you if we define trace and trace: on Object? Stef
Hi guys
I introduce log to replace Transcript show: ? logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace?
In OSProcess, #trace and #trace: are used for a similar purpose. This is intended for debugging with "transcript" output coming from the VM and therefore less dependent on process scheduling in the image.
Dave
It is OSProcess class>>trace and OSProcess class>>trace: so there is no conflict at all. I mentioned it only as a data point. I chose the name "trace" because it is used for debugging, and the intent is to trace the flow of execution by putting e.g. "OSProcess trace: 'the VM is about to core dump now' " in various methods ;) Dave On Sat, Nov 05, 2011 at 10:35:36PM +0100, St?phane Ducasse wrote:
Thanks david
I do not have OSProcess at hand, but where are these messages defined? On Object? Would it be a problem for you if we define trace and trace: on Object?
Stef
Hi guys
I introduce log to replace Transcript show: ? logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
How about trace?
In OSProcess, #trace and #trace: are used for a similar purpose. This is intended for debugging with "transcript" output coming from the VM and therefore less dependent on process scheduling in the image.
Dave
Have you thought of a decent logging system with logging levels, output formatter and output appenders? Current logging sure comes handy, but is really rudimentary. A business application must have a modern logging system, and it's not even a complex thing to do. I'm just asking whether you have discussed this or have something in mind already. On 5 November 2011 12:50, Stéphane Ducasse <stephane.ducasse@inria.fr>wrote:
Hi guys
I introduce log to replace Transcript show: ⦠logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
Stef
-- Milan Mimica http://sparklet.sf.net
did you check toothpick by joseph pelrine? Because transcript is not a logger just an historical simple output place. Stef On Nov 5, 2011, at 5:00 PM, Milan Mimica wrote:
Have you thought of a decent logging system with logging levels, output formatter and output appenders? Current logging sure comes handy, but is really rudimentary. A business application must have a modern logging system, and it's not even a complex thing to do. I'm just asking whether you have discussed this or have something in mind already.
On 5 November 2011 12:50, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi guys
I introduce log to replace Transcript show: ⦠logCr and crLog
Now stupidly I did not notice that it will capture log on number :( and also on collection,
So any suggestion of what would be a nice logging message? short and cool.
Stef
-- Milan Mimica http://sparklet.sf.net
participants (7)
-
David T. Lewis -
Guillermo Polito -
Milan Mimica -
Norbert Hartl -
Schwab,Wilhelm K -
Stefan Marr -
Stéphane Ducasse