[Vm-dev] [Pharo-dev] Squeak and Pharo speed differences

[Shaping]

== First, on the text selection delay issue. ==

 

Now that you mention it, the text seems to get highlighted slightly slower
than in native Windows widgets or WordPad (which is what I had available for
comparison). But it also behaves differently.

 

Please try the following and report whether you experience the same

delay: 1) click into the middle of a word with a single click - it won't get
highlighted,

 

Correct.

 

2) click again at the same cursor position 

 

How soon after?  If more than a small fraction of second, this is just
another single click.

 

- the whole word should be selected now.

 

No, not unless this is a double click.  If I do a double click (splitting a
double click into two different click locations is almost impossible), then
the text highlights with a noticeable delay.

 

Is the reaction to the second click also too slow?

 

There is no response to the second click except to place the cursor in the
same place again.  A rapid sequence of clicks (double-click) must happen to
cause selection.

 

In regular Windows widgets you have to double-click, not click again, to
toggle word selection. Your experienced delay might therefore be associated
with Squeak/Pharo processing two consecutive single clicks and the OS
widgets processing one proper double click event. But that's only
speculation on my part, I didn't check the code.

 

These are Pharo windows, not native Windows windows.  I'm doing the tests in
a Pharo 9 Playground.  It follows the same selection protocol as a native
window:  a double click.  Pharo has its own event loop, like VW, right?  

 

== Second, on the divergence of Pharo and Squeak == from my perspective and
I have not been around at the time of the split yet.

 

A general note: you will obviously get biased views from each side and the
other one might view them as unfairly presented (which makes such
discussions unproductive quickly). Moreover, much of the divergence is not
in the VM but in the image, 

 

No good reason for image divergence has been given yet.  The Pharo effort to
modularize completely, if successful, gives all Squeak and Pharo
Smalltalkers what they want:  painless, reliable/predictable, deep
fine-grain reconfigurability of the environ.   Is there something else to
want here?  What does the bold stuff not cover?  

 

 

so you might not even be talking to the right people on the Squeak side.
Since not everyone is subscribed to both (or all three) mailing lists, they
might not see all the answers, so you cannot have a coherent discussion at
all.

 

I might not be mailing to the right lists.  Feel free to make suggestions.

 

