Either you run doits in separate process (as Sven demonstrated), or you run it in UI process, blocking the rest of UI. Stef, you complaining about not being able to see output of code that blocks a process from doing such output. I wonder how you going to fix that, and how much other complaints you will face, once you will fix that. The solution could be to change the whole UI paradigm and separate rendering from UI handling, which means that display no longer depends on what UI process are busy with. That means a lot of work revising the way how morphic delivers content to the real estate.. Only then Transcript could work as expected, scheduling screen updates into rendering/screen update schedule, as well as many other applications that can benefit from separating rendering pipeline from event handling. But alas, even then, you won't be fully satisfied, since VM is single threaded and it can be busy only with one thing at a time, either updating your screen, or advancing in progress of an action you instructed it to perform. And i remember many complaints of the past, where people was really annoyed that 'Transcript is tooooo damn slow' because often for VM it takes more cycles to update transcript than to do any progress with computation you run.. So, the choice is yours: you can run simulation that force updates of its progress every microsecond on screen (so fast, that human eye cannot notice) and as result your simulation takes hours rather than seconds, or you block the updates , or at least do not update that often (for human eyes updating more than 25 times per second is overkill). On 8 May 2015 at 16:16, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 11:34, stepharo a écrit :

...

Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515 Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem.

Probably in squeak, in Transcript this is done somewhere under the hood.

via dependents ?

TranscriptStream>>endEndtry "Display all the characters since the last endEntry, and reset the stream" self semaphore critical:[ self changed: #appendEntry. self reset. ].

Object>>changed: aParameter self dependents do: [:aDependent | aDependent update: aParameter]

And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows).

-- Regards,

Alain

-- Best regards, Igor Stasenko.

Le 08/05/2015 16:16, Eliot Miranda a écrit :

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO: There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution. The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't. If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too. Wouldn't it be better to execute do-it (s) systematically in another process ? and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ? And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point) I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ? -- Regards, Alain

On 8 May 2015 at 19:15, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 12:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

...

Wouldn't it be better to execute do-it (s) systematically in another process ?

This is an interesting idea. Actually if you DebugIt you already get a separate process, so always forking a separate process for DoIts could be considered more consistent. What would be the downside of doing this? cheers -ben

aside of numerous complaints 'now nothing is works the way it used to be'? i guess none. :)

and have a friendly way to control those processes, a bit similar to what

...

happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?

And to start, with a simple right-click menu option : 'Do it async' to experiment

I'd go the other way and make the forking 'DoIt' default, and while we test it out, have a backup menu item 'DoIt within system UI loop'.

...

(from a recent discussion, may be few problems with the inspector, but that's another point)

The Pharo philosophy is to press forward. If it forces a few UI threading issues into the light, that could be beneficial overall.

Now to the Squeak/Pharo difference. Squeak does this... TranscriptStream>>show: TranscriptStream>>endEntry TranscriptStream>>changed: DependentsArray>>do: TranscriptStream>>changed: PluggableTextMorphPlus>>update: PluggableTextMorph>>update: Morph>>refreshWorld PasteUpMorph>>displayWorldSafely:

First, Pharo's PluggableTextMorph>>update: does not call #refreshWorld. Second, Pharo replaced TranscriptStream with ThreadSafeTranscript. This behaviour has been present since at least build 20000 (I could not find an earlier one). Further, the fix [1] for the "Transcript red screen of death" occurring just before Pharo 3 release ensures the Transcript display is updated only once each Morphic cycle (which has the side effect of making calls to #show: faster.)

[1] https://pharo.fogbugz.com/default.asp?13032

cheers -ben

...

I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?

-- Regards,

Alain

-- Best regards, Igor Stasenko.

On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

ahh yes. Maybe we're not ready to be that adventurous yet. cheers -ben

On Fri, May 8, 2015 at 10:38 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 8 May 2015 at 19:31, Ben Coman <btc@openinworld.com> wrote:

...

On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

ahh yes. Maybe we're not ready to be that adventurous yet. cheers -ben

Unlike other software environments, smalltalk(s) allow you to change virtually anything in the system. And i found this to be really great thing.. and was happy until the moment i realized that the real thing, that prevents changes is not the software but people who opposing the changes :)

Nonsense. Changes are not the same as breakages. I've just changed the entire VM and object representation. I implemented a JIT and then followed up with a faster one, and Clément and I are following up with an even faster one. But I didn't break things; I made them better. SOmeone who reimplements the transcript so that - it doesn't have all the stream messages any more, and hence isn't a stream as it was always, - it doesn't update has not made changes; they have broken things. And in a shared space we rightly get to complain when that happens. -- best, Eliot

On Fri, May 8, 2015 at 11:10 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 8 May 2015 at 19:42, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 10:38 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:31, Ben Coman <btc@openinworld.com> wrote:

...

On Sat, May 9, 2015 at 1:22 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

ahh yes. Maybe we're not ready to be that adventurous yet. cheers -ben

Unlike other software environments, smalltalk(s) allow you to change virtually anything in the system. And i found this to be really great thing.. and was happy until the moment i realized that the real thing, that prevents changes is not the software but people who opposing the changes :)

Nonsense. Changes are not the same as breakages. I've just changed the entire VM and object representation. I implemented a JIT and then followed up with a faster one, and Clément and I are following up with an even faster one. But I didn't break things; I made them better. SOmeone who reimplements the transcript so that - it doesn't have all the stream messages any more, and hence isn't a stream as it was always, - it doesn't update has not made changes; they have broken things. And in a shared space we rightly get to complain when that happens.

<idioto> i truly believe that any changes to Transcript that being made in Pharo was with intent of making things better not to break them. As well as other 99.999% of changes. Of course, in shared space, there are potential risk of meeting a malicious person, who will break things intentionally forcing people to frustration and misery, but luckily, we have little or no such persons involved in developing pharo.. so... i am not sure what breakage you are talking about :) </idioto>

i think there is a fundamental difference between 'stream' and 'update on the screen' . Choose one and stick to it. We shall separate such responsibilities and NEVER ever merge them again , even if it was cool, nice, soft and puffy in the past. Yes, sure, we can then build the facade on top of that providing similar behavior of what was in the past..

Then VM development will happen in Squeak where we ca log output from the internals of the JIT as it runs as we do our soft and puffy work with machine code adaptive optimization and garbage collection. It won't happen in Pharo, because one can't see what's going on, because doctrine is more important than workflow. Afterall why would one want to design computing systems for people? What a strange idea.

But if not, then it will always be something that will forever be causing problem, since it is conceptually wrong and looks like attempt to cross breed two different species.

Right. The terminal is an abomination. We should do all computing in braille, and submit programs on punch cards, because systems that both consume and display data are against God. I'm glad I got that straight.

--

...

best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

Hi guys Eliot I do not understand why you are reacting like that. Our goal is not to make the live of people worse. All the efforts we do in Pharo is to get better. I changed the transcript because when I started to work on concurrent programming chapters then the transcript was simply useless. Now I would like to know how we can improve the solution and this is why I sent this mail. But apparently I should not have. :( I did not send it to receive your kind of emails. I'm convinced you can do better. I do not know what you mean about doctrine. Pharo objectives is to bring money in Smalltalk and to build better tools and infrastructure. Stef

On Sat, May 9, 2015 at 5:37 AM, stepharo <stepharo@free.fr> wrote:

Hi guys

Eliot I do not understand why you are reacting like that. Our goal is not to make the live of people worse. All the efforts we do in Pharo is to get better.

Reacting like what? I am trying to establish that the transcript is broken and needs fixing. Do you agree or not? If you don't agree then fine, Clément will continue to develop the VM in Squeak, and I'll always be confused about the Pharo community's ability to discuss technical issues. If you do agree, then why not plan to fix it? If instead you don't want to discuss the technical issue and instead see this as some kind of emotional attack then I'm sorry but that's completely dysfuncitonal. People make mistakes. Communities bake bad decisions. These things happen. But mature people and functional communities can recognize (you notice I didn't say admit, no one wants to ridicule people for their mistakes, I make serious mistakes continuously) their mistakes and rectify them. I am /not/ attacking the community, I am /not/ saying that Pharo is not trying to improve things, I am /not/ saying the old transcript was the most perfect piece of software ever, I am saying that the current behaviour and api of the transcript is *broken*. It needs to be a) compatible with WriteStream, and b) needs to display its output as soon as it is sent flush. Do you disagree?

I changed the transcript because when I started to work on concurrent programming chapters then the transcript was simply useless. Now I would like to know how we can improve the solution and this is why I sent this mail. But apparently I should not have. :(

I did not send it to receive your kind of emails. I'm convinced you can do better. I do not know what you mean about doctrine. Pharo objectives is to bring money in Smalltalk and to build better tools and infrastructure.

Stef

-- best, Eliot

On Sat, May 9, 2015 at 11:18 AM, stepharo <stepharo@free.fr> wrote:

Le 9/5/15 16:24, Eliot Miranda a écrit :

On Sat, May 9, 2015 at 5:37 AM, stepharo <stepharo@free.fr> wrote:

...

Hi guys

Eliot I do not understand why you are reacting like that. Our goal is not to make the live of people worse. All the efforts we do in Pharo is to get better.

Reacting like what?

Why do you mentioned doctrine? I was sad about this remark.

Because I saw Igor talking about internal issues, the internal architecture of the transcript, never having a stream crossed with a UI element, which were nothing to do with the point of the utility of the transcript and everything to do with a doctrinal attitude to software artifacts. I don't want to spend time defending hybrids, but I don;t see anything wrong in them; in real life hybrids are often strong and useful. So Igor's discussion strucl me as doctrinal and not addressing the pont, which is the utility of the transcript.

Our goal is to produce a good environment with excellent tools. Now you believe that I changed this code because I do not know what.

I don't know who changed the transcript, nor do I care. In this discussion I only care that Pharo has a useful transcript, so that Clément and others working on the VM can be productive in Pharo.

What I would have prefered is that you take the same attitude than me: consider that your case made sense. Remember that I raised the issue because I discussed with clement and I wanted to understand why my changes were not good.

But you tell me that I follow a doctrine. Well. Now I should have continue to believe that I'm right and I would feel much better. Now the truth should be also in the eye of the beholder.

You are reading things into what I said. I didn't accuse you of following a doctrine. I specifically found Igor's comments on hybrids doctrinal. Perhaps you are having an emotional reaction to my criticising the transcript. That's human, but I hope that you can put your emotional reaction aside and instead focus on the important technical issue here.

You think that transcript should the fast and you do not care about thread safety.

That's not true. I clarified my comments on thread-safety in a previous message. Thread-safety, so that the transcript does not lock-up, is IMO a really good thing. I don't think that ensuring a good interleaving is important however.

When I started to work on concurrency, should I write in the book that the students should not use the transcript because it does not handle concurrent updates. It does not look sexy for arrogant people like us that claim having excellent tools?

I always thought that the transcript' goal was to display correctly results of program execution not just sequential execution. And with two threads the old transcript clearly does not do it. So to me the "fast" transcript is broken. And up to today I did not see any class comments mentionning that the transcript first goal was to be fast displaying something.

Arranging that two updaters synchronise is not necessarily the function of the target data structure, but instead could be left to the clients to agree upon. For example, one could wrap the transcript with some object that provided more correct interleavings (that Igor might prefer because it is better decoupled). But the fundamental issue of thread-safety with the transcript is IMO that it not break when accessed from different threads. But the bottom line is that a technical community must strive to have productive discussions of technical issues and individuals in the community should strive to not take things personally and focus on technical issues. If we descend into ad hominem attacks and emotional reactions we will fail as a technical enterprise, no?

Stef

I am trying to establish that the transcript is broken and needs fixing. Do you agree or not? If you don't agree then fine, Clément will continue to develop the VM in Squeak, and I'll always be confused about the Pharo community's ability to discuss technical issues.

If you do agree, then why not plan to fix it?

If instead you don't want to discuss the technical issue and instead see this as some kind of emotional attack then I'm sorry but that's completely dysfuncitonal. People make mistakes. Communities bake bad decisions. These things happen. But mature people and functional communities can recognize (you notice I didn't say admit, no one wants to ridicule people for their mistakes, I make serious mistakes continuously) their mistakes and rectify them.

I am /not/ attacking the community, I am /not/ saying that Pharo is not trying to improve things, I am /not/ saying the old transcript was the most perfect piece of software ever, I am saying that the current behaviour and api of the transcript is *broken*. It needs to be a) compatible with WriteStream, and b) needs to display its output as soon as it is sent flush. Do you disagree?

...

I changed the transcript because when I started to work on concurrent programming chapters then the transcript was simply useless. Now I would like to know how we can improve the solution and this is why I sent this mail. But apparently I should not have. :(

I did not send it to receive your kind of emails. I'm convinced you can do better. I do not know what you mean about doctrine. Pharo objectives is to bring money in Smalltalk and to build better tools and infrastructure.

Stef

-- best, Eliot

-- best, Eliot

...

i think there is a fundamental difference between 'stream' and 'update on the screen' . Choose one and stick to it. We shall separate such responsibilities and NEVER ever merge them again , even if it was cool, nice, soft and puffy in the past. Yes, sure, we can then build the facade on top of that providing similar behavior of what was in the past..

But if not, then it will always be something that will forever be causing problem, since it is conceptually wrong and looks like attempt to cross breed two different species. <OT> I have no particular opinions about Transcsript, but I would like to say that I am very happy to have Igor back in the Squeak/Pharo/Cuis/Smalltalk discussions. I may not agree with everything, but I really appreciate his thoughtful perspective. There are a few people whose posts I will always read, and Igor is one of them. </OT> Thanks Dave. I share the same feelings. Dave

Speaking about penetrating multiple layers.. Lemme tell you the story: One day, a brave hero (let's call him Stef :) ) decided to save the world... err improve Transcript and make it thread-safe. And everything vent well until he stumbled upon #endEntry logic, because he was unable to figure out how it is handled and where it is handled.. He asked me for help and we sat together and looked for what can be done.. After many months and fierce battles (longer that any developer would except), we finally discovered that #endEntry logic is handled .. (drumroll...) in TextMorph, as a separate case in case-statement in its #changed: method. Sure it was a long ago, and my memory could fail me, i might be completely wrong on some details, and maybe instead we were drinking ale with fairies in the pub, and there was no any fights. But that's what is fairy tale for :) -- Best regards, Igor Stasenko.

On Mon, May 11, 2015 at 11:52:37PM +0200, Igor Stasenko wrote:

On 11 May 2015 at 22:54, Igor Stasenko <siguctua@gmail.com> wrote:

...

Speaking about penetrating multiple layers.. Lemme tell you the story:

One day, a brave hero (let's call him Stef :) ) decided to save the world... err improve Transcript and make it thread-safe. And everything vent well until he stumbled upon #endEntry logic, because he was unable to figure out how it is handled and where it is handled.. He asked me for help and we sat together and looked for what can be done.. After many months and fierce battles (longer that any developer would except), we finally discovered that #endEntry logic is handled .. (drumroll...) in TextMorph, as a separate case in case-statement in its #changed: method.

Sure it was a long ago, and my memory could fail me, i might be completely wrong on some details, and maybe instead we were drinking ale with fairies in the pub, and there was no any fights. But that's what is fairy tale for :)

I keep coming to this, so you guys can understand what is it.. There's a fairy tale in our culture where hero needs to kill an Immortal King, and he asked for advice from old which that told him how to do it: - there's a Mammoth, inside it a wolf, and inside wolf a rabbit, and inside rabbit - a duck, and inside duck, an egg, and inside egg a needle, and once you break the needle, so the Immortal King will be dead.. So, to recap, in order to kill an Immortal King, one must kill mammoth, wolf, rabbit, duck, break an egg and here we are.. job done! Now what is good and cool for fairy tale, not that cool and and suitable for daily programming tasks.. If one needs to break a needle - there should be a way to do just that, without need to peruse through piles of dead animal victims to achieve the goal.

Thanks for sharing the fairy tale :-)

On 11 May 2015 at 23:22, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 11/05/2015 22:27, Igor Stasenko a écrit :

...

On 10 May 2015 at 10:23, stepharo <stepharo@free.fr> wrote:

...

i think there is a fundamental difference between 'stream' and 'update on

...

the screen' . Choose one and stick to it.

...

We shall separate such responsibilities and NEVER ever merge them again , even if it was cool, nice, soft and puffy in the past. Yes, sure, we can then build the facade on top of that providing similar behavior of what was in the past..

But if not, then it will always be something that will forever be causing problem, since it is conceptually wrong and looks like attempt to cross breed two different species.

<OT> I have no particular opinions about Transcsript, but I would like to say that I am very happy to have Igor back in the Squeak/Pharo/Cuis/Smalltalk discussions. I may not agree with everything, but I really appreciate his thoughtful perspective. There are a few people whose posts I will always read, and Igor is one of them. </OT>

Thanks Dave. I share the same feelings.

Dave

...

Guys, that was completely unnecessary. :)

