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) >> > > >