To start with the example, I suppose the new preferences look has probably
not gotten from Pharo into Squeak not because the Squeak community did not
like it, but because it was simply not contributed back. The Squeak folks
would have had to pull it and probably did not deem it important enough (or
were not even aware if they don't use Pharo regularly).

 

Yeah, that's a problem. 

 

Besides, the preferences in Squeak are also not a flat list, they have had
categories for ages.

 

 

The categories are in an alphabetic list.  It should be a tree.  The list is
too long and doesn't show any organization besides the alphabetic ordering.
That's the point.  There is one invisible root and  a wide first level-not
much branching.  Two levels.  Also, the subitems in each category are
sometimes alphabetic and other time not.   I'd have to study the options for
a week to determine what I would do differently, but I don't like the first
impression this gives.  There is some sense of subcategory, like several
contiguous browse* items or syntax* items, but these groups should be in
subnodes.  I'm seeing three of four levels.  I'm not sure.  It would take
some study.  It doesn't feel coherent and compelling.  It doesn't pull me
in.  It looks like a bunch of miscellaneous details.  The Settings browser
makes pretty get sense, yes?

If the Squeak community was busy all the time pulling things

 

--Not all the time, just what you can use when you need it.  I don't think
the need for tree is perceived beyond the two levels.

 

back from Pharo, they could not concentrate on their own efforts.

 

Can you tell me about those efforts?  I know the VM is one, maybe the
biggest.  What else do Squeak folks work on?

 I also understand why the developers of the new Pharo preferences tree did
not like to invest the same effort in Squeak. What incentive would they
have?

 

Make all features (GUIs/frameworks) loadable into a new, mostly empty image.
Make all aware of those features.  Knowing that this will happen for all
feature-work contemplated will lower the threshold to doing the
feature-work.  A Squeak dev will learn about the Settings feature, for
example, and adapt it if he wants.  If we have the same basic graphical
framework, there is nothing to adapt (to Morphic).  It just works.  Yes, the
transition is painful.  And there is always a new transition coming as new
tech surfaces.  We need a way to deal with that systematically without
killing creativity and without creating so much disruption that commercial
interests are wary of the environ.   

 

And here we are. Such differences and the additional effort are the
liability of a fork, for both sides. Some people are or were active in both
communities to invest the effort. For example, Eliot also provided the image
side of VM improvements to Pharo, not only Squeak, if I remember correctly.
I don't know whether he still does that since the fork of the VM.

 

What fork of the VM?  Please explain.

 

Pharo would like to get rid of Morphic; as far as I know, Squeak embraces
Morphic for its direct manipulation interface and UI discoverability
(inspecting Morphs and such). 

 

Right.  

 

GTK has its inspector, but I don't know whether you get the same features
out of it. Direct manipulation probably not, only indirect. And can you
control that inspector from Pharo or do you have to write C code to change
it in GTK itself? From my impression, this would be a no-go for Squeak. The
tools must be maintainable in Smalltalk, working with C is a necessary evil
in the VM. Maybe Pharo has found a way to have the best of both worlds, I
don't know.

 

I don't know much about GTK yet.  I'll get to it.

 

Still that leaves all Morphic applications behind; their UI (or even the
entire program) would have to be rewritten from scratch. I doubt that Pharo
will keep Morphic workable once they can drop it from the mainline.

 

I don't understand.  Drop?   Why?  If Morphic works and someone wants it,
then keep it.   Are you saying it would be dropped because it cannot be
satisfactorily re-implemented with the GTK3 backend?  What's wrong with
keeping Morphic primitives?

 

And Spec2 is not the first new idea of UI technology in Pharo, you know. In
return, the different technology makes it harder for Squeak to port new
features even if they wanted to, making it less likely to happen. Even some
basic Collection API has changed in Pharo (string trimming and joining for
example), now try to keep your code compatible with both without messing it
up...

 

Yes.  The "port" is only difficult once if the aim is thereafter to work
from a common base image.  But there will be more ports and conversions.
Is there a system on either side for managing incorporation of new tech,
libraries, and standards?

 The compatibility and porting problems are offloaded to the application and
library developers, even between Pharo releases. I don't know how this can
be advertised as appealing to commercial development. VisualWorks & Co.

could certainly not deal with their users that way.

 

This happens in any case.  That it happens in one image and not two is
better.

 

 

I don't think that Pharo does bad stuff in general, in fact their work could
be very good (I don't look at it regularly and certainly don't follow the
implementation). Like you said, disentangling, modularization, test
automation, and innovation are valuable goals.

Squeak mostly agrees on the goals, but does not pursue them in the same
disruptive manner. Probably this is the "pushback" you have been told of...

 

Right.  How does squeak do things less disruptively?  I agree that the
innovation on the Pharo side is accompanied by almost as much bloat and
confusion, especially for new comers trying to port.  What is the Squeak way
of improving the frameworks and using new tech, like 3rd part libs?

 

If Spec is a UI generalization framework that makes it independent from the
graphics implementation, 

 

Yes, that's the aim. 

 

then one should rather compare it to Squeak's ToolBuilder, not Morphic.
ToolBuilder as well could have different targets, such as GTK, (I have seen
Squeak tools rendered with some Java UI Framework a few months ago) but
nobody pushes that in the Squeak trunk. There was no voiced demand.

 

I don't know ToolBuilder.  Perhaps I should have a look.  Why would the best
of both TB and Spec2 not be used in a common base tool-building framework,
which sounds broader than what Spec2 does, but may not be?  I don't know
enough of TB to say. 

 

How is framework adoption/inclusion decided?  The dev who writes the
framework first and demonstrates utility first with that framework will have
it included in the base image?  Just thinking aloud.  How does it work?  How
do you want it to work?

 

I haven't participated in such discussions of the right wayT in the past,
but my impression from what I heard so far is that Pharo pushes forward
rigorously and does not look back, and if it does, then sometimes with a
disparaging or snappy tone.

 

Does this mean that Pharo folks are unfairly critical of old frameworks in
order to push the new thing (whatever it is) along?

 

Some of the Squeak guys are therefore very sceptical about Pharo and their
attitude, to say the least, and sometimes also talk harshly. 

 

I can see how that might happen.  Too many changes too quickly doesn't look
like innovation to some.  It looks risky, especially to commercial
interests, but clearly the consortium don't want this view.  It's not
healthy for Pharo or Smalltalk.  

 

The recent fork of the VM further deepens the trenches,

 

Okay, this must have been the fork I saw Eliot mention a few weeks back.  I
don't know the details, but it sounds like a bad idea.

 

especially since the foundation of "OpenSmalltalk" VM (no longer "Squeak"
VM) was in my perception a commitment to cooperate at least on that end.
There are probably only a bunch of persons who are responsible for the bad
mood, and I assume that the majority of both communities are in fact
friendly people. :-)

 

So it seems, but I don't know the details.  I prefer to focus on the tech,
not personalities and self-esteem issues.  

 

Thanks for the perspective.

 

 

Shaping

 

 

 

 

 

Am Sa., 16. Mai 2020 um 08:40 Uhr schrieb Shaping <
<mailto:shaping at uurda.org> shaping at uurda.org>:

> 

> 

> 

> Why can't the OSVM be a single, unforked, maxed-out VM with all the best
and fastest features working in Squeak and Pharo?   Why did the split
happen?

> 

> 

> 

> In very general terms, the fork was due to their being Group A wanting 

> to go one direction and Group B wanting to go in a different direction.
i.e....

> 

> B says "We want to do X".

> 

> A says "We don't want to do X."

> 

> B says "We really want to do X."

> 

> A says "Definitely no."

> 

> B says "We really want to do X and actually we're doing it over here."

> 

> 

> 

> Lol  Thanks for the explanation.  That's more or less what I thought.

> 

> 

> 

> But can't the differences be setup at config-your-environ time instead of
build time, when the task is heavier and slower?

> 

> 

> 

> In essence, Squeak considered backward compatibility of prime importance
including the code of some applications that had become entangled in the
main code base.    Pharo wanted to "clean the code" by disentangling and
stripping those parts.

> 

> 

> 

> I like disentangling and modularizing.   I suppose this is a universal
like.

> 

> 

> 

>   They also wanted to move to a reproducible-build-system where each 

> change "bootstrapped" a nightly image from an empty file,

> 

> 

> 

> I like this too.

> 

> 

> 

> whereas Squeak continues to use a "continuous evolution" model.

> 

> 

> 

> Don't both groups want the automatic building and testing the Consortium
is talking about recently?

> 

> 

> 

> I'm not sure I understand how "continuous evolution" works.  Sounds like
there is lots of wiggle room in that idea.  Don't we need some structure?
We seem to be getting that in Pharo.

> 

> 

> 

> I'm not sure about Squeak.  The GUI tools/menus still feel hodgepodge
(much nicer, but still not well organized) 16 years later.  I used it
between 2002 to 2004, and then again just a few days ago.  I like the faster
debugger and the flat GUIs, but I don't need Morphic to have those dev-tool
GUIs.  I'd prefer to rework the GUIs with Spec2/GTK3, and keep the flat,
clean, button-packed look with some improvements (like the new Spec2
selection highlighting pattern, which is very nice).  The rest of Squeak
seems messy.

> 

> 

> 

> I do very much like the technical, concrete feel of Squeak's details about
the VM.  That reminds me of old times and why I got involved in computers,
and it supports my current interest in VM parallelization.  Those VM details
need a somewhat different shape/presentation.  There is a beauty in Squeak,
but the eviron still feels a bit rough.

> 

> 

> 

> For example, why aren't all those preferences in a tree where you can
actually find things because they are categorized.  It's a big list.  That
seems very strange in 2020.  Why don't Squeak folks borrow the Pharo
Settings GUI idea, and implement that in Morphic, as they like?  I thought
more would have happened in the Squeak GUI in 16 years, but I've not seen
all of 5.3 yet.  I'm still poking around.  I suppose most of the
improvements are in the VM, which I imagine absorbs most of the group's
energy.

> 

> 

> 

> And there are more reasons I probably not aware of.

> 

> Here is the Pharo Vision document circa 2012 which inspired me  

>  <https://hal.inria.fr/hal-01879346/document>
https://hal.inria.fr/hal-01879346/document

> 

> 

> 

> Thank you.  I will read it.   Is the Consortium updating that doc?  There
was a doc recently from Stef that looks like it belongs in there, merged
somehow.

> 

> 

> 

> It looks like a bad use of energy in a community that is small and needs
to use its human resources efficiently.

> 

> 

> 

> Trying to go one way and dealing with continual pushback and conflict
around that is also bad energy.

> 

> 

> 

> Agreed.  I don't understand the pushback because I don't understand Squeak
folks' objection to rigorous, systematic, automatic testing and
disentangling/modularizing of frameworks.  They are probably fine with all
that.  Do Squeak folks have a document that defines "continuous
development."  I know that VM testing is automated.  I don't see how the
objectives are so different, at least on the automation front.  Everyone
seems to agree that CI is good.

> 

> 

> 

> 

> 

>  I want to help, but need to port first from VW, and I'm trying to choose
Squeak or Pharo.  Both have speed problems.  Squeak has fewer, but Pharo
could be much faster with broad use of Spec2.

> 

> 

> 

> Would reintegrating Squeak and Pharo development make more sense?

> 

> 

> 

> I think that is not likely.  Both continue to have different goals.  And a
significant area where they are likely to continue to diverge is the
graphics.  Squeak is likely(?) to stay with Morphic a long while Pharo
intends to dump Morphic.

> 

> 

> 

> I never liked the halo thing.  It's okay.  It seemed/seems too busy and
distracting.  I think Morphic and the "too many cooks" problem is why I
broke off in 2004.

> 

> 

> 

> If we are fully modular, and you love Morphic, and want to live there
mentally and visually, all the time, then load the Morphic package into the
new universal OpenSmalltalk.  Have all your GUIs built with Morphic.  Have
cute little morphs stuck here and there.  Knock yourself out.  Don't like
Morphic?  Don't think it's cute?  Load the more business-like-but-not-boring
Spec2.  I don't see an insurmountable technical problem here.

> 

> 

> 

> 

> 

> This is one of the reasons that Spec was created - to be independence
layer.

> IIUC in Pharo 9 Spec is already working on top of a GTK3 backend.

> 

> 

> 

> Yes, the Spec2 Launcher is inspiringly snappy, modulo the text-selection
slowness problem, which is everywhere in Pharo and Squeak.  I've mentioned
this a few times recently-of all the goofy things to prevent a port from
VW...Okay, that and Pharo's slow debugger.  Two things keep me out of
Pharo/Squeak.  I don't love VW.   I tolerate it really well.  That's
different.  J

> 

> 

> 

> wrt the VM, Pharo want to remove all native-windowing from the VM, so 

> that window opening

> 

> is controlled from the Image via FFI rather than the VM.

> 

> 

> 

> I agree with the objective.

> 

> 

> 

> This conflicts with Squeak's backward comparability goals.

> 

> 

> 

> Okay, this is the real problem.

> 

> 

> 

> So there is a ton of old Squeak code that no one is willing to rework in
order to be compatible with the new vision for native-windowing
independence.  Perhaps someone can give more details on that old code.

> 

> I suppose many Squeak folks bemoan all the extra work needed for a
recoding.  Is this still really an issue?  Maybe very little of that old
code is still being used in business-critical ways.  The need for a recoding
may not be the big issue it once was.

> 

> 

> 

> This change would effectively create more devs willing to work on any
problem.  This change would also prevent fracturing of feature-sets across
the two Smalltalks from happening in the first place.

> 

> 

> 

> I personally had the inspiration that Squeak might be based off the 

> Pharo Headless Bootstrap,

> 

> but in the end I didn't find the time to push this further.

> 

> 

> 

> That's a very good idea.  Why don't all the Squeak folks work on it?  Are
you the only one pushing for this?

> 

> 

> 

> 

> 

>  Squeak and Pharo GUI styles are different.  So be it.  Can't the GUI
frameworks and conventions be separated in the same image, and configured as
desired in GUI sections of Settings?

> 

> 

> 

> Pharo currently can use both Morphic and GTK3 for its GUI backend.

> Possibly the GTK3 backend would provide some speed benefit (??)

> 

> 

> 

> It's a good question.  Is the core Morphic issue whether GTK3 can render
non-rectangular shapes efficiently?  There's a lot of that in Morphic.  I
suppose it's the main concern.  Even if Morphic relies on special drawing
primitives, they can go in a lib and be accessed via FFI.

> 

> 

> 

> Shaping

 

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20200516/e14e9ed1/attachment-0001.html>