Smalltalk › Cuis Smalltalk

differences between Cuis and Squeak and Pharo

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

5 messages Options

Davide Della Casa

differences between Cuis and Squeak and Pharo

Hi,

I’m working my way through Cuis code…

I start to see some patterns emerging, and it’s clear that design philosophy is minimal and "clean".

I’ve read the discussions around the class count being kept to a minimum compared to Squeak and Pharo, and the Morphic 3.0 approach being about "multi-scale" and best-of-class anti-aliasing solutions, and the philosophy of keeping the core to a minimum.

I’m wondering whether there is a more detailed summary of what has been taken out and refactored and re-architected in respect to Squeak and Pharo?

And I mention this because it’s the kind of thing that is difficult to do for a newbie like me, cause one would need to have some in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be really cool to have this map and go “ah I see, this is available just like in the Squeak examples I’ve seen but I need to plug it from a package in because the core can do without it…, and look this part is so much cleaner with two classes I can do what I needed to do with five”. Also this could be a really useful map for people who would like to know how to migrate code/packages from one system to Cuis, so it would be useful well beyond newbies actually…

This is what I know so far in terms of comparisons by reading online:

- core class count (much lower than other two systems, core kept to a minimum)

- morphic 3.0 is scale-agnostic

- rotation of morphs in Cuis is not part of core (is it part of another package?)

- line morphs in Cuis are plug-in

- layouts in Cuis are minimal (can’t make comparison here, don’t know enough about the other systems but I know that Squeak needs a number of other classes)

- list of main Cuis packages and repos

I wonder whether there are more deltas that can be highlighted… some come to mind but ideally one would want to have a larger list… for example I’d love to know:

- approach to naming, are there major classes/methods that are the same but follow a different naming convention?

- are all the main morphs still there in the same hierarchy structure? What are the differences?

- is the event system and the re-paint code similar?

- traits being used or encouraged?

- text/fonts, are those the same approach?

- main tools in the vanilla environment: different/same?

- menus structuring: different/how?

- other parts that have been taken out completely or put in a package?

Cheers,

Davide

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Casey Ransberger-2

Re: differences between Cuis and Squeak and Pharo

Hi David. I'll try to answer as many of your questions to the best of my ability; I will appreciate corrections from others on the list if I get anything wrong.

Inline.

On Aug 20, 2014, at 7:15 AM, Davide Della Casa <[hidden email]> wrote:

Hi,

I’m working my way through Cuis code…

I start to see some patterns emerging, and it’s clear that design philosophy is minimal and "clean".

That's the idea, yes:) and to the end that an elegant system lends itself to personal mastery better than a large system with decorations all over it.

I’ve read the discussions around the class count being kept to a minimum compared to Squeak and Pharo, and the Morphic 3.0 approach being about "multi-scale" and best-of-class anti-aliasing solutions, and the philosophy of keeping the core to a minimum.

That's all consistent with my experience here yes.

I’m wondering whether there is a more detailed summary of what has been taken out and refactored and re-architected in respect to Squeak and Pharo?

First off, don't assume it was all "taken out" by us: in fact many things (e.g. Traits and EToys) were never loaded into Cuis in the first place, as Cuised diverged some time back during Squeak 3.x IIRC. OTOH, Juan has also incorporated a lot of great stuff from Squeak trunk as well. So it's not so straight forward.

And I mention this because it’s the kind of thing that is difficult to do for a newbie like me, cause one would need to have some in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be really cool to have this map and go “ah I see, this is available just like in the Squeak examples I’ve seen but I need to plug it from a package in because the core can do without it…, and look this part is so much cleaner with two classes I can do what I needed to do with five”. Also this could be a really useful map for people who would like to know how to migrate code/packages from one system to Cuis, so it would be useful well beyond newbies actually…

There isn't a map. Even if such a thing were desirable, I think it would be premature to write that book. Cuis is a planet that hasn't quite cooled yet. It's evolving a lot.

One general rule of thumb might be, you'll have to rewrite most Morphic code from other systems to make it work here. With the rest of the code it depends. "Vanilla" Smalltalk code often cares less which fork it runs on, but stuff with heavy dependencies on parts of Squeak/Pharo which are not absolutely essential to the operation of the system may need heavy porting.

This is what I know so far in terms of comparisons by reading online:
- core class count (much lower than other two systems, core kept to a minimum)

