Squeak and Pharo speed differences

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Squeak and Pharo speed differences

Shaping1
 

Hi all.

 

 

Squeak 5.3: 

  Time millisecondsToRun: [ 100000 factorial  ] 6250

 

Pharo 8:

  Time millisecondsToRun: [ 100000 factorial  ] 7736

 

Why the difference?

 

Squeak 5.3 release notes describe arithmetic improvements.  Nice.  I crunch very big numbers, and these improvements therefore have value.  Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo?

 

Playing with Squeak 5.3, I’ve noticed that the GUI is snappier.  Browser ergonomics are better too (for me at least), but that can be fixed/tuned in either environ to suit the developer.  (Still that’s some work I prefer not to do.)  Pharo GUIs are now generally slower, except for the Launcher, which is delightfully quick because it is written in Spec2.  I presume that all Pharo GUIs will eventually (ETA?) be written in Spec2 and that Pharo will then be quick in all its GUIs.  The obvious question is:  Will Squeak be improving GUI look/behavior and speed with Spec2?  If not, can I load Spec2 into Squeak so that I can do new GUI work there?

 

Both Squeak and Pharo have slow text selection.  Pick any word in any pane, and double click it to select it.  When I do this, I sense a 75 to 100 ms latency between the end of the double click and the selection highlight appearing on the word.   I thought I’d entered a wormhole.  So I did the same experiment in VW 8.3.2, VS Code, and Notepad, and all three showed undetectable latencies.   This matters to me.  I’m trying to port from VW to Pharo or Squeak (for a really long time now), and can’t push myself past the text-selection delay problem.  Can text-selection speed be improved to the level of VW’s?   Can someone sketch the algo used and/or point me to the right class/methods. 

 

The Squeak debugging experience step-to-step is much quicker.  The latencies in Pharo after button- release are very long.  I estimate 100 to 150 ms.   That’s too long for me to work productively.  I lose my mental thread with many of those delays, and have to restart the thought.  It’s a serious problem, caused mostly by acclimation to no detectable latency for many years (Dolphin and VW have quick GUIs).  Is speeding up the Pharo debugger with Spec2 a priority?  I can’t think of a better GUI-related priority for Pharo.

 

 

Not speed-related:

 

-  How can I load additional fonts into Squeak?  Pharo does this with the font dialog’s Update button.

 

- Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge?  Some of the Squeak panes have this; others don’t.  I want leading-edge action in all panes, and wish the feature were in Preferences/Settings.

 

 

 

Shaping

 

 

 

 

 

 

 

 

 

Reply | Threaded
Open this post in threaded view
|

Re: Squeak and Pharo speed differences

timrowledge
 


> On 2020-05-14, at 9:47 PM, Shaping <[hidden email]> wrote:
>
> Squeak 5.3 release notes describe arithmetic improvements.  Nice.  I crunch very big numbers, and these improvements therefore have value.  Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo?

The VM changes *are* in the VM code. If pharo haven't bothered to take advantage of them, that's their job to do. There are also image changes involved. Again, somebody has to do the work.

>  The obvious question is:  Will Squeak be improving GUI look/behavior and speed with Spec2?  If not, can I load Spec2 into Squeak so that I can do new GUI work there?

Unlikely and unlikely.

>  
> Both Squeak and Pharo have slow text selection.  Pick any word in any pane, and double click it to select it.

Really? I can't detect any difference. And that's with the Squeak running on a Pi and VW on a big iMac.

It mostly depends on how you detect a double-click as opposed to a single, or a mouse-down-drag etc.

> (Dolphin and VW have quick GUIs).  
Never used Dolphin but I disagree about the (currnet)VW GUI; I'm using both for work right now and Squeak (again, on a Pi vs the VW/iMac) seems much faster to me.


> Is speeding up the Pharo debugger with Spec2 a priority?  I can’t think of a better GUI-related priority for Pharo.

Why ask that here?

>  
>  
> Not speed-related:
>  
> -  How can I load additional fonts into Squeak?  Pharo does this with the font dialog’s Update button.

Font importer. It's right there in the Apps list, second row.

>  
> - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge?  Some of the Squeak panes have this; others don’t.  I want leading-edge action in all panes, and wish the feature were in Preferences/Settings.

As a general UI point, leading edge action is rarely a good thing.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Long computations that yield zero are probably all for naught.


Reply | Threaded
Open this post in threaded view
|

Re: Squeak and Pharo speed differences

Shaping1
 

> Squeak 5.3 release notes describe arithmetic improvements.  Nice.  I crunch very big numbers, and these improvements therefore have value.  Why would they not be included in OSVM (forked or not) and the basic class-set for both Squeak and Pharo?

 

The VM changes *are* in the VM code. If pharo haven't bothered to take advantage of them, that's their job to do. There are also image changes involved. Again, somebody has to do the work.

 

>  The obvious question is:  Will Squeak be improving GUI look/behavior and speed with Spec2?  If not, can I load Spec2 into Squeak so that I can do new GUI work there?

 

Unlikely and unlikely.

 

> Both Squeak and Pharo have slow text selection.  Pick any word in any pane, and double click it to select it.

 

Really? I can't detect any difference. And that's with the Squeak running on a Pi and VW on a big iMac.

 

Yeah, it’s bad, and I often wonder why no one says anything about it.  It definitely slows my work, and I’m not talking about the extra time for rendering.  It’s mentally disruptive.  

 

It mostly depends on how you detect a double-click as opposed to a single, or a mouse-down-drag etc.

 

I go by the definition of a double click:  the button-up event of the second click ends the double-click event.  Searching for and rendering of the selected text then begins.  This takes roughly 75 to 100 ms consistently in Pharo and Squeak.

 

> (Dolphin and VW have quick GUIs). 

Never used Dolphin but I disagree about the (currnet)VW GUI; I'm using both for work right now and Squeak (again, on a Pi vs the VW/iMac) seems much faster to me.

 

Note that I was specific about the current porting problem as it relates to GUI deficiencies.  The problem is not about general GUI speed (like opening and closing windows), which is okay to good in VW, and better overall in Pharo, especially in a Spec2 component (the Launcher).  This problem is about text selection speed.   I’m running Windows 10 Pro on an 2.7 GHz Xeon with 96 GB. 

 

I just tried text selection again in Pharo 9 in a Playground and in VW 8.3.2’s Transcript.  VW is much faster.  This is stopping my port--that and the debugger’s slowness (even slower than the text selection).   The porting problem for me reduces to two little, but extremely important GUI dynamics I experience frequently when coding.

 

 

> Is speeding up the Pharo debugger with Spec2 a priority?  I can’t think of a better GUI-related priority for Pharo.

 

Why ask that here?

 

(I thought I was posting to the Pharo lists too; corrected above.)

 

Font importer. It's right there in the Apps list, second row.

 

Yes, I found it.

 

> - Where in the Squeak and Pharo images can I change mouse-selection behavior to be leading-edge?  Some of the Squeak panes have this; others don’t.  I want leading-edge action in all panes, and wish the feature were in Preferences/Settings.

 

As a general UI point, leading edge action is rarely a good thing.

 

I use leading edge single clicks all the time for most of the last 25 years of Smalltalk coding.  The choice is for me as dev, not for clients.  The issue is once again about high-speed continuity of gesture and thought during coding.  Eliminating the delay matters.  I’ve had time to try it both ways.

 

Shaping

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Shaping1
In reply to this post by Shaping1
 

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

 

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

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Jakob Reschke-2
 
Hi 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, 2) click again at the same cursor position -
the whole word should be selected now. Is the reaction to the second
click also too slow? 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.

== 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, 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.

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). Besides, the preferences in Squeak are also not a
flat list, they have had categories for ages.

If the Squeak community was busy all the time pulling things back from
Pharo, they could not concentrate on their own efforts. 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? 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.

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

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

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

If Spec is a UI generalization framework that makes it independent
from the graphics implementation, 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 haven't participated in such discussions of the right way™ 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. Some of the Squeak guys
are therefore very sceptical about Pharo and their attitude, to say
the least, and sometimes also talk harshly.  The recent fork of the VM
further deepens the trenches, 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. :-)

Kind regards,
Jakob

Am Sa., 16. Mai 2020 um 08:40 Uhr schrieb Shaping <[hidden email]>:

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

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Shaping1
In reply to this post by Shaping1
 

== 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 way™ 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 <[hidden email]>:

> 

> 

> 

> 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

> 

> 

> 

> 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

 

 

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Robert Withers-2
 

Hi Shaping,

On 5/16/20 8:47 AM, Shaping wrote:

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.


Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. I couldn't get distracted from my core work.

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. That is step number one to having features co-loadable, common load systems. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :(

K, r

-- 
Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Stephan Eggermont-3
 
Metacello works well across Gemstone, Squeak and Pharo

Verstuurd vanaf mijn iPhone

Op 16 mei 2020 om 15:33 heeft Robert <[hidden email]> het volgende geschreven:



Hi Shaping,

On 5/16/20 8:47 AM, Shaping wrote:

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.


Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. I couldn't get distracted from my core work.

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. That is step number one to having features co-loadable, common load systems. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :(

K, r

-- 
Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Robert Withers-2
 

I prefer the dependency model supported by .mcm files, Monticello Configuration Maps. There has been some recent work to them adding author and comments. Monticello Configuration Maps allows linking of a specific version of dependent packages, across multiple repositories. Evidently there is a way to specify the latest version, but I just link/update specific versions. There is so much I don't know!

My thoughts regarding Metacello are that it solves the problem with side effect complexities, such as #baseline and such messages. It builds subclass to be versioned in turn, with all of the needs. I get it the flex of writing custom protocol for a Metacello subclass. The same is achieved relying on the #startUp: protocols on real domain objects of a robust role. To my experience, Metacello is way too verbose.

TSTTCPW, seems reflected in Monticello maps design. How hard could it be to provide support for them in Pharo? And Tonel? Good Christ!

Kindly, rabbit

On 5/16/20 10:07 AM, Stephan Eggermont wrote:
Metacello works well across Gemstone, Squeak and Pharo

Verstuurd vanaf mijn iPhone

Op 16 mei 2020 om 15:33 heeft Robert [hidden email] het volgende geschreven:



Hi Shaping,

On 5/16/20 8:47 AM, Shaping wrote:

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.


Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. I couldn't get distracted from my core work.

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. That is step number one to having features co-loadable, common load systems. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :(

K, r

--
Kindly,
Robert
-- 
Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Jakob Reschke-2
In reply to this post by Shaping1
 
Hi Shaping,

To clarify about the VM fork: few years ago, the transpiled C source
code of the VM, along with the genuine C parts and core plugins, were
migrated to GitHub under the common name OpenSmalltalk VM, to be
shared by Squeak, Pharo, Cuis, and Newspeak. But a few months ago,
Pharo eventually decided to fork the repository and proceed to make
their desired changes to the VM promptly and without the need for
mutual agreement. They can progress faster now, but we have another
fork.

Since the only shared mailing list at the moment is vm-dev (although I
don't know whether that is still true since the fork), that is your
best bet. Of course you will miss out Squeak and Pharo members not
subscribed to the vm list, so there is not really a nice way to
address both communities widely and reliably at the same time and have
a connected discussion. At least no way that I know of. I just wanted
to ensure you are aware of the fact that you might not get
counterarguments or other perspectives where some are due.

Looks like the text editor has diverged in Pharo as well. In Squeak,
what I described works (at least in my image and I don't remember
changing anything about text editing): you can toggle the selection of
a whole word with a separate single click (can be any number of
seconds after the first) on the cursor position. It is not so in Pharo
(I have a Pharo 8 image here), so my speculation about the click
handling is no "excuse" that explains the delay there, but maybe the
underlying event handling is still waiting for two separate single
clicks in a short time frame. Would be nice if someone rectified my
assumptions, if they know better. Anyway the selection in Squeak is
quick enough for me personally to not be bothered by it.

By dropping Morphic I meant that as soon as Pharo no longer needs it,
they will probably not include it in the "default"
image/configuration. As soon as this happens, someone would have to
make sure that Morphic still works when loaded into a Pharo image.
Otherwise Morphic in Pharo will rot and eventually become unusable,
and so will applications programmed with Morphic. And I doubt that
this maintenance effort of Morphic in Pharo will happen on behalf of
the official Pharo leadership.

Incidentally, in the early days Pharo adopted several new packages or
factoring styles that were not accepted in the default Squeak image
yet for whatever reason, coupling them more tightly with the base
system. For example, the new file API (not the VM primitives, but the
Smalltalk API) which was just an add-on package for Squeak in the
beginning, or the usage of Traits in the core packages, which means
you cannot unload the Traits package. Pharo has since then tossed out
the original file API and w.r.t. traits may have redefined what "the
core" is... Maybe Squeak and Pharo do not mean the same things or do
not draw the same lines when they say "completely modularized". With
respect to Morphic, maybe Pharo wants to replace some subsystems with
more professional-looking alternatives, and not maintain so much
self-built technology. It is not entirely impossible to have different
UIs in Squeak either (it still has the legacy Smalltalk-80 MVC GUI
which you could use instead of Morphic, and there is a basic console
interface). The questions are 1) would a particular backend be
supported by the official distribution (Morphic in Pharo? GTK in
Squeak?), 2) which APIs are supported and stable to build applications
with (ToolBuilder vs. Morphic vs. GlamorousToolkit vs. Spec vs. Block
and Brick vs. GTK-binding vs. whatever), and 3) is anything of the API
reliably available in both Squeak and Pharo, without duplicating a lot
of code? At the moment, not even the Collection API is entire
compatible, as I said.

Regarding "Morphic primitives", to my knowledge Morphic builds on the
event input primitives, and uses the Graphics API (pens, lines,
shapes, colors, fonts etc.) to draw, which in turn relies on BitBlt
primitives for rendering. I am not sure whether one could implement
Morphic on top of GTK without compromises. With just enough effort,
you can probably make anything happen... But the resources of the
community are severely limited, especially for Squeak.

Kind regards,
Jakob

Am Sa., 16. Mai 2020 um 14:47 Uhr schrieb Shaping <[hidden email]>:

>
>
>
> == 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 way™ 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 <[hidden email]>:
>
> >
>
> >
>
> >
>
> > 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
>
> >
>
> >
>
> >
>
> > 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
>
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Robert Withers-2
 

Hi Jakob,

On 5/16/20 10:28 AM, Jakob Reschke wrote:
I am not sure whether one could implement
Morphic on top of GTK without compromises. With just enough effort,
you can probably make anything happen... 

Yummy!

But the resources of the
community are severely limited, especially for Squeak.

Any chance of some official recruiting & marketing? Or marketing for recruiting... How to get broad college compScis into Squeak?

Make a game. A user-extensible game. So the kids can hack!

K, r


    
-- 
Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Jakob Reschke-2
In reply to this post by Stephan Eggermont-3
 
Metacello itself does work well across dialects, but one currently
cannot load Tonel repositories via Metacello in Squeak because with
Tonel, Squeak was left behind. The format was devised by Pharo and
pushed by Pharo, no cooperation with Squeak I have heard of. It was a
matter of sink or swim. Some of us are trying to fix that with a Tonel
fork (mainly because of changes to Collection API and Monticello in
Pharo) and an an ongoing pull request to Metacello...

Am Sa., 16. Mai 2020 um 16:08 Uhr schrieb Stephan Eggermont <[hidden email]>:

>
>
> Metacello works well across Gemstone, Squeak and Pharo
>
> Verstuurd vanaf mijn iPhone
>
> Op 16 mei 2020 om 15:33 heeft Robert <[hidden email]> het volgende geschreven:
>
> 
>
> Hi Shaping,
>
> On 5/16/20 8:47 AM, Shaping wrote:
>
> 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.
>
>
> Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed. I couldn't get distracted from my core work.
>
> NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format, from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created. So there is no commonality of load systems between Squeak/Pharo. It totally sucks. That is step number one to having features co-loadable, common load systems. I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :(
>
> K, r
>
> --
> Kindly,
> Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Jakob Reschke-2
In reply to this post by Robert Withers-2
 
Am Sa., 16. Mai 2020 um 16:37 Uhr schrieb Robert <[hidden email]>:
>
> Any chance of some official recruiting & marketing? Or marketing for recruiting... How to get broad college compScis into Squeak?
>

Who has got the money?

>
> Make a game. A user-extensible game. So the kids can hack!
>

It's not that simple. The kids rather like to hack in node.js and such
nowadays. ;-) Attracting them to Smalltalk in university courses works
for some, but not so many. Might also be a reason why Pharo wants to
look more attractive.
tty
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

tty
In reply to this post by Shaping1
 


hi Shaping

There was a brief exchange on vm dev board a week or so ago about integrating feenk.com fork of the vm, which supports glamorous toolkit into squeak vm.

That might be worth your time to review.

Iirc, in the squeak startup sequence, the morphic process is launched, barring any morphic tentacles into the non morphic portions of squeak, it appears that morphic PROCESS, may be bypassable. 

Lastly for further treeview item sorting adventures, check out FileList on linux (:

Ok, really last point. Squeak/ smalltalks feel like Linux back in the 1990s.  Lots of qkuirks, but something very important to the craftvof software was/is happening. I was mocked and scoffed fir embracing linux over DOS . Nit so crazy now, heh?

Good luck




Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Sean P. DeNigris
Administrator
In reply to this post by Robert Withers-2
 
Robert wrote
> TSTTCPW, seems reflected in Monticello maps design. How hard could it be
> to provide support for them in Pharo? And Tonel? Good Christ!
> ...
>  there is no interested in making features cross-image. NONE. ZERO! It is
> a hard fork. So sad. :(

From an idealogical point of view, I share everyone's frustration with the
divergence between Squeak and Pharo. Yes, it would be wonderful to
reintegrate the fork(s)! I've dreamed this dream almost since the beginning,
when I tried to keep all my projects compatible between Squeak and Pharo
(impossible). I've shared this dream many times on various MLs, including:
-
http://forum.world.st/Fork-Proposal-Cuis-Killer-Apps-tp3796633p3798801.html
-
http://forum.world.st/Survey-what-do-you-do-with-Squeak-what-do-you-want-to-do-tp5067643p5075317.html
-
http://forum.world.st/Pharo-and-the-rest-of-the-ecosystem-tp4582839p4590003.html

But this is ultimately not the story of Squeak and Pharo, but the story of
human beings! This is how it is. People and groups have goals and pursue
them to the best of their ability, and sure it is sloppy and inefficient.
Eventually I realized there is no use in complaining (it's raining, so be
it), although there can be value in keeping this dream alive. Who knows,
maybe at some point, after enough time, with enough generations of
programmers, the political and personal barriers (the main ones) will lessen
enough to make more things possible, but the problem will remain: who will
do the work?!

We say "how much work could it be", but PARC, and Pharo, and many of us are
building cathedrals. Even if we focus 100% on our primary dreams, it's
unlikely we will see the goal reached in our career/lifetime. So "how much
work could it be": too much!!! We are asking drowning people to light our
cigarette and then complaining that it would have been spoken easy to just
help us out. And it's worse, because these drowning people are already
dedicating much of their lives to provide software for us for free!

The only way forward for us is to keep the dream alive, and share it to
inspire others, but get to work and don't stop, with what we have today, and
be grateful for it.





-----
Cheers,
Sean
--
Sent from: http://forum.world.st/Squeak-VM-f104410.html
Cheers,
Sean
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Shaping1
In reply to this post by Robert Withers-2
 

Hi Shaping,

Hi Robert.  (We’ll get back to the parallelizing any day now…)

On 5/16/20 8:47 AM, Shaping wrote:

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.

 

Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed.

 

Who oversees stuff like this?

Specifically, why don’t we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimately—a nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time.

Why wasn’t this done when Tonel was first created?  The Pharo dev probably didn’t see it as good use of  dev time.  I kindly suggest that this attitude change for all contributors to both Smalltalks.

How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things?

 I couldn't get distracted from my core work.

Sure, I feel the same.  I imaging that most of us do.  

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format,

In my Pharo 9 I have a bit these bits:

 

Gofer new

    squeaksource: 'MetacelloRepository';

    package: 'ConfigurationOfAida';

    load.

  (Smalltalk at: #ConfigurationOfAida) load.

 

Metacello new

baseline:'Seaside3';

repository: 'github://SeasideSt/Seaside:master/repository';

load

 

So does this that mean Pharo strictly uses only Metacello and Git for version control now?

 

from a long time in Squeak. In particular, it is not possible to load a Monticello Configuration Map in Pharo and Squeak can't load the newer formats Pharo has created.

Yeah, that’s not healthy for the community.

 

So there is no commonality of load systems between Squeak/Pharo. It totally sucks.

Agreed.  Thanks for plainly saying so.  We need more of that.

 

That is step number one to having features co-loadable, common load systems.

Agreed.

I recall someone from the Pharo side being disparaging to the Monticello load format, so there is no interested in making features cross-image. NONE. ZERO! It is a hard fork. So sad. :(

It is very sad.   Let’s fix it.

Don’t the Consortium have an interest in such things?  Are the Consortium so Pharo-centric that they view Squeak as a useless blob of programming IP?  I don’t think so.  If there is genuine respect for the value of Squeak and Pharo on both sides, allowing their continued divergence and the many attendant frustrations to mount is negligent and wasteful. 

 Can we stop doing that?

I’m under the impression that Pharo folks want ultimately to use only Git, and that even the Metacello will be phased out.  Is that correct?   What is the version-control plan on Pharo, and can we implement the same plan—whatever that is--for Squeak too?

 

Shaping

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Robert Withers-2
 

Hi Shaping, I can't comment on parallelizing the VM. I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model.

On 5/16/20 11:29 PM, Shaping wrote:

Hi Shaping,

Hi Robert.  (We’ll get back to the parallelizing any day now…)

On 5/16/20 8:47 AM, Shaping wrote:

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.

 

Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed.

 

Who oversees stuff like this?

Specifically, why don’t we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimately—a nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time.

Why wasn’t this done when Tonel was first created?  The Pharo dev probably didn’t see it as good use of  dev time.  I kindly suggest that this attitude change for all contributors to both Smalltalks.

How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things?

 I couldn't get distracted from my core work.

Sure, I feel the same.  I imaging that most of us do.  

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format,

In my Pharo 9 I have a bit these bits:

 

Gofer new

    squeaksource: 'MetacelloRepository';

    package: 'ConfigurationOfAida';

    load.

  (Smalltalk at: #ConfigurationOfAida) load.

 

Metacello new

baseline:'Seaside3';

repository: 'github://SeasideSt/Seaside:master/repository';

load

In Squeak I can now ensureRecentMetacello, which I was not able to before.

Installer ensureRecentMetacello.

Metacello new
  baseline: 'MagicMouse';
  repository: 'filetree:///home/quotar/tribe/MagicMouse/packages';
  load

However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript

gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring
...FAILED->BaselineOfMagicMouse

I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer

The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus:

spec
    name: 'BaselineOfMagicMouse';
    repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'.

At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak.

Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo.

Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'CapabilitiesLocal';
    project: 'Oceanside'; install: 'ston-config-map';
    project: 'Cryptography'; install: 'SSLLoader;
    project: 'Cryptography'; install: 'Raven'.

Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo...


If there is genuine respect for the value of Squeak and Pharo on both sides

Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that..

K, r

--
Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Ronie Salgado
 
Hi Shaping,

About the latency, it may be because of the default idle time. Try running the following:

ProcessorScheduler idleTime: 1000
 
By the release of Pharo 7 the idle time was increased to 50 ms in order to reduce the CPU usage on the cloud and reduce costs. If I remember correctly Ben Coman did a PR that changes the way the delays are scheduled in order to select the most appropriate time for sleeping, but since the PR was to close to a Pharo release, it was decided to not be included for safeness reasons. We should resurrect that change soon because the default latency is really bad.

Best regards,
Ronie


El dom., 17 may. 2020 a las 7:03, Robert (<[hidden email]>) escribió:
 

Hi Shaping, I can't comment on parallelizing the VM. I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model.

On 5/16/20 11:29 PM, Shaping wrote:

Hi Shaping,

Hi Robert.  (We’ll get back to the parallelizing any day now…)

On 5/16/20 8:47 AM, Shaping wrote:

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.

 

Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed.

 

Who oversees stuff like this?

Specifically, why don’t we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimately—a nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time.

Why wasn’t this done when Tonel was first created?  The Pharo dev probably didn’t see it as good use of  dev time.  I kindly suggest that this attitude change for all contributors to both Smalltalks.

How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things?

 I couldn't get distracted from my core work.

Sure, I feel the same.  I imaging that most of us do.  

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format,

In my Pharo 9 I have a bit these bits:

 

Gofer new

    squeaksource: 'MetacelloRepository';

    package: 'ConfigurationOfAida';

    load.

  (Smalltalk at: #ConfigurationOfAida) load.

 

Metacello new

baseline:'Seaside3';

repository: 'github://SeasideSt/Seaside:master/repository';

load

In Squeak I can now ensureRecentMetacello, which I was not able to before.

Installer ensureRecentMetacello.

Metacello new
  baseline: 'MagicMouse';
  repository: 'filetree:///home/quotar/tribe/MagicMouse/packages';
  load

However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript

gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring
...FAILED->BaselineOfMagicMouse

I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer

The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus:

spec
    name: 'BaselineOfMagicMouse';
    repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'.

At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak.

Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo.

Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'CapabilitiesLocal';
    project: 'Oceanside'; install: 'ston-config-map';
    project: 'Cryptography'; install: 'SSLLoader;
    project: 'Cryptography'; install: 'Raven'.

Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo...


If there is genuine respect for the value of Squeak and Pharo on both sides

Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that..

K, r

--
Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Shaping1
In reply to this post by Robert Withers-2
 

Hi Shaping, I can't comment on parallelizing the VM.

That’s mostly what the thread is for, ultimately.  The refcaps are needed by the concurrent collector.  Some interesting memory-management options are surfacing soon with Verona.   That scheme is supposed to eliminate the cost of tracing refs to mutable objects in many small heaps.  This is the main cost of having all the small heaps with Orca protocol.  Verona should fix this.  I need to look into it further before discussing the details.

I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model.

Sorry for the delay.  I’ve not read the e-mail yet.  I’ll be a bit longer.  Thanks for the patience.

 

Shaping

 

On 5/16/20 11:29 PM, Shaping wrote:

Hi Shaping,

Hi Robert.  (We’ll get back to the parallelizing any day now…)

On 5/16/20 8:47 AM, Shaping wrote:

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.

 

Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed.

 

Who oversees stuff like this?

Specifically, why don’t we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimately—a nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time.

Why wasn’t this done when Tonel was first created?  The Pharo dev probably didn’t see it as good use of  dev time.  I kindly suggest that this attitude change for all contributors to both Smalltalks.

How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things?

 I couldn't get distracted from my core work.

Sure, I feel the same.  I imaging that most of us do.  

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format,

In my Pharo 9 I have a bit these bits:

 

Gofer new

    squeaksource: 'MetacelloRepository';

    package: 'ConfigurationOfAida';

    load.

  (Smalltalk at: #ConfigurationOfAida) load.

 

Metacello new

baseline:'Seaside3';

repository: 'github://SeasideSt/Seaside:master/repository';

load

In Squeak I can now ensureRecentMetacello, which I was not able to before.

Installer ensureRecentMetacello.

Metacello new
  baseline: 'MagicMouse';
  repository: 'filetree:///home/quotar/tribe/MagicMouse/packages';
  load

However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript

gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring
...FAILED->BaselineOfMagicMouse

I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer

The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus:

spec
    name: 'BaselineOfMagicMouse';
    repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'.

At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak.

Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo.

Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'CapabilitiesLocal';
    project: 'Oceanside'; install: 'ston-config-map';
    project: 'Cryptography'; install: 'SSLLoader;
    project: 'Cryptography'; install: 'Raven'.

Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo...

 

If there is genuine respect for the value of Squeak and Pharo on both sides

Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that..

K, r

--

Kindly,
Robert
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] Squeak and Pharo speed differences

Shaping1
In reply to this post by Ronie Salgado
 

Hi Shaping,

 

Hey Ronie.

 

About the latency, it may be because of the default idle time. Try running the following:

 

ProcessorScheduler idleTime: 1000

 

I did the eval in Pharo 9, and the selection is still sluggish.  I added some zeros and also tried 1.  The different values don’t seem to make any difference.

 

By the release of Pharo 7 the idle time was increased to 50 ms in order to reduce the CPU usage on the cloud and reduce costs.

 

Ok.

 

If I remember correctly Ben Coman did a PR that changes the way the delays are scheduled in order to select the most appropriate time for sleeping, but since the PR was to close to a Pharo release, it was decided to not be included for safeness reasons. We should resurrect that change soon because the default latency is really bad.

 

If the sleeping is happening and the associated delay above is also happening when sleeping/idle-time happens, then shouldn’t we see variations in latency with changes in the number above?  I must not be understanding something.

 

When you click or double-click on a spot in a text editor on a word, these basic things happen:

 

1. A mouse event containing the pixel location clicked is emitted.

 

2. The event handler looks up which bounding rectangle or which line and character range for an given font contains the word to be highlighted.  Ultimately you get a bounding rectangle.

 

3. The event handler renders the new colored background and then renders the text again on top of the new background, probably on a bitmap/DIB section (flicker-free double buffering).  Then the finished bitmap is blitted to the device context, and we see the result.

 

Where do you think the slowness is?  My bet is (2); then maybe (1).  Are you saying (1) is the problem? I’m thinking (3) is always fast.  But I could wrong about that.  I’ve not looked at any code.  Someone must know.

 

 

Shaping

 

 

El dom., 17 may. 2020 a las 7:03, Robert (<[hidden email]>) escribió:

 

Hi Shaping, I can't comment on parallelizing the VM. I was waiting to hear from you regarding 'CapabilitiesLocal' and its ref-cap state transition model.

On 5/16/20 11:29 PM, Shaping wrote:

Hi Shaping,

Hi Robert.  (We’ll get back to the parallelizing any day now…)

On 5/16/20 8:47 AM, Shaping wrote:

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.

 

Andso, here we have the biggest challenge to doing such sharing. You say all features should be loadable into either image. The issue is that Pharo has driven forwards in creating new load formats, such as Tonel. I tried to load up the Tonel format, but failed.

 

Who oversees stuff like this?

Specifically, why don’t we now make Tonel avaibable on Squeak, with the objective of equalizing access to source code, so that we can use one image ultimately—a nice steady gradual drift toward one image, so that no one is in too much pain at any one point in time.

Why wasn’t this done when Tonel was first created?  The Pharo dev probably didn’t see it as good use of  dev time.  I kindly suggest that this attitude change for all contributors to both Smalltalks.

How long is the list of format-related code/frameworks that need to be equalized, so that Squeak and Pharo can always load the same things?

 I couldn't get distracted from my core work.

Sure, I feel the same.  I imaging that most of us do.  

NO EFFORTS have been made to have Squeak able to load such formats, and the Pharo folks have deprecated the existing Montecello load format,

In my Pharo 9 I have a bit these bits:

 

Gofer new

    squeaksource: 'MetacelloRepository';

    package: 'ConfigurationOfAida';

    load.

  (Smalltalk at: #ConfigurationOfAida) load.

 

Metacello new

baseline:'Seaside3';

repository: 'github://SeasideSt/Seaside:master/repository';

load

In Squeak I can now ensureRecentMetacello, which I was not able to before.

Installer ensureRecentMetacello.

Metacello new
  baseline: 'MagicMouse';
  repository: 'filetree:///home/quotar/tribe/MagicMouse/packages';
  load

However, I still choke on the Metacello #baseline:; #repository:. #load. It prints to the Transcript

gofer repository error: 'GoferRepositoryError: UndefinedObject>>isAlphaNumeric'...ignoring
...FAILED->BaselineOfMagicMouse

I get a debugger on MetacelloFetchingMCSpecLoader>>#retryingResolvePackageSpecReferences: packageSpec gofer: gofer

The Gofer is pointing to a MCFileTreeRepository(filetree:///home/quotar/tribe/MagicMouse/packages) as its only repo. The packageSpec is thus:

spec
    name: 'BaselineOfMagicMouse';
    repository: 'filetree:///home/quotar/tribe/MagicMouse/packages'.

At one time I had found what caused the #isAlphaNumeric error (I think an empty stream). The point is that I cannot load with Metacello in Squeak.

Here is code I use in Squeak to load Cryptography and ParrotTalk and SSL and Raven. This works in Squeak but not in Pharo.

Installer ss
    project: 'Cryptography'; install: 'ProCrypto-1-1-1';
    project: 'Cryptography'; install: 'ProCryptoTests-1-1-1';
    project: 'Cryptography'; install: 'CapabilitiesLocal';
    project: 'Oceanside'; install: 'ston-config-map';
    project: 'Cryptography'; install: 'SSLLoader;
    project: 'Cryptography'; install: 'Raven'.

Packages #1, #2, #4, and #5 are all Monticello configuration maps (.mcm), thus unloadable in Pharo...

 

If there is genuine respect for the value of Squeak and Pharo on both sides

Good question! We shall see. The feeling to me is a couple of stiff french fingers being sent Squeak's way. There is probably a french word for that..

K, r

--

Kindly,
Robert
12