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

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 10 May 2015 at 10:23, stepharo <stepharo(a)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. :) -- Best regards, Igor Stasenko.

May 11, 2015

Re: [Pharo-dev] On Missing Class: Why not describe error?

by Sean P. DeNigris

Sean P. DeNigris wrote > Any reason not to make it... Issue 15524: CodeImport: Better info on non-existent behavior https://pharo.fogbugz.com/default.asp?15524 Fix in inbox: SLICE-Issue-15524-CodeImport-Better-info-on-non-existent-behavior-SeanDeNigris.1 - Put which class and which label in the error message ----- Cheers, Sean -- View this message in context: http://forum.world.st/On-Missing-Class-Why-not-describe-error-tp4825681p482… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2015

Issue 15523: Code Cruft Rule Only Matches One-Liners

by Sean P. DeNigris

https://pharo.fogbugz.com/default.asp?15523 Ouch, burned by "you must match at the level of the parse tree you are altering" again... It is ridiculously easy to fall into the following trap - when rewriting, you must match at the same level that you alter the parse tree. Thus, if your rule has one statement, like "`@object setHaltOnce", you can just focus on it... Unless you want to remove it completely! Then, you are altering the parse tree one level up, so you can't just write the above... Unless you're working on a one-line method, in which case you are at the top level and can do what you want! Woah! WTH!! Because of this common pitfall, RBCodeCruftLeftInMethodsRule was only matching one-line methods (which are the only ones we test of course). I rewrote it and added some tests. Fix in inbox: SLICE-Issue-15523-Code-Cruft-Rule-Only-Matches-One-Liners-SeanDeNigris.1 - Fix and clean RBCodeCruftLeftInMethodsRule to work on methods with multiple lines - Add tests for above - Move Object halting methods into 'halting' protocol. I had originally put them in an extension protocol, but Halt is in the same package, so that doesn't make much sense! ----- Cheers, Sean -- View this message in context: http://forum.world.st/Issue-15523-Code-Cruft-Rule-Only-Matches-One-Liners-t… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2015

Re: [Pharo-dev] Package comments

by stepharo

Le 11/5/15 20:10, Kasper Osterbye a Ã©crit : > Sergio Fedi and I are now working on this. > > As part of the work, we need a "default package comment", akin the the > default class comment. The class comment is inspired by CRC idea. > Translating CRC to a PRC, we suggest the following, and ask for comments > from the community. As I believe we will by the end of the year have a > inworld pillar renderer which is fairly stable, the default PRC template > could be: Coooooool :) > 'Please comment me using the following ""template"", ''inspired'' by Class > Responsibility Collaborator (CRC) design: > > !Package XXX, part of (reference to main package if one exist) I did not get " (reference to main package if one exist) " > one line description: For example, I'm xxx package, containing the hierarchy > of visitor objects. What are the public main classes? > > ;Responsibiliies > :Three sentences about my main responsibility, what I'm doing, what classes > do I offer. > ;Collaborators > :State my related packages, and which classes are the ones used from the > outside of the package. > > !!Public API > > - message one in class one > - message two in class two > - what is the way to use this package. > > One simple example is simply gorgeous. Or refer to which package is the > main package if there are several packages in play > > !!Internal Representation and Key Implementation Points. > > -Implementation Points, in particular references to classes with good class > comments.' > > Will this work? > > Best, Sergio & Kasper > > > > -- > View this message in context: http://forum.world.st/Package-comments-tp4824353p4825838.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > > >

May 11, 2015

Re: [Pharo-dev] Lighthouse example throw segfault

by stepharo

Hi alejandro which image? which version? which latest vm? do you see a pattern :) Stef Le 11/5/15 20:37, Alejandro Infante a Ã©crit : > Hello, > > When I try to open the image from Jenkins the screen goes black for 5 seconds and then it throws a segmentation fault in my Mac. I use a Macbook air with the latest stable Pharo VM. > > Using the ConfigurationOf I have found that Lighthouse by default set the display to work in fullscreen, and is perfectly usable, but when saving the image it is impossible to open it again (segfault). I attached the crash.dmp. > > If I try to disable the fullscreen before saving it, the error does not appear again. > > Iâm the only one capable to reproduce this? > > Cheers, > Alejandro >

May 11, 2015

Re: [Pharo-dev] On Missing Class: Why not describe error?

by stepharo

Yes It was on my to do to create a little addd-ons that create stupid stub classes. so that I can load broken code and do not care. Le 11/5/15 14:40, Sean P. DeNigris a Ã©crit : > Current implementation: > MethodDeclaration>>#handleMissingBehavior > "self error: ('Cannot install method in unexistent behavior {1}' format: > {(behaviorName asString)})" > > (MissingClassError > className: behaviorName asString) > signal > > Any reason not to make it: > MethodDeclaration>>#handleMissingBehavior > > (MissingClassError > className: behaviorName asString) > signal: 'Cannot install method in unexistent behavior', behaviorName > asString > ? > > It seems so obvious that I'm sure I must be missing something important! > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/On-Missing-Class-Why-not-describe-error-tp4825681.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 10/05/2015 13:15, Esteban Lorenzano a Ã©crit : > >> On 10 May 2015, at 13:10, stepharo <stepharo(a)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) -- Regards, Alain

May 11, 2015

Lighthouse example throw segfault

by Alejandro Infante

Hello, When I try to open the image from Jenkins the screen goes black for 5 seconds and then it throws a segmentation fault in my Mac. I use a Macbook air with the latest stable Pharo VM. Using the ConfigurationOf I have found that Lighthouse by default set the display to work in fullscreen, and is perfectly usable, but when saving the image it is impossible to open it again (segfault). I attached the crash.dmp. If I try to disable the fullscreen before saving it, the error does not appear again. Iâm the only one capable to reproduce this? Cheers, Alejandro

May 11, 2015

Re: [Pharo-dev] Package comments

by Kasper Osterbye

Sergio Fedi and I are now working on this. As part of the work, we need a "default package comment", akin the the default class comment. The class comment is inspired by CRC idea. Translating CRC to a PRC, we suggest the following, and ask for comments from the community. As I believe we will by the end of the year have a inworld pillar renderer which is fairly stable, the default PRC template could be: 'Please comment me using the following ""template"", ''inspired'' by Class Responsibility Collaborator (CRC) design: !Package XXX, part of (reference to main package if one exist) one line description: For example, I'm xxx package, containing the hierarchy of visitor objects. ;Responsibiliies :Three sentences about my main responsibility, what I'm doing, what classes do I offer. ;Collaborators :State my related packages, and which classes are the ones used from the outside of the package. !!Public API - message one in class one - message two in class two - what is the way to use this package. One simple example is simply gorgeous. Or refer to which package is the main package if there are several packages in play !!Internal Representation and Key Implementation Points. -Implementation Points, in particular references to classes with good class comments.' Will this work? Best, Sergio & Kasper -- View this message in context: http://forum.world.st/Package-comments-tp4824353p4825838.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by ClÃ©ment Bera

2015-05-11 13:06 GMT+02:00 Nicolai Hess <nicolaihess(a)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(a)gmail.com>: > >> >> >> 2015-05-10 10:37 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: >> >>> >>> On 10 May 2015, at 10:28, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: >>> >>> >>> >>> 2015-05-09 23:21 GMT+02:00 Tudor Girba <tudor(a)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(a)gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> 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) >>>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >>>> >>> >>> >>> >> >

May 11, 2015