transcript is plain bad
Locked
 
|
I can tell that it does not work when loading partial code because all the compiler warnings make sure that you
cannot see anything…. I should have pushed my logger more. :( |
|
|
The return of the toothpick is near. o/
On Mon, Dec 2, 2013 at 6:54 PM, Stéphane Ducasse <[hidden email]> wrote: I can tell that it does not work when loading partial code because all the compiler warnings make sure that you |
|
|
> The return of the toothpick is near. o/ No I will finish my logger :) Stef |
|
|
yes, please :) On Mon, Dec 2, 2013 at 7:56 PM, Stéphane Ducasse <[hidden email]> wrote:
|
|
|
Buy the way, is absence of Transcript class - ok?
I know how it all works now, but is it ok? :) uko
On 02 Dec 2013, at 19:58, Esteban Lorenzano <[hidden email]> wrote:
|
|
|
yes, the transcript is ThreadSafeTranscript On Mon, Dec 2, 2013 at 8:00 PM, Yuriy Tymchuk <[hidden email]> wrote:
|
|
|
And missing a ton of methods.
Teh StackInterpreterSimulator is agreeing with this statement. On Mon, Dec 2, 2013 at 8:05 PM, Esteban Lorenzano <[hidden email]> wrote:
|
|
Administrator
|
In reply to this post by EstebanLM
Does "ThreadSafe" mean I don't have to wrap all my debug logging in "WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot of time :)
Cheers,
Sean |
Re: transcript is plain bad
|
|
2013/12/2 Sean P. DeNigris <[hidden email]>:
> EstebanLM wrote >> yes, the transcript is ThreadSafeTranscript > > Does "ThreadSafe" mean I don't have to wrap all my debug logging in > "WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot > of time :) According to the implementation it means there is a Mutex stopping multiple processes from doing operations (#nextPut:, #nextPutAll:) at the same time. It is... who sends the message first will be received happily, whoever is second will have to wait in a semaphore :D Funny outputs might happen if two different senders use #nextPut: intertwined. (other frameworks only left "complete line" outputs to loggers, to avoid this kind of scenarios). Regards! |
|
|
On 3 December 2013 02:59, Esteban A. Maringolo <[hidden email]> wrote: 2013/12/2 Sean P. DeNigris <[hidden email]>: imo this is exactly the case when for 0.00001% of chance that it will be required once, you spend tons of effort to make it work, means: overengineering. And, btw, good luck with solving the Halting problem along the way when you will be implementing this 'complete line' (when multiple threads sending output, but don't allowed to mix the lines) -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Stéphane Ducasse
> Am 02.12.2013 um 19:56 schrieb Stéphane Ducasse <[hidden email]>: > > >> The return of the toothpick is near. o/ > > No I will finish my logger :) > From next week on I will have a little time to work on it, too. If you like we can discuss a few things and bring to some usable state. Norbert |
|
|
In reply to this post by philippeback
On Dec 2, 2013, at 8:46 PM, [hidden email] wrote:
Please note that we should kill the transcript in the future because this is a ^%$&*((^%$* outdated way to manage feedback: plain string, close the window data is lost, limited in length, no filtering….. bad bad bad does not scale horrible and so frustrating. I will not send you the current transcript I have because I deal with private code but this does not work. Stef
|
|
|
In reply to this post by Esteban A. Maringolo
On Dec 3, 2013, at 2:59 AM, Esteban A. Maringolo <[hidden email]> wrote: > 2013/12/2 Sean P. DeNigris <[hidden email]>: >> EstebanLM wrote >>> yes, the transcript is ThreadSafeTranscript >> >> Does "ThreadSafe" mean I don't have to wrap all my debug logging in >> "WorldState addDeferredUIMessage: [ Transcript... ]? That would save a lot >> of time :) > > According to the implementation it means there is a Mutex stopping > multiple processes from doing operations (#nextPut:, #nextPutAll:) at > the same time. It is... who sends the message first will be received > happily, whoever is second will have to wait in a semaphore :D I did that because I was trying to write a chapter on concurrent programming and since the output could be in any order it was difficult to show anything reliably. Now the implementation can be bad and anybody willing to imporve it is more than welcome. > Funny outputs might happen if two different senders use #nextPut: intertwined. > (other frameworks only left "complete line" outputs to loggers What is is? In the new logger I'm writing we have log ***OBJECTS*** and not dead strings. > , to > avoid this kind of scenarios). > > Regards! > |
|
|
In reply to this post by Stéphane Ducasse
I am working on this one. Don't kill the transcript, it is useful when working without a console.--- Philippe Back Dramatic Performance Improvements Mob: +32(0) 478 650 140 | Fax: +32 (0) 70 408 027
Blog: http://philippeback.be | Twitter: @philippeback
High Octane SPRL rue cour Boisacq 101 | 1301 Bierges | Belgium Pharo Consortium Member - http://consortium.pharo.org/
Featured on the Software Process and Measurement Cast - http://spamcast.libsyn.com Sparx Systems Enterprise Architect and Ability Engineering EADocX Value Added Reseller
On Tue, Dec 3, 2013 at 10:10 AM, Stéphane Ducasse <[hidden email]> wrote:
|
|
|
On Dec 3, 2013, at 10:34 AM, [hidden email] wrote:
the transcript just displays the printstring of my log objects. So I can even control what I want to output. more important I can filter the log ojbjects. For example I need to know when my framework finish to deal with a class and now this is mix with the compiler logherea
No i just DO NOT WANT STRINGS!!!!
|
|
|
What's wrong with Strings anyway? But yeah, I understand your point. What I have done for my own stuff is to have a TLog aspect with info, debug, error, warn and, well, Strings. But double dispatch could take care of that, like printOn:, storeOn: etc.Do you have some code that I can look at? Phil On Tue, Dec 3, 2013 at 11:27 AM, Stéphane Ducasse <[hidden email]> wrote:
|
|
|
Am 03.12.2013 um 11:47 schrieb [hidden email]: Strings are fine when you don’t need specific behavior oder structure of your log messages anymore. A conversion to string should in most cases happen as late as possible. A log entry can still serve other purposes than represent an custom formatted string thing. Think about making all the exception handling in away that it can only signal strings. The same you feel now you would lose here is similar to the gain you’ll get making log messages objects ;) It is just that you are used to objects when it comes to exceptions and you are used to strings when comes to log messages. The former being a good idea the latter not. http://smalltalkhub.com/#!/~StephaneDucasse/SystemLogger Norbert
|
|
|
In reply to this post by philippeback
Sure have a look at SystemLogger
http://smalltalkhub.com/#!/~StephaneDucasse/SystemLogger I did not check the changes made by norbert. I will work on it during xmas. Stef On Dec 3, 2013, at 11:47 AM, "[hidden email]" <[hidden email]> wrote:
|
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |