May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Transcript needs your love

by stepharo

Le 9/5/15 16:24, Eliot Miranda a Ã©crit : > > > On Sat, May 9, 2015 at 5:37 AM, stepharo <stepharo(a)free.fr > <mailto: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. 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. 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 think that transcript should the fast and you do not care about thread safety. 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. 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

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by ClÃ©ment Bera

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). 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(a)gmail.com>: > Hi Ben, > > On May 9, 2015, at 7:41 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > > On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc(a)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) >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by J. Vuletich (mail lists)

Hi Folks, (below) Quoting Ben Coman <btc(a)openinworld.com>: > On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> >> >> On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)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

May 9, 2015

Re: [Pharo-dev] external package handling ... a concrete case

by stepharo

I will Le 7/5/15 15:21, Andrei Chis a Ã©crit : > In the meantime can you let us know when you integrate a slice for a > project managed through configurations. > I cannot guess when this happens. > > On Wed, May 6, 2015 at 11:24 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > > > Le 6/5/15 22:37, Esteban Lorenzano a Ã©crit : > > but that happens because GTools guys made a mistake: > > spotterActDefault > ^ Smalltalk tools browser openOnPackage: self > > thatâs the correct implementation of that method. > > > Ok but I do not care. This is just an example of the problem. > I will **not** publish the GTSpotter code nor update the > configuration because I do know the internal of GT. > If I would be maintaining an external pharo tool I would hate that > somebody publish random code to it. > > > The configuration of spotter and of any other project from gt is > nothing special nor complicated. > Feel free to update it or push changes directly to the repo at any time. > You'll get no complaints from us :) > > Cheers, > Andrei > > > When we publish a change in Pharo for external tools this is like > a pull request! > > Stef > > > Esteban > > On 06 May 2015, at 22:14, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > Hi guys > > I'm cleaning nautilus model and Spotter is extended. > Now I will not publish the fix in Spotter, I will not > update a configuration of a tool I do not know. > So what should I do, stop working? No this is not > possible. So I will push this changes in the inbox and > integrate it and GT people should merge the fix in their > baseline when they want. > Or I will really stop doing anything for Pharo 50 alpha. > > Stef > > spotterActDefault > ^ Nautilus openOnPackage: self > > > > > >

May 9, 2015

Re: [Pharo-dev] How can I specify the bindings when evaluating an expression?

by stepharo

Nice :) > https://pharo.fogbugz.com/f/cases/15490/provide-a-way-to-specify-external-b… > > > This Slice adds an API to the compiler to set a dictionary with > bindings to be taken into account. > They are compiled as pushLinteralVariable: (thus refer to the > association of the dictionary) > > Smalltalk compiler > bindings: { #a -> 3 } asDictionary; > evaluate: '1+a'. > > Internally this for now (ab)-uses the #requestor: API... later we will > change this to be inverted: the requestors > should privide binding and get notified using Announcements. > > > > >

May 9, 2015

Re: [Pharo-dev] Differences between TextConverters and ZnEncoders

by stepharo

Le 30/4/15 16:07, Guillermo Polito a Ã©crit : > They already are integrated! it's a matter of rewrite all usages of > MultiByteScaryStream and friends... Can you give me just a simple example so that I can understand what has to be done? > > El jue., 30 de abr. de 2015 a la(s) 4:06 p. m., stepharo > <stepharo(a)free.fr <mailto:stepharo@free.fr>> escribiÃ³: > > > I am biased, but the Zn converters are better. Why ? Because > they work between String <-> Bytes as a text encoder/decoder > should. They also have a number of extra features (counting the > number of encoded bytes, being able to move backwards on input, > being able to be very strict), are faster and have a clearer > implementation. Furthermore, they are more correct and implement > more encodings. > > > > There is also good documentation > http://stfx.eu/EnterprisePharo/Zinc-Encoding-Meta/ > > > > ZnCharacter[Read|Write]Stream are also very instructive, compare > them to MultiByteStream. > > > > Should we throw the other one out ? Probably. But it is the same > problems as with Xtreams: the API is different and adding a > compatibility layer would defeat the purpose. So I don't know. > > > > Sven > > I would integrate the good ones and deprecate the old ones! > > Stef > >

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

Hi Ben, On Sat, May 9, 2015 at 8:18 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> >> >> On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)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. > 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

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

Hi Ben, On May 9, 2015, at 7:41 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On Sat, May 9, 2015 at 10:09 PM, Ben Coman <btc(a)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)

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

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(a)openinworld.com> wrote: > > > On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >> >> On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)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

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Ben Coman

On Sat, May 9, 2015 at 10:35 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Sat, May 9, 2015 at 7:09 AM, Ben Coman <btc(a)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

May 9, 2015