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

Re: [Pharo-dev] Transcript needs your love

by J. Vuletich (mail lists)

Thanks Sven. I think that in any case it is useful, even if you end implementing something different. Cheers, Juan Vuletich Quoting Sven Van Caekenberghe <sven(a)stfx.eu>: > 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(a)jvuletich.org> wrote: >> >> 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

[Review]: Issue 13159: ListDialogWindow - Grow Width to Fit List

by Sean P. DeNigris

https://pharo.fogbugz.com/default.asp?13159 Right now, it doesn't do a very good job of sizing itself. See the screenshot below of the Metacello Configuration Browsers "Switch Repository" dialog. The width is insufficient for the tool to be resizable without first manually resizing. <http://forum.world.st/file/n4825490/Screenshot_2015-05-09_09.png> Fix in inbox, validated by monkey: SLICE-Issue-13159-ListDialogWindow---Grow-Width-to-Fit-List-SeanDeNigris.1 - Keep extent relatively consistent with the contained list morph ----- Cheers, Sean -- View this message in context: http://forum.world.st/Review-Issue-13159-ListDialogWindow-Grow-Width-to-Fit… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 9, 2015

A fast Transcript

by Eliot Miranda

Hi Juan, I see that your new transcript is indeed much faster but is also not editable. I wonder if it would be possible to have the best of both worlds and arrange that, when active, the transcript is editable. For example, selecting the TranscriptWIndow could put it into a mode where the transcript's state was imported into a more conventional editable text morph, and then when the window was exited, reverted to the standard fast output mode. As you can infer I like having an editable transcript. I can do without it, because Squeak's slow transcript is indeed a PITA, but I'm not sure that speed need preclude editability. On Sat, May 9, 2015 at 10:17 AM, J. Vuletich (mail lists) < juanlists(a)jvuletich.org> wrote: > 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 > > > -- best, Eliot

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by ClÃ©ment Bera

2015-05-09 20:25 GMT+02:00 stepharo <stepharo(a)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(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 Eliot Miranda

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(a)jvuletich.org> wrote: > 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 > > > -- best, Eliot

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Sat, May 9, 2015 at 10:17 AM, J. Vuletich (mail lists) < juanlists(a)jvuletich.org> wrote: > 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. > 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

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Eliot Miranda

On Sat, May 9, 2015 at 11:18 AM, stepharo <stepharo(a)free.fr> wrote: > > > Le 9/5/15 16:24, Eliot Miranda a Ã©crit : > > > > On Sat, May 9, 2015 at 5:37 AM, stepharo <stepharo(a)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

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by Sven Van Caekenberghe

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(a)jvuletich.org> wrote: > > 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] Transcript needs your love

by stepharo

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

May 9, 2015

Re: [Pharo-dev] Transcript needs your love

by stepharo

Thanks Juan. Stef >> 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