Definition of Cuis parts

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

Definition of Cuis parts

bpi
Hi Juan,

Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE

If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)

Seriously, I looked briefly at the class categories and came up with first rough separation. See below. Can you have a look? Do you see any obvious errors? Any categories in Core which are not needed by Morphic? Any categories in Core which are needed but are not reasonably compatible with Squeak? Any categories in Morphic which are optional for STE? Any categories in Other which are needed by Morphic or STE?

Cheers,
Bernhard

1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
Balloon-Collections
Collections-Abstract
Collections-Arrayed
Collections-Sequenceable
Collections-SkipLists
Collections-Streams
Collections-Support
Collections-Unordered
Collections-Weak
Compiler-Exceptions
Compiler-Kernel
Compiler-ParseNodes
Compiler-Support
Compiler-Syntax
Kernel-Chronology
Kernel-Classes
Kernel-Magnitudes
Kernel-Methods
Kernel-Numbers
Kernel-Objects
Kernel-Processes
Network-Kernel
Package Support
SUnit
SUnit-Preload

2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
Graphics-Display Objects
Graphics-Files
Graphics-Files-TIFF
Graphics-Primitives
Graphics-Text
Kernel-Text
Morphic-Basic
Morphic-Events
Morphic-Halos
Morphic-Kernel
Morphic-Layouts
Morphic-Menus
Morphic-Support
Morphic-Tests
Morphic-Text Support
Morphic-Tools
Morphic-Views for Models
Morphic-Widgets
Morphic-Worlds
Shout-Parsing
Shout-Styling
UCompletion
System-Exceptions Extensions
System-Exceptions Kernel
System-Files
System-Object Storage
System-Text
System-TextAttributes
Theme-Core
Theme-Tests
Theme-Themes

3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
Compiler-Tests
GraphicsTests-Primitives
Kernel-Tests
KernelTests-Numbers
KernelTests-Processes
LinearAlgebra
SUnit-UI
Signal Processing
Sound-Scores
Sound-Synthesis
System-Applications
System-Archives
System-Code Differ
System-Compression
System-Object Storage-Tests
System-Support
System-Tests
Taskbar-Core
Taskbar-Tests
Tests-Exceptions
Tests-Files
Tools-Browser
Tools-Changes
Tools-Debugger
Tools-Explorer
Tools-File Contents Browser
Tools-FileList
Tools-Inspector
Tools-Menus
CollectionTests
Tests-Bugs


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

Hannes Hirzel
Hello Bernhard and Juan

I like this idea. And thank you for coming up with the three groups.
Good to see what is compatible with Squeak and what is not.

Two remarks come to my mind.

a) What about loading _all_ classes of Cuis into a namespace of
Squeak? And then gradually start relying on the Squeak classes?


or alternatively


b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
which was only a partial success. It did not work reliably. So the
question is not so much on the Cuis side but more on the receiving
side.

A simple test could be to do a very minimal morphic (e.g. Morphic0)
which basically just displays the desktop background (with a downsized
version of PasteUpMorph) and with a mouse click does 'go to previous
project'.

The test in Squeak from the user point of view would be menu
'Projects' -> 'New Morphic0 project', then Morphic0 is entered and by
a mouse click it would be left again.

Then in batches more classes might be added from Cuis to go towards
the full Cuis Morphic. So a second step might be a Worldmenu
(Morphic02) and a third step an emergency exit to the Morphic of
Squeak (Morphic03). A forth might be to be able to create
RectangleMorphs and move them around (Morphic04) and so on. I.e. not a
mechanic loading of the Cuis part but a batch-wise copy/paste and
versioning exercise.

To summarize point b)
I think the fact that Squeak now has name spaces does not make a big
difference in the difficulties which arise for the integration. The
challenge is to find a good sequence of integration steps.


Kind regards
--Hannes


On 1/19/13, Bernhard Pieber <[hidden email]> wrote:

> Hi Juan,
>
> Now that Squeak supports Environments I thought a little bit what it would
> take to load Cuis' Morphic and STE in Squeak. The minimum would be to define
> three logical parts of Cuis:
> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
> with Squeak
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
> Morphic nor STE
>
> If we had defined these, then we would need to "just" file out the Morphic
> part and STE and file it in in a separate Squeak environment and do some
> fairly minimal compatibility changes, right? ;-)
>
> Seriously, I looked briefly at the class categories and came up with first
> rough separation. See below. Can you have a look? Do you see any obvious
> errors? Any categories in Core which are not needed by Morphic? Any
> categories in Core which are needed but are not reasonably compatible with
> Squeak? Any categories in Morphic which are optional for STE? Any categories
> in Other which are needed by Morphic or STE?
>
> Cheers,
> Bernhard
>
> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> Balloon-Collections
> Collections-Abstract
> Collections-Arrayed
> Collections-Sequenceable
> Collections-SkipLists
> Collections-Streams
> Collections-Support
> Collections-Unordered
> Collections-Weak
> Compiler-Exceptions
> Compiler-Kernel
> Compiler-ParseNodes
> Compiler-Support
> Compiler-Syntax
> Kernel-Chronology
> Kernel-Classes
> Kernel-Magnitudes
> Kernel-Methods
> Kernel-Numbers
> Kernel-Objects
> Kernel-Processes
> Network-Kernel
> Package Support
> SUnit
> SUnit-Preload
>
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
> with Squeak
> Graphics-Display Objects
> Graphics-Files
> Graphics-Files-TIFF
> Graphics-Primitives
> Graphics-Text
> Kernel-Text
> Morphic-Basic
> Morphic-Events
> Morphic-Halos
> Morphic-Kernel
> Morphic-Layouts
> Morphic-Menus
> Morphic-Support
> Morphic-Tests
> Morphic-Text Support
> Morphic-Tools
> Morphic-Views for Models
> Morphic-Widgets
> Morphic-Worlds
> Shout-Parsing
> Shout-Styling
> UCompletion
> System-Exceptions Extensions
> System-Exceptions Kernel
> System-Files
> System-Object Storage
> System-Text
> System-TextAttributes
> Theme-Core
> Theme-Tests
> Theme-Themes
>
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
> Morphic nor STE
> Compiler-Tests
> GraphicsTests-Primitives
> Kernel-Tests
> KernelTests-Numbers
> KernelTests-Processes
> LinearAlgebra
> SUnit-UI
> Signal Processing
> Sound-Scores
> Sound-Synthesis
> System-Applications
> System-Archives
> System-Code Differ
> System-Compression
> System-Object Storage-Tests
> System-Support
> System-Tests
> Taskbar-Core
> Taskbar-Tests
> Tests-Exceptions
> Tests-Files
> Tools-Browser
> Tools-Changes
> Tools-Debugger
> Tools-Explorer
> Tools-File Contents Browser
> Tools-FileList
> Tools-Inspector
> Tools-Menus
> CollectionTests
> Tests-Bugs
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

Juan Vuletich-4
In reply to this post by bpi
Hi Bernhard,

(below)

Bernhard Pieber wrote:

> Hi Juan,
>
> Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
>
> If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)
>
>  

You make it look quite easy. I wonder how easy it really is!

> Seriously, I looked briefly at the class categories and came up with first rough separation. See below. Can you have a look? Do you see any obvious errors? Any categories in Core which are not needed by Morphic? Any categories in Core which are needed but are not reasonably compatible with Squeak? Any categories in Morphic which are optional for STE? Any categories in Other which are needed by Morphic or STE?
>
> Cheers,
> Bernhard
>  

It looks quite reasonable to me. Not sure if the utility of this work is
enough to justify the effort, though.

Cheers,
Juan Vuletich

> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
> Balloon-Collections
> Collections-Abstract
> Collections-Arrayed
> Collections-Sequenceable
> Collections-SkipLists
> Collections-Streams
> Collections-Support
> Collections-Unordered
> Collections-Weak
> Compiler-Exceptions
> Compiler-Kernel
> Compiler-ParseNodes
> Compiler-Support
> Compiler-Syntax
> Kernel-Chronology
> Kernel-Classes
> Kernel-Magnitudes
> Kernel-Methods
> Kernel-Numbers
> Kernel-Objects
> Kernel-Processes
> Network-Kernel
> Package Support
> SUnit
> SUnit-Preload
>
> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
> Graphics-Display Objects
> Graphics-Files
> Graphics-Files-TIFF
> Graphics-Primitives
> Graphics-Text
> Kernel-Text
> Morphic-Basic
> Morphic-Events
> Morphic-Halos
> Morphic-Kernel
> Morphic-Layouts
> Morphic-Menus
> Morphic-Support
> Morphic-Tests
> Morphic-Text Support
> Morphic-Tools
> Morphic-Views for Models
> Morphic-Widgets
> Morphic-Worlds
> Shout-Parsing
> Shout-Styling
> UCompletion
> System-Exceptions Extensions
> System-Exceptions Kernel
> System-Files
> System-Object Storage
> System-Text
> System-TextAttributes
> Theme-Core
> Theme-Tests
> Theme-Themes
>
> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
> Compiler-Tests
> GraphicsTests-Primitives
> Kernel-Tests
> KernelTests-Numbers
> KernelTests-Processes
> LinearAlgebra
> SUnit-UI
> Signal Processing
> Sound-Scores
> Sound-Synthesis
> System-Applications
> System-Archives
> System-Code Differ
> System-Compression
> System-Object Storage-Tests
> System-Support
> System-Tests
> Taskbar-Core
> Taskbar-Tests
> Tests-Exceptions
> Tests-Files
> Tools-Browser
> Tools-Changes
> Tools-Debugger
> Tools-Explorer
> Tools-File Contents Browser
> Tools-FileList
> Tools-Inspector
> Tools-Menus
> CollectionTests
> Tests-Bugs
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