My problem with transcript was always a multiple layers penetration to get things done. And Cuis version is good demonstration to that (sorry, Juan): - who the heck needs APIs, protocols and overall design rules, if we can just cut through things to get to the functionality we need and put things one the screen right away without dabbling with Morphic/whatever? Because why not? Half of Squeak (and subsequently, Pharo) code is written that way anyways.. Following such development style, then i should rewrite everything in assembler, make it work blazingly fast, and who are you to criticize thing that works well and outperforms everything that ever written before? Right?

What is broken, needs to be fixed. Who opposed that? I just have different than Eliot view on what is broken and consequently, what is needed to fix it. Note, that i *want* the very same behavior at the end. I want transcript that can handle immediate updates on the screen. But i want it to be async, and do not impact the performance of the system, because it is awful, when console output takes 99% of your computation resources. Sure, it may be cool for VM devs, but have you thought about rest of use cases? Because there's plenty of them, and not all of them require immediate feedback on the screen. My 'doctrine' is to have a versatile tool that suits well for many use cases, not just one.

P.S. Please note, i said nothing new about Transcript that i wasn't saying couple years ago to Stef and to other people i was communicating with.. Yeah time runs fast, and not everything you want can be done, but it doesn't means that i changed my mind. I wonder, how other people feel, when they stating obvious (to their thinking), and others look at them as a doctrinal dumbass. That's how i feel. :)

Igor, of course nobody never saw you as a 'doctrinal dumbass' you are 100% correct on all you said, Elliot is just pragmatic here and does want to go into other considerations that would break the workflow he likes and introduce complexity where there is largely enough, may be that made him overreacting a little... this can happen to anybody

Don't think i am overreacting on Eliot's overreacting whatever.. We're a good friends, and pike fight on mailing list is not gonna change that. I just stating my POV, he stating own.. and that's how i see it, if you remove the giggles :).

If he needs some tools or has some specific requirements that are doable, why not trying to give him and Clement even if they are not the bests ? I see the CuisTranscript as a pragmatic solution that does not change too much things since vm developement is complex and needs a proven basis, plus as explained by Clement too sophisticated tools cannot be used sometimes.

So, why complaining? Why not just do it. Or do you think i will scream 'over my dead body' or what? If you know how to make it better, do it. I popped-out here mainly to explain the motivation of changes we did,and to point out on the problems we had in the past and shared some insights how i would deal with it.

That said, about Transcript being asynchronous, I fully agree that it would be be better, but I guess it would also imply some serious changes in UI process and the World>>doOnecycle concept (that would be good anyway, it is weird). I also think my suggestion of asynchronous do-it has some other interests (exploration of futures in asynchronous processing for example), but I am not interested in fighting on that, it's overkill here with too much complexity introduced.

One thing at a time. I don't think it is too hard to do, or make things overly complex. What is true,is that we got little or no incentive/resources among people, to do that.

:)

-- Regards,

Alain

-- Best regards, Igor Stasenko.

On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

True.. but this is only highlights how deeply broken the overall system around UI are. Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ? I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning. I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)

...

and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?

And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point)

I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?

-- Regards,

Alain

-- best, Eliot

-- Best regards, Igor Stasenko.

On 8 May 2015 at 19:39, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

True.. but this is only highlights how deeply broken the overall system around UI are. Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ? I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning.

I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)

I still don't hear any rationale for the transcript not updating itself when it does flush/endEntry:. I still don't hear any rationale for the morphic transcript behaving differently to a stdout transcript. In that case, it only makes sense to fix the transcript, right?

Transcript is not an UI element, it is a stream. Period.

From that perspective, is it *not* broken in Pharo and works well. You can write to transcript and everything you written to it is not lost and recorded.. to be later piped wherever used wants it to. I repeat again, Transcript is *not* an UI element simply because it works even if there's no any transcript window open. From that perspective the 'flush' command issued cannot be interpreted as a 'do whatever it takes and deliver immediately my contents to the screen', because obviously there may be no any screen nor window.. So, the 'flush' behavior is more like a soft hint, that can be completely ignored (making users mad :) ) rather than strict command.

So, forcing updates to the screen (even if you not really neeed it), is a separate issue, and as to me, has little to do with transcript, because it is more general problem of being able to update screen at the moment you want, not at the moment, when a system designed to do that.

...

...

...

and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?

And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point)

I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?

-- Regards,

Alain

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

On 8 May 2015 at 20:00, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 8, 2015 at 10:52 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:39, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

True.. but this is only highlights how deeply broken the overall system around UI are. Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ? I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning.

I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)

I still don't hear any rationale for the transcript not updating itself when it does flush/endEntry:. I still don't hear any rationale for the morphic transcript behaving differently to a stdout transcript. In that case, it only makes sense to fix the transcript, right?

Transcript is not an UI element, it is a stream. Period.

Ah, a write-only invisible transcript. Riiiight. Really useful to log output to somewhere no one can see it. Riiight.

No, Igor, the Transcript is a UI element and a stream. It is a place to

log textual output where the programmer can see it. It is Smalltalk's standard output console. If one ants a stream which will record output one can use a file. If one wants to see it in real time, one uses a transcript.

what if i want to log to stdout.. why i need morphic UI element? Look, understand me wrong not. ;) I am not against having a UI element that showing the contents of transcript (or any other stream, why not?) and updates it as soon as possible (or as often as users see fit). Such element is indeed quite useful and quite needed.. What i am against is putting equality sign between transcript and such UI element. It is two different things, two different concerns. That's it.

...

From that perspective, is it *not* broken in Pharo and works well. You can write to transcript and everything you written to it is not lost and recorded.. to be later piped wherever used wants it to. I repeat again, Transcript is *not* an UI element simply because it works even if there's no any transcript window open. From that perspective the 'flush' command issued cannot be interpreted as a 'do whatever it takes and deliver immediately my contents to the screen', because obviously there may be no any screen nor window.. So, the 'flush' behavior is more like a soft hint, that can be completely ignored (making users mad :) ) rather than strict command.

So, forcing updates to the screen (even if you not really neeed it), is a separate issue, and as to me, has little to do with transcript, because it is more general problem of being able to update screen at the moment you want, not at the moment, when a system designed to do that.

...

...

...

...

and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?

And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point)

I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?

-- Regards,

Alain

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

On 8 May 2015 at 20:23, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 8, 2015 at 11:16 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 20:00, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 10:52 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:39, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com

...

wrote:

...

Le 08/05/2015 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

True.. but this is only highlights how deeply broken the overall system around UI are. Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ? I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning.

I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)

I still don't hear any rationale for the transcript not updating itself when it does flush/endEntry:. I still don't hear any rationale for the morphic transcript behaving differently to a stdout transcript. In that case, it only makes sense to fix the transcript, right?

Transcript is not an UI element, it is a stream. Period.

Ah, a write-only invisible transcript. Riiiight. Really useful to log output to somewhere no one can see it. Riiight.

No, Igor, the Transcript is a UI element and a stream. It is a place to

...

log textual output where the programmer can see it. It is Smalltalk's standard output console. If one ants a stream which will record output one can use a file. If one wants to see it in real time, one uses a transcript.

what if i want to log to stdout.. why i need morphic UI element?

I've said my piece. You're making me laugh. Keep digging.

What's so funny? Would you be against having a widget, called , for instance 'stream contents viewer', that can be connected to any writeable stream and which display contents of that stream? And then sure thing, once we got such widget, it wouldn't be a much of a hassle to hook it with transcript stream and everyone is happy and joyful. Again, what is so funny in redirecting transcript to stdout or file? What if i run things on a server and can only connect via console and need to be aware of what happening with my image? Does that sounds funny?

Look, understand me wrong not. ;)

...

I am not against having a UI element that showing the contents of transcript (or any other stream, why not?) and updates it as soon as possible (or as often as users see fit). Such element is indeed quite useful and quite needed.. What i am against is putting equality sign between transcript and such UI element. It is two different things, two different concerns. That's it.

...

...

From that perspective, is it *not* broken in Pharo and works well. You can write to transcript and everything you written to it is not lost and recorded.. to be later piped wherever used wants it to. I repeat again, Transcript is *not* an UI element simply because it works even if there's no any transcript window open. From that perspective the 'flush' command issued cannot be interpreted as a 'do whatever it takes and deliver immediately my contents to the screen', because obviously there may be no any screen nor window.. So, the 'flush' behavior is more like a soft hint, that can be completely ignored (making users mad :) ) rather than strict command.

So, forcing updates to the screen (even if you not really neeed it), is a separate issue, and as to me, has little to do with transcript, because it is more general problem of being able to update screen at the moment you want, not at the moment, when a system designed to do that.

...

...

...

...

and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?

And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point)

I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?

-- Regards,

Alain

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

-- Best regards, Igor Stasenko.

On 8 May 2015 at 21:00, Clément Bera <bera.clement@gmail.com> wrote:

2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

...

On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua@gmail.com> wrote:

...

On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?

...

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

True.. but this is only highlights how deeply broken the overall system around UI are. Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ? I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning.

I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)

I still don't hear any rationale for the transcript not updating itself when it does flush/endEntry:. I still don't hear any rationale for the morphic transcript behaving differently to a stdout transcript. In that case, it only makes sense to fix the transcript, right?

That was my original point. I would like a tool, as used to be the Transcript, that has the same behavior than the stdout transcript but shows the stream in the image instead of the command line.

In Pharo stdout is not broken. It works fine and I use it often. You can start Pharo from the command line and try the do-it:

1 to: 100 do: [ :i | 0.1 seconds asDelay wait. FileStream stdout << 'x'. ]

x is displayed every 100 ms on the command line.

Only the Transcript has a different behavior, which is not compatible with the use cases of VM development.

The rationale was to change things in a way that: - updates on the screen should not impact heavily the performance of the system and should not happen more often than actual physical screen can update itself, not speaking about that users's cannot read text that flies at the light speed before your eyes and therefore completely useless from the usability perspective. Another rationale is that the only facility that should know how 'immediately' of 'forcibly' update the screen should be the GUI framework, and should properly expose such functionality via its own API or whatever.. but not the strangely wired and single utility (albeit quite useful), that tries to force updates on the screen disregarding everything and stalling the system, burning cpu on redrawing the screen faster than anyone can read.. -- Best regards, Igor Stasenko.

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup. Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities. I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions. So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity Which of these is broken depends on your viewpoint. For which I see two solutions: 1. Next to the doIt menu item add a forkIt menu item -- so its optional, but not the default 2. Have a Preference that enables Transcript>>nextPut: to call #changed: The first I think could be useful anyway, not having to do a cumbersome coded fork. This would also provide a measure of documentation and discoverability. There might be a submenu for forking at the different user priorities. For the second, it would be pragmatic to do what we can to facilitate VM development on Pharo. The preference can describe how it might adverse affect multithreaded applications. cheers -ben On Sat, May 9, 2015 at 3:12 AM, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 08 May 2015, at 21:00, Clément Bera <bera.clement@gmail.com> wrote:

2015-05-08 19:39 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

On Fri, May 8, 2015 at 10:32 AM, Igor Stasenko <siguctua@gmail.com> wrote:

On 8 May 2015 at 19:22, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Fri, May 8, 2015 at 9:21 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote: Le 08/05/2015 16:16, Eliot Miranda a écrit : Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Yes using World dooneCycle is bad, but forking another process not bad IMHO:

There is probably a solution to make the Transcript less moronic and refresh the world (it seems very different from Squeak transcript) but it would be an uncomplete specific-to-Transcript solution.

Why? Why wouldn't it e a general solution that was available to any morph that wanted to update its contents immediately?

The first thing I did when I tried Stef's example in Squeak was trying to move the window (it was a bit overlapped by my workspace) but I couldn't.

If we do [ | m | [ m := BorderedMorph new borderColor: (Color yellow) . m position: 0@0. m openInWorld . 1 to: 500 do: [ :i | m position: i@i . 1 milliSeconds asDelay wait ] ] ensure: [ m delete ] . ] value we see nothing. if we replace value by fork, we can see a morph moving , because of the way Morphic world runs you know that of course, it's just that this example does not sound nice to me too.

Wouldn't it be better to execute do-it (s) systematically in another process ?

I find this faintly absurd. This is, in the English phrase, the tail wagging the dog. You don;t know how many issues executing doits in their own process will cause (it could break Monticello package update for example, when running package postscripts, it could prevent doits doing simple things, for example) all for want of the transcript updating itself. So instead of fixing the problem we're considering introducing huge unknowns in a core piece of the system? I think that's a little mad.

True.. but this is only highlights how deeply broken the overall system around UI are. Why would MC postscripts need to run in UI thread? Aren't they should be completely independent of having UI process at all (unless we're talking about packages that actually providing these facilities) ? I know that running doits in separate process is 'bad idea' (tm). Only because of original bad idea in the past to not care about clearly separate things and rely on de-facto non-linear and intricate dependencies in system, that established over the years, because of lack of design and planning.

I know it may sound like an arrogant moron blabbery, but it doesn't means i wrong :)

I still don't hear any rationale for the transcript not updating itself when it does flush/endEntry:. I still don't hear any rationale for the morphic transcript behaving differently to a stdout transcript. In that case, it only makes sense to fix the transcript, right?

That was my original point. I would like a tool, as used to be the Transcript, that has the same behavior than the stdout transcript but shows the stream in the image instead of the command line.

In Pharo stdout is not broken. It works fine and I use it often. You can start Pharo from the command line and try the do-it:

1 to: 100 do: [ :i | 0.1 seconds asDelay wait. FileStream stdout << 'x'. ]

x is displayed every 100 ms on the command line.

We also have NonInteractiveTranscript which I use a lot !

...

Only the Transcript has a different behavior, which is not compatible with the use cases of VM development.

IMHO this is a discussion about efficiency, the price you are willing to pay: the old system was slow because it tries to update for each #endEntry, the new system is way faster, but does not update if you block the UI thread. (There are also correctness issues, the red screen of death).

It would not be too hard to image this being an option/setting.

The 'better' design would be to have a stream viewer thing that is clever enough to batch updates if they come fast and only draw them when needed.

...

and have a friendly way to control those processes, a bit similar to what happens when you launch your program in other IDEs like eclipse, visual studio, it starts another process ?

And to start, with a simple right-click menu option : 'Do it async' to experiment (from a recent discussion, may be few problems with the inspector, but that's another point)

I don't know how it works under other smalltalks, does it blocks under VisualWorks when you execute some do-it ?

-- Regards,

Alain

-- best, Eliot

-- Best regards, Igor Stasenko.

-- best, Eliot

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil.

3. Thinking further on this, I suppose the main issue from the original example is that its running in the UI thread. In this case I guess calling #changed: and #refreshWorld is okay (there have been no problems in Squeak). So in ThreadSafe>>endEntry we could check to see if we are in the UI thread and only in that case issue #changed:. So only the "user interactive" workspace will see the "slow" behaviour (which any is too fast for a human to notice), and forked processes will not be slowed. cheers -ben

There are too many assumptions throughout the system that the UI is single

...

threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

...

For which I see two solutions: 1. Next to the doIt menu item add a forkIt menu item -- so its optional, but not the default 2. Have a Preference that enables Transcript>>nextPut: to call #changed:

Is this the entire solution space?

See (3.) above. 4. Run Workspaces in their own thread per VW (but that already got knocked down)

Are there not ways of engineering the transcript to update at, say, 10Hz?

Can the transcript not be made to render changes much faster?

Still thinking about these.

I see terminals with performance thousands of times faster than the transcript that still display output immediately. I don't understand why the Squeak transcript is so slow. That's a bug also.

...

The first I think could be useful anyway, not having to do a cumbersome coded fork. This would also provide a measure of documentation and discoverability. There might be a submenu for forking at the different user priorities.

For the second, it would be pragmatic to do what we can to facilitate VM development on Pharo. The preference can describe how it might adverse affect multithreaded applications.

cheers -ben

On Sun, May 10, 2015 at 12:35 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

Hi Ben,

On Sat, May 9, 2015 at 8:18 AM, Ben Coman <btc@openinworld.com> wrote:

...

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil.

3. Thinking further on this, I suppose the main issue from the original example is that its running in the UI thread. In this case I guess calling #changed: and #refreshWorld is okay (there have been no problems in Squeak). So in ThreadSafe>>endEntry we could check to see if we are in the UI thread and only in that case issue #changed:. So only the "user interactive" workspace will see the "slow" behaviour (which any is too fast for a human to notice), and forked processes will not be slowed.

So what about doing something such as remembering the last time the transcript updated the UI, and a) not allowing #changed to update the UI if it has been less than x milliseconds since it was last updated, and b) scheduling a deferred ui update when #changed is filtered-out in this way and c) cancelling the deferred ui update if another transcript update occurs before the deferred update is processed.

Hi Eliot, Just to let you know I've been contemplating this. It sounds a good idea, but I've been too tired the past few nights to dig into it further. Also l like Cuis' Transcript for being extremely self contained and so I guess harder to break accidentally, but it was missing editing and highlighting. So I was waiting to see if there were more opinions arising from that. cheers -ben

...

cheers -ben

...

There are too many assumptions throughout the system that the UI is

...

single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

...

For which I see two solutions: 1. Next to the doIt menu item add a forkIt menu item -- so its optional, but not the default 2. Have a Preference that enables Transcript>>nextPut: to call #changed:

Is this the entire solution space?

See (3.) above. 4. Run Workspaces in their own thread per VW (but that already got knocked down)

...

Are there not ways of engineering the transcript to update at, say, 10Hz?

Can the transcript not be made to render changes much faster?

...

Still thinking about these.

...

I see terminals with performance thousands of times faster than the transcript that still display output immediately. I don't understand why the Squeak transcript is so slow. That's a bug also.

...

...

The first I think could be useful anyway, not having to do a cumbersome coded fork. This would also provide a measure of documentation and discoverability. There might be a submenu for forking at the different user priorities.

For the second, it would be pragmatic to do what we can to facilitate VM development on Pharo. The preference can describe how it might adverse affect multithreaded applications.

cheers -ben

-- best, Eliot

Hi Ben, first, thanks for responding dispassionately to the technical issues. As far as thread-safety I thought the issue with the transcript was not providing some form of protection against unpredictable interleavings of output from multiple separate processes, but was just avoiding lock-up. If one outputs to another kind of stream (file, terminal window) from multiple processes you typically get jumbled output on a first-come first-served basis. What one wants IMO is that the transcript remains robust, with no red morphs of death, not that output is interleaved with a specific policy. Eliot (phone) On May 9, 2015, at 8:54 AM, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

As a point of comparison for correctness, for the following...

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

Squeak 4.5 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 $h2 $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 $b7 $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 $u3 $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 $o4 $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 $m5 $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 $k6 $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 $l7 $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 $h8 $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 $f9 $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 $u9 $u9 $z9 $x9

Pharo 50041 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 $e2 $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 $g3 $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 $i4 $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 $m6 $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 $o7 $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 $q8 $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 $s9 $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 $v1 $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 $x2 $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 $z3 $z4 $z5 $z6 $z7 $z8 $z9

(start your comparison at $b5)

So in one axis Pharo has improved Transcript, but we didn't notice the significance of the use case we lost.

cheers -ben

On 10 May 2015 at 13:57, Ben Coman <btc@openinworld.com> wrote:

...

not that output is interleaved with a specific policy.

Hi Eliot,

I guess it was hard to analyse that output dump from your phone, and I should have been more explicit. The problem is not the interleave order, but duplicate and missing output items. I've cut down the example and and manually reordered the Squeak items to make it easier to see this.

Transcript clear. [ $a asciiValue to: $h asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' '. Processor yield. ]. ] forkAt: 40. ]. ] forkAt: 41.

Squeak 4.5 gives... $a1 $b1 $b1 $c1 $d1 $e1 $f1 $g1 $h1 $a2 $b2 $b2 $c2 $d2 $e2 $f2 $g2 $h2 $a3 $b3 $b3 $c3 $d3 $b4 $d4 $f4 $g4 $g4 $b5 $c5 $d5 $d5 $f5 $a6 $a6 $c6 $d6 $e6 $f6 $g6 $h6 $a7 $b7 $d7 $d7 $g7 $h7 $f7 $a8 $a8 $b8 $c8 $c8 $f8 $g8 $h8 $h8 $b9 $b9 $c9 $e9 $e9 $f9 $f9 $g9 $h9

Pharo 50041 gives... $a1 $b1 $c1 $d1 $e1 $f1 $g1 $h1 $a2 $b2 $c2 $d2 $e2 $f2 $g2 $h2 $a3 $b3 $c3 $d3 $e3 $f3 $g3 $h3 $a4 $b4 $c4 $d4 $e4 $f4 $g4 $h4 $a5 $b5 $c5 $d5 $e5 $f5 $g5 $h5 $a6 $b6 $c6 $d6 $e6 $f6 $g6 $h6 $a7 $b7 $c7 $d7 $e7 $f7 $g7 $h7 $a8 $b8 $c8 $d8 $e8 $f8 $g8 $h8 $a9 $b9 $c9 $d9 $e9 $f9 $g9 $h9

The Pharo output is untouched (except to insert newlines). Its ordering is only a side effect of correct behaviour wrt showing *all* output *once only*. Indeed its only a side effect that the output ordering (presumably) reflects the actual order that processes were scheduled -- but actually this is a critical advantage when trying to debug multi-threaded race conditions.

cheers -ben

On Sun, May 10, 2015 at 12:20 AM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

Hi Ben,

first, thanks for responding dispassionately to the technical issues.

As far as thread-safety I thought the issue with the transcript was not providing some form of protection against unpredictable interleavings of output from multiple separate processes, but was just avoiding lock-up. If one outputs to another kind of stream (file, terminal window) from multiple processes you typically get jumbled output on a first-come first-served basis. What one wants IMO is that the transcript remains robust, with no red morphs of death, not that output is interleaved with a specific policy.

How you gonna ensure that, when only tool that you have is a completely single-minded (err.. threaded :) ) / thread unsafe Morphic in your hands, that is absolutely dangerous to use outside UI thread and recipe for disaster when fiddling with its state or interrupting it at non-safe point? Red morphs of death is actually a good sign of that, that Morphic has little to offer to those, who dare to use multiple threads. Sometimes i thinking, would it be better to throw away all that multi-threading crafts in VM and image, and make smalltalk *way more* simpler and straight (like many other interpreted languages, that don't have threads).. Because bulk majority 99.999% of our codebase never using/deals with threading anyways. Besides, most of the people finding multi-threading bizarre and confusing.. So, lets just throw it away, no big loss. :) P.S. and i didn't meant to sound passionate, but rather sarcastic :)

Eliot (phone)

...

-- Best regards, Igor Stasenko.

Hi Folks, (below) Quoting Ben Coman <btc@openinworld.com>:

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

As a point of comparison for correctness, for the following...

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

Squeak 4.5 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 $h2 $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 $b7 $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 $u3 $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 $o4 $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 $m5 $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 $k6 $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 $l7 $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 $h8 $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 $f9 $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 $u9 $u9 $z9 $x9

Pharo 50041 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 $e2 $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 $g3 $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 $i4 $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 $m6 $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 $o7 $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 $q8 $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 $s9 $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 $v1 $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 $x2 $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 $z3 $z4 $z5 $z6 $z7 $z8 $z9

(start your comparison at $b5)

So in one axis Pharo has improved Transcript, but we didn't notice the significance of the use case we lost.

cheers -ben

Please take a good look at Cuis' Transcript and consider using it. By default, the display is updated immediately, but without calling Morphic, it can even work with no UI framework at all. It does updates faster than Squeak or Visualworks: Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. 763. But if you want minimum overhead without immediate feedback: Time millisecondsToRun: [ Transcript showOnDisplay: false. 1000 timesRepeat: [ Transcript show: 'x' ]. Transcript showOnDisplay: true ]. 1. "As fast as Pharo" It is also thread safe, and for Ben's example: Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41 it gives the same result as Pharo. The fact that the updates are not bound to Morphic also means that it is possible to do #show: deep in Morphic logic, without causing infinite loops or recursions, and get immediate feedback. It has proved to be a useful aid in debugging Morphic code. Cheers, Juan Vuletich

Yes, the Cuis implementation is cool. Especially because it implements both the limited/circular buffer and timed/batched updating. It does however mix different things in 1 class (side!): the transcript stream behavior, the display/tool part, an alternative file output, some sort of newer API, and more logging oriented thing (adding a timestamp). These are all things that we would like to separate, make modular/pluggable.

On 09 May 2015, at 19:17, J. Vuletich (mail lists) <juanlists@jvuletich.org> wrote:

Hi Folks,

(below)

Quoting Ben Coman <btc@openinworld.com>:

...

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

As a point of comparison for correctness, for the following...

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

Squeak 4.5 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 $h2 $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 $b7 $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 $u3 $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 $o4 $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 $m5 $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 $k6 $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 $l7 $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 $h8 $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 $f9 $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 $u9 $u9 $z9 $x9

Pharo 50041 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 $e2 $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 $g3 $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 $i4 $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 $m6 $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 $o7 $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 $q8 $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 $s9 $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 $v1 $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 $x2 $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 $z3 $z4 $z5 $z6 $z7 $z8 $z9

(start your comparison at $b5)

So in one axis Pharo has improved Transcript, but we didn't notice the significance of the use case we lost.

cheers -ben

Please take a good look at Cuis' Transcript and consider using it.

By default, the display is updated immediately, but without calling Morphic, it can even work with no UI framework at all. It does updates faster than Squeak or Visualworks:

Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. 763.

But if you want minimum overhead without immediate feedback:

Time millisecondsToRun: [ Transcript showOnDisplay: false. 1000 timesRepeat: [ Transcript show: 'x' ]. Transcript showOnDisplay: true ]. 1. "As fast as Pharo"

It is also thread safe, and for Ben's example:

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

it gives the same result as Pharo.

The fact that the updates are not bound to Morphic also means that it is possible to do #show: deep in Morphic logic, without causing infinite loops or recursions, and get immediate feedback. It has proved to be a useful aid in debugging Morphic code.

Cheers, Juan Vuletich

Le 9/5/15 20:51, Sven Van Caekenberghe a écrit :

Yes, the Cuis implementation is cool. Especially because it implements both the limited/circular buffer and timed/batched updating.

I should finish my circular linkedList. I will resume it.

It does however mix different things in 1 class (side!): the transcript stream behavior, the display/tool part, an alternative file output, some sort of newer API, and more logging oriented thing (adding a timestamp). These are all things that we would like to separate, make modular/pluggable.

...

On 09 May 2015, at 19:17, J. Vuletich (mail lists) <juanlists@jvuletich.org> wrote:

Hi Folks,

(below)

Quoting Ben Coman <btc@openinworld.com>:

...

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

As a point of comparison for correctness, for the following...

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

Squeak 4.5 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 $h2 $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 $b7 $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 $u3 $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 $o4 $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 $m5 $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 $k6 $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 $l7 $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 $h8 $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 $f9 $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 $u9 $u9 $z9 $x9

Pharo 50041 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 $e2 $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 $g3 $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 $i4 $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 $m6 $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 $o7 $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 $q8 $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 $s9 $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 $v1 $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 $x2 $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 $z3 $z4 $z5 $z6 $z7 $z8 $z9

(start your comparison at $b5)

So in one axis Pharo has improved Transcript, but we didn't notice the significance of the use case we lost.

cheers -ben Please take a good look at Cuis' Transcript and consider using it.

By default, the display is updated immediately, but without calling Morphic, it can even work with no UI framework at all. It does updates faster than Squeak or Visualworks:

Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. 763.

But if you want minimum overhead without immediate feedback:

Time millisecondsToRun: [ Transcript showOnDisplay: false. 1000 timesRepeat: [ Transcript show: 'x' ]. Transcript showOnDisplay: true ]. 1. "As fast as Pharo"

It is also thread safe, and for Ben's example:

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

it gives the same result as Pharo.

The fact that the updates are not bound to Morphic also means that it is possible to do #show: deep in Morphic logic, without causing infinite loops or recursions, and get immediate feedback. It has proved to be a useful aid in debugging Morphic code.

Cheers, Juan Vuletich

On Sat, May 9, 2015 at 10:17 AM, J. Vuletich (mail lists) < juanlists@jvuletich.org> wrote:

Hi Folks,

(below)

Quoting Ben Coman <btc@openinworld.com>:

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com>

...

wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

From my limited experience bug hunting, calling #changed: from a thread

...

other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

As a point of comparison for correctness, for the following...

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

Squeak 4.5 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 $h2 $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 $b7 $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 $u3 $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 $o4 $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 $m5 $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 $k6 $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 $l7 $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 $h8 $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 $f9 $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 $u9 $u9 $z9 $x9

Pharo 50041 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 $e2 $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 $g3 $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 $i4 $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 $m6 $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 $o7 $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 $q8 $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 $s9 $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 $v1 $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 $x2 $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 $z3 $z4 $z5 $z6 $z7 $z8 $z9

(start your comparison at $b5)

So in one axis Pharo has improved Transcript, but we didn't notice the significance of the use case we lost.

cheers -ben

Please take a good look at Cuis' Transcript and consider using it.

By default, the display is updated immediately, but without calling Morphic, it can even work with no UI framework at all. It does updates faster than Squeak or Visualworks:

Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. 763.

But if you want minimum overhead without immediate feedback:

Time millisecondsToRun: [ Transcript showOnDisplay: false. 1000 timesRepeat: [ Transcript show: 'x' ]. Transcript showOnDisplay: true ]. 1. "As fast as Pharo"

It is also thread safe, and for Ben's example:

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

it gives the same result as Pharo.

Thanks Juan, that sounds perfect. I'll take a look asap!

The fact that the updates are not bound to Morphic also means that it is possible to do #show: deep in Morphic logic, without causing infinite loops or recursions, and get immediate feedback. It has proved to be a useful aid in debugging Morphic code.

Cheers, Juan Vuletich

-- best, Eliot

Hi Eliot, Yes, that's the active repo, and that's latest commit. You might also take a look at the packages folder. Not related to Transcript, but there is a lot of good stuff in there. Cheers, Juan Vuletich Quoting Eliot Miranda <eliot.miranda@gmail.com>:

Hi Juan,

I'm cloning https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev and will take a look at Cuis4.2-2280. Is that right?

On Sat, May 9, 2015 at 10:17 AM, J. Vuletich (mail lists) < juanlists@jvuletich.org> wrote:

...

Hi Folks,

(below)

Quoting Ben Coman <btc@openinworld.com>:

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda@gmail.com>

...

wrote:

...

On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc@openinworld.com> wrote:

From my limited experience bug hunting, calling #changed: from a thread

...

other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

