Smalltalk › Squeak › Squeak VM

Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

27 messages Options

Shaping1

Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

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.

Why was this done? Are there details I can read about the technical decision process. Eliot’s comment about the forked seemed negative—that it should not have happened. I agree. I don’t have any more details.

Since the only shared mailing list at the moment is vm-dev

Thanks for saying so. I was wondering.

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

Right. Why is there no common list that we all want to watch? That doesn’t seem health, either.

so there is not really a nice way to address both communities widely and reliably at the same time and have a connected discussion.

That’s what I want. I also want to involve the Verona group in the context of parallelizing the VM Pony-Orca-style or eventually Pony-Verona-style if that happens (which apparently seems to be their objective). I need to talk to those guys first, though. When the time comes to share those convos with Robert and other VM folks, clearly I want as many Pharo and Squeak people as possible to see that.

Can we have a common Squeak/Pharo mailing that is not so VM-specific/specialized as to leave some of the Squeak/Pharo contributors/users uninterested in subscribing? “OpenSmalltalk-dev” or “OpenSmalltalk-gen”? Something like that.

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.

Yes, thank you.

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.

Yes, you’re right; the click pattern is as you say in Pharo 9, but it’s still slow. It is however, much faster than Pharo’s text selection, much more tolerable, but still somewhat distracting. VW selection is still much faster than Squeak’s.

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.

It's just barely okay for me.

Does anyone know how the text selection algo works in Squeak and Pharo?

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.

Right. Does each framework have an unofficial caretaker/maintainer? That’s how it seems.

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.

Must maintenance/inclusion of any framework depend on official Pharo leadership? Official pharo leadership == Consortium?

Someone has to coordinate? Arbitrate? I don’t know. Vote based on measurements all participants can verify? That’s sounds better.

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.

Traits are becoming part of the basic machinery, aren’t they? I have something I want to do with them. I’m not convinced yet that they are in final form. Is their presence a big problem for anyone?

For file handling we need agreement on what works best, so that we can include that in the base image if your image needs to handle files. It should still be unloadable if you don’t want file handling.

If Traits are as basic as Class and Behavior, they can’t be unloaded. Do you want Traits to be loadable? If so, we need no-trait and trait-using versions of frameworks, which is probably worse, assuming Traits have general utility, which they do, even if the details need some work. Do you want the file API to be loadable? If so, Traits probably have to stay in the image, because they might be used in the core at some point. If you want Traits to be loadable, a no-traits and trait-using file API may both need to be maintained. The core dependency tree for classes/packages probably isn’t reviewed by every developer before it is fixed in a way that makes change hard. Is that thinking process exposed to the community before a decision is made?

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

Do we agree that Spec2 is a better architecture than the original MVC? It’s similar in the basic ways, but uses a pluggable backend renderer. Does anyone still want to use MVC now? Why can’t we still keep it and load it if needed? Does it break something?

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

Should we test prototypes of each back end, and decide to include one based on performance results?

I’m not sure what “official distribution” means. The distribution would be more fine-grain, a version of a package or a version of a class. I that what it means?

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.

I’m not sure either. GTK is very flexible though.

With just enough effort, you can probably make anything happen... But the resources of the community are severely limited, especially for Squeak.

The aim with a single Smalltalk is to free up resources for future development. There is short-term dev cost to make that happen.

Shaping

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

Bruce O'Neel-2

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

The blog post that talks about the Pharo VM statement is

https://pharoweekly.wordpress.com/2020/04/28/consortium-pharo-vm-statement/

I suspect that someone who attended the 2019 consortium general assembly during PharoDays might be able to speak to the discussion behind this decision.

====

CONSORTIUM PHARO VM STATEMENT

As promised the consortium engineering team composed of G. Polito, P. Tesone, E. Lorenzano, M. Denker, C. Demarey and S. Ducasse produced a statement about the Pharo VM. This statement was reviewed by the Pharo board and follows decisions taken during the 2019 consortium general assembly held during PharoDays.

S. Ducasse on the behalf of the consortium

Statement about the VM-2

17 May 2020 07:23 "Shaping" <[hidden email]> wrote:

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

Why was this done? Are there details I can read about the technical decision process.   Eliot’s comment about the forked seemed negative—that it should not have happened. I agree. I don’t have any more details.

Since the only shared mailing list at the moment is vm-dev

Thanks for saying so. I was wondering.

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

Right. Why is there no common list that we all want to watch? That doesn’t seem health, either.

so there is not really a nice way to address both communities widely and reliably at the same time and have a connected discussion.

That’s what I want. I also want to involve the Verona group in the context of parallelizing the VM Pony-Orca-style or eventually Pony-Verona-style if that happens (which apparently seems to be their objective). I need to talk to those guys first, though. When the time comes to share those convos with Robert and other VM folks, clearly I want as many Pharo and Squeak people as possible to see that.

Can we have a common Squeak/Pharo mailing that is not so VM-specific/specialized as to leave some of the Squeak/Pharo contributors/users uninterested in subscribing?   “OpenSmalltalk-dev” or “OpenSmalltalk-gen”? Something like that.

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.

Yes, thank you.

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.

Yes, you’re right; the click pattern is as you say in Pharo 9, but it’s still slow. It is however, much faster than Pharo’s text selection, much more tolerable, but still somewhat distracting. VW selection is still much faster than Squeak’s.

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.

It's just barely okay for me.

Does anyone know how the text selection algo works in Squeak and Pharo?

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.

Right. Does each framework have an unofficial caretaker/maintainer? That’s how it seems.

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.

Must maintenance/inclusion of any framework depend on official Pharo leadership? Official pharo leadership == Consortium?

Someone has to coordinate? Arbitrate? I don’t know. Vote based on measurements all participants can verify? That’s sounds better.

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.

Traits are becoming part of the basic machinery, aren’t they? I have something I want to do with them. I’m not convinced yet that they are in final form. Is their presence a big problem for anyone?

For file handling we need agreement on what works best, so that we can include that in the base image if your image needs to handle files. It should still be unloadable if you don’t want file handling.

If Traits are as basic as Class and Behavior, they can’t be unloaded. Do you want Traits to be loadable? If so, we need no-trait and trait-using versions of frameworks, which is probably worse, assuming Traits have general utility, which they do, even if the details need some work. Do you want the file API to be loadable? If so, Traits probably have to stay in the image, because they might be used in the core at some point. If you want Traits to be loadable, a no-traits and trait-using file API may both need to be maintained.   The core dependency tree for classes/packages probably isn’t reviewed by every developer before it is fixed in a way that makes change hard. Is that thinking process exposed to the community before a decision is made?

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

Do we agree that Spec2 is a better architecture than the original MVC? It’s similar in the basic ways, but uses a pluggable backend renderer.   Does anyone still want to use MVC now? Why can’t we still keep it and load it if needed? Does it break something?

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

Should we test prototypes of each back end, and decide to include one based on performance results?

I’m not sure what “official distribution” means.   The distribution would be more fine-grain, a version of a package or a version of a class. I that what it means?

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.

I’m not sure either.   GTK is very flexible though.

With just enough effort, you can probably make anything happen... But the resources of the community are severely limited, especially for Squeak.

The aim with a single Smalltalk is to free up resources for future development. There is short-term dev cost to make that happen.

Shaping

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

Jakob Reschke

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

This was an interesting read and the features that were added sound
awesome. None of the improvements would meet obvious objections from
the Squeak side, I suppose.

The main reasons given for the fork is to be in control of the build
infrastructure, especially using CMake, and "As the past has shown it
is likely to have pull requests rejected we refrain on creating them
for now."

I briefly looked at the closed and not merged pull requests on
OpenSmalltalk VM. I did not find a single one that is related to the
topics addressed in the Pharo VM statement and was not closed in
mutual agreement or by the author himself to refactor something
(mainly the request, not the code), or was not just closed because the
pull request was obsoleted by integrating the changes in another way
than a direct merge (e. g. though a rebase). The start of the headless
feature was integrated in OpenSmalltalk VM this way, for example.

Were there "pull requests" for other topics not posted via GitHub?
What was rejected, except for the official adoption of the CMake-based
build system? I'll continue from CMake in another email...

Am So., 17. Mai 2020 um 10:11 Uhr schrieb Bruce O'Neel
<[hidden email]>:

>
>
> The blog post that talks about the Pharo VM statement is
>
> https://pharoweekly.wordpress.com/2020/04/28/consortium-pharo-vm-statement/
>
> I suspect that someone who attended the 2019 consortium general assembly during PharoDays might be able to speak to the discussion behind this decision.
>
> ====
>
> CONSORTIUM PHARO VM STATEMENT
>
> As promised the consortium engineering team composed of G. Polito, P. Tesone, E. Lorenzano, M. Denker, C. Demarey and S. Ducasse produced a statement about the Pharo VM. This statement was reviewed by the Pharo board and follows decisions taken during the 2019 consortium general assembly held during PharoDays.
>
> S. Ducasse on the behalf of the consortium
>
>
> Statement about the VM-2
>
>
>
>
> 17 May 2020 07:23 "Shaping" <[hidden email]> wrote:
>
> <>
>
> 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.
>
>
>
> Why was this done? Are there details I can read about the technical decision process. Eliot’s comment about the forked seemed negative—that it should not have happened. I agree. I don’t have any more details.
>
>
>
>
>
>
>
> Since the only shared mailing list at the moment is vm-dev
>
>
>
> Thanks for saying so. I was wondering.
>
>
>
> (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,
>
>
>
> Right. Why is there no common list that we all want to watch? That doesn’t seem health, either.
>
>
>
> so there is not really a nice way to address both communities widely and reliably at the same time and have a connected discussion.
>
>
>
> That’s what I want. I also want to involve the Verona group in the context of parallelizing the VM Pony-Orca-style or eventually Pony-Verona-style if that happens (which apparently seems to be their objective). I need to talk to those guys first, though. When the time comes to share those convos with Robert and other VM folks, clearly I want as many Pharo and Squeak people as possible to see that.
>
>
>
> Can we have a common Squeak/Pharo mailing that is not so VM-specific/specialized as to leave some of the Squeak/Pharo contributors/users uninterested in subscribing? “OpenSmalltalk-dev” or “OpenSmalltalk-gen”? Something like that.
>
>
> 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.
>
>
>
> Yes, thank you.
>
>
>
> 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.
>
>
>
> Yes, you’re right; the click pattern is as you say in Pharo 9, but it’s still slow. It is however, much faster than Pharo’s text selection, much more tolerable, but still somewhat distracting. VW selection is still much faster than Squeak’s.
>
>
>
> 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.
>
>
>
> It's just barely okay for me.
>
>
>
> Does anyone know how the text selection algo works in Squeak and Pharo?
>
>
>
> 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.
>
>
>
> Right. Does each framework have an unofficial caretaker/maintainer? That’s how it seems.
>
>
>
> 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.
>
>
>
> Must maintenance/inclusion of any framework depend on official Pharo leadership? Official pharo leadership == Consortium?
>
>
>
> Someone has to coordinate? Arbitrate? I don’t know. Vote based on measurements all participants can verify? That’s sounds better.
>
>
>
> 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.
>
>
>
> Traits are becoming part of the basic machinery, aren’t they? I have something I want to do with them. I’m not convinced yet that they are in final form. Is their presence a big problem for anyone?
>
>
>
> For file handling we need agreement on what works best, so that we can include that in the base image if your image needs to handle files. It should still be unloadable if you don’t want file handling.
>
>
>
> If Traits are as basic as Class and Behavior, they can’t be unloaded. Do you want Traits to be loadable? If so, we need no-trait and trait-using versions of frameworks, which is probably worse, assuming Traits have general utility, which they do, even if the details need some work. Do you want the file API to be loadable? If so, Traits probably have to stay in the image, because they might be used in the core at some point. If you want Traits to be loadable, a no-traits and trait-using file API may both need to be maintained. The core dependency tree for classes/packages probably isn’t reviewed by every developer before it is fixed in a way that makes change hard. Is that thinking process exposed to the community before a decision is made?
>
>
> 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
>
>
>
> Do we agree that Spec2 is a better architecture than the original MVC? It’s similar in the basic ways, but uses a pluggable backend renderer. Does anyone still want to use MVC now? Why can’t we still keep it and load it if needed? Does it break something?
>
>
>
> 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?),
>
>
>
> Should we test prototypes of each back end, and decide to include one based on performance results?
>
>
>
> I’m not sure what “official distribution” means. The distribution would be more fine-grain, a version of a package or a version of a class. I that what it means?
>
>
>
>
>
> 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.
>
>
>
> I’m not sure either. GTK is very flexible though.
>
>
>
> With just enough effort, you can probably make anything happen... But the resources of the community are severely limited, especially for Squeak.
>
>
>
> The aim with a single Smalltalk is to free up resources for future development. There is short-term dev cost to make that happen.
>
>
>
>
>
> Shaping
>
>
>
>
>
> 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
>
> >
>
> >
>
> >
>
> >
>
>
>
>