Yep.

- morphic 3.0 is scale-agnostic

And is vector-based. That's why it's scale agnostic. And it's coming soon, I think.

- rotation of morphs in Cuis is not part of core (is it part of another package?)

Wrong. It was removed because Squeak's rotation is raster-based, and we're going to do it with vector graphics. See also, Morphic 3.

- line morphs in Cuis are plug-in

Not sure about this one off-hand. Juan?

- layouts in Cuis are minimal (can’t make comparison here, don’t know enough about the other systems but I know that Squeak needs a number of other classes)

Yes. One thing I'd like to see us do later is WYSIWYG layout controls from e.g. the halo. But yes, layouts in Cuis have been simplified.

Another thing to note is that coordinates in Cuis are relative to the parent morph, not the world. This is also to support a scalable UI.

- list of main Cuis packages and repos

I wonder whether there are more deltas that can be highlighted… some come to mind but ideally one would want to have a larger list… for example I’d love to know:
- approach to naming, are there major classes/methods that are the same but follow a different naming convention?

Not usually. It's common to see classes with far fewer convenience methods in Cuis. Juan prefers to create new selectors rather than reuse the old ones when the behavior has to change a great deal. Don't quite me on my example because it's from memory, but #position in Cuis became #morphPosition for this reason.

We use the left arrow (underscore) consistently in the core system for assignment, whereas authors of external packages are left to make their own decisions about that.

- are all the main morphs still there in the same hierarchy structure? What are the differences?

Only the most essential Morphs generally are a part of the core of Cuis. The hierarchy of the system is likely to be very similar, with some nodes in the hierarchy removed (e.g. we don't have thirty kinds of buttons or anything like that.)

- is the event system and the re-paint code similar?

Not my department. I think Juan wrote a nice summary of of the differences between the various flavors of Morphic some time back.

- traits being used or encouraged?

Nope.

- text/fonts, are those the same approach?

The font system in Squeak trunk, last I checked, was from Cuis.

- main tools in the vanilla environment: different/same?

We have less tools in the core than Squeak does (e.g. no dependency browser, etc) but all of the classic ST-80 tools are included.

- menus structuring: different/how?

Different? Totally different. How? Partly me:) one concern we have in Cuis is small screens (on general DynaBook principle and because the first two contributors are fond of tiny laptops,) and as such the world menu is much less monolithic.

