2015-05-10 10:37 GMT+02:00 Esteban Lorenzano <[email protected]>: > > On 10 May 2015, at 10:28, Clément Bera <[email protected]> wrote: > > > > 2015-05-09 23:21 GMT+02:00 Tudor Girba <[email protected]>: > >> 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. > > *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 <[email protected]> >> wrote: >> >>> >>> >>> 2015-05-09 20:25 GMT+02:00 stepharo <[email protected]>: >>> >>>> >>>> >>>> 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 <[email protected]>: >>> >>>> Hi Ben, >>>> >>>> On May 9, 2015, at 7:41 AM, Ben Coman <[email protected]> wrote: >>>> >>>> >>>> >>>> On Sat, May 9, 2015 at 10:09 PM, Ben Coman <[email protected]> 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" >> > > >