K K Subbu

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

In reply to this post by Shaping1

On 17/05/20 10:53 am, Shaping wrote:
> 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.

The src directories in opensmalltalk-vm github are just caches - meant
to avoid transpilation overheads during repeated builds. The original
Smalltalk/Slang source is at http://source.squeak.org/VMMaker.html
repository in two packages:

* VMMaker.oscog package - OpenSmalltalk VM - active development,
platforms+build code is at github.com/OpenSmalltalk/opensmalltalk-vm.
Proposed patches go into VMMakerInbox repo on the same server.

* VMMaker package - Squeak Interpreter VM (compatible with 6502 format
images), maintenance mode. platforms+build code in SVN repo
(squeakvm.org/svn/squeak/trunk/platforms). src cache is also on the same
SVN.

So "forking" github would only fork platforms/ part of VMMaker.oscog and
not to its src/ parts.

HTH .. Subbu

Jakob Reschke

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

In reply to this post by Jakob Reschke

What remains indisputable is that the CMake build system was not
promoted as the official one in the OpenSmalltalk repository. Many of
the Squeak folks would also like to use CMake to build... But Eliot
always objects to it and he is one of the main active contributors
(outside of the topics developed at Inria-RMOD, obviously). Maybe the
Squeak community should have tried harder to convince Eliot. Or
maintain the CMake files for him if necessary. It is also no secret
that the relationship between Eliot and some of the Pharo leaders is a
difficult one, which I assume is also one of the main reasons for the
fork. I suppose this might be encoded in the next to last paragraph in
the Pharo VM statement, the one about freedom.

As Subbu posted in the meantime, the Smalltalk part of the VM sources
are traditionally stored in the VMMaker Monticello repository, and
Pharo wanted to move and has moved that to Git (understandably in my
opinion), which requires to choose a file-out format to render the
source code to files. They chose to use the fresh new Tonel format to
do that, not surprisingly. They can afford that because Pharo has the
tools to work with Git repositories and Tonel, obviously. At the time
there were no such tools in Squeak (although I built some
independently during my master thesis three years ago and these are
now easily installable from a Squeak image, but not widespread in the
overall community I suppose). Pharo's tool set is Iceberg and it is
based on an FFI binding to libgit2, but that binding is implemented in
a form of FFI that is not even available in Squeak, in turn because it
was implemented in a new Smalltalk compiler that is not in Squeak,
etc, etc. Under these circumstances, moving away from Monticello means
to some degree to exclude Squeakers from contributing to the VM from
Squeak, once the transition has been made.

Actually, the pull request to include the Smalltalk sources in Tonel
format in OpenSmalltalk VM is still open.
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/305 Given its
age, you might count that as rejected... According to the discussion,
the reason for that is that an important issue in the history
conversion was not addressed in the Monticello to Git converter being
used. https://github.com/peteruhnak/git-migration/issues/18 But this
does not seem to be a valid argument!?

Supporting something that Pharo invented, to continue being able to
target both Squeak and Pharo or simply work together, is mostly left
as an exercise to the interested or "needy" Squeaker. For example
developing equivalent tools to deal with Git repositories, porting the
new FFI and maybe the new compiler... *Active* sharing between Pharo
and Squeak seems to have been handled inadequately in the past, and it
seems to have ceased in the VM as well. Pharo shapes its future, and
maybe the committee does not like or cannot afford to put much effort
into the relationship with Squeak. Not doing it is also part of
freedom, sure.

If I am being unfair now, or misrepresenting some facts, please
apologize and correct me. Maybe I just missed an important mailing
list thread shared with the Squeak community, or I do not know the
right channels. It is also entirely possible that Squeak would just
need to ask for help in porting some of the features and would get the
help. Though, asking for help requires that you get to know and
realize that you truly need to support a particular feature to stay in
the game (even more so if you would not even want the feature, were it
not for interoperability's sake).

Am So., 17. Mai 2020 um 19:09 Uhr schrieb Jakob Reschke
<[hidden email]>:

>
> This was an interesting read and the features that were added sound
> awesome. None of the improvements would meet obvious objections from
> the Squeak side, I suppose.
>
> The main reasons given for the fork is to be in control of the build
> infrastructure, especially using CMake, and "As the past has shown it
> is likely to have pull requests rejected we refrain on creating them
> for now."
>
> I briefly looked at the closed and not merged pull requests on
> OpenSmalltalk VM. I did not find a single one that is related to the
> topics addressed in the Pharo VM statement and was not closed in
> mutual agreement or by the author himself to refactor something
> (mainly the request, not the code), or was not just closed because the
> pull request was obsoleted by integrating the changes in another way
> than a direct merge (e. g. though a rebase). The start of the headless
> feature was integrated in OpenSmalltalk VM this way, for example.
>
> Were there "pull requests" for other topics not posted via GitHub?
> What was rejected, except for the official adoption of the CMake-based
> build system? I'll continue from CMake in another email...
>
> Am So., 17. Mai 2020 um 10:11 Uhr schrieb Bruce O'Neel
> <[hidden email]>:
> >
> >
> > The blog post that talks about the Pharo VM statement is
> >
> > https://pharoweekly.wordpress.com/2020/04/28/consortium-pharo-vm-statement/
> >
> > I suspect that someone who attended the 2019 consortium general assembly during PharoDays might be able to speak to the discussion behind this decision.
> >
> > ====
> >
> > CONSORTIUM PHARO VM STATEMENT
> >
> > As promised the consortium engineering team composed of G. Polito, P. Tesone, E. Lorenzano, M. Denker, C. Demarey and S. Ducasse produced a statement about the Pharo VM. This statement was reviewed by the Pharo board and follows decisions taken during the 2019 consortium general assembly held during PharoDays.
> >
> > S. Ducasse on the behalf of the consortium
> >
> >
> > Statement about the VM-2
> >
> >
> >
> >
> > 17 May 2020 07:23 "Shaping" <[hidden email]> wrote:
> >
> > <>
> >
> > 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.
> >
> >
> >
> > Why was this done? Are there details I can read about the technical decision process. Eliot’s comment about the forked seemed negative—that it should not have happened. I agree. I don’t have any more details.
> >
> >
> >
> >
> >
> >
> >
> > Since the only shared mailing list at the moment is vm-dev
> >
> >
> >
> > Thanks for saying so. I was wondering.
> >
> >
> >
> > (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,
> >
> >
> >
> > Right. Why is there no common list that we all want to watch? That doesn’t seem health, either.
> >
> >
> >
> > so there is not really a nice way to address both communities widely and reliably at the same time and have a connected discussion.
> >
> >
> >
> > That’s what I want. I also want to involve the Verona group in the context of parallelizing the VM Pony-Orca-style or eventually Pony-Verona-style if that happens (which apparently seems to be their objective). I need to talk to those guys first, though. When the time comes to share those convos with Robert and other VM folks, clearly I want as many Pharo and Squeak people as possible to see that.
> >
> >
> >
> > Can we have a common Squeak/Pharo mailing that is not so VM-specific/specialized as to leave some of the Squeak/Pharo contributors/users uninterested in subscribing? “OpenSmalltalk-dev” or “OpenSmalltalk-gen”? Something like that.
> >
> >
> > 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.
> >
> >
> >
> > Yes, thank you.
> >
> >
> >
> > 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.
> >
> >
> >
> > Yes, you’re right; the click pattern is as you say in Pharo 9, but it’s still slow. It is however, much faster than Pharo’s text selection, much more tolerable, but still somewhat distracting. VW selection is still much faster than Squeak’s.
> >
> >
> >
> > 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.
> >
> >
> >
> > It's just barely okay for me.
> >
> >
> >
> > Does anyone know how the text selection algo works in Squeak and Pharo?
> >
> >
> >
> > 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.
> >
> >
> >
> > Right. Does each framework have an unofficial caretaker/maintainer? That’s how it seems.
> >
> >
> >
> > 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.
> >
> >
> >
> > Must maintenance/inclusion of any framework depend on official Pharo leadership? Official pharo leadership == Consortium?
> >
> >
> >
> > Someone has to coordinate? Arbitrate? I don’t know. Vote based on measurements all participants can verify? That’s sounds better.
> >
> >
> >
> > 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.
> >
> >
> >
> > Traits are becoming part of the basic machinery, aren’t they? I have something I want to do with them. I’m not convinced yet that they are in final form. Is their presence a big problem for anyone?
> >
> >
> >
> > For file handling we need agreement on what works best, so that we can include that in the base image if your image needs to handle files. It should still be unloadable if you don’t want file handling.
> >
> >
> >
> > If Traits are as basic as Class and Behavior, they can’t be unloaded. Do you want Traits to be loadable? If so, we need no-trait and trait-using versions of frameworks, which is probably worse, assuming Traits have general utility, which they do, even if the details need some work. Do you want the file API to be loadable? If so, Traits probably have to stay in the image, because they might be used in the core at some point. If you want Traits to be loadable, a no-traits and trait-using file API may both need to be maintained. The core dependency tree for classes/packages probably isn’t reviewed by every developer before it is fixed in a way that makes change hard. Is that thinking process exposed to the community before a decision is made?
> >
> >
> > 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
> >
> >
> >
> > Do we agree that Spec2 is a better architecture than the original MVC? It’s similar in the basic ways, but uses a pluggable backend renderer. Does anyone still want to use MVC now? Why can’t we still keep it and load it if needed? Does it break something?
> >
> >
> >
> > 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?),
> >
> >
> >
> > Should we test prototypes of each back end, and decide to include one based on performance results?
> >
> >
> >
> > I’m not sure what “official distribution” means. The distribution would be more fine-grain, a version of a package or a version of a class. I that what it means?
> >
> >
> >
> >
> >
> > 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.
> >
> >
> >
> > I’m not sure either. GTK is very flexible though.
> >
> >
> >
> > With just enough effort, you can probably make anything happen... But the resources of the community are severely limited, especially for Squeak.
> >
> >
> >
> > The aim with a single Smalltalk is to free up resources for future development. There is short-term dev cost to make that happen.
> >
> >
> >
> >
> >
> > Shaping
> >
> >
> >
> >
> >
> > 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
> >
> > >
> >
> > >
> >
> > >
> >
> > >
> >
> >
> >
> >

Robert Withers-2

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

On 5/17/20 2:03 PM, Jakob Reschke wrote:


What remains indisputable is that the CMake build system was not
promoted as the official one in the OpenSmalltalk repository. Many of
the Squeak folks would also like to use CMake to build... But Eliot
always objects to it and he is one of the main active contributors
(outside of the topics developed at Inria-RMOD, obviously). Maybe the
Squeak community should have tried harder to convince Eliot. Or
maintain the CMake files for him if necessary. It is also no secret
that the relationship between Eliot and some of the Pharo leaders is a
difficult one, which I assume is also one of the main reasons for the
fork. I suppose this might be encoded in the next to last paragraph in
the Pharo VM statement, the one about freedom.

As Subbu posted in the meantime, the Smalltalk part of the VM sources
are traditionally stored in the VMMaker Monticello repository, and
Pharo wanted to move and has moved that to Git (understandably in my
opinion), which requires to choose a file-out format to render the
source code to files. They chose to use the fresh new Tonel format to
do that, not surprisingly. They can afford that because Pharo has the
tools to work with Git repositories and Tonel, obviously. At the time
there were no such tools in Squeak (although I built some
independently during my master thesis three years ago and these are
now easily installable from a Squeak image, but not widespread in the
overall community I suppose). Pharo's tool set is Iceberg and it is
based on an FFI binding to libgit2, but that binding is implemented in
a form of FFI that is not even available in Squeak, in turn because it
was implemented in a new Smalltalk compiler that is not in Squeak,
etc, etc. Under these circumstances, moving away from Monticello means
to some degree to exclude Squeakers from contributing to the VM from
Squeak, once the transition has been made.

Actually, the pull request to include the Smalltalk sources in Tonel
format in OpenSmalltalk VM is still open.
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/305 Given its
age, you might count that as rejected... According to the discussion,
the reason for that is that an important issue in the history
conversion was not addressed in the Monticello to Git converter being
used. https://github.com/peteruhnak/git-migration/issues/18 But this
does not seem to be a valid argument!?

Supporting something that Pharo invented, to continue being able to
target both Squeak and Pharo or simply work together, is mostly left
as an exercise to the interested or "needy" Squeaker. For example
developing equivalent tools to deal with Git repositories, porting the
new FFI and maybe the new compiler... *Active* sharing between Pharo
and Squeak seems to have been handled inadequately in the past, and it
seems to have ceased in the VM as well. Pharo shapes its future, and
maybe the committee does not like or cannot afford to put much effort
into the relationship with Squeak. Not doing it is also part of
freedom, sure.

It's shortsighted. And it does not honor Pharo's heritage. Squeak needs Tonel & Tool support, to interoperate. Pharo needs Monticello maps. A worthy goal and ought be registered higher on priority.

If the core technical issue is the use of CMake versus autoconf and so on, then why not support both build systems? Well, how can we do that without huge complexity and double the work of config specification, one may ask me? I reply, it requires common code mgmt systems, Tonel and Monticello in both Squeak & Pharo. Otherwise, we got nothing.

The answer is that we construct a Smalltalk-based build system with a swap-able back-end to generate & emit CMake config or autoconf config. Run ./mvm which would call

squeak VMBuildSystem makeVMWithAutoconf
pharo VMBuildSystem makeVMWithCMake

Similar to groovy, allow Smalltalk scripts to define the build.

As far as relations can go, perhaps that is the intent: to break relations. A divorce.

"It is not the honor that you take with you, but the heritage you leave behind." - Branch Rickey

Let us not leave with a bad taste in the mouth, alright?

K, r


If I am being unfair now, or misrepresenting some facts, please
apologize and correct me. Maybe I just missed an important mailing
list thread shared with the Squeak community, or I do not know the
right channels. It is also entirely possible that Squeak would just
need to ask for help in porting some of the features and would get the
help. Though, asking for help requires that you get to know and
realize that you truly need to support a particular feature to stay in
the game (even more so if you would not even want the feature, were it
not for interoperability's sake).


Am So., 17. Mai 2020 um 19:09 Uhr schrieb Jakob Reschke
[hidden email]:

This was an interesting read and the features that were added sound
awesome. None of the improvements would meet obvious objections from
the Squeak side, I suppose.

The main reasons given for the fork is to be in control of the build
infrastructure, especially using CMake, and "As the past has shown it
is likely to have pull requests rejected we refrain on creating them
for now."

I briefly looked at the closed and not merged pull requests on
OpenSmalltalk VM. I did not find a single one that is related to the
topics addressed in the Pharo VM statement and was not closed in
mutual agreement or by the author himself to refactor something
(mainly the request, not the code), or was not just closed because the
pull request was obsoleted by integrating the changes in another way
than a direct merge (e. g. though a rebase). The start of the headless
feature was integrated in OpenSmalltalk VM this way, for example.

Were there "pull requests" for other topics not posted via GitHub?
What was rejected, except for the official adoption of the CMake-based
build system? I'll continue from CMake in another email...

Am So., 17. Mai 2020 um 10:11 Uhr schrieb Bruce O'Neel
[hidden email]:

The blog post that talks about the Pharo VM statement is

https://pharoweekly.wordpress.com/2020/04/28/consortium-pharo-vm-statement/

I suspect that someone who attended the 2019 consortium general assembly during PharoDays might be able to speak to the discussion behind this decision.

====

CONSORTIUM PHARO VM STATEMENT

S. Ducasse on the behalf of the consortium

Statement about the VM-2

17 May 2020 07:23 "Shaping" [hidden email] wrote:

Since the only shared mailing list at the moment is vm-dev

Thanks for saying so. I was wondering.

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

Right. Why is there no common list that we all want to watch? That doesn’t seem health, either.

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.

Yes, thank you.

It's just barely okay for me.

Does anyone know how the text selection algo works in Squeak and Pharo?

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.

Right. Does each framework have an unofficial caretaker/maintainer? That’s how it seems.

Must maintenance/inclusion of any framework depend on official Pharo leadership? Official pharo leadership == Consortium?

Someone has to coordinate? Arbitrate? I don’t know. Vote based on measurements all participants can verify? That’s sounds better.

Should we test prototypes of each back end, and decide to include one based on performance results?

I’m not sure what “official distribution” means. The distribution would be more fine-grain, a version of a package or a version of a class. I that what it means?

I’m not sure either. GTK is very flexible though.

With just enough effort, you can probably make anything happen... But the resources of the community are severely limited, especially for Squeak.

The aim with a single Smalltalk is to free up resources for future development. There is short-term dev cost to make that happen.

Shaping

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

-- 
Kindly,
Robert

Robert Withers-2

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

On 5/17/20 2:30 PM, Robert wrote:

On 5/17/20 2:03 PM, Jakob Reschke wrote:
Supporting something that Pharo invented, to continue being able to
target both Squeak and Pharo or simply work together, is mostly left
as an exercise to the interested or "needy" Squeaker. For example
developing equivalent tools to deal with Git repositories, porting the
new FFI and maybe the new compiler... *Active* sharing between Pharo
and Squeak seems to have been handled inadequately in the past, and it
seems to have ceased in the VM as well. Pharo shapes its future, and
maybe the committee does not like or cannot afford to put much effort
into the relationship with Squeak. Not doing it is also part of
freedom, sure.
It's shortsighted. And it does not honor Pharo's heritage. Squeak needs Tonel & Tool support, to interoperate. Pharo needs Monticello maps. A worthy goal and ought be registered higher on priority.

If the core technical issue is the use of CMake versus autoconf and so on, then why not support both build systems? Well, how can we do that without huge complexity and double the work of config specification, one may ask me? I reply, it requires common code mgmt systems, Tonel and Monticello in both Squeak & Pharo. Otherwise, we got nothing.

The answer is that we construct a Smalltalk-based build system with a swap-able back-end to generate & emit CMake config or autoconf config. Run ./mvm which would call

squeak VMBuildSystem makeVMWithAutoconf
pharo VMBuildSystem makeVMWithCMake

Similar to groovy, allow Smalltalk scripts to define the build.

The reference to groovy was the build system known as gradle. I propose we construct a gradle equivalent in Smalltalk.

---

Kindly,
Robert

Robert Withers-2

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

On 5/17/20 2:50 PM, Robert wrote:

The answer is that we construct a Smalltalk-based build system with a swap-able back-end to generate & emit CMake config or autoconf config. Run ./mvm which would call

squeak VMBuildSystem makeVMWithAutoconf
pharo VMBuildSystem makeVMWithCMake

Similar to groovy, allow Smalltalk scripts to define the build.

The reference to groovy was the build system known as gradle. I propose we construct a gradle equivalent in Smalltalk.

Gradle: https://docs.gradle.org/current/userguide/userguide.html.

---

Kindly,
Robert

-- 
Kindly,
Robert

Eliot Miranda-2

Re: Squeak/Pharo VM fork history (was: RE: [Pharo-dev] Squeak and Pharo speed differences)

In reply to this post by K K Subbu

Hi Subbu,

> On May 17, 2020, at 10:13 AM, K K Subbu <[hidden email]> wrote:
>
> On 17/05/20 10:53 am, Shaping wrote:
>> 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.
>
> The src directories in opensmalltalk-vm github are just caches - meant to avoid transpilation overheads during repeated builds.

No, they are not just caches. They are also versioned artifacts that eliminate the possibility that translation at a later time might produce different results. They have many advantages other than this, such as quicker Bude Yoon tor finding bugs, the ability to build a vm without having a full VMMaker build environment, etc.

> The original Smalltalk/Slang source is at http://source.squeak.org/VMMaker.html repository in two packages:
>
> * VMMaker.oscog package - OpenSmalltalk VM - active development, platforms+build code is at github.com/OpenSmalltalk/opensmalltalk-vm. Proposed patches go into VMMakerInbox repo on the same server.
>
> * VMMaker package - Squeak Interpreter VM (compatible with 6502 format images), maintenance mode. platforms+build code in SVN repo (squeakvm.org/svn/squeak/trunk/platforms). src cache is also on the same SVN.
>
> So "forking" github would only fork platforms/ part of VMMaker.oscog and not to its src/ parts.

And of house one toes not need you fork platforms. minheadless exists alongside platforms. And makefiles based build systems coexist against CMake based abd auto one based ones. With cooperation there is no need to form. We can do evolve together.

>
> HTH .. Subbu

K K Subbu

Re: Squeak/Pharo VM fork history

On 18/05/20 1:25 am, Eliot Miranda wrote:

>>> 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.
>> The src directories in opensmalltalk-vm github are just caches -
>> meant to avoid transpilation overheads during repeated builds.
> No, they are not just caches. They are also versioned artifacts that
> eliminate the possibility that translation at a later time might
> produce different results. They have many advantages other than
> this, such as quicker Bude Yoon tor finding bugs, the ability to
> build a vm without having a full VMMaker build environment, etc.

Eliot,

That's precisely what I meant by "transpilation overheads". I didn't
want to expand on that because I just wanted to point out that VMMaker
is the original source and not the github. So copying git files is not
really a "source fork". It is a build hack. Any updates to this git
outside of transpilation will only be local to a build and will be
overwritten by next transpilation.

Regards .. Subbu

Jakob Reschke

Re: Squeak/Pharo VM fork history

Pharo VM did not only fork the transpiled C code, they also put the
Smalltalk VMMaker code in the repository and maintain it there. They
do not use the VMMaker Monticello repository if I understand
correctly. So in their repository and workflow, it really is a source
fork.

Am Mo., 18. Mai 2020 um 09:54 Uhr schrieb K K Subbu <[hidden email]>:

>
>
> On 18/05/20 1:25 am, Eliot Miranda wrote:
> >>> 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.
> >> The src directories in opensmalltalk-vm github are just caches -
> >> meant to avoid transpilation overheads during repeated builds.
> > No, they are not just caches. They are also versioned artifacts that
> > eliminate the possibility that translation at a later time might
> > produce different results. They have many advantages other than
> > this, such as quicker Bude Yoon tor finding bugs, the ability to
> > build a vm without having a full VMMaker build environment, etc.
>
> Eliot,
>
> That's precisely what I meant by "transpilation overheads". I didn't
> want to expand on that because I just wanted to point out that VMMaker
> is the original source and not the github. So copying git files is not
> really a "source fork". It is a build hack. Any updates to this git
> outside of transpilation will only be local to a build and will be
> overwritten by next transpilation.
>
> Regards .. Subbu

K K Subbu

Re: Squeak/Pharo VM fork history

In reply to this post by Jakob Reschke

On 17/05/20 11:33 pm, Jakob Reschke wrote:
> What remains indisputable is that the CMake build system was not
> promoted as the official one in the OpenSmalltalk repository. Many
> of the Squeak folks would also like to use CMake to build...

CMake and autoconf tools are not exclusive. Both will work in the
typical 'configure && make && make install' sequence.

[I am just jotting down my own recollections below. please correct if I
am wrong]

Squeak was developed on Darwin (Unix flavor) and then quickly ported to
other Unix flavors (Solaris, HPUX) and Wintel because of portability of
both its code and its CMake build scripts. GNU/Linux port appeared only
around 2005 (2.5?) but quickly dominated over other Unix ports,
especially when Etoys shipped in OLPC's XO. Its native toolset -
Autotools - came to be preferred over CMake. Squeak VM continued with
its CMake build tools in SVN while the newer Open Smalltalk VM moved
towards GNU toolchain and github.

The choice of build tools affects only the platforms code maintained in
github and not the VMMaker code. The platform champions get to pick
their build tools. If there are sufficient supporters for a platform
port, then its code is likely to evolve sustainably. When supporters
dwindle, build rot is inevitable. That's life :-(.

So the real question is "Are there enough supporters to make a platform
fork (either in build tools or OS flavors) viable in the long term?" If
not, the fork will gets its seven days of fame and then rot slowly.

GNU/Linux and MacOS have a large supporter base, but ports like Solaris,
FreeBSD may not. So Squeak/Pharo platform fork will affect them much
more deeply than GNU/Linux or MacOS, particularly when it comes to
hardware plugins like graphics or sound.

But a bigger risk is that if GNU/Linux starts dominating the ports, then
Squeak/Pharo will become like other apps in the GNU stack with
increasing dependencies on GNU toolchain and runtime frameworks. There
is nothing wrong in building an app. It is just not a virtual personal
computing system. It is just a balloon descending into its castle ;-).

Regards .. Subbu

Karl Ramberg

Re: Squeak/Pharo VM fork history

Squeak was made on MacOs 7, 8 or 9 before Apple used Unix.

Best,

Karl

On Mon, May 18, 2020 at 11:25 AM K K Subbu <[hidden email]> wrote:

On 17/05/20 11:33 pm, Jakob Reschke wrote:
> What remains indisputable is that the CMake build system was not
> promoted as the official one in the OpenSmalltalk repository. Many
> of the Squeak folks would also like to use CMake to build...

CMake and autoconf tools are not exclusive. Both will work in the
typical 'configure && make && make install' sequence.

[I am just jotting down my own recollections below. please correct if I
am wrong]

Squeak was developed on Darwin (Unix flavor) and then quickly ported to
other Unix flavors (Solaris, HPUX) and Wintel because of portability of
both its code and its CMake build scripts. GNU/Linux port appeared only
around 2005 (2.5?) but quickly dominated over other Unix ports,
especially when Etoys shipped in OLPC's XO. Its native toolset -
Autotools - came to be preferred over CMake. Squeak VM continued with
its CMake build tools in SVN while the newer Open Smalltalk VM moved
towards GNU toolchain and github.

The choice of build tools affects only the platforms code maintained in
github and not the VMMaker code. The platform champions get to pick
their build tools. If there are sufficient supporters for a platform
port, then its code is likely to evolve sustainably. When supporters
dwindle, build rot is inevitable. That's life :-(.

So the real question is "Are there enough supporters to make a platform
fork (either in build tools or OS flavors) viable in the long term?" If
not, the fork will gets its seven days of fame and then rot slowly.

GNU/Linux and MacOS have a large supporter base, but ports like Solaris,
FreeBSD may not. So Squeak/Pharo platform fork will affect them much
more deeply than GNU/Linux or MacOS, particularly when it comes to
hardware plugins like graphics or sound.

But a bigger risk is that if GNU/Linux starts dominating the ports, then
Squeak/Pharo will become like other apps in the GNU stack with
increasing dependencies on GNU toolchain and runtime frameworks. There
is nothing wrong in building an app. It is just not a virtual personal
computing system. It is just a balloon descending into its castle ;-).

Regards .. Subbu

Eliot Miranda-2

Re: Squeak/Pharo VM fork history

In reply to this post by Jakob Reschke

> On May 18, 2020, at 1:08 AM, Jakob Reschke <[hidden email]> wrote:
>
>
> Pharo VM did not only fork the transpiled C code, they also put the
> Smalltalk VMMaker code in the repository and maintain it there. They
> do not use the VMMaker Monticello repository if I understand
> correctly. So in their repository and workflow, it really is a source
> fork.

+1

>> Am Mo., 18. Mai 2020 um 09:54 Uhr schrieb K K Subbu <[hidden email]>:
>>
>>
>> On 18/05/20 1:25 am, Eliot Miranda wrote:
>>>>> 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.
>>>> The src directories in opensmalltalk-vm github are just caches -
>>>> meant to avoid transpilation overheads during repeated builds.
>>> No, they are not just caches. They are also versioned artifacts that
>>> eliminate the possibility that translation at a later time might
>>> produce different results. They have many advantages other than
>>> this, such as quicker Bude Yoon tor finding bugs, the ability to
>>> build a vm without having a full VMMaker build environment, etc.
>>
>> Eliot,
>>
>> That's precisely what I meant by "transpilation overheads". I didn't
>> want to expand on that because I just wanted to point out that VMMaker
>> is the original source and not the github. So copying git files is not
>> really a "source fork". It is a build hack. Any updates to this git
>> outside of transpilation will only be local to a build and will be
>> overwritten by next transpilation.
>>
>> Regards .. Subbu

K K Subbu

Re: Squeak/Pharo VM fork history

In reply to this post by Karl Ramberg

On 18/05/20 5:00 pm, karl ramberg wrote:
> Squeak was made on MacOS 7, 8 or 9 before Apple used Unix.

Thank you for the correction. AFAIK, the first releases were on MacOS
System 7.0 (68020 or PPC). Ian's Unix ports and Andreas Raab's Wintel
port followed pretty quickly - a tribute to Squeak's portability.

Regards .. Subbu

timrowledge

Re: Squeak/Pharo VM fork history

> On 2020-05-18, at 7:37 AM, K K Subbu <[hidden email]> wrote:
>
> On 18/05/20 5:00 pm, karl ramberg wrote:
>> Squeak was made on MacOS 7, 8 or 9 before Apple used Unix.
>
> Thank you for the correction. AFAIK, the first releases were on MacOS System 7.0 (68020 or PPC). Ian's Unix ports and Andreas Raab's Wintel port followed pretty quickly - a tribute to Squeak's portability.

I'm not absolutely certain, but I think Andreas' Windows port was the first to appear. Ian wasn't far behind with the basic unix stuff and then I was allowed to release my RISC OS port (done on Interval Research time) shortly after; I also had to do a little-endian BitBlt and some rather complicated filing system trickery. We also (Interval) had a proprietary bit of hardware based on the same StrongARM cpu as my RISC OS machine, another in the long list of ARM powered Smalltalk based tablet machines I've worked on over the decades.

Remember - this was 1996, well before Apple released OS X to general use. Mac OS, Windows and RISC OS were co-operative multi-tasking GUIs. Ethernet cards were expensive options for most machines. WiFi was a several hundred dollar add-on and I don't think anyone anticipated it ever being practical in anything like a $2 ESP8266 board. I don't think we got any socket support into the system until around v1.20

The original build 'system' involved much of the source code being in the very early and very primitive slang-C held in the main image along with the plain C code for the Mac version kept as huge literal strings. We ran the code generator methods to produce the transliterated text and dump those literal strings into files. Then very platform specific hacks were performed to actually compile the C code. Gradually we tidied that up a bit but it wasn't until I made the first VMMaker package in '01 that things started to get more organised for the platform spread. Once Ian, John, Andreas & I were all using it, VMMaker became the standard.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
If you must choose between two evils, pick the one you've never tried before.

David T. Lewis

Re: Squeak/Pharo VM fork history

On Mon, May 18, 2020 at 09:29:06AM -0700, tim Rowledge wrote:

>
>
>
> > On 2020-05-18, at 7:37 AM, K K Subbu <[hidden email]> wrote:
> >
> > On 18/05/20 5:00 pm, karl ramberg wrote:
> >> Squeak was made on MacOS 7, 8 or 9 before Apple used Unix.
> >
> > Thank you for the correction. AFAIK, the first releases were on MacOS System 7.0 (68020 or PPC). Ian's Unix ports and Andreas Raab's Wintel port followed pretty quickly - a tribute to Squeak's portability.
>
> I'm not absolutely certain, but I think Andreas' Windows port was the first to appear. Ian wasn't far behind with the basic unix stuff and then I was allowed to release my RISC OS port (done on Interval Research time) shortly after; I also had to do a little-endian BitBlt and some rather complicated filing system trickery. We also (Interval) had a proprietary bit of hardware based on the same StrongARM cpu as my RISC OS machine, another in the long list of ARM powered Smalltalk based tablet machines I've worked on over the decades.
>
> Remember - this was 1996, well before Apple released OS X to general use. Mac OS, Windows and RISC OS were co-operative multi-tasking GUIs. Ethernet cards were expensive options for most machines. WiFi was a several hundred dollar add-on and I don't think anyone anticipated it ever being practical in anything like a $2 ESP8266 board. I don't think we got any socket support into the system until around v1.20
>
> The original build 'system' involved much of the source code being in the very early and very primitive slang-C held in the main image along with the plain C code for the Mac version kept as huge literal strings. We ran the code generator methods to produce the transliterated text and dump those literal strings into files. Then very platform specific hacks were performed to actually compile the C code. Gradually we tidied that up a bit but it wasn't until I made the first VMMaker package in '01 that things started to get more organised for the platform spread. Once Ian, John, Andreas & I were all using it, VMMaker became the standard.
>

It is worth remembering that Juan Vuletich did an OS/2 port back in
that general time frame.

https://www.jvuletich.org/Squeak/SqueakForOS2/SqueakForOS2Eng.html

I wouldn't be surprised if it still works. But this was never part
of the official releases.

Dave

timrowledge

Re: Squeak/Pharo VM fork history

> On 2020-05-18, at 9:47 AM, David T. Lewis <[hidden email]> wrote:
>
>>
>
> It is worth remembering that Juan Vuletich did an OS/2 port back in
> that general time frame.
>
> https://www.jvuletich.org/Squeak/SqueakForOS2/SqueakForOS2Eng.html
>
> I wouldn't be surprised if it still works. But this was never part
> of the official releases.

Hunh - I didn't remember that at all; I thought Boris Shingarov had been Mr OS/2-Squeak. Ah - http://www.edm2.com/index.php/Squeak

OS/2 was ... interesting. I used it for some time at ParcPlace in order to help test the VW port. Some really neat ideas and some truly awful implementation issues made it not the most pleasant OS to use.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
What passes for common sense is always revisable

codefrau

Re: Squeak/Pharo VM fork history

In reply to this post by timrowledge

On Mon, May 18, 2020 at 9:35 AM tim Rowledge <[hidden email]> wrote:

> On 2020-05-18, at 7:37 AM, K K Subbu <[hidden email]> wrote:
>
AFAIK, the first releases were on MacOS System 7.0 (68020 or PPC). Ian's Unix ports and Andreas Raab's Wintel port followed pretty quickly - a tribute to Squeak's portability.

I'm not absolutely certain, but I think Andreas' Windows port was the first to appear.

Ian was earlier - he made it work on little-endian machines first. Andreas used and extended that in his Windows port.

- Vanessa -

Juan Vuletich-3

Re: Squeak/Pharo VM fork history

In reply to this post by timrowledge

On 5/18/2020 1:55 PM, tim Rowledge wrote:

>
>
>
>> On 2020-05-18, at 9:47 AM, David T. Lewis<[hidden email]> wrote:
>>
>> It is worth remembering that Juan Vuletich did an OS/2 port back in
>> that general time frame.
>>
>> https://www.jvuletich.org/Squeak/SqueakForOS2/SqueakForOS2Eng.html
>>
>> I wouldn't be surprised if it still works. But this was never part
>> of the official releases.
> Hunh - I didn't remember that at all; I thought Boris Shingarov had been Mr OS/2-Squeak. Ah - http://www.edm2.com/index.php/Squeak
>
> OS/2 was ... interesting. I used it for some time at ParcPlace in order to help test the VW port. Some really neat ideas and some truly awful implementation issues made it not the most pleasant OS to use.
>
> tim
> --
> tim Rowledge; [hidden email]; http://www.rowledge.org/tim
> What passes for common sense is always revisable
>
>
>
>

Thanks Dave for remembering!

http://www.edm2.com/index.php/Squeak is correct.

Boris' work was essentially a recompilation of Ian's Unix VM using
XFree86, not really a new port. It required the user to install XFree86
on their OS/2 system in order to use the VM. Later this was the base of
his extremely interesting Cheese project. Boris is still around in the
community, building great stuff. He is also a good friend of mine.

I independently wrote a new port of the VM platform support code,
specifically for OS/2. It didn't require any installation of additional
software, and it was a regular OS/2 program.

When I did it, Andreas' Windows VM still wasn't able to use DirectX or
OpenGL, and display update was rather slow, so a "defer display update"
option was included in the VM. My OS/2 VM used DIVE, a game API, sort of
OS/2 version of DirectX. Display updates were much faster, no need to
defer updates. This was important in 486 class machines. It also used
DART for low latency audio. I was so into this project that spent about
half a month salary on the rather expensive VisualAge C++ C compiler.

This was in the Windows 95 time. Running my VM on OS/2 3.0 or 4.0 was a
much better experience than suffering Windows 95.

Unfortunately OS/2 failed in the market, and later Windows 2000 and
Windows XP were for the first time more reliable than OS/2. People
abandoned OS/2 en masse. Around that time, Andreas wrote support for
OpenGL and DirectX in the Windows VM, making display updates fast too.
At some time, I saw no point in pushing for OS/2, and started using
Windows XP and Andreas' Windows VM too.

It was a lot of fun.

Cheers,

--
Juan Vuletich
www.cuis-smalltalk.org
https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev
https://github.com/jvuletich
https://www.linkedin.com/in/juan-vuletich-75611b3
@JuanVuletich