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. Cheers, Doru On Sat, May 9, 2015 at 9:31 PM, Clément Bera <bera.clem...@gmail.com> wrote: > > > 2015-05-09 20:25 GMT+02:00 stepharo <steph...@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.mira...@gmail.com>: >> >>> Hi Ben, >>> >>> On May 9, 2015, at 7:41 AM, Ben Coman <b...@openinworld.com> wrote: >>> >>> >>> >>> On Sat, May 9, 2015 at 10:09 PM, Ben Coman <b...@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"