Juan Vuletich-4
In reply to this post by Hannes Hirzel
H. Hirzel wrote:

> Hello Bernhard and Juan
>
> I like this idea. And thank you for coming up with the three groups.
> Good to see what is compatible with Squeak and what is not.
>
> Two remarks come to my mind.
>
> a) What about loading _all_ classes of Cuis into a namespace of
> Squeak? And then gradually start relying on the Squeak classes?
>
>
> or alternatively
>
>
> b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
> which was only a partial success. It did not work reliably. So the
> question is not so much on the Cuis side but more on the receiving
> side.
>
>  

I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
quite reliably. It was a technical success, but a social failure. No
matter how much the Pharo folks talk about simplifying Morphic, you give
it to them, and nobody adopts it.

> A simple test could be to do a very minimal morphic (e.g. Morphic0)
> which basically just displays the desktop background (with a downsized
> version of PasteUpMorph) and with a mouse click does 'go to previous
> project'.
>
> The test in Squeak from the user point of view would be menu
> 'Projects' -> 'New Morphic0 project', then Morphic0 is entered and by
> a mouse click it would be left again.
>
> Then in batches more classes might be added from Cuis to go towards
> the full Cuis Morphic. So a second step might be a Worldmenu
> (Morphic02) and a third step an emergency exit to the Morphic of
> Squeak (Morphic03). A forth might be to be able to create
> RectangleMorphs and move them around (Morphic04) and so on. I.e. not a
> mechanic loading of the Cuis part but a batch-wise copy/paste and
> versioning exercise.
>
> To summarize point b)
> I think the fact that Squeak now has name spaces does not make a big
> difference in the difficulties which arise for the integration. The
> challenge is to find a good sequence of integration steps.
>
>
> Kind regards
> --Hannes
>
>  

The other challenge is to have enough time and energy to bring such
project to usable state.

Good luck with it!

Cheers,
Juan Vuletich

