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