I also added a bunch of icons to everything. They were from the Tango icon set. One place we could really improve things throughout the user experience is by replacing the Tango icons with some new ones designed to better fit the Smalltalk experience (e.g. currently we have a terminal icon for the workspace, which really isn't appropriate.)

- other parts that have been taken out completely or put in a package?

I think everything that has been made into a package by Juan is in the Git repository. So you can see that stuff. There isn't a catalogue.

One fun experiment might be to write a workspace expression that makes a dictionary out of the structure of all of the classes in the system, their class and instance methods, their implementations (I'd go with byte code to rule out stuff like assignment, white space) and then compare the resulting dictionaries from the different forks. Because you can do stuff like that !

Cheers,
Davide

Hope I helped a little,

--Casey

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Juan Vuletich-4

Re: differences between Cuis and Squeak and Pharo

Hi Folks,

Casey comments are right spot on, so I'll add little to them (inline).

On 8/21/2014 6:03 AM, Casey Ransberger wrote:

Hi David. I'll try to answer as many of your questions to the best of my ability; I will appreciate corrections from others on the list if I get anything wrong.

Inline.

On Aug 20, 2014, at 7:15 AM, Davide Della Casa <[hidden email]> wrote:

Hi,

I’m working my way through Cuis code…

I start to see some patterns emerging, and it’s clear that design philosophy is minimal and "clean".

That's the idea, yes:) and to the end that an elegant system lends itself to personal mastery better than a large system with decorations all over it.

I’ve read the discussions around the class count being kept to a minimum compared to Squeak and Pharo, and the Morphic 3.0 approach being about "multi-scale" and best-of-class anti-aliasing solutions, and the philosophy of keeping the core to a minimum.

That's all consistent with my experience here yes.

I’m wondering whether there is a more detailed summary of what has been taken out and refactored and re-architected in respect to Squeak and Pharo?

First off, don't assume it was all "taken out" by us: in fact many things (e.g. Traits and EToys) were never loaded into Cuis in the first place, as Cuised diverged some time back during Squeak 3.x IIRC. OTOH, Juan has also incorporated a lot of great stuff from Squeak trunk as well. So it's not so straight forward.

The common ancestor of Squeak, Pharo and Cuis is Squeak 3.7. From there, each system evolved. I can recall from memory many of the main changes done in Cuis since it forked from Squeak 3.7. But to compare with current Squeak, I'd need to know in detail how Squeak evolved. I don't think doing that is worth it. What I think that makes sense is, when studying / working on some specific part of the system, check the others, to write cross-fork code, or to import good stuff from them.

In any case, the bigger differences were already told by both of you (Davide & Casey).

And I mention this because it’s the kind of thing that is difficult to do for a newbie like me, cause one would need to have some in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be really cool to have this map and go “ah I see, this is available just like in the Squeak examples I’ve seen but I need to plug it from a package in because the core can do without it…, and look this part is so much cleaner with two classes I can do what I needed to do with five”. Also this could be a really useful map for people who would like to know how to migrate code/packages from one system to Cuis, so it would be useful well beyond newbies actually…

There isn't a map. Even if such a thing were desirable, I think it would be premature to write that book. Cuis is a planet that hasn't quite cooled yet. It's evolving a lot.

One general rule of thumb might be, you'll have to rewrite most Morphic code from other systems to make it work here. With the rest of the code it depends. "Vanilla" Smalltalk code often cares less which fork it runs on, but stuff with heavy dependencies on parts of Squeak/Pharo which are not absolutely essential to the operation of the system may need heavy porting.

In any case, if you Davide start documenting your experience (relevance of examples written for Squeak or Pharo, etc) in, for example, some .md documents, we could add them to the GitHub repo, so others could also build on top of that. In other words, like everything else in Open Source, if it is not there, and it is needed, then just do it.

This is what I know so far in terms of comparisons by reading online:

- core class count (much lower than other two systems, core kept to a minimum)

Yep.

- morphic 3.0 is scale-agnostic

And is vector-based. That's why it's scale agnostic. And it's coming soon, I think.

- rotation of morphs in Cuis is not part of core (is it part of another package?)

Wrong. It was removed because Squeak's rotation is raster-based, and we're going to do it with vector graphics. See also, Morphic 3.

- line morphs in Cuis are plug-in

Not sure about this one off-hand. Juan?

Well, I removed all non-essential morphs, just to make migration to Morphic 3 as simple as possible. Ken saw value on some morphs I'd removed, so he added them to an optional package. In any case, for Morphic 3 we'd build new morphs, closer to SVG concepts.

- layouts in Cuis are minimal (can’t make comparison here, don’t know enough about the other systems but I know that Squeak needs a number of other classes)

Yes. One thing I'd like to see us do later is WYSIWYG layout controls from e.g. the halo. But yes, layouts in Cuis have been simplified.

That would be cool to have! In the future, I'd like to make visual construction of morphs have the same power as code. That, and some code generation would mean having a powerful "visual builder". This is not a new idea, Dan Ingalls wanted to do this in the good old Squeak Central days.

Another thing to note is that coordinates in Cuis are relative to the parent morph, not the world. This is also to support a scalable UI.

- list of main Cuis packages and repos

I wonder whether there are more deltas that can be highlighted… some come to mind but ideally one would want to have a larger list… for example I’d love to know:

- approach to naming, are there major classes/methods that are the same but follow a different naming convention?

Not usually. It's common to see classes with far fewer convenience methods in Cuis. Juan prefers to create new selectors rather than reuse the old ones when the behavior has to change a great deal. Don't quite me on my example because it's from memory, but #position in Cuis became #morphPosition for this reason.

We use the left arrow (underscore) consistently in the core system for assignment, whereas authors of external packages are left to make their own decisions about that.

- are all the main morphs still there in the same hierarchy structure? What are the differences?

Only the most essential Morphs generally are a part of the core of Cuis. The hierarchy of the system is likely to be very similar, with some nodes in the hierarchy removed (e.g. we don't have thirty kinds of buttons or anything like that.)

Yes to all Casey's comments. In addition, I did quite some refactoring to honor View / Model separation: Models should not know about Views. For instance, class Browser deals with all stuff related with Smalltalk code, but it is UI agnostic. It is unaware of the existance of GUIs on it. BrowserWindow is the GUI. By contrast, see in Squeak the 'toolbuilder' category in class Browser.

- is the event system and the re-paint code similar?

Not my department. I think Juan wrote a nice summary of of the differences between the various flavors of Morphic some time back.

Similar but not identical. I did several optimizations. And I haven't checked the evolution of that code in Squeak or Pharo since 3.7.

- traits being used or encouraged?

Nope.

(although we won't complain if someone implements them and uses them for external packages)

- text/fonts, are those the same approach?

The font system in Squeak trunk, last I checked, was from Cuis.

Yes. I did the anti aliased engine and font set used by Cuis and later adopted by Squeak and Pharo.

- main tools in the vanilla environment: different/same?

We have less tools in the core than Squeak does (e.g. no dependency browser, etc) but all of the classic ST-80 tools are included.

- menus structuring: different/how?

Different? Totally different. How? Partly me:) one concern we have in Cuis is small screens (on general DynaBook principle and because the first two contributors are fond of tiny laptops,) and as such the world menu is much less monolithic.

I also added a bunch of icons to everything. They were from the Tango icon set. One place we could really improve things throughout the user experience is by replacing the Tango icons with some new ones designed to better fit the Smalltalk experience (e.g. currently we have a terminal icon for the workspace, which really isn't appropriate.)

And some day, those icons will look better if SVG.

- other parts that have been taken out completely or put in a package?

I think everything that has been made into a package by Juan is in the Git repository. So you can see that stuff. There isn't a catalogue.

One fun experiment might be to write a workspace expression that makes a dictionary out of the structure of all of the classes in the system, their class and instance methods, their implementations (I'd go with byte code to rule out stuff like assignment, white space) and then compare the resulting dictionaries from the different forks. Because you can do stuff like that !

Cheers,

Davide

Hope I helped a little,

--Casey

Please don't hesitate to ask any questions that arise. Or criticize and tell about any problems or defects you see. We are open to discussion!

Cheers,
Juan Vuletich

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

hbalaraman

Re: differences between Cuis and Squeak and Pharo

In reply to this post by Davide Della Casa

Hi Davide,

Are you the author of zombie kernel? If so, kudos.

It looks super fantabulous. And I see Monsieur Vuletich’s efforts have been an inspiration (if you aren’t … whatever …. take a bow anyway on behalf of the author.)

(I am exploring ways to take my crappy little app in morphic to the web and am looking at amber and app servers and the rest of the worldwide interweb to find a way to stay in smalltalk and morphic.)

How different is your approach from Amber? Will you be going down that road?

Regards,

Hari

twitter: @balarapolis

e-mail: [hidden email]

phone: +1 647 719 5350

On Aug 20, 2014, at 10:15 AM, Davide Della Casa <[hidden email]> wrote:

Hi,

I’m working my way through Cuis code…

I start to see some patterns emerging, and it’s clear that design philosophy is minimal and "clean".

I’ve read the discussions around the class count being kept to a minimum compared to Squeak and Pharo, and the Morphic 3.0 approach being about "multi-scale" and best-of-class anti-aliasing solutions, and the philosophy of keeping the core to a minimum.

I’m wondering whether there is a more detailed summary of what has been taken out and refactored and re-architected in respect to Squeak and Pharo?

And I mention this because it’s the kind of thing that is difficult to do for a newbie like me, cause one would need to have some in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be really cool to have this map and go “ah I see, this is available just like in the Squeak examples I’ve seen but I need to plug it from a package in because the core can do without it…, and look this part is so much cleaner with two classes I can do what I needed to do with five”. Also this could be a really useful map for people who would like to know how to migrate code/packages from one system to Cuis, so it would be useful well beyond newbies actually…

This is what I know so far in terms of comparisons by reading online:
- core class count (much lower than other two systems, core kept to a minimum)
- morphic 3.0 is scale-agnostic
- rotation of morphs in Cuis is not part of core (is it part of another package?)
- line morphs in Cuis are plug-in
- layouts in Cuis are minimal (can’t make comparison here, don’t know enough about the other systems but I know that Squeak needs a number of other classes)
- list of main Cuis packages and repos

I wonder whether there are more deltas that can be highlighted… some come to mind but ideally one would want to have a larger list… for example I’d love to know:
- approach to naming, are there major classes/methods that are the same but follow a different naming convention?
- are all the main morphs still there in the same hierarchy structure? What are the differences?
- is the event system and the re-paint code similar?
- traits being used or encouraged?
- text/fonts, are those the same approach?
- main tools in the vanilla environment: different/same?
- menus structuring: different/how?
- other parts that have been taken out completely or put in a package?

Cheers,
Davide
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

Davide Della Casa

Re: differences between Cuis and Squeak and Pharo

Hi Hari,

Thanks for the praise yes I'm working on Zombie Kernel. Cuis is most definitely a guideline for when I have questions about how the "proper" mechanism for things should be - the code is more compact so it's easier to inspect. I've done so for general architecture and for layouts so far. Will take a closer look into the new Morphic 3 soon and see what are the implications for a port to a browser environment (performance model etc).

Also Zombie Kernel used "Morphic.js" by Jens Moenig as trampoline, important credit to give there.

You are the second person to suggest a mix of Morphic and Amber on the web and yes it could be done, I don't see why not.

Zombie Kernel will definitely support "bi-language" because it's coded in coffeescript, so the "pairing" of sources to javascript is definitely in roadmap. So Amber smalltalk could fit into that, once pairing of languages is supported I think that more languages could come into the picture. I appreciate smalltalk but coffeescript suits my needs just fine, and I commit to a good implementation of Morphic on the web (e.g. with automated end-to-end tests with perceptual diffing I just finished making), that's a lot of work on its own, so I have no plans for Amber myself, but it could be a very fun path to pursue.

Davide

Pardon any typos, sent from my mobile.

On Oct 3, 2014, at 4:58 AM, Hari Balaraman <[hidden email]> wrote:

Hi Davide,

Are you the author of zombie kernel? If so, kudos.

It looks super fantabulous. And I see Monsieur Vuletich’s efforts have been an inspiration (if you aren’t … whatever …. take a bow anyway on behalf of the author.)

(I am exploring ways to take my crappy little app in morphic to the web and am looking at amber and app servers and the rest of the worldwide interweb to find a way to stay in smalltalk and morphic.)

How different is your approach from Amber? Will you be going down that road?

Regards,

Hari

twitter: @balarapolis
e-mail: [hidden email]
phone: +1 647 719 5350

On Aug 20, 2014, at 10:15 AM, Davide Della Casa <[hidden email]> wrote:

Hi,

I’m working my way through Cuis code…

I start to see some patterns emerging, and it’s clear that design philosophy is minimal and "clean".

I’ve read the discussions around the class count being kept to a minimum compared to Squeak and Pharo, and the Morphic 3.0 approach being about "multi-scale" and best-of-class anti-aliasing solutions, and the philosophy of keeping the core to a minimum.

I’m wondering whether there is a more detailed summary of what has been taken out and refactored and re-architected in respect to Squeak and Pharo?

And I mention this because it’s the kind of thing that is difficult to do for a newbie like me, cause one would need to have some in-depth knowledge of Squeak and Pharo and Cuis, and yet it would be really cool to have this map and go “ah I see, this is available just like in the Squeak examples I’ve seen but I need to plug it from a package in because the core can do without it…, and look this part is so much cleaner with two classes I can do what I needed to do with five”. Also this could be a really useful map for people who would like to know how to migrate code/packages from one system to Cuis, so it would be useful well beyond newbies actually…

This is what I know so far in terms of comparisons by reading online:
- core class count (much lower than other two systems, core kept to a minimum)
- morphic 3.0 is scale-agnostic
- rotation of morphs in Cuis is not part of core (is it part of another package?)
- line morphs in Cuis are plug-in
- layouts in Cuis are minimal (can’t make comparison here, don’t know enough about the other systems but I know that Squeak needs a number of other classes)
- list of main Cuis packages and repos

I wonder whether there are more deltas that can be highlighted… some come to mind but ideally one would want to have a larger list… for example I’d love to know:
- approach to naming, are there major classes/methods that are the same but follow a different naming convention?
- are all the main morphs still there in the same hierarchy structure? What are the differences?
- is the event system and the re-paint code similar?
- traits being used or encouraged?
- text/fonts, are those the same approach?
- main tools in the vanilla environment: different/same?
- menus structuring: different/how?
- other parts that have been taken out completely or put in a package?

Cheers,
Davide
_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org