> On 1/19/13, Bernhard Pieber <[hidden email]> wrote:
>  
>> Hi Juan,
>>
>> Now that Squeak supports Environments I thought a little bit what it would
>> take to load Cuis' Morphic and STE in Squeak. The minimum would be to define
>> three logical parts of Cuis:
>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
>> with Squeak
>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
>> Morphic nor STE
>>
>> If we had defined these, then we would need to "just" file out the Morphic
>> part and STE and file it in in a separate Squeak environment and do some
>> fairly minimal compatibility changes, right? ;-)
>>
>> Seriously, I looked briefly at the class categories and came up with first
>> rough separation. See below. Can you have a look? Do you see any obvious
>> errors? Any categories in Core which are not needed by Morphic? Any
>> categories in Core which are needed but are not reasonably compatible with
>> Squeak? Any categories in Morphic which are optional for STE? Any categories
>> in Other which are needed by Morphic or STE?
>>
>> Cheers,
>> Bernhard
>>
>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>> Balloon-Collections
>> Collections-Abstract
>> Collections-Arrayed
>> Collections-Sequenceable
>> Collections-SkipLists
>> Collections-Streams
>> Collections-Support
>> Collections-Unordered
>> Collections-Weak
>> Compiler-Exceptions
>> Compiler-Kernel
>> Compiler-ParseNodes
>> Compiler-Support
>> Compiler-Syntax
>> Kernel-Chronology
>> Kernel-Classes
>> Kernel-Magnitudes
>> Kernel-Methods
>> Kernel-Numbers
>> Kernel-Objects
>> Kernel-Processes
>> Network-Kernel
>> Package Support
>> SUnit
>> SUnit-Preload
>>
>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible
>> with Squeak
>> Graphics-Display Objects
>> Graphics-Files
>> Graphics-Files-TIFF
>> Graphics-Primitives
>> Graphics-Text
>> Kernel-Text
>> Morphic-Basic
>> Morphic-Events
>> Morphic-Halos
>> Morphic-Kernel
>> Morphic-Layouts
>> Morphic-Menus
>> Morphic-Support
>> Morphic-Tests
>> Morphic-Text Support
>> Morphic-Tools
>> Morphic-Views for Models
>> Morphic-Widgets
>> Morphic-Worlds
>> Shout-Parsing
>> Shout-Styling
>> UCompletion
>> System-Exceptions Extensions
>> System-Exceptions Kernel
>> System-Files
>> System-Object Storage
>> System-Text
>> System-TextAttributes
>> Theme-Core
>> Theme-Tests
>> Theme-Themes
>>
>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by
>> Morphic nor STE
>> Compiler-Tests
>> GraphicsTests-Primitives
>> Kernel-Tests
>> KernelTests-Numbers
>> KernelTests-Processes
>> LinearAlgebra
>> SUnit-UI
>> Signal Processing
>> Sound-Scores
>> Sound-Synthesis
>> System-Applications
>> System-Archives
>> System-Code Differ
>> System-Compression
>> System-Object Storage-Tests
>> System-Support
>> System-Tests
>> Taskbar-Core
>> Taskbar-Tests
>> Tests-Exceptions
>> Tests-Files
>> Tools-Browser
>> Tools-Changes
>> Tools-Debugger
>> Tools-Explorer
>> Tools-File Contents Browser
>> Tools-FileList
>> Tools-Inspector
>> Tools-Menus
>> CollectionTests
>> Tests-Bugs
>>
>>
>> _______________________________________________
>> 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
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

Hannes Hirzel
Hello again

On 1/22/13, Juan Vuletich <[hidden email]> wrote:

> H. Hirzel wrote:
>> Hello Bernhard and Juan
>>
>> I like this idea. And thank you for coming up with the three groups.
>> Good to see what is compatible with Squeak and what is not.
>>
>> Two remarks come to my mind.
>>
>> a) What about loading _all_ classes of Cuis into a namespace of
>> Squeak? And then gradually start relying on the Squeak classes?
>>
>>
>> or alternatively
>>
>>
>> b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
>> which was only a partial success. It did not work reliably. So the
>> question is not so much on the Cuis side but more on the receiving
>> side.
>>
>>
>
> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
> quite reliably. It was a technical success, but a social failure. No
> matter how much the Pharo folks talk about simplifying Morphic, you give
> it to them, and nobody adopts it.
>
>> A simple test could be to do a very minimal morphic (e.g. Morphic0)
>> which basically just displays the desktop background (with a downsized
>> version of PasteUpMorph) and with a mouse click does 'go to previous
>> project'.
>>
>> The test in Squeak from the user point of view would be menu
>> 'Projects' -> 'New Morphic0 project', then Morphic0 is entered and by
>> a mouse click it would be left again.
>>
>> Then in batches more classes might be added from Cuis to go towards
>> the full Cuis Morphic. So a second step might be a Worldmenu
>> (Morphic02) and a third step an emergency exit to the Morphic of
>> Squeak (Morphic03). A forth might be to be able to create
>> RectangleMorphs and move them around (Morphic04) and so on. I.e. not a
>> mechanic loading of the Cuis part but a batch-wise copy/paste and
>> versioning exercise.
>>
>> To summarize point b)
>> I think the fact that Squeak now has name spaces does not make a big
>> difference in the difficulties which arise for the integration. The
>> challenge is to find a good sequence of integration steps.
>>
>>
>> Kind regards
>> --Hannes
>>
>>
>
> The other challenge is to have enough time and energy to bring such
> project to usable state.


> Good luck with it!


This sounds that is is very difficult and time consuming and I think it is.

On a smaller scale I think I now have most of the ingredients to do a
simple REPL GUI (not a priority for me at the moment).

Another idea to try out is to include some Cuis classes and methods in
a  layer on top of the already quite crowded Squeak API so that Cuis
GUI code runs unaltered.

I do not have time for that either as of now. Just enough to do with
keeping a common base on Non-GUI classes. I.e. I aim at writing Cuis
(Non-GUI) code and run it unaltered in Squeak and vice-versa. For this
I need a layer 'CuisCompatibilityForSqueak'.

A third thing is to file in whole class categories from Squeak into
Cuis and run all the tests to see how the compatibility is for these
particular categories.

Regards
Hannes


> Cheers,
> Juan Vuletich
>
>> On 1/19/13, Bernhard Pieber <[hidden email]> wrote:
>>
>>> Hi Juan,
>>>
>>> Now that Squeak supports Environments I thought a little bit what it
>>> would
>>> take to load Cuis' Morphic and STE in Squeak. The minimum would be to
>>> define
>>> three logical parts of Cuis:
>>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite
>>> incompatible
>>> with Squeak
>>> 3. Other (Applications, Tools, System, Support, Tests): neither needed
>>> by
>>> Morphic nor STE
>>>
>>> If we had defined these, then we would need to "just" file out the
>>> Morphic
>>> part and STE and file it in in a separate Squeak environment and do some
>>> fairly minimal compatibility changes, right? ;-)
>>>
>>> Seriously, I looked briefly at the class categories and came up with
>>> first
>>> rough separation. See below. Can you have a look? Do you see any obvious
>>> errors? Any categories in Core which are not needed by Morphic? Any
>>> categories in Core which are needed but are not reasonably compatible
>>> with
>>> Squeak? Any categories in Morphic which are optional for STE? Any
>>> categories
>>> in Other which are needed by Morphic or STE?
>>>
>>> Cheers,
>>> Bernhard
>>>
>>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>>> Balloon-Collections
>>> Collections-Abstract
>>> Collections-Arrayed
>>> Collections-Sequenceable
>>> Collections-SkipLists
>>> Collections-Streams
>>> Collections-Support
>>> Collections-Unordered
>>> Collections-Weak
>>> Compiler-Exceptions
>>> Compiler-Kernel
>>> Compiler-ParseNodes
>>> Compiler-Support
>>> Compiler-Syntax
>>> Kernel-Chronology
>>> Kernel-Classes
>>> Kernel-Magnitudes
>>> Kernel-Methods
>>> Kernel-Numbers
>>> Kernel-Objects
>>> Kernel-Processes
>>> Network-Kernel
>>> Package Support
>>> SUnit
>>> SUnit-Preload
>>>
>>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite
>>> incompatible
>>> with Squeak
>>> Graphics-Display Objects
>>> Graphics-Files
>>> Graphics-Files-TIFF
>>> Graphics-Primitives
>>> Graphics-Text
>>> Kernel-Text
>>> Morphic-Basic
>>> Morphic-Events
>>> Morphic-Halos
>>> Morphic-Kernel
>>> Morphic-Layouts
>>> Morphic-Menus
>>> Morphic-Support
>>> Morphic-Tests
>>> Morphic-Text Support
>>> Morphic-Tools
>>> Morphic-Views for Models
>>> Morphic-Widgets
>>> Morphic-Worlds
>>> Shout-Parsing
>>> Shout-Styling
>>> UCompletion
>>> System-Exceptions Extensions
>>> System-Exceptions Kernel
>>> System-Files
>>> System-Object Storage
>>> System-Text
>>> System-TextAttributes
>>> Theme-Core
>>> Theme-Tests
>>> Theme-Themes
>>>
>>> 3. Other (Applications, Tools, System, Support, Tests): neither needed
>>> by
>>> Morphic nor STE
>>> Compiler-Tests
>>> GraphicsTests-Primitives
>>> Kernel-Tests
>>> KernelTests-Numbers
>>> KernelTests-Processes
>>> LinearAlgebra
>>> SUnit-UI
>>> Signal Processing
>>> Sound-Scores
>>> Sound-Synthesis
>>> System-Applications
>>> System-Archives
>>> System-Code Differ
>>> System-Compression
>>> System-Object Storage-Tests
>>> System-Support
>>> System-Tests
>>> Taskbar-Core
>>> Taskbar-Tests
>>> Tests-Exceptions
>>> Tests-Files
>>> Tools-Browser
>>> Tools-Changes
>>> Tools-Debugger
>>> Tools-Explorer
>>> Tools-File Contents Browser
>>> Tools-FileList
>>> Tools-Inspector
>>> Tools-Menus
>>> CollectionTests
>>> Tests-Bugs
>>>
>>>
>>> _______________________________________________
>>> 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
>

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

David T. Lewis
In reply to this post by Juan Vuletich-4
On Mon, Jan 21, 2013 at 11:24:01PM -0300, Juan Vuletich wrote:

> H. Hirzel wrote:
> >Hello Bernhard and Juan
> >
> >I like this idea. And thank you for coming up with the three groups.
> >Good to see what is compatible with Squeak and what is not.
> >
> >Two remarks come to my mind.
> >
> >a) What about loading _all_ classes of Cuis into a namespace of
> >Squeak? And then gradually start relying on the Squeak classes?
> >
> >
> >or alternatively
> >
> >
> >b) There was an earlier attempt at loading 'SimpleMorphic' into Squeak
> >which was only a partial success. It did not work reliably. So the
> >question is not so much on the Cuis side but more on the receiving
> >side.
> >
> >  
>
> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
> quite reliably. It was a technical success, but a social failure. No
> matter how much the Pharo folks talk about simplifying Morphic, you give
> it to them, and nobody adopts it.

I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
of Squeak Project (MVC project, Morphic project, and SMxProject). This
was intended as a proof of concept, and I never finished it. But clearly
it is possible to do this. I do not yet know anything about Environments
in Squeak, but it sounds to me like this might it easier to do.

If I had unlimited time and energy (which I do not), here is how I would
want to approach it from the Squeak side:

1) Fix enough of the bugs in MVC to make it useable. Mainly get the
debugger working with ToolBuilder.

2) Unload Morphic from Squeak.

3) Load Cuis Morphic in Squeak and get it working.

4) Make some kind of Project (CuisMorphicProject?) for projects that use the
Cuis Morphic.

5) Figure out how to use Environments so that Squeak Morphic and Cuis
Morphic projects can exist in the same image, and make sure they are
all reloadable.

6) Migrate Etoys to Cuis Morphic?

Dave


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
bpi
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

bpi
In reply to this post by Juan Vuletich-4
Hi Juan,

Here is a list of things to do to be able to load CuisMorphic in Squeak.
In Cuis:
1. Allow the definition of "internal" Cuis packages. They are defined like external packages using PackageInfo. However, code in there is still maintained using ChangeSets, not pck.st files.
2. Allow the definition of Configurations. A configuration is a list of packages with a defined order which is used for loading and updating.
3. Define three Configurations, each corresponding to the parts defined below, by recategorizing extension methods to move them to the correct packages.
4. Export the CuisMorphic Configuration using Cuis-Cypress. Fix remaining bugs in Cuis-Cypress.
5. Fix world creation in Cuis.

In Squeak:
5. Load CuisMorphic into a separate Environment. Fix remaining bugs in Environments.
6. Add a CuisMorphicProject as a holder for Cuis Morphs.
7. Add compatibility methods to Squeak to make CuisMorphic work.

Optional:
8. Port MudPie to Cuis to help with 3.

Did I forget anything? How much analysis would be needed to estimate the effort of those tasks.

I think 2. would be very useful on its own for most external packages, certainly for STE.

Cheers,
Bernhard

Am 22.01.2013 um 03:20 schrieb Juan Vuletich:

> Bernhard Pieber wrote:
>> Hi Juan,
>>
>> Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
>>
>> If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)
> You make it look quite easy. I wonder how easy it really is!
>
>> Seriously, I looked briefly at the class categories and came up with first rough separation. See below. Can you have a look? Do you see any obvious errors? Any categories in Core which are not needed by Morphic? Any categories in Core which are needed but are not reasonably compatible with Squeak? Any categories in Morphic which are optional for STE? Any categories in Other which are needed by Morphic or STE?
> It looks quite reasonable to me. Not sure if the utility of this work is enough to justify the effort, though.
>
> Cheers,
> Juan Vuletich


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
bpi
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

bpi
In reply to this post by David T. Lewis
Hi David,

Thanks for the list of tips. See my other mail to Juan in this thread.

I wonder if it would be essential to unload Morphic from Squeak? Could CuisMorphic not just be loaded in addition?

How difficult would it be to create a CuisMorphicProject? I see the current two subclasses MVCProject and MorphicProject have quite a few methods. How many of them are the bare minimum? Can you estimate how much effort it would take?

Cheers,
Bernhard

Am 22.01.2013 um 15:28 schrieb David T. Lewis:

> On Mon, Jan 21, 2013 at 11:24:01PM -0300, Juan Vuletich wrote:
>> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
>> quite reliably. It was a technical success, but a social failure. No
>> matter how much the Pharo folks talk about simplifying Morphic, you give
>> it to them, and nobody adopts it.
>
> I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
> of Squeak Project (MVC project, Morphic project, and SMxProject). This
> was intended as a proof of concept, and I never finished it. But clearly
> it is possible to do this. I do not yet know anything about Environments
> in Squeak, but it sounds to me like this might it easier to do.
>
> If I had unlimited time and energy (which I do not), here is how I would
> want to approach it from the Squeak side:
>
> 1) Fix enough of the bugs in MVC to make it useable. Mainly get the
> debugger working with ToolBuilder.
>
> 2) Unload Morphic from Squeak.
>
> 3) Load Cuis Morphic in Squeak and get it working.
>
> 4) Make some kind of Project (CuisMorphicProject?) for projects that use the
> Cuis Morphic.
>
> 5) Figure out how to use Environments so that Squeak Morphic and Cuis
> Morphic projects can exist in the same image, and make sure they are
> all reloadable.
>
> 6) Migrate Etoys to Cuis Morphic?
>
> Dave


_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

David T. Lewis
On Tue, Jan 22, 2013 at 09:38:57PM +0100, Bernhard Pieber wrote:
> Hi David,
>
> Thanks for the list of tips. See my other mail to Juan in this thread.
>
> I wonder if it would be essential to unload Morphic from Squeak? Could CuisMorphic not just be loaded in addition?

It is not essential. But making Squeak Morphic reloadable is a good thing
to do anyway, so if I had enough time to do all the things on the list, I
would do this first, and load Cuis Morphic second. There are a number of
globals and interdependencies between Morphic and Projects in Squeak, and
my guess is that making Morphic reloadable would force a lot of this to be
cleaned up, which in turn would make it easier to load Cuis Morphic.

>
> How difficult would it be to create a CuisMorphicProject? I see the current two subclasses MVCProject and MorphicProject have quite a few methods. How many of them are the bare minimum? Can you estimate how much effort it would take?
>

This would be very similar to the proof of concept in "SimpleMorphic for Squeak",
which is incomplete but is good enough to show most of what needs to be done.
The code is on SqueakSource at http://www.squeaksource.com/SimpleMorphicSqueak.

It is not a small project, but it can be done.

Dave

> Cheers,
> Bernhard
>
> Am 22.01.2013 um 15:28 schrieb David T. Lewis:
> > On Mon, Jan 21, 2013 at 11:24:01PM -0300, Juan Vuletich wrote:
> >> I did a port of 'SimpleMorphic' for Pharo some time ago. It did work
> >> quite reliably. It was a technical success, but a social failure. No
> >> matter how much the Pharo folks talk about simplifying Morphic, you give
> >> it to them, and nobody adopts it.
> >
> > I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
> > of Squeak Project (MVC project, Morphic project, and SMxProject). This
> > was intended as a proof of concept, and I never finished it. But clearly
> > it is possible to do this. I do not yet know anything about Environments
> > in Squeak, but it sounds to me like this might it easier to do.
> >
> > If I had unlimited time and energy (which I do not), here is how I would
> > want to approach it from the Squeak side:
> >
> > 1) Fix enough of the bugs in MVC to make it useable. Mainly get the
> > debugger working with ToolBuilder.
> >
> > 2) Unload Morphic from Squeak.
> >
> > 3) Load Cuis Morphic in Squeak and get it working.
> >
> > 4) Make some kind of Project (CuisMorphicProject?) for projects that use the
> > Cuis Morphic.
> >
> > 5) Figure out how to use Environments so that Squeak Morphic and Cuis
> > Morphic projects can exist in the same image, and make sure they are
> > all reloadable.
> >
> > 6) Migrate Etoys to Cuis Morphic?
> >
> > Dave
>
>
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

Juan Vuletich-4
In reply to this post by David T. Lewis
Hi David,

I remember that this interested you, and that you talked about doing all
this. I wasn't aware you actually made it run. Apologies.

It would be great to have this. I wish you had unlimited time and
energy! (And I had that too :) .

Cheers,
Juan Vuletich

David T. Lewis wrote:

>
> I did some work in Squeak to bring SimpleMorphic into Squeak as a kind
> of Squeak Project (MVC project, Morphic project, and SMxProject). This
> was intended as a proof of concept, and I never finished it. But clearly
> it is possible to do this. I do not yet know anything about Environments
> in Squeak, but it sounds to me like this might it easier to do.
>
> If I had unlimited time and energy (which I do not), here is how I would
> want to approach it from the Squeak side:
>
> 1) Fix enough of the bugs in MVC to make it useable. Mainly get the
> debugger working with ToolBuilder.
>
> 2) Unload Morphic from Squeak.
>
> 3) Load Cuis Morphic in Squeak and get it working.
>
> 4) Make some kind of Project (CuisMorphicProject?) for projects that use the
> Cuis Morphic.
>
> 5) Figure out how to use Environments so that Squeak Morphic and Cuis
> Morphic projects can exist in the same image, and make sure they are
> all reloadable.
>
> 6) Migrate Etoys to Cuis Morphic?
>
> Dave
>
>  

_______________________________________________
Cuis mailing list
[hidden email]
http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org
Reply | Threaded
Open this post in threaded view
|

Re: Definition of Cuis parts

Juan Vuletich-4
In reply to this post by bpi
Hi Bernhard,

Bernhard Pieber wrote:

> Hi Juan,
>
> Here is a list of things to do to be able to load CuisMorphic in Squeak.
> In Cuis:
> 1. Allow the definition of "internal" Cuis packages. They are defined like external packages using PackageInfo. However, code in there is still maintained using ChangeSets, not pck.st files.
> 2. Allow the definition of Configurations. A configuration is a list of packages with a defined order which is used for loading and updating.
> 3. Define three Configurations, each corresponding to the parts defined below, by recategorizing extension methods to move them to the correct packages.
> 4. Export the CuisMorphic Configuration using Cuis-Cypress. Fix remaining bugs in Cuis-Cypress.
> 5. Fix world creation in Cuis.
>
> In Squeak:
> 5. Load CuisMorphic into a separate Environment. Fix remaining bugs in Environments.
> 6. Add a CuisMorphicProject as a holder for Cuis Morphs.
> 7. Add compatibility methods to Squeak to make CuisMorphic work.
>
> Optional:
> 8. Port MudPie to Cuis to help with 3.
> Did I forget anything? How much analysis would be needed to estimate the effort of those tasks.
>
>  

Not that I can think of. Your list looks pretty good. Talking about 1.
to 5., the only parts that would require some effort to make an
estimation are:
- 3. Requires taking a close look at list of packages for each
Configuration or PackageCluster. Class references, some analysis of
methods that should reside in extensions, etc. I guess about 3 or 4
hours would suffice.
- 4. Can't really be estimated, as any bugs in Cuis-Cypress will just
pop-up. In any case, effort for fixing those bugs can not be too much.
Maybe between <= 1 hour (best case) and 10 hours (worst case).

WRT 5., and 6., making an estimation would be rather difficult. I
haven't been using Squeak lately, I don't know anything about
Environments, and haven't used Projects in a long time. 7. is really
easy, at least for me, as I know the purpose for the APIs I added to Cuis.

8. would require taking a look again at MudPie, after, maybe 8 years. It
great, and it really helped me in my Morphic Team Leader times in Squeak.

I hope this helps.

> I think 2. would be very useful on its own for most external packages, certainly for STE.
>  

Indeed!

Cheers,
Juan Vuletich

> Cheers,
> Bernhard
>
> Am 22.01.2013 um 03:20 schrieb Juan Vuletich:
>  
>> Bernhard Pieber wrote:
>>    
>>> Hi Juan,
>>>
>>> Now that Squeak supports Environments I thought a little bit what it would take to load Cuis' Morphic and STE in Squeak. The minimum would be to define three logical parts of Cuis:
>>> 1. Core: needed by Morphic & STE, but reasonably compatible with Squeak
>>> 2. Morphic: Morphic itself, needed by Morphic & STE, but quite incompatible with Squeak
>>> 3. Other (Applications, Tools, System, Support, Tests): neither needed by Morphic nor STE
>>>
>>> If we had defined these, then we would need to "just" file out the Morphic part and STE and file it in in a separate Squeak environment and do some fairly minimal compatibility changes, right? ;-)
>>>      
>> You make it look quite easy. I wonder how easy it really is!
>>
>>    
>>> Seriously, I looked briefly at the class categories and came up with first rough separation. See below. Can you have a look? Do you see any obvious errors? Any categories in Core which are not needed by Morphic? Any categories in Core which are needed but are not reasonably compatible with Squeak? Any categories in Morphic which are optional for STE? Any categories in Other which are needed by Morphic or STE?
>>>      
>> It looks quite reasonable to me. Not sure if the utility of this work is enough to justify the effort, though.
>>
>> Cheers,
>> Juan Vuletich
>>    
>
>  


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