This better performance helped me a lot trying to understand the high priority timerEventLoop being able to indiscriminately scatter Transcript tracing through that code. I believe its also probably beneficial for working with externally triggered semaphores and timing sensitive race conditions.

So we have two mutually exclusive cases: * better interactivity, poorer system performance * faster system performance, worse interactivity

Which of these is broken depends on your viewpoint.

Something that runs fast but is incorrect is still incorrect. The fact that the transcript doesn't output until a world step is possible is a bug. It forces programs that use the transcript to be rewritten in order to see transcript output.

As a point of comparison for correctness, for the following...

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

Squeak 4.5 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b5 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $d9 $e2 $g2 $h2 $h2 $i2 $k2 $k2 $l2 $n2 $n2 $o2 $o2 $r2 $s2 $t2 $u2 $u2 $v2 $x2 $y2 $z2 $z2 $b7 $f3 $e3 $e3 $g3 $j3 $h3 $i3 $k3 $k3 $m3 $n3 $p3 $p3 $q3 $o3 $s3 $t3 $t3 $u3 $v3 $x3 $y3 $z3 $b8 $f4 $e4 $e4 $g4 $h4 $i4 $k4 $l4 $m4 $m4 $n4 $r4 $q4 $o4 $o4 $s4 $w4 $u4 $u4 $v4 $y4 $y4 $z4 $z4 $f5 $j5 $j5 $g5 $i5 $k5 $l5 $l5 $m5 $m5 $n5 $q5 $o5 $s5 $s5 $t5 $u5 $u5 $x5 $y5 $z5 $f6 $f6 $h6 $h6 $g6 $g6 $k6 $p6 $m6 $r6 $r6 $n6 $o6 $s6 $s6 $w6 $u6 $x6 $x6 $e7 $f7 $j7 $h7 $h7 $i7 $l7 $l7 $k7 $m7 $m7 $q7 $n7 $n7 $o7 $t7 $w7 $w7 $u7 $v7 $x7 $z7 $z7 $e8 $e8 $h8 $g8 $i8 $i8 $l8 $k8 $k8 $m8 $q8 $n8 $n8 $s8 $t8 $w8 $y8 $y8 $u8 $x8 $z8 $f9 $f9 $e9 $h9 $h9 $g9 $p9 $p9 $k9 $r9 $r9 $m9 $n9 $n9 $o9 $t9 $t9 $w9 $v9 $u9 $u9 $z9 $x9

Pharo 50041 gives... $a1 $a2 $a3 $a4 $a5 $a6 $a7 $a8 $a9 $b1 $b2 $b3 $b4 $b5 $b6 $b7 $b8 $b9 $c1 $c2 $c3 $c4 $c5 $c6 $c7 $c8 $c9 $d1 $d2 $d3 $d4 $d5 $d6 $d7 $d8 $d9 $e1 $e2 $e3 $e4 $e5 $e6 $e7 $e8 $e9 $f1 $f2 $f3 $f4 $f5 $f6 $f7 $f8 $f9 $g1 $g2 $g3 $g4 $g5 $g6 $g7 $g8 $g9 $h1 $h2 $h3 $h4 $h5 $h6 $h7 $h8 $h9 $i1 $i2 $i3 $i4 $i5 $i6 $i7 $i8 $i9 $j1 $j2 $j3 $j4 $j5 $j6 $j7 $j8 $j9 $k1 $k2 $k3 $k4 $k5 $k6 $k7 $k8 $k9 $l1 $l2 $l3 $l4 $l5 $l6 $l7 $l8 $l9 $m1 $m2 $m3 $m4 $m5 $m6 $m7 $m8 $m9 $n1 $n2 $n3 $n4 $n5 $n6 $n7 $n8 $n9 $o1 $o2 $o3 $o4 $o5 $o6 $o7 $o8 $o9 $p1 $p2 $p3 $p4 $p5 $p6 $p7 $p8 $p9 $q1 $q2 $q3 $q4 $q5 $q6 $q7 $q8 $q9 $r1 $r2 $r3 $r4 $r5 $r6 $r7 $r8 $r9 $s1 $s2 $s3 $s4 $s5 $s6 $s7 $s8 $s9 $t1 $t2 $t3 $t4 $t5 $t6 $t7 $t8 $t9 $u1 $u2 $u3 $u4 $u5 $u6 $u7 $u8 $u9 $v1 $v2 $v3 $v4 $v5 $v6 $v7 $v8 $v9 $w1 $w2 $w3 $w4 $w5 $w6 $w7 $w8 $w9 $x1 $x2 $x3 $x4 $x5 $x6 $x7 $x8 $x9 $y1 $y2 $y3 $y4 $y5 $y6 $y7 $y8 $y9 $z1 $z2 $z3 $z4 $z5 $z6 $z7 $z8 $z9

(start your comparison at $b5)

So in one axis Pharo has improved Transcript, but we didn't notice the significance of the use case we lost.

cheers -ben

Please take a good look at Cuis' Transcript and consider using it.

By default, the display is updated immediately, but without calling Morphic, it can even work with no UI framework at all. It does updates faster than Squeak or Visualworks:

Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. 763.

But if you want minimum overhead without immediate feedback:

Time millisecondsToRun: [ Transcript showOnDisplay: false. 1000 timesRepeat: [ Transcript show: 'x' ]. Transcript showOnDisplay: true ]. 1. "As fast as Pharo"

It is also thread safe, and for Ben's example:

Transcript clear. [ $a asciiValue to: $z asciiValue do: [ :c | [ 1 to: 9 do: [ :i | Transcript show: c asCharacter printString , i printString , ' ' ] ] forkAt: 40 ]. ] forkAt: 41

it gives the same result as Pharo.

The fact that the updates are not bound to Morphic also means that it is possible to do #show: deep in Morphic logic, without causing infinite loops or recursions, and get immediate feedback. It has proved to be a useful aid in debugging Morphic code.

Cheers, Juan Vuletich

-- best, Eliot

On 09 May 2015, at 16:41, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com> wrote: From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

I am not sure, but in VW it looks like each Workspace (Window) is (executing its Doit) in a separate thread. In any case, their abstraction, TextCollector is nicer.

Hi Ben, On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/ Eliot (phone)

Le 9/5/15 20:16, Clément Bera a écrit :

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

*Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ?* *Do you think a system that is not good enough to handle its own VM development is a good system ?*

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:

Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

...

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

I do not think there are many people around here that would think that it is irrelevant if the Pharo VM can be developed in Pharo or not. Of course, it is important. So, the discussion should not go to challenge this direction, but rather in you telling us the use cases that you need supported. Please note that I did not say which exact code and how it should look like. I would be interested in learning about the use cases you have. I am quite certain that there are a number of ways to support them and when we work on GT it would be useful to have your use cases on our table. Cheers, Doru On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clement@gmail.com> wrote:

2015-05-09 20:25 GMT+02:00 stepharo <stepharo@free.fr>:

...

Le 9/5/15 20:16, Clément Bera a écrit :

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

I have already stated that you believe that it is important that Pharo is able to host development for its own VM.

I am not against what you did and I am very excited with Guille's work.

Pharo is community-driven, so I am not asking the question to you only, but to the community.

...

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

*Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ?* *Do you think a system that is not good enough to handle its own VM development is a good system ?*

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

...

Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

-- www.tudorgirba.com "Every thing has its own flow"

On 10 May 2015, at 10:28, Clément Bera <bera.clement@gmail.com> wrote:

2015-05-09 23:21 GMT+02:00 Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>: I do not think there are many people around here that would think that it is irrelevant if the Pharo VM can be developed in Pharo or not. Of course, it is important.

So, the discussion should not go to challenge this direction, but rather in you telling us the use cases that you need supported. Please note that I did not say which exact code and how it should look like. I would be interested in learning about the use cases you have. I am quite certain that there are a number of ways to support them and when we work on GT it would be useful to have your use cases on our table.

Well I need many lines to explain each point and there are many... I can talk here about a few points. Then I will deal with Esteban for most of them because it is difficult to explain without an interactive discussion.

Let me explain the use cases for the Transcript for example. The issues in Pharo are: - The Transcript does not show the stream as it is printed. - The Transcript does not inherit from Stream and thus cannot print with all the methods implemented in Stream. - The Transcript does not allow the user to decorate the text with bold, italic or colors.

sorry… you can do that with squeak's transcript?

Usecase 1: Debug printing methods: In the VM you have debug printing methods, for example, to print the call stack. These methods are used from the VM simulator, to output the string in the Transcript, and in gdb, to ouput the string in the commandline. The commandline (FileStream stdout in Pharo) and the Squeak Transcript have the same behavior. In Pharo, the Transcript does not inherit from Stream so you can't use the required stream methods to print the debug printing method on the Transcript. In addition, some printing methods print a lot of things and it is important to show the stream as it is printed. For this use-case, we want to keep the smallest difference between the gdb/commadline behavior and the VM simulator/Transcript behavior. If you implement advanced tooling in GT, you therefore need to implement gdb extensions (and lldb extensions because some of us use lldb instead of gdb) and maintain them. I don't think this is a solution.

Usecase 2: CCode generation debugging: The CCodeGenerator or Slang translator translates Slang code into C code. Sometimes there is a bug. To debug, instead of generating the faulty C method into an external C file, we print only the faulty C method in the Transcript. Again, we want to keep the lowest difference between the real usecase (printing on the C file) and the debug usecase (printing on the Transcript). In Squeak the FileStream and the Transcript are both Stream, everything works as expected. In Pharo the Transcript has not the expected behavior. Again the method can be long, you can have to wait several seconds, so you'd like the transcript to show the stream as you print it.

Usecase 3: VM simulation: Simulating the VM is quite slow, especially the machine code execution simulation. During the simulation process, the UI is non interactive and shows only every while what the simulator is doing in the Transcript. It is important as sometimes when debugging with a test at each machine code instruction it could take several hours before the UI is interactive again and you want to know what is going on. I don't complain that it takes several hours because the alternatives usually require days of debugging and we can launch the VM simulator overnight. In Pharo this does not work as expected.

Usecase 4: In-image machine-code compilation: While working in the JIT compiler, sometimes the machine code generated for a bytecoded method is faulty. A common way of debugging it is to print the machine code instructions of the machine code version of the method in the Transcript. It can take a while to print, so it is important to have the Transcript showing the text as it prints. Then, the easiest way of debugging is to look at the machine code and understand what is wrong. For this purpose, we add text decoration to color jump addresses or the instructions where the instruction pointer was when the VM crashed. Then, in squeak, we can easily copy the decorated text to a workspace and generate a new version of the machine code method and compare. In machine code, it is very difficult to do analysis to have more information than just the decompiled text. We add some information while simulating because we know for example the address of specific trampolines, therefore we can print the name of the trampoline when we see that its address is called. Again, sometimes we also have to debug in gdb. In this case, we disassemble the machine code and compare it to the one from in-image compilation, so both printed strings have to be similar (similar text, same chariot returns).

Another example is the complexity of the Pharo tools:

While developing the VM, I have sometimes a VM partially working or with some plugins not working. In the Squeak image, I can open a workspace on top of this half-working VM and run do-its to see what is working and what is not. In the Pharo image, I can't do anything. You can't open the workspace without opening more advanced tools. I tried to open the Playground, but the first time there was a bug with Traits (Playground use Traits somehow and they were not working due to the new bytecode set not being finished), when that first bug was fixed I could not open it because it crashed simply the VM (I believe it tried to access an external file such as playground-cache). Currently, the Pharo team is trying to build a set of basic tools that have few dependencies to debug a partially working system (that I think you will use to debug glamour while editing it, because you cannot use the glamour inspector if glamour is not working). That would solve this issue. But in no way this point is something that I can do alone to be able to develop the VM in Pharo. This has to be a community effort. And I am saying that because I can't be blamed not to work on the VM in Pharo if to do so I need to spend many months changing Pharo.

An example that I believe is a problem in term of the community is the following:

I added with Eliot the support for the new bytecode set. Currently, the Squeak image works with the new bytecode set but not the Pharo image. This is because only the Traits are broken, but this is something I could hardly figure out in the Pharo image because nothing is working as the GT tools use Traits. In Squeak I believe there are very few users of Traits so everything worked, and the test suite can reveal that the Traits are broken easily.

Currently, the VM process to me is to first make new features work in Squeak, because it is simpler, and then make it work with Pharo, which is more complex. In the last section I discussed how Traits were a problem while implementing the new bytecode set. So what is the long term solution for this issue ? - Will we have a bootstrap process that creates first a Trait-free Kernel and then build the Pharo Kernel out of it ? - Do we forbid people to use Traits in the Pharo Kernel and does that make sense to have Traits in Pharo in this case ? - If we don't do anything, maybe the Traits are only a slight difference with low impact in most cases and it's fine. But maybe there are many small aspects like Traits, such as the Slots the way they were used in GT recently (I don't blame GT or anything, it was just using features in the system that created issues for me), and maybe we reached a point where the complexity between the Pharo kernel and the Squeak kernel is big enough so that a VM developer will first make Squeak works when introducing new features and then deals with the complexity of Pharo ?

So, what do we do ? I don't see any simple solution for this issue. And I believe there are people around that see as the only solution for this issue not to have the Pharo VM development process in Pharo because they will see it as a threat to what they want to do with Pharo.

Best Doru !

PS: I am still using the GTInspector with additional views on graphs created with Roassal everyday and I still enjoy it.

PS2: I am on vacation currently because I was getting crazy looking at machine code all day long, so I may not answer as quick as usually during the next week.

Cheers, Doru

On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:

2015-05-09 20:25 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:

Le 9/5/15 20:16, Clément Bera a écrit :

...

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

I have already stated that you believe that it is important that Pharo is able to host development for its own VM.

I am not against what you did and I am very excited with Guille's work.

Pharo is community-driven, so I am not asking the question to you only, but to the community.

...

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ? Do you think a system that is not good enough to handle its own VM development is a good system ?

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>: Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

...

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote: From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

About the GTools, I am sure you know it but, you can disable them and work with the good old Workspace and (Eye-)Inspector. BTW, how do Traits depend on the bytecode set? 2015-05-10 16:43 GMT+02:00 Clément Bera <bera.clement@gmail.com>:

2015-05-10 10:37 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com>:

...

On 10 May 2015, at 10:28, Clément Bera <bera.clement@gmail.com> wrote:

2015-05-09 23:21 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

...

I do not think there are many people around here that would think that it is irrelevant if the Pharo VM can be developed in Pharo or not. Of course, it is important.

So, the discussion should not go to challenge this direction, but rather in you telling us the use cases that you need supported. Please note that I did not say which exact code and how it should look like. I would be interested in learning about the use cases you have. I am quite certain that there are a number of ways to support them and when we work on GT it would be useful to have your use cases on our table.

Well I need many lines to explain each point and there are many... I can talk here about a few points. Then I will deal with Esteban for most of them because it is difficult to explain without an interactive discussion.

Let me explain the use cases for the Transcript for example. The issues in Pharo are: - The Transcript does not show the stream as it is printed. - The Transcript does not inherit from Stream and thus cannot print with all the methods implemented in Stream. - The Transcript does not allow the user to decorate the text with bold, italic or colors.

sorry… you can do that with squeak's transcript?

Of course you can.

Try short cut such as Cmd+ 6 or Cmd + 7. Else in the right click menu those are the first 3 entries. And you can copy the decorated text from Transcript to a Workspace.

I am not sure this was changed on purpose. (from my other posts about text and fonts and my bug reports) I got the impression some people did changes (for cleanup or other reasons) and maybe don't know what they changed or didn't not find the time to finish the cleanup: TextMorph righclick does not work anymore. Some text emphasis on FT fonts dont work. Some TextMorph halos don't work anymore. I don't think alls this was done on purpose. For the Transcript shortcuts for example, if we change ThreadSafeTranscript to use PluggableTextEditorMorph instead of PluggableTextMorph cmd+6/7/8/9/0 for changing emphasis/color works again. nicolai

...

*Usecase 1: Debug printing methods:* In the VM you have debug printing methods, for example, to print the call stack. These methods are used from the VM simulator, to output the string in the Transcript, and in gdb, to ouput the string in the commandline. The commandline (FileStream stdout in Pharo) and the Squeak Transcript have the same behavior. In Pharo, the Transcript does not inherit from Stream so you can't use the required stream methods to print the debug printing method on the Transcript. In addition, some printing methods print a lot of things and it is important to show the stream as it is printed. For this use-case, we want to keep the smallest difference between the gdb/commadline behavior and the VM simulator/Transcript behavior. If you implement advanced tooling in GT, you therefore need to implement gdb extensions (and lldb extensions because some of us use lldb instead of gdb) and maintain them. I don't think this is a solution.

*Usecase 2: CCode generation debugging:* The CCodeGenerator or Slang translator translates Slang code into C code. Sometimes there is a bug. To debug, instead of generating the faulty C method into an external C file, we print only the faulty C method in the Transcript. Again, we want to keep the lowest difference between the real usecase (printing on the C file) and the debug usecase (printing on the Transcript). In Squeak the FileStream and the Transcript are both Stream, everything works as expected. In Pharo the Transcript has not the expected behavior. Again the method can be long, you can have to wait several seconds, so you'd like the transcript to show the stream as you print it.

*Usecase 3: VM simulation:* Simulating the VM is quite slow, especially the machine code execution simulation. During the simulation process, the UI is non interactive and shows only every while what the simulator is doing in the Transcript. It is important as sometimes when debugging with a test at each machine code instruction it could take several hours before the UI is interactive again and you want to know what is going on. I don't complain that it takes several hours because the alternatives usually require days of debugging and we can launch the VM simulator overnight. In Pharo this does not work as expected.

*Usecase 4: In-image machine-code compilation:* While working in the JIT compiler, sometimes the machine code generated for a bytecoded method is faulty. A common way of debugging it is to print the machine code instructions of the machine code version of the method in the Transcript. It can take a while to print, so it is important to have the Transcript showing the text as it prints. Then, the easiest way of debugging is to look at the machine code and understand what is wrong. For this purpose, we add text decoration to color jump addresses or the instructions where the instruction pointer was when the VM crashed. Then, in squeak, we can easily copy the decorated text to a workspace and generate a new version of the machine code method and compare. In machine code, it is very difficult to do analysis to have more information than just the decompiled text. We add some information while simulating because we know for example the address of specific trampolines, therefore we can print the name of the trampoline when we see that its address is called. Again, sometimes we also have to debug in gdb. In this case, we disassemble the machine code and compare it to the one from in-image compilation, so both printed strings have to be similar (similar text, same chariot returns).

Another example is the complexity of the Pharo tools:

While developing the VM, I have sometimes a VM partially working or with some plugins not working. In the Squeak image, I can open a workspace on top of this half-working VM and run do-its to see what is working and what is not. In the Pharo image, I can't do anything. You can't open the workspace without opening more advanced tools. I tried to open the Playground, but the first time there was a bug with Traits (Playground use Traits somehow and they were not working due to the new bytecode set not being finished), when that first bug was fixed I could not open it because it crashed simply the VM (I believe it tried to access an external file such as playground-cache). Currently, the Pharo team is trying to build a set of basic tools that have few dependencies to debug a partially working system (that I think you will use to debug glamour while editing it, because you cannot use the glamour inspector if glamour is not working). That would solve this issue. But in no way this point is something that I can do alone to be able to develop the VM in Pharo. This has to be a community effort. And I am saying that because I can't be blamed not to work on the VM in Pharo if to do so I need to spend many months changing Pharo.

An example that I believe is a problem in term of the community is the following:

I added with Eliot the support for the new bytecode set. Currently, the Squeak image works with the new bytecode set but not the Pharo image. This is because only the Traits are broken, but this is something I could hardly figure out in the Pharo image because nothing is working as the GT tools use Traits. In Squeak I believe there are very few users of Traits so everything worked, and the test suite can reveal that the Traits are broken easily.

Currently, the VM process to me is to first make new features work in Squeak, because it is simpler, and then make it work with Pharo, which is more complex. In the last section I discussed how Traits were a problem while implementing the new bytecode set. So what is the long term solution for this issue ? - Will we have a bootstrap process that creates first a Trait-free Kernel and then build the Pharo Kernel out of it ? - Do we forbid people to use Traits in the Pharo Kernel and does that make sense to have Traits in Pharo in this case ? - If we don't do anything, maybe the Traits are only a slight difference with low impact in most cases and it's fine. But maybe there are many small aspects like Traits, such as the Slots the way they were used in GT recently (I don't blame GT or anything, it was just using features in the system that created issues for me), and maybe we reached a point where the complexity between the Pharo kernel and the Squeak kernel is big enough so that a VM developer will first make Squeak works when introducing new features and then deals with the complexity of Pharo ?

So, what do we do ? I don't see any simple solution for this issue. And I believe there are people around that see as the only solution for this issue not to have the Pharo VM development process in Pharo because they will see it as a threat to what they want to do with Pharo.

Best Doru !

PS: I am still using the GTInspector with additional views on graphs created with Roassal everyday and I still enjoy it.

PS2: I am on vacation currently because I was getting crazy looking at machine code all day long, so I may not answer as quick as usually during the next week.

Cheers,

...

Doru

On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clement@gmail.com> wrote:

...

2015-05-09 20:25 GMT+02:00 stepharo <stepharo@free.fr>:

...

Le 9/5/15 20:16, Clément Bera a écrit :

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

I have already stated that you believe that it is important that Pharo is able to host development for its own VM.

I am not against what you did and I am very excited with Guille's work.

Pharo is community-driven, so I am not asking the question to you only, but to the community.

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

*Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ?* *Do you think a system that is not good enough to handle its own VM development is a good system ?*

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

...

Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

-- www.tudorgirba.com

"Every thing has its own flow"

Thanks Clement. I think that this is true that we should take care about all the hidden behavior (like creating repo and others). Stef Le 11/5/15 17:02, Clément Bera a écrit :

2015-05-11 13:06 GMT+02:00 Nicolai Hess <nicolaihess@web.de <mailto:nicolaihess@web.de>>:

About the GTools, I am sure you know it but, you can disable them and work with the good old Workspace and (Eye-)Inspector.

Yeah but I could not open the setting browser because you need to be able to create a directory to do so and it didn't work. I could not either run a Do-it. And EyeInspector also relies on several framework so I don't know if it would have worked.

The problem is that going to the point where you reach your bug can take a while in debug VMs / the simulator, so having to open the image form a working VM to change it and restarting the debug VM / simulator takes a while and reduce your productivity greatly compared to a squeak image.

BTW, how do Traits depend on the bytecode set?

Through markerOrNil. It looks for methods that have the pattern (at bytecode level):

selector ^ self traitConflict

I will add a fix for that next week. I am doing the next slice on things I found were not working in the new bytecode set such as traits.

2015-05-10 16:43 GMT+02:00 Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>>:

2015-05-10 10:37 GMT+02:00 Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>>:

...

On 10 May 2015, at 10:28, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:

2015-05-09 23:21 GMT+02:00 Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>:

I do not think there are many people around here that would think that it is irrelevant if the Pharo VM can be developed in Pharo or not. Of course, it is important.

So, the discussion should not go to challenge this direction, but rather in you telling us the use cases that you need supported. Please note that I did not say which exact code and how it should look like. I would be interested in learning about the use cases you have. I am quite certain that there are a number of ways to support them and when we work on GT it would be useful to have your use cases on our table.

Well I need many lines to explain each point and there are many... I can talk here about a few points. Then I will deal with Esteban for most of them because it is difficult to explain without an interactive discussion.

Let me explain the use cases for the Transcript for example. The issues in Pharo are: - The Transcript does not show the stream as it is printed. - The Transcript does not inherit from Stream and thus cannot print with all the methods implemented in Stream. - The Transcript does not allow the user to decorate the text with bold, italic or colors.

sorry… you can do that with squeak's transcript?

Of course you can.

Try short cut such as Cmd+ 6 or Cmd + 7. Else in the right click menu those are the first 3 entries. And you can copy the decorated text from Transcript to a Workspace.

I am not sure this was changed on purpose. (from my other posts about text and fonts and my bug reports) I got the impression some people did changes (for cleanup or other reasons) and maybe don't know what they changed or didn't not find the time to finish the cleanup:

TextMorph righclick does not work anymore. Some text emphasis on FT fonts dont work. Some TextMorph halos don't work anymore.

I don't think alls this was done on purpose.

For the Transcript shortcuts for example, if we change ThreadSafeTranscript to use PluggableTextEditorMorph instead of PluggableTextMorph

cmd+6/7/8/9/0 for changing emphasis/color works again.

Great ! Well that's one thing that can be fixed easily then. Thanks for looking into it.

nicolai

...

/Usecase 1: Debug printing methods:/ In the VM you have debug printing methods, for example, to print the call stack. These methods are used from the VM simulator, to output the string in the Transcript, and in gdb, to ouput the string in the commandline. The commandline (FileStream stdout in Pharo) and the Squeak Transcript have the same behavior. In Pharo, the Transcript does not inherit from Stream so you can't use the required stream methods to print the debug printing method on the Transcript. In addition, some printing methods print a lot of things and it is important to show the stream as it is printed. For this use-case, we want to keep the smallest difference between the gdb/commadline behavior and the VM simulator/Transcript behavior. If you implement advanced tooling in GT, you therefore need to implement gdb extensions (and lldb extensions because some of us use lldb instead of gdb) and maintain them. I don't think this is a solution.

/Usecase 2: CCode generation debugging:/ The CCodeGenerator or Slang translator translates Slang code into C code. Sometimes there is a bug. To debug, instead of generating the faulty C method into an external C file, we print only the faulty C method in the Transcript. Again, we want to keep the lowest difference between the real usecase (printing on the C file) and the debug usecase (printing on the Transcript). In Squeak the FileStream and the Transcript are both Stream, everything works as expected. In Pharo the Transcript has not the expected behavior. Again the method can be long, you can have to wait several seconds, so you'd like the transcript to show the stream as you print it.

/Usecase 3: VM simulation:/ Simulating the VM is quite slow, especially the machine code execution simulation. During the simulation process, the UI is non interactive and shows only every while what the simulator is doing in the Transcript. It is important as sometimes when debugging with a test at each machine code instruction it could take several hours before the UI is interactive again and you want to know what is going on. I don't complain that it takes several hours because the alternatives usually require days of debugging and we can launch the VM simulator overnight. In Pharo this does not work as expected.

/Usecase 4: In-image machine-code compilation:/ While working in the JIT compiler, sometimes the machine code generated for a bytecoded method is faulty. A common way of debugging it is to print the machine code instructions of the machine code version of the method in the Transcript. It can take a while to print, so it is important to have the Transcript showing the text as it prints. Then, the easiest way of debugging is to look at the machine code and understand what is wrong. For this purpose, we add text decoration to color jump addresses or the instructions where the instruction pointer was when the VM crashed. Then, in squeak, we can easily copy the decorated text to a workspace and generate a new version of the machine code method and compare. In machine code, it is very difficult to do analysis to have more information than just the decompiled text. We add some information while simulating because we know for example the address of specific trampolines, therefore we can print the name of the trampoline when we see that its address is called. Again, sometimes we also have to debug in gdb. In this case, we disassemble the machine code and compare it to the one from in-image compilation, so both printed strings have to be similar (similar text, same chariot returns).

Another example is the complexity of the Pharo tools:

While developing the VM, I have sometimes a VM partially working or with some plugins not working. In the Squeak image, I can open a workspace on top of this half-working VM and run do-its to see what is working and what is not. In the Pharo image, I can't do anything. You can't open the workspace without opening more advanced tools. I tried to open the Playground, but the first time there was a bug with Traits (Playground use Traits somehow and they were not working due to the new bytecode set not being finished), when that first bug was fixed I could not open it because it crashed simply the VM (I believe it tried to access an external file such as playground-cache). Currently, the Pharo team is trying to build a set of basic tools that have few dependencies to debug a partially working system (that I think you will use to debug glamour while editing it, because you cannot use the glamour inspector if glamour is not working). That would solve this issue. But in no way this point is something that I can do alone to be able to develop the VM in Pharo. This has to be a community effort. And I am saying that because I can't be blamed not to work on the VM in Pharo if to do so I need to spend many months changing Pharo.

An example that I believe is a problem in term of the community is the following:

I added with Eliot the support for the new bytecode set. Currently, the Squeak image works with the new bytecode set but not the Pharo image. This is because only the Traits are broken, but this is something I could hardly figure out in the Pharo image because nothing is working as the GT tools use Traits. In Squeak I believe there are very few users of Traits so everything worked, and the test suite can reveal that the Traits are broken easily.

Currently, the VM process to me is to first make new features work in Squeak, because it is simpler, and then make it work with Pharo, which is more complex. In the last section I discussed how Traits were a problem while implementing the new bytecode set. So what is the long term solution for this issue ? - Will we have a bootstrap process that creates first a Trait-free Kernel and then build the Pharo Kernel out of it ? - Do we forbid people to use Traits in the Pharo Kernel and does that make sense to have Traits in Pharo in this case ? - If we don't do anything, maybe the Traits are only a slight difference with low impact in most cases and it's fine. But maybe there are many small aspects like Traits, such as the Slots the way they were used in GT recently (I don't blame GT or anything, it was just using features in the system that created issues for me), and maybe we reached a point where the complexity between the Pharo kernel and the Squeak kernel is big enough so that a VM developer will first make Squeak works when introducing new features and then deals with the complexity of Pharo ?

So, what do we do ? I don't see any simple solution for this issue. And I believe there are people around that see as the only solution for this issue not to have the Pharo VM development process in Pharo because they will see it as a threat to what they want to do with Pharo.

Best Doru !

PS: I am still using the GTInspector with additional views on graphs created with Roassal everyday and I still enjoy it.

PS2: I am on vacation currently because I was getting crazy looking at machine code all day long, so I may not answer as quick as usually during the next week.

Cheers, Doru

On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:

2015-05-09 20:25 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:

Le 9/5/15 20:16, Clément Bera a écrit :

...

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

I have already stated that you believe that it is important that Pharo is able to host development for its own VM.

I am not against what you did and I am very excited with Guille's work.

Pharo is community-driven, so I am not asking the question to you only, but to the community.

...

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

*Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ?* *Do you think a system that is not good enough to handle its own VM development is a good system ?*

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:

Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

...

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

-- www.tudorgirba.com <http://www.tudorgirba.com/>

"Every thing has its own flow"

Just so that I understand why Transcript does not support stream api ThreadSafeTranscript implements the following selectors: #(#ensureCr #close #print: #white #openLabel: #characterLimit #'<<' #initialize #title #printOn: #nextPutAll: #show: #shoutAboutToStyle: #cr #tab #black #initialExtent #clear #codePaneMenu:shifted: #endEntry #nextPut: #with: #reset #space #crShow: #flush #open #isSelfEvaluating #pastEndPut: #contents) and in there we have #close #print: #'<<' #nextPut: #nextPutAll: #show: #cr #tab #clear #space #crShow: #flush #open #pastEndPut: #contents So which ones are missing? Stef Le 10/5/15 10:28, Clément Bera a écrit :

2015-05-09 23:21 GMT+02:00 Tudor Girba <tudor@tudorgirba.com <mailto:tudor@tudorgirba.com>>:

I do not think there are many people around here that would think that it is irrelevant if the Pharo VM can be developed in Pharo or not. Of course, it is important.

So, the discussion should not go to challenge this direction, but rather in you telling us the use cases that you need supported. Please note that I did not say which exact code and how it should look like. I would be interested in learning about the use cases you have. I am quite certain that there are a number of ways to support them and when we work on GT it would be useful to have your use cases on our table.

Well I need many lines to explain each point and there are many... I can talk here about a few points. Then I will deal with Esteban for most of them because it is difficult to explain without an interactive discussion.

Let me explain the use cases for the Transcript for example. The issues in Pharo are: - The Transcript does not show the stream as it is printed. - The Transcript does not inherit from Stream and thus cannot print with all the methods implemented in Stream. - The Transcript does not allow the user to decorate the text with bold, italic or colors.

/Usecase 1: Debug printing methods:/ In the VM you have debug printing methods, for example, to print the call stack. These methods are used from the VM simulator, to output the string in the Transcript, and in gdb, to ouput the string in the commandline. The commandline (FileStream stdout in Pharo) and the Squeak Transcript have the same behavior. In Pharo, the Transcript does not inherit from Stream so you can't use the required stream methods to print the debug printing method on the Transcript. In addition, some printing methods print a lot of things and it is important to show the stream as it is printed. For this use-case, we want to keep the smallest difference between the gdb/commadline behavior and the VM simulator/Transcript behavior. If you implement advanced tooling in GT, you therefore need to implement gdb extensions (and lldb extensions because some of us use lldb instead of gdb) and maintain them. I don't think this is a solution.

/Usecase 2: CCode generation debugging:/ The CCodeGenerator or Slang translator translates Slang code into C code. Sometimes there is a bug. To debug, instead of generating the faulty C method into an external C file, we print only the faulty C method in the Transcript. Again, we want to keep the lowest difference between the real usecase (printing on the C file) and the debug usecase (printing on the Transcript). In Squeak the FileStream and the Transcript are both Stream, everything works as expected. In Pharo the Transcript has not the expected behavior. Again the method can be long, you can have to wait several seconds, so you'd like the transcript to show the stream as you print it.

/Usecase 3: VM simulation:/ Simulating the VM is quite slow, especially the machine code execution simulation. During the simulation process, the UI is non interactive and shows only every while what the simulator is doing in the Transcript. It is important as sometimes when debugging with a test at each machine code instruction it could take several hours before the UI is interactive again and you want to know what is going on. I don't complain that it takes several hours because the alternatives usually require days of debugging and we can launch the VM simulator overnight. In Pharo this does not work as expected.

/Usecase 4: In-image machine-code compilation:/ While working in the JIT compiler, sometimes the machine code generated for a bytecoded method is faulty. A common way of debugging it is to print the machine code instructions of the machine code version of the method in the Transcript. It can take a while to print, so it is important to have the Transcript showing the text as it prints. Then, the easiest way of debugging is to look at the machine code and understand what is wrong. For this purpose, we add text decoration to color jump addresses or the instructions where the instruction pointer was when the VM crashed. Then, in squeak, we can easily copy the decorated text to a workspace and generate a new version of the machine code method and compare. In machine code, it is very difficult to do analysis to have more information than just the decompiled text. We add some information while simulating because we know for example the address of specific trampolines, therefore we can print the name of the trampoline when we see that its address is called. Again, sometimes we also have to debug in gdb. In this case, we disassemble the machine code and compare it to the one from in-image compilation, so both printed strings have to be similar (similar text, same chariot returns).

Another example is the complexity of the Pharo tools:

While developing the VM, I have sometimes a VM partially working or with some plugins not working. In the Squeak image, I can open a workspace on top of this half-working VM and run do-its to see what is working and what is not. In the Pharo image, I can't do anything. You can't open the workspace without opening more advanced tools. I tried to open the Playground, but the first time there was a bug with Traits (Playground use Traits somehow and they were not working due to the new bytecode set not being finished), when that first bug was fixed I could not open it because it crashed simply the VM (I believe it tried to access an external file such as playground-cache). Currently, the Pharo team is trying to build a set of basic tools that have few dependencies to debug a partially working system (that I think you will use to debug glamour while editing it, because you cannot use the glamour inspector if glamour is not working). That would solve this issue. But in no way this point is something that I can do alone to be able to develop the VM in Pharo. This has to be a community effort. And I am saying that because I can't be blamed not to work on the VM in Pharo if to do so I need to spend many months changing Pharo.

An example that I believe is a problem in term of the community is the following:

I added with Eliot the support for the new bytecode set. Currently, the Squeak image works with the new bytecode set but not the Pharo image. This is because only the Traits are broken, but this is something I could hardly figure out in the Pharo image because nothing is working as the GT tools use Traits. In Squeak I believe there are very few users of Traits so everything worked, and the test suite can reveal that the Traits are broken easily.

Currently, the VM process to me is to first make new features work in Squeak, because it is simpler, and then make it work with Pharo, which is more complex. In the last section I discussed how Traits were a problem while implementing the new bytecode set. So what is the long term solution for this issue ? - Will we have a bootstrap process that creates first a Trait-free Kernel and then build the Pharo Kernel out of it ? - Do we forbid people to use Traits in the Pharo Kernel and does that make sense to have Traits in Pharo in this case ? - If we don't do anything, maybe the Traits are only a slight difference with low impact in most cases and it's fine. But maybe there are many small aspects like Traits, such as the Slots the way they were used in GT recently (I don't blame GT or anything, it was just using features in the system that created issues for me), and maybe we reached a point where the complexity between the Pharo kernel and the Squeak kernel is big enough so that a VM developer will first make Squeak works when introducing new features and then deals with the complexity of Pharo ?

So, what do we do ? I don't see any simple solution for this issue. And I believe there are people around that see as the only solution for this issue not to have the Pharo VM development process in Pharo because they will see it as a threat to what they want to do with Pharo.

Best Doru !

PS: I am still using the GTInspector with additional views on graphs created with Roassal everyday and I still enjoy it.

PS2: I am on vacation currently because I was getting crazy looking at machine code all day long, so I may not answer as quick as usually during the next week.

Cheers, Doru

On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clement@gmail.com <mailto:bera.clement@gmail.com>> wrote:

2015-05-09 20:25 GMT+02:00 stepharo <stepharo@free.fr <mailto:stepharo@free.fr>>:

Le 9/5/15 20:16, Clément Bera a écrit :

...

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

I have already stated that you believe that it is important that Pharo is able to host development for its own VM.

I am not against what you did and I am very excited with Guille's work.

Pharo is community-driven, so I am not asking the question to you only, but to the community.

...

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

*Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ?* *Do you think a system that is not good enough to handle its own VM development is a good system ?*

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>>:

Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

...

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com <mailto:btc@openinworld.com>> wrote:

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

-- www.tudorgirba.com <http://www.tudorgirba.com>

"Every thing has its own flow"

Hi Clement, Thanks a lot for taking the time to describes these use cases. I was never exposed to the constraints of developing a VM and this type of descriptions is what we need to have a chance of producing tools that can help. I will think of them. Cheers, Doru On Sun, May 10, 2015 at 10:28 AM, Clément Bera <bera.clement@gmail.com> wrote:

2015-05-09 23:21 GMT+02:00 Tudor Girba <tudor@tudorgirba.com>:

...

I do not think there are many people around here that would think that it is irrelevant if the Pharo VM can be developed in Pharo or not. Of course, it is important.

So, the discussion should not go to challenge this direction, but rather in you telling us the use cases that you need supported. Please note that I did not say which exact code and how it should look like. I would be interested in learning about the use cases you have. I am quite certain that there are a number of ways to support them and when we work on GT it would be useful to have your use cases on our table.

Well I need many lines to explain each point and there are many... I can talk here about a few points. Then I will deal with Esteban for most of them because it is difficult to explain without an interactive discussion.

Let me explain the use cases for the Transcript for example. The issues in Pharo are: - The Transcript does not show the stream as it is printed. - The Transcript does not inherit from Stream and thus cannot print with all the methods implemented in Stream. - The Transcript does not allow the user to decorate the text with bold, italic or colors.

*Usecase 1: Debug printing methods:* In the VM you have debug printing methods, for example, to print the call stack. These methods are used from the VM simulator, to output the string in the Transcript, and in gdb, to ouput the string in the commandline. The commandline (FileStream stdout in Pharo) and the Squeak Transcript have the same behavior. In Pharo, the Transcript does not inherit from Stream so you can't use the required stream methods to print the debug printing method on the Transcript. In addition, some printing methods print a lot of things and it is important to show the stream as it is printed. For this use-case, we want to keep the smallest difference between the gdb/commadline behavior and the VM simulator/Transcript behavior. If you implement advanced tooling in GT, you therefore need to implement gdb extensions (and lldb extensions because some of us use lldb instead of gdb) and maintain them. I don't think this is a solution.

*Usecase 2: CCode generation debugging:* The CCodeGenerator or Slang translator translates Slang code into C code. Sometimes there is a bug. To debug, instead of generating the faulty C method into an external C file, we print only the faulty C method in the Transcript. Again, we want to keep the lowest difference between the real usecase (printing on the C file) and the debug usecase (printing on the Transcript). In Squeak the FileStream and the Transcript are both Stream, everything works as expected. In Pharo the Transcript has not the expected behavior. Again the method can be long, you can have to wait several seconds, so you'd like the transcript to show the stream as you print it.

*Usecase 3: VM simulation:* Simulating the VM is quite slow, especially the machine code execution simulation. During the simulation process, the UI is non interactive and shows only every while what the simulator is doing in the Transcript. It is important as sometimes when debugging with a test at each machine code instruction it could take several hours before the UI is interactive again and you want to know what is going on. I don't complain that it takes several hours because the alternatives usually require days of debugging and we can launch the VM simulator overnight. In Pharo this does not work as expected.

*Usecase 4: In-image machine-code compilation:* While working in the JIT compiler, sometimes the machine code generated for a bytecoded method is faulty. A common way of debugging it is to print the machine code instructions of the machine code version of the method in the Transcript. It can take a while to print, so it is important to have the Transcript showing the text as it prints. Then, the easiest way of debugging is to look at the machine code and understand what is wrong. For this purpose, we add text decoration to color jump addresses or the instructions where the instruction pointer was when the VM crashed. Then, in squeak, we can easily copy the decorated text to a workspace and generate a new version of the machine code method and compare. In machine code, it is very difficult to do analysis to have more information than just the decompiled text. We add some information while simulating because we know for example the address of specific trampolines, therefore we can print the name of the trampoline when we see that its address is called. Again, sometimes we also have to debug in gdb. In this case, we disassemble the machine code and compare it to the one from in-image compilation, so both printed strings have to be similar (similar text, same chariot returns).

Another example is the complexity of the Pharo tools:

While developing the VM, I have sometimes a VM partially working or with some plugins not working. In the Squeak image, I can open a workspace on top of this half-working VM and run do-its to see what is working and what is not. In the Pharo image, I can't do anything. You can't open the workspace without opening more advanced tools. I tried to open the Playground, but the first time there was a bug with Traits (Playground use Traits somehow and they were not working due to the new bytecode set not being finished), when that first bug was fixed I could not open it because it crashed simply the VM (I believe it tried to access an external file such as playground-cache). Currently, the Pharo team is trying to build a set of basic tools that have few dependencies to debug a partially working system (that I think you will use to debug glamour while editing it, because you cannot use the glamour inspector if glamour is not working). That would solve this issue. But in no way this point is something that I can do alone to be able to develop the VM in Pharo. This has to be a community effort. And I am saying that because I can't be blamed not to work on the VM in Pharo if to do so I need to spend many months changing Pharo.

An example that I believe is a problem in term of the community is the following:

I added with Eliot the support for the new bytecode set. Currently, the Squeak image works with the new bytecode set but not the Pharo image. This is because only the Traits are broken, but this is something I could hardly figure out in the Pharo image because nothing is working as the GT tools use Traits. In Squeak I believe there are very few users of Traits so everything worked, and the test suite can reveal that the Traits are broken easily.

Currently, the VM process to me is to first make new features work in Squeak, because it is simpler, and then make it work with Pharo, which is more complex. In the last section I discussed how Traits were a problem while implementing the new bytecode set. So what is the long term solution for this issue ? - Will we have a bootstrap process that creates first a Trait-free Kernel and then build the Pharo Kernel out of it ? - Do we forbid people to use Traits in the Pharo Kernel and does that make sense to have Traits in Pharo in this case ? - If we don't do anything, maybe the Traits are only a slight difference with low impact in most cases and it's fine. But maybe there are many small aspects like Traits, such as the Slots the way they were used in GT recently (I don't blame GT or anything, it was just using features in the system that created issues for me), and maybe we reached a point where the complexity between the Pharo kernel and the Squeak kernel is big enough so that a VM developer will first make Squeak works when introducing new features and then deals with the complexity of Pharo ?

So, what do we do ? I don't see any simple solution for this issue. And I believe there are people around that see as the only solution for this issue not to have the Pharo VM development process in Pharo because they will see it as a threat to what they want to do with Pharo.

Best Doru !

PS: I am still using the GTInspector with additional views on graphs created with Roassal everyday and I still enjoy it.

PS2: I am on vacation currently because I was getting crazy looking at machine code all day long, so I may not answer as quick as usually during the next week.

Cheers,

...

Doru

On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clement@gmail.com> wrote:

...

2015-05-09 20:25 GMT+02:00 stepharo <stepharo@free.fr>:

...

Le 9/5/15 20:16, Clément Bera a écrit :

This whole conversation here shows very well the point that I tried to explain to Stef last week. I'm sorry if the mail is a bit long but I think this discussion has to be done.

My whole Smalltalk development life, I have used Pharo and was happy with it. Now I am also working in Cog's JIT compiler and for this specific project, I am working with Squeak. I don't work with Squeak because I don't like Pharo, I told you before, I have worked with Pharo on all my project before, enjoyed it and if it was possible I would use Pharo. I work with Squeak because the VM development tool and development process simply does *not* work in Pharo. This is not only because of VM tools working with the old Morphic not working anymore in Pharo or details like that, it is also due to deeper changes in Pharo.

Stef believes it is important that Pharo is able to host development for its own VM. Therefore, I discussed with him and Esteban about a first list of points that are necessary for Pharo to support its VM development in Pharo, which includes this Transcript behavior.

As of today, and I am honest here, I believe that what is required for Pharo to support the development process of its VM includes points which goes in the opposite direction than a few points in the Pharo roadmap, that people in the Pharo community will see as a regression, as "an intrusion from the Squeak philosophy into Pharo", or as forbidding the integration of features that breaks the VM development process. Therefore, I believe the Pharo community would disapprove to make such changes and I highly doubt that it is possible to have the development process of the Pharo VM in Pharo.

I was thinking that only a few points would be a problem such as the increasing memory footprint of the Pharo image that is going to get worse with the sources that will be included in the image in the future, whereas a VM developer needs a small image (See previous threads in this mailing list where Hilaire complains about that for example).

clement can I ask a simple question? why did I ask guille to work on minikernels and bootstrap for his phd instead on a topic where we can publish? - choice A: lack of idea - choice B: ....

I have already stated that you believe that it is important that Pharo is able to host development for its own VM.

I am not against what you did and I am very excited with Guille's work.

Pharo is community-driven, so I am not asking the question to you only, but to the community.

...

However, I didn't think that even simple points like the Transcript behavior discussed here, which looks like to me as a regression and is required for VM development, would be seen as an improvement by a non negligible part of the community.

In this mailing-list, the whole Pharo community is present and can see this discussion. So the open questions are:

*Do you want to have the development of the Pharo VM in Pharo, or do you want the development of the Pharo VM to remain in Squeak ?* *Do you think a system that is not good enough to handle its own VM development is a good system ?*

I am not willing to go against the will of the community because I enjoy community-driven softwares. If the answer is that Pharo should be able to support its own VM development then as I started I will help Esteban and Stef to improve Pharo so that it can support its own VM development. Now, if the answer is that the development of the Pharo VM should remain in Squeak, I will continue developing the VM in Squeak.

You are the Pharo community, you are the ones that make Pharo alive and kicking, so you tell me what you think we should do.

Clement

2015-05-09 18:23 GMT+02:00 Eliot Miranda <eliot.miranda@gmail.com>:

...

Hi Ben,

On May 9, 2015, at 7:41 AM, Ben Coman <btc@openinworld.com> wrote:

On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc@openinworld.com> wrote:

...

From my limited experience bug hunting, calling #changed: from a thread other than the UI thread is a source of evil. There are too many assumptions throughout the system that the UI is single threaded. Can anyone advise me that is not a proper belief?

Then that implies that a Transcript implementation where #nextPut: direct calls #changed: is not appropriate for use with multi-threaded applications. In Pharo, #changed: is only called from #stepGlobal, which is called from doOneCycle:. (This came about as a last minute bug fix before Pharo 3 release and maybe could use some cleanup.

Separating the UI from Transcript into its own viewer might be a good idea, but actually it would not solve Stef's case since his code would still be running in the UI thread -- unless the viewer ran in another thread, which would have its own complexities.

I think the point about efficiency is significant. The following example... Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ] on Squeak 4.5 --> 12749ms on Pharo 50029 --> 2ms

As a point of comparison, on VW 8.0 --> 43817ms and so you might guess, VW 8.0 outputs each 'x' immediately. cheers -ben

Way to go, Squeak! Actually this is disappointing. I'm rather frustrated with Squeak's slow transcript, and was hoping that VW would demonstrate it could be faster. Looking at the Squeak implementation I only see an obvious 30% or so improvement via tuning. Looks like good performance will take more work :-/

Eliot (phone)

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"

Le 08/05/2015 16:16, Eliot Miranda a écrit :

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

Interesting points Yes Eliot, I suspect some things could be broken But *breakage* ? to prevent this, I submitted the idea to add an *extra* option 'run async' and afterall may be not that much. when nobody tries who knows ? May be just very few breakages ? (may be none ... mmm well I don't think ... ;) ) And again this could be an *extra* menu option (...) Anyway, it is certainly possible in Pharo too to update the Transcript while in the UI process and find a non breaking solution here. (probably very different from squeak implementation but it doesn't matter) -- Regards, Alain

On Sat, May 9, 2015 at 5:29 AM, stepharo <stepharo@free.fr> wrote:

Eliot

I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. It was terrible.

I don't see what that has to do with my usability point. The transcript was a) a stream b) something that displayed its output immediately Those two features are essential. If you change the transcript so that it no longer has those features you have broken it. Igor waffled on about internals, the desire to separate the UI from the stream, a point that has nothing to do with the utility of the transcript. No you're going on about its thread-safety. But no one is addressing my point. And you have Clément telling you that he cannot develop the VM in Pharo because the transcript is broken, and you have others proposing various potentially error-prone work-arounds to get around the fact that the transcript is broken. Why won't anyone stand up and say yes, the transcript is broken and yes we will fix it? This is dysfunctional.

Stef

Le 8/5/15 16:16, Eliot Miranda a écrit :

Hi,

...

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 08/05/2015 11:34, stepharo a écrit :

...

...

Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515

Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem.

Probably in squeak, in Transcript this is done somewhere under the hood.

via dependents ?

TranscriptStream>>endEndtry "Display all the characters since the last endEntry, and reset the stream" self semaphore critical:[ self changed: #appendEntry. self reset. ].

Object>>changed: aParameter self dependents do: [:aDependent | aDependent update: aParameter]

And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows).

-- Regards,

Alain

-- best, Eliot

+1 let’s recapitulate: requirement is - fast - editable - polymorphic with WriteStream - and immediate to screen from our perspective (pharo), it has to be also - thread safe - well designed. our constraints are: - bad design of transcripts - super naive implementation of text editors (this is, IMO, the reason why transcripts are so slow: if you redraw all the window interior each time you add a line, you are screw) basically… we need a good log console (if it is a transcript or not, is another discussion) :) So… who proposes a solution? Esteban

On 10 May 2015, at 00:40, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

For me saying that internals are not important as long as transcript does what is expected from it, is like saying that Parser being a subclass of Scanner and Compiler being as subclass of Parser is ok as long as it compiles source code. We already had that and it was bad.

On the other hand it’s obvious that we don’t have enough resources to rewrite Pharo from scratch and we cannot leave issues as they are just because we cannot solve them perfectly now.

I would say that Igor is correct saying that we need a better architecture, and Stef and Eliot are correct saying that we need tools that fulfill users’ needs. And we have to say: “ok now we hack this around, but we have to do this the right way one day”. Is anyone familiar with same-css[1] concept?

Uko

P.S. maybe my 2 cents are useless, but all the fight around this discussion is really strange for me. In Ukraine we have a saying that it’s better to be healthy and poor than sick and rich. Now I use to say that it’s better to be healthy and rich than sick and poor. And all the fight here was if it’s better to be healthy or rich. Definitely it’s better to be both, we cannot do that instantly but we can set goals and milestones, and find the optimal strategy.

[1]: http://csswizardry.com/2013/04/shame-css/ <http://csswizardry.com/2013/04/shame-css/>

...

On 09 May 2015, at 16:17, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:

On Sat, May 9, 2015 at 5:29 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: Eliot

I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. It was terrible.

I don't see what that has to do with my usability point. The transcript was a) a stream b) something that displayed its output immediately

Those two features are essential. If you change the transcript so that it no longer has those features you have broken it.

Igor waffled on about internals, the desire to separate the UI from the stream, a point that has nothing to do with the utility of the transcript. No you're going on about its thread-safety. But no one is addressing my point. And you have Clément telling you that he cannot develop the VM in Pharo because the transcript is broken, and you have others proposing various potentially error-prone work-arounds to get around the fact that the transcript is broken.

Why won't anyone stand up and say yes, the transcript is broken and yes we will fix it? This is dysfunctional.

Stef

Le 8/5/15 16:16, Eliot Miranda a écrit :

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote:

Le 08/05/2015 11:34, stepharo a écrit : Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515 <https://pharo.fogbugz.com/default.asp?15515> Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem.

Probably in squeak, in Transcript this is done somewhere under the hood.

via dependents ?

TranscriptStream>>endEndtry "Display all the characters since the last endEntry, and reset the stream" self semaphore critical:[ self changed: #appendEntry. self reset. ].

Object>>changed: aParameter self dependents do: [:aDependent | aDependent update: aParameter]

And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows).

-- Regards,

Alain

-- best, Eliot

On 5/10/15, Sven Van Caekenberghe <sven@stfx.eu> wrote:

...

On 10 May 2015, at 10:36, Esteban Lorenzano <estebanlm@gmail.com> wrote:

+1

let’s recapitulate:

requirement is - fast - editable - polymorphic with WriteStream - and immediate to screen from our perspective (pharo), it has to be also - thread safe - well designed.

our constraints are: - bad design of transcripts - super naive implementation of text editors (this is, IMO, the reason why transcripts are so slow: if you redraw all the window interior each time you add a line, you are screw)

Good summary!

+1

...

basically… we need a good log console (if it is a transcript or not, is another discussion) :) +1

As an independent pluggable package because not everybody does VM development all the time. There might be several of them focusing on different needs. And there are already libraries claiming to be loggers. Might be used as a start.

Yes, that is really all there is to it

...

So… who proposes a solution?

Esteban

...

On 10 May 2015, at 00:40, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:

For me saying that internals are not important as long as transcript does what is expected from it, is like saying that Parser being a subclass of Scanner and Compiler being as subclass of Parser is ok as long as it compiles source code. We already had that and it was bad.

On the other hand it’s obvious that we don’t have enough resources to rewrite Pharo from scratch and we cannot leave issues as they are just because we cannot solve them perfectly now.

I would say that Igor is correct saying that we need a better architecture, and Stef and Eliot are correct saying that we need tools that fulfill users’ needs. And we have to say: “ok now we hack this around, but we have to do this the right way one day”. Is anyone familiar with same-css[1] concept?

Uko

P.S. maybe my 2 cents are useless, but all the fight around this discussion is really strange for me. In Ukraine we have a saying that it’s better to be healthy and poor than sick and rich. Now I use to say that it’s better to be healthy and rich than sick and poor. And all the fight here was if it’s better to be healthy or rich. Definitely it’s better to be both, we cannot do that instantly but we can set goals and milestones, and find the optimal strategy.

[1]: http://csswizardry.com/2013/04/shame-css/

...

On 09 May 2015, at 16:17, Eliot Miranda <eliot.miranda@gmail.com> wrote:

On Sat, May 9, 2015 at 5:29 AM, stepharo <stepharo@free.fr> wrote: Eliot

I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. It was terrible.

I don't see what that has to do with my usability point. The transcript was a) a stream b) something that displayed its output immediately

Those two features are essential. If you change the transcript so that it no longer has those features you have broken it.

Igor waffled on about internals, the desire to separate the UI from the stream, a point that has nothing to do with the utility of the transcript. No you're going on about its thread-safety. But no one is addressing my point. And you have Clément telling you that he cannot develop the VM in Pharo because the transcript is broken, and you have others proposing various potentially error-prone work-arounds to get around the fact that the transcript is broken.

Why won't anyone stand up and say yes, the transcript is broken and yes we will fix it? This is dysfunctional.

Stef

Le 8/5/15 16:16, Eliot Miranda a écrit :

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 08/05/2015 11:34, stepharo a écrit : Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515 Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem.

Probably in squeak, in Transcript this is done somewhere under the hood.

via dependents ?

TranscriptStream>>endEndtry "Display all the characters since the last endEntry, and reset the stream" self semaphore critical:[ self changed: #appendEntry. self reset. ].

Object>>changed: aParameter self dependents do: [:aDependent | aDependent update: aParameter]

And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows).

-- Regards,

Alain

-- best, Eliot

On 10 May 2015, at 13:10, stepharo <stepharo@free.fr> wrote:

Why we cannot use the of Juan?

Le 10/5/15 10:36, Esteban Lorenzano a écrit :

...

+1

let’s recapitulate:

requirement is - fast - editable why do you need to edit it?

you can type in it, make do it, etc. (just like now)

...

- polymorphic with WriteStream - and immediate to screen from our perspective (pharo), it has to be also - thread safe - well designed.

our constraints are: - bad design of transcripts - super naive implementation of text editors (this is, IMO, the reason why transcripts are so slow: if you redraw all the window interior each time you add a line, you are screw)

basically… we need a good log console (if it is a transcript or not, is another discussion) :)

So… who proposes a solution?

Esteban

...

On 10 May 2015, at 00:40, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:

For me saying that internals are not important as long as transcript does what is expected from it, is like saying that Parser being a subclass of Scanner and Compiler being as subclass of Parser is ok as long as it compiles source code. We already had that and it was bad.

On the other hand it’s obvious that we don’t have enough resources to rewrite Pharo from scratch and we cannot leave issues as they are just because we cannot solve them perfectly now.

I would say that Igor is correct saying that we need a better architecture, and Stef and Eliot are correct saying that we need tools that fulfill users’ needs. And we have to say: “ok now we hack this around, but we have to do this the right way one day”. Is anyone familiar with same-css[1] concept?

Uko

P.S. maybe my 2 cents are useless, but all the fight around this discussion is really strange for me. In Ukraine we have a saying that it’s better to be healthy and poor than sick and rich. Now I use to say that it’s better to be healthy and rich than sick and poor. And all the fight here was if it’s better to be healthy or rich. Definitely it’s better to be both, we cannot do that instantly but we can set goals and milestones, and find the optimal strategy.

[1]: http://csswizardry.com/2013/04/shame-css/ <http://csswizardry.com/2013/04/shame-css/>

...

On 09 May 2015, at 16:17, Eliot Miranda <eliot.miranda@gmail.com <mailto:eliot.miranda@gmail.com>> wrote:

On Sat, May 9, 2015 at 5:29 AM, stepharo <stepharo@free.fr <mailto:stepharo@free.fr>> wrote: Eliot

I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. It was terrible.

I don't see what that has to do with my usability point. The transcript was a) a stream b) something that displayed its output immediately

Those two features are essential. If you change the transcript so that it no longer has those features you have broken it.

Igor waffled on about internals, the desire to separate the UI from the stream, a point that has nothing to do with the utility of the transcript. No you're going on about its thread-safety. But no one is addressing my point. And you have Clément telling you that he cannot develop the VM in Pharo because the transcript is broken, and you have others proposing various potentially error-prone work-arounds to get around the fact that the transcript is broken.

Why won't anyone stand up and say yes, the transcript is broken and yes we will fix it? This is dysfunctional.

Stef

Le 8/5/15 16:16, Eliot Miranda a écrit :

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat@gmail.com <mailto:alf.mmm.cat@gmail.com>> wrote:

Le 08/05/2015 11:34, stepharo a écrit : Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515 <https://pharo.fogbugz.com/default.asp?15515> Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem.

Probably in squeak, in Transcript this is done somewhere under the hood.

via dependents ?

TranscriptStream>>endEndtry "Display all the characters since the last endEntry, and reset the stream" self semaphore critical:[ self changed: #appendEntry. self reset. ].

Object>>changed: aParameter self dependents do: [:aDependent | aDependent update: aParameter]

And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows).

-- Regards,

Alain

-- best, Eliot

thanks alain did you publish a slice attached to the ug entry? Le 11/5/15 20:54, Alain Rastoul a écrit :

Le 10/05/2015 13:15, Esteban Lorenzano a écrit :

...

...

On 10 May 2015, at 13:10, stepharo <stepharo@free.fr> wrote:

Why we cannot use the of Juan?

...

you can type in it, make do it, etc. (just like now)

...

Hi Esteban, did you try it in pharo ?

It took me some time to read this whole thread yesterday evening back from WE, wow ... lot of posts... and make a test today.

(thanks to Clement explanations, the issue is more clear now. Indeed it's a pity that vm development cannot be done in pharo too, sometimes I really would like to have a look at it when I have questions on internals).

I tried to import Juan's source from the fogbugz post in pharo, renaming Tranncript to CuisTranscript, TranscriptMorph to CuisTranscriptMorph etc. finally after some big red-death morph, and now a weird non-correctly refreshing transcript I wonder how good this solution fit in pharo morphic world ?

It is somewhat hooked to morphic at low level and I had to import some old deprecated methods from squeak - since cuis doesn't start on my pc, I took them from squeak but may be this is not good. Also it will not solve the Elliot's editable and styling requirement.

(Editable should be possible, but styling...? no clue)

On 09 May 2015, at 16:57, phil@highoctane.be wrote:

I wonder why a couple of stream methods are not in.

This whole thread started with a discussion about a multi-threading issue. What is wrong with the API exactly ? Writestream has way too many methods already, do people really want them all ?

Also the idea of having something we can connect to observe a stream is really interesting.

yes

A single transcript is a bit too little for my tastes.

yes

I often write to several files and have tail -f on them in several windows in tmux.

yes

Would be nice to have that in Pharo.

yes

Phil

Le 9 mai 2015 14:29, "stepharo" <stepharo@free.fr> a écrit :

...

Eliot

I changed the transcript because it is not thread safe so I could use it at all to explain concurrent programming output. It was terrible.

Stef

Le 8/5/15 16:16, Eliot Miranda a écrit :

...

Hi,

if one uses a at doit transcript then no special action is required to get output to appear beyond sending flush to Transcript right? So any solution that requires special action to get the moronic transcript to work us broken. We should fix the transcript, not expect every application to work around a bug.

Eliot (phone)

On May 8, 2015, at 6:15 AM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

...

Le 08/05/2015 11:34, stepharo a écrit :

...

Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515

Yes, as do it are evaluated in the World morphic process, running in a forked process or sending World doOneCycle in the loop solve the problem.

Probably in squeak, in Transcript this is done somewhere under the hood.

via dependents ?

TranscriptStream>>endEndtry "Display all the characters since the last endEntry, and reset the stream" self semaphore critical:[ self changed: #appendEntry. self reset. ].

Object>>changed: aParameter self dependents do: [:aDependent | aDependent update: aParameter]

And probably not doOnecycle since you cannot do anything else during execution (clicking or moving windows).

-- Regards,

Alain

Le 12/05/2015 19:02, Alain Rastoul a écrit :

Le 08/05/2015 11:34, stepharo a écrit :

...

Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515

Hi, I updated the fogbugz entry with a changeset containing the sources Stef already put here, so that it should be easy for anybody to load CuisTranscript into a Pharo image and have a look.

IMHO another solution has to be found, or a big review of this has to be done. see details in fogbugz entry.

A very ugly but simple workaround could be ThreadSafeTranscript>>endEntry: accessSemaphore critical: [ deferredEndEntry := true . " is Synchronous coudl be a setting" self isSynchronous ifTrue: [ self stepGlobal . "handles appendEntry" World displayWorldSafely "redraw now" ] ]. with a setings for isSynchronous ugly but works, -- Regards, Alain

Le 13/05/2015 16:06, Ben Coman a écrit :

The problem with this is that non-UI threads call #endEntry: which bypasses the intent of #stepGlobal only being called from the UI thread. (btw I should update its comment to reflect this.) So the minimal effective change would be...

ThreadSafeTranscript>>endEntry: accessSemaphore critical: [ deferredEndEntry := true ]. (UIManager default uiProcess = Processor activeProcess) ifTrue: [ self stepGlobal. World displayWorldSafely. ].

Ah yes, you are perfectly right, I missed those points

However this would need to massaged to remove the referenced global classes (UIManager and World) to avoid introducing dependencies breaking the Image shrink work. Maybe these can be passed into the Transcript object where #stepGlobal is currently called from.

Yes, may be one day the UI (doOnecycle, runStepxxx with World etc) will be refactored too, however, today this is just a hack. Elliot's expression "the tail wagging the dog" perfectly applies here: the morph wagging the world :) -- Regards, Alain

I tried to abstract the Transcript API from the Pharo perspective in https://pharo.fogbugz.com/f/cases/15528/Add-TTranscript-and-DailyNonInteract... If the Cuis Transcript implementation conformed to this, it could become just a plugin replacement/alternative, next to others already present.

On 13 May 2015, at 16:08, J. Vuletich (mail lists) <juanlists@jvuletich.org> wrote:

Hi Alain,

Quoting Alain Rastoul <alf.mmm.cat@gmail.com>:

...

Le 08/05/2015 11:34, stepharo a écrit :

...

Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515

Hi, I updated the fogbugz entry with a changeset containing the sources Stef already put here, so that it should be easy for anybody to load CuisTranscript into a Pharo image and have a look.

Today I did a new commit to the Cuis repo. The Cuis image is now in Cog format (6505) instead of Closures format (6504). I hope this allows you to run Cuis in your system.

I also addressed some of the issues you raised. I optimized the refresh, and avoided the "bolder text" effect.

Now, Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. takes 2 ms, even while updating the Display. (Hundreds of times faster).

I hope the slugginess you see also gets better.

...

IMHO another solution has to be found, or a big review of this has to be done. see details in fogbugz entry.

-- Regards,

Alain

Cheers, Juan Vuletich

On 13 May 2015, at 17:57, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 13/05/2015 16:12, Sven Van Caekenberghe a écrit :

...

I tried to abstract the Transcript API from the Pharo perspective in

https://pharo.fogbugz.com/f/cases/15528/Add-TTranscript-and-DailyNonInteract...

If the Cuis Transcript implementation conformed to this, it could become just a plugin replacement/alternative, next to others already present.

A Trait for the Transcript is very good idea.

Just a question I had browsing the ThreadsafeTranscript implemntation, I wonder why there is no accessor to instance variables (stream accessSemaphore etc...). I thought the smalltalk way was to always prefer accessors, under the private protocol if private, but discourage direct access ?

Hmm, why ? I think it is more a question of (personal) style. Direct instance variable access without an accessor is a very good way to keep something private, it is faster as well. With the current tools, finding usages is very easy in both cases. IMO, an object should only implement the strict minimum of (public) messages, so not necessarily getters and setters for everything. Nothing is absolute though.

-- Regards,

Alain

Weren't Traits one of things reported to make VM development harder, or was there a fix coming for that? cheers -ben On Wed, May 13, 2015 at 11:57 PM, Alain Rastoul <alf.mmm.cat@gmail.com> wrote:

Le 13/05/2015 16:12, Sven Van Caekenberghe a écrit :

...

I tried to abstract the Transcript API from the Pharo perspective in

https://pharo.fogbugz.com/f/cases/15528/Add-TTranscript-and-DailyNonInteract...

If the Cuis Transcript implementation conformed to this, it could become just a plugin replacement/alternative, next to others already present.

A Trait for the Transcript is very good idea.

Just a question I had browsing the ThreadsafeTranscript implemntation, I wonder why there is no accessor to instance variables (stream accessSemaphore etc...). I thought the smalltalk way was to always prefer accessors, under the private protocol if private, but discourage direct access ?

-- Regards,

Alain

Hi Sven, A port of the code to Pharo is required, as Alain and Stef have shown. Besides, Cuis doesn't include support for Traits. I think your idea is very good, and I hope some Pharoer (Alain?) does it. Cheers, Juan Vuletich Quoting Sven Van Caekenberghe <sven@stfx.eu>:

I tried to abstract the Transcript API from the Pharo perspective in

https://pharo.fogbugz.com/f/cases/15528/Add-TTranscript-and-DailyNonInteract...

If the Cuis Transcript implementation conformed to this, it could become just a plugin replacement/alternative, next to others already present.

...

On 13 May 2015, at 16:08, J. Vuletich (mail lists) <juanlists@jvuletich.org> wrote:

Hi Alain,

Quoting Alain Rastoul <alf.mmm.cat@gmail.com>:

...

Le 08/05/2015 11:34, stepharo a écrit :

...

Hi guys

the Transcript in Pharo is that it's not asynchronous so I can't use it in VM development to show the current progress of the simulation. For example: 1 to: 100 do: [ :i | 0.1 seconds asDelay wait. Transcript show: 'x'. ] => on Squeak, this shows a x every 0.1 second in the Transcript => on Pharo, nothing happens during 10 seconds then all the x are shown.

https://pharo.fogbugz.com/default.asp?15515

Hi, I updated the fogbugz entry with a changeset containing the sources Stef already put here, so that it should be easy for anybody to load CuisTranscript into a Pharo image and have a look.

Today I did a new commit to the Cuis repo. The Cuis image is now in Cog format (6505) instead of Closures format (6504). I hope this allows you to run Cuis in your system.

I also addressed some of the issues you raised. I optimized the refresh, and avoided the "bolder text" effect.

Now, Time millisecondsToRun: [ 1000 timesRepeat: [ Transcript show: 'x' ] ]. takes 2 ms, even while updating the Display. (Hundreds of times faster).

I hope the slugginess you see also gets better.

...

IMHO another solution has to be found, or a big review of this has to be done. see details in fogbugz entry.

-- Regards,

Alain

Cheers, Juan Vuletich

Hi Alain, Quoting Alain Rastoul <alf.mmm.cat@gmail.com>:

Le 14/05/2015 02:08, J. Vuletich (mail lists) a écrit :

...

A port of the code to Pharo is required, as Alain and Stef have shown. Besides, Cuis doesn't include support for Traits. I think your idea is very good, and I hope some Pharoer (Alain?) does it.

Hi Juan,

I tried Cuis, you did a very nice work here.

Thanks.

About porting, I did this first raw port to allow other peoples who complains about pharo transcript to have a look at Cuis Trancript more easily. And apart from a small window inset problem and an initial display Form I probably did not get well (and/or a clip missing somewhere?), it does the same thing than in Cuis.

Cool.

May be we should wait a little so that people can say their word about it too and eventually/if they want/can/... investigate those two morphic porting issues. In the meanwhile, a simple "fix" in the Transcript could be done too (see last Ben's post) with an extra system settings.

Sure.

About sluggishnesh and Transcript speedup , the changes you made in Cuis, as seen in git commits, are a bit intrusive (DateAndTime, AbstractFont, Strikefont ?), I don't think I know pharo enough to report them.

The only relevant changeset is 2321, in folder CoreUpdates (the DateAndTime changes are completely unrelated). The changes to Fonts are only to let #displayUnfinishedEntryOn: save the last updated X for the unfinished entry. This is needed to avoid overwriting stuff (the "bold" efeect you saw). This is a good optimization and it is the only relevant change. If you find a way to make #drawString:at:font:color: answer the x of the rightmost affected pixel, that is more amenable to Pharo, it would be equally useful.

Also I experienced another issue that exits in Cuis too:

The Transcript overwrite other morphs/windows when showing its contents during do-it

After end of execution, the world redisplays correctly but not in Pharo

(see attached screen shots)

In Cuis, the world repair is requested in the last line of #display, that reads self changed: #redraw "So any morph in front of us is repaired when Morphic cycles" This works because in #openTranscript, the Transcript is set as the model of the TranscriptWindow. An appropriate idiom for Pharo is needed here.

-- Regards,

Alain

Cheers, Juan Vuletich

Le 14/05/2015 21:18, stepharo a écrit :

Thanks alain for checking. I think that we can offer different implementations and let people pick the ones they like. My goal is to remove direct refer to Transcript from the image so that we can plug an implementation and in particular the merge of Doru and Norbert/Mine loggers

Stef

I did a cs that I've added in fogbugz entry, I tried to make as few modifications as possible, so that it remains like original Cuis implementation. May be a CS is not the best, but I do not know slices well, I don't know for example if they are cumulatives, and automaticallly processed as a fix when the issue is closed, that would not be good here, it is still a WIP. May be a repo on Smalltalkhub for that transcript would be better? I will also edit (or remove, but I don't know how yet) some comments I added in fogbugz entry, because the mailing list is a better place for discussions, IIUC it would be better to put only recaps in the fogbugz entry. As of today, the integration with Pharo ui is not good : it overwrites windows etc (as you may have seen in attached screenshots), some work is needed to make it better. modifications I made to the original Cuis sources : - changed all _ with := - renamed Transcript to CuisTranscript - renamed TranscriptMorph to CuisTranscriptMorph - renamed Transcriptwindow to CuisTranscriptWindow all in original st files, in order to keep the original stamp (author) filed-in those st files in pharo then in pharo: - filed-in 2 deprecated methods borrowed from squeak 4.5 (Canvas>>image:at: and Rectangle>>outsetBy: ) todo here: find the replacement - Modified 4 methods about extent, position etc, and added 2 for Cuis/Pharo compatibility : to be checked too and filed out the cs. -- Regards, Alain

Le 14/5/15 15:12, Alain Rastoul a écrit :

Le 14/05/2015 02:08, J. Vuletich (mail lists) a écrit :

...

...

A port of the code to Pharo is required, as Alain and Stef have shown. Besides, Cuis doesn't include support for Traits. I think your idea is very good, and I hope some Pharoer (Alain?) does it.

Hi Juan,

I tried Cuis, you did a very nice work here.

About porting, I did this first raw port to allow other peoples who complains about pharo transcript to have a look at Cuis Trancript more easily. And apart from a small window inset problem and an initial display Form I probably did not get well (and/or a clip missing somewhere?), it does the same thing than in Cuis.

May be we should wait a little so that people can say their word about it too and eventually/if they want/can/... investigate those two morphic porting issues. In the meanwhile, a simple "fix" in the Transcript could be done too (see last Ben's post) with an extra system settings.

About sluggishnesh and Transcript speedup , the changes you made in Cuis, as seen in git commits, are a bit intrusive (DateAndTime, AbstractFont, Strikefont ?), I don't think I know pharo enough to report them.

Also I experienced another issue that exits in Cuis too:

The Transcript overwrite other morphs/windows when showing its contents during do-it

After end of execution, the world redisplays correctly but not in Pharo

(see attached screen shots)

On Fri, May 15, 2015 at 3:18 AM, stepharo <stepharo@free.fr> wrote:

Thanks alain for checking. I think that we can offer different implementations and let people pick the ones they like. My goal is to remove direct refer to Transcript from the image so that we can plug an implementation and in particular the merge of Doru and Norbert/Mine loggers

Stef

I don't quite follow "remove direct refer to Transcript". Isn't "Transcript" effectively a global variable that can already be plugged with any implementation? As I've been contemplating the Transcript situation, I keep coming back to the idea that Transcript should be a client of a broader logging framework, but wondering how much complication that would to tracing VM simulation. Further, since the logging framework needs to be threadsafe, rather than using protected access to a shared datastructure, would it be good to have a separate "logging" process to consume log entry submissions from multiple threads, and pass them on to output threads (including Transcript viewer). Some possible advantages: * Eliminate complications from priority inversion ( http://en.wikipedia.org/wiki/Priority_inversion) * Minimise code that log-entry-producer-thread needs to execute/debug into -- maybe beneficial for VM simulation? * Minimises execution time in log-entry-producer-thread. cheers -ben

Pressed save too early. The infrastructures for doing that exist already in SystemLogger and Beacon, and we will merge these two and produce one common logging engine. However, one challenge that came out of the description of Clement is to show a partial representation of an event before the full event is completed. For example, one issue is to see the printing of a compiled method while it is being compiled. In a regular case, you would model the event to be the MethodCompiledSignal that holds the string or the object, but this would only be available after the method was compiled. As you need to get information during the compilation process, you either need finer grained events, or another mechanism. This is a fun one to play with, but it is certainly doable. Cheers, Doru On Fri, May 15, 2015 at 7:30 AM, Tudor Girba <tudor@tudorgirba.com> wrote:

What Stef means is that ideally, we should no strive to not have code like: "Transcript show: 'my event'". Instead, we should only log events (ideally, concrete classes like MyEvent) and if we want to see the textual representation of this, we just plug a Transcript interface to the logger.

Cheers, Doru

On Fri, May 15, 2015 at 4:27 AM, Ben Coman <btc@openinworld.com> wrote:

...

...

Le 14/5/15 15:12, Alain Rastoul a écrit :

Le 14/05/2015 02:08, J. Vuletich (mail lists) a écrit :

...

...

A port of the code to Pharo is required, as Alain and Stef have shown. Besides, Cuis doesn't include support for Traits. I think your idea is very good, and I hope some Pharoer (Alain?) does it.

Hi Juan,

I tried Cuis, you did a very nice work here.

About porting, I did this first raw port to allow other peoples who complains about pharo transcript to have a look at Cuis Trancript more easily. And apart from a small window inset problem and an initial display Form I probably did not get well (and/or a clip missing somewhere?), it does the same thing than in Cuis.

May be we should wait a little so that people can say their word about it too and eventually/if they want/can/... investigate those two morphic porting issues. In the meanwhile, a simple "fix" in the Transcript could be done too (see last Ben's post) with an extra system settings.

About sluggishnesh and Transcript speedup , the changes you made in Cuis, as seen in git commits, are a bit intrusive (DateAndTime, AbstractFont, Strikefont ?), I don't think I know pharo enough to report them.

Also I experienced another issue that exits in Cuis too:

The Transcript overwrite other morphs/windows when showing its contents during do-it

After end of execution, the world redisplays correctly but not in Pharo

(see attached screen shots)

On Fri, May 15, 2015 at 3:18 AM, stepharo <stepharo@free.fr> wrote:

...

Thanks alain for checking. I think that we can offer different implementations and let people pick the ones they like. My goal is to remove direct refer to Transcript from the image so that we can plug an implementation and in particular the merge of Doru and Norbert/Mine loggers

Stef

I don't quite follow "remove direct refer to Transcript". Isn't "Transcript" effectively a global variable that can already be plugged with any implementation?

As I've been contemplating the Transcript situation, I keep coming back to the idea that Transcript should be a client of a broader logging framework, but wondering how much complication that would to tracing VM simulation.

Further, since the logging framework needs to be threadsafe, rather than using protected access to a shared datastructure, would it be good to have a separate "logging" process to consume log entry submissions from multiple threads, and pass them on to output threads (including Transcript viewer). Some possible advantages: * Eliminate complications from priority inversion ( http://en.wikipedia.org/wiki/Priority_inversion) * Minimise code that log-entry-producer-thread needs to execute/debug into -- maybe beneficial for VM simulation? * Minimises execution time in log-entry-producer-thread.

cheers -ben

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com "Every thing has its own flow"