logging to Transcript from not-UI process

The recent discussions about change logs etc, along with thinking about how the Toothpick package might do the job better (just realised that one could add an MQTT logger to it so that clusters of images could simply publish the logs and 'normal' tools could be used for sysadmin purposes) have reminded of a problem that has bitten me a couple of times over the last few weeks.

Basically, if we have a non-UI process (like Seaside handling) that tries to send something to the Transcript, then just occasionally and always, of course, during a demo, it will cause a problem. Obviously, I can't find a log file of it happening to illustrate; that would be far to helpful. IIRC it's something relating to the re-layout phase of the text morph.

Now I'd swear (and did!) that we 'fixed' this several years ago but I can't find any email about it so maybe I'm just hallucinating again.

Has anybody else seen this, or can remember about it or... ?

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Java:  the best argument for Smalltalk since C++

On Sun, Sep 13, 2020 at 11:29:38AM -0700, tim Rowledge wrote:
> The recent discussions about change logs etc, along with thinking about how the Toothpick package might do the job better (just realised that one could add an MQTT logger to it so that clusters of images could simply publish the logs and 'normal' tools could be used for sysadmin purposes) have reminded of a problem that has bitten me a couple of times over the last few weeks.
>
> Basically, if we have a non-UI process (like Seaside handling) that tries to send something to the Transcript, then just occasionally and always, of course, during a demo, it will cause a problem. Obviously, I can't find a log file of it happening to illustrate; that would be far to helpful. IIRC it's something relating to the re-layout phase of the text morph.
>
> Now I'd swear (and did!) that we 'fixed' this several years ago but I can't find any email about it so maybe I'm just hallucinating again.
>
> Has anybody else seen this, or can remember about it or... ?
>

This does not answer your question, but just in case you have overlooked
it, "OSProcess trace: something asString" is useful for dirt-simple logging
to the console from any process. I have never trusted the Transcript for
things like that.

Dave

I'll throw onto this discussion. I believe tim tested the TraceMonitor,
but went with Toothpick, which I have never used.

TraceMonitor (package in Cryptography) is mutex protected and writes to
multiple streams, including the Transcript. Therefore, multiple event
loops or other background processes can concurrently write to Transcript
and it will be properly interleaved.

K, r

On 9/13/20 3:06 PM, David T. Lewis wrote:

Hi Tim,

On Sun, 13 Sep 2020, tim Rowledge wrote:

> The recent discussions about change logs etc, along with thinking about how the Toothpick package might do the job better (just realised that one could add an MQTT logger to it so that clusters of images could simply publish the logs and 'normal' tools could be used for sysadmin purposes) have reminded of a problem that has bitten me a couple of times over the last few weeks.
>
> Basically, if we have a non-UI process (like Seaside handling) that tries to send something to the Transcript, then just occasionally and always, of course, during a demo, it will cause a problem. Obviously, I can't find a log file of it happening to illustrate; that would be far to helpful. IIRC it's something relating to the re-layout phase of the text morph.
>
> Now I'd swear (and did!) that we 'fixed' this several years ago but I can't find any email about it so maybe I'm just hallucinating again.
>
> Has anybody else seen this, or can remember about it or... ?

Only the #endEntry message is protected against concurrent access, so
you can't write anything in a thread-safe manner outside the UI process.

I would say it was written with a single process in mind, and later
"patched" to be able to "handle" concurrent access.

My workaround is that whenever I need to log something to the Transcript
from potentially another process, I prepare the string to log in my
process then use #addDeferredUIMessage: to inject it into the UI process
in a safe way. E.g.

Transcript open.
[
         | message |
         message := 'This is a very {1} log message at {2}.' format: {
'important'. DateAndTime now
}.
         Project current addDeferredUIMessage: [ Transcript nextPutAll:
message; cr; endEntry ] ] fork.

What I've been thinking about in the past decade is to add new formatting
messages to TranscriptStream. E.g. #show:formattedWith:, which does what
the above thing would but you could just send it to Transcript directly,
like:

Transcript show: 'This is a very {1} log message at {2}.{3}' formattedWith: { 'important'. DateAndTime now. String cr }

Or #showStream:, which would let you safely write a message on a stream.
E.g.:

Transcript showStream: [ :stream | stream nextPutAll: 'foo'; nextPutAll: 'bar'; cr ].

However, that would require a few changes like turning AccessSema into a
Mutex to be reentrant. (also, why is AccessSema a class variable used by
an instance?)

#nextPut:, #nextPutAll: and all the other Stream API exposed by
inheritance are useless, because tThey can't be made concurrent unless
they are all overridden.
So, IMHO TranscriptStream should be replaced with a new class inheriting
from Object, containing a single WriteStream, and providing a
thread-safe API (which can be the same as the current one).


Levente

>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Java:  the best argument for Smalltalk since C++

> On 2020-09-13, at 1:03 PM, Robert Withers via Squeak-dev <[hidden email]> wrote:
>
> I'll throw onto this discussion. I believe tim tested the TraceMonitor,
> but went with Toothpick, which I have never used.

There's nothing particularly wrong with TraceMonitor but Toothpick has a lot more options and has a very nice explanatory wiki on squeaksource. Explaining in order to be able to understand how to use it is always a winning strategy. Now, it is indeed true that I had to find the doc buried deep in the Wayback Machine and convert it to the wiki myself...


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DTF: Dump Tape to Floor

Hi Levente,

Agreed.  We should at least fix this.  The mutex should be an inst var.

> #nextPut:, #nextPutAll: and all the other Stream API exposed by inheritance are useless, because tThey can't be made concurrent unless they are all overridden.
> So, IMHO TranscriptStream should be replaced with a new class inheriting from Object, containing a single WriteStream, and providing a thread-safe API (which can be the same as the current one).

Agreed.  And if the internal architecture uses a shared queue we can cleanly separate writing from rendering.

> Levente
>
>>
>> tim
>> --
>> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
>> Java:  the best argument for Smalltalk since C++
>

On 9/13/20 10:28 PM, tim Rowledge wrote:
>> On 2020-09-13, at 1:03 PM, Robert Withers via Squeak-dev <[hidden email]> wrote:
>>
>> I'll throw onto this discussion. I believe tim tested the TraceMonitor,
>> but went with Toothpick, which I have never used.
> There's nothing particularly wrong with TraceMonitor but Toothpick has a lot more options and has a very nice explanatory wiki on squeaksource. Explaining in order to be able to understand how to use it is always a winning strategy. Now, it is indeed true that I had to find the doc buried deep in the Wayback Machine and convert it to the wiki myself...

Yes, indeed. This is the exact issue I am facing with PromisesLocal,
providing a good explanation of its operation. What is the link to the
Toothpick wiki page? I found the SqueakSource project with some
documentation: http://www.squeaksource.com/Toothpick.html.

I believe Toothpick uses Aspects, so in this regard it may be easier to
add Logging to some code, than with TraceMonitor.

In TraceMonitor one must start monitoring by sending 'traceMonitor
monitor: mainObject', there after the mainObject can send 'mainObject
monitor: subObject' and so on, to allow subObjects to send #etrace:msg:
and be monitored...my paltry documentation, here. :/

K, r

On 9/13/20 10:28 PM, tim Rowledge wrote:
>> On 2020-09-13, at 1:03 PM, Robert Withers via Squeak-dev <[hidden email]> wrote:
>>
>> I'll throw onto this discussion. I believe tim tested the TraceMonitor,
>> but went with Toothpick, which I have never used.
> There's nothing particularly wrong with TraceMonitor but Toothpick has a lot more options and has a very nice explanatory wiki on squeaksource. Explaining in order to be able to understand how to use it is always a winning strategy. Now, it is indeed true that I had to find the doc buried deep in the Wayback Machine and convert it to the wiki myself...

Yes, indeed. This is the exact issue I am facing with PromisesLocal,
providing a good explanation of its operation. What is the link to the
Toothpick wiki page? I found the SqueakSource project with some
documentation: http://www.squeaksource.com/Toothpick.html.

I believe Toothpick uses Aspects, so in this regard it may be easier to
add Logging to some code, than with TraceMonitor.

In TraceMonitor one must start monitoring by sending 'traceMonitor
monitor: mainObject', there after the mainObject can send 'mainObject
monitor: subObject' and so on, to allow subObjects to send #etrace:msg:
and be monitored...my paltry documentation, here. :/

K, r

> On 2020-09-13, at 10:27 PM, Robert Withers <[hidden email]> wrote:
>
> Yes, indeed. This is the exact issue I am facing with PromisesLocal,
> providing a good explanation of its operation. What is the link to the
> Toothpick wiki page? I found the SqueakSource project with some
> documentation: http://www.squeaksource.com/Toothpick.html.

It's the tab at the near-top of the page conveniently labelled 'Wiki' :-)

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.

On 9/14/20 12:56 PM, tim Rowledge wrote:
> On 2020-09-13, at 10:27 PM, Robert Withers <[hidden email]> wrote:
>> Yes, indeed. This is the exact issue I am facing with PromisesLocal,
>> providing a good explanation of its operation. What is the link to the
>> Toothpick wiki page? I found the SqueakSource project with some
>> documentation: http://www.squeaksource.com/Toothpick.html.
> It's the tab at the near-top of the page conveniently labelled 'Wiki' :-)
Ok, so I had already found the documentation you mentioned. Good. Thx.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> Useful Latin Phrases:- Ventis secundis, tene cursum. = Go with the flow.
>
>
>