Smalltalk › Squeak › Squeak - Dev

Package unload status

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

40 messages Options

Levente Uzonyi-2

Re: Re: Package unload status

On Tue, 5 Jan 2010, Juan Vuletich wrote:

> Levente Uzonyi wrote:
>> On Wed, 6 Jan 2010, Igor Stasenko wrote:
>>
>>> 2010/1/5 Edgar J. De Cleene <[hidden email]>:
>>>>
>>>>
>>>>
>>>> This is GREAT news.
>>>> I like help with any Cuis + MC + M17N = SqueakCore , starting with
>>>> 3.11Unloaded.
>>>>
>>>
>>> And what to do with all changes to Kernel being added recently to trunk?
>>> Or you want to deal with them later, in same fashion as Juan
>>> backported closure compiler?
>>
>> That's going to be a lot of work. AFAIK Cuis is built on top of 3.7, so it
>> probably doesn't have the changes from 3.8, 3.9 and 3.10 besides the trunk
>> changes.
>
> Cuis is not "built on top" of 3.7 but derived from it, in the same way as
> 3.8, 3.9, etc. Cuis does include many changes from later Squeak versions,
> especially bugfixes to kernel. If I could get Closures working on it, porting
> anything else will be much easier than that. Besides, Squeak trunk is
> actually closer to 3.7 than Cuis is. I mean, I really modified lots of stuff
> there.
>
> Anyway, after stripping a lof of stuff from Cuis, I can tell that the biggest
> work of all will be to turn packages into well factored units that can be
> unloaded and reloaded. I avoided that. I just removed them. That's why I
> believe Andreas is right: the best way is to work in Squeak, using Cuis as a
> reference.
>
>> Another issue with this approach is licensing.
>
> There are no licensing issues. Cuis is MIT.

Good to know. It's funny that every fork has MIT license, but not squeak.

Levente

>
>> Levente
>
> Cheers,
> Juan Vuletich
>
>

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Andreas.Raab

Andreas Raab wrote:

> Juan Vuletich wrote:
>> BTW, in Cuis, Morph will eventually have a lot less than 500 methods.
>> I hope to get to about 200.
>
> Very nice. It's extremely valuable to have someone with a real
> interest in making things smaller. Coincidentally, I'm quite okay with
> the idea that Cuis will always have a smaller image than a core Squeak
> image would be. I think the important part is to have reasonable
> compatibility betweeen the two. I want compatible kernel interfaces,
> compatible collection libraries, compatible morph protocols. In other
> words, anything built for Cuis should run on top of Squeak without
> changes.

Interesting. So far I have only thought about how Cuis could support
stuff meant for Squeak!

WRT compatibility of apps with Squeak, I believe Cuis packages will fall
in 3 categories:

1) Stuff that is identical (almost) to Squeak. For example, I took the
current Compiler categories and Kernel-Methods to support closures.
Kernel-Classes, Kernel-Objects, Kernel-Numbers and all Collections-
categories could follow. These are parts of the system that are in good
shape in Squeak, and have people doing great work there too. Stuff I
can't really improve.

2) Stuff that I have somewhat modified. I removed lots of protocol. This
obviously doesn't affect porting Cuis apps to Squeak. But I also removed
arguments, making some messages shorter, and added some convenience
methods. This is easy to address by adding an optional 'Cuis
compatibility' package for Squeak.

3) Stuff that is really different. For example TextStyle, and the new
TextEditor application. (I'm not talking about the Editor hierarchy
here. In Cuis do World/Open/Text Editor. I also have a fairly complete,
not yet released, style based text editor.) These might need being
ported to Squeak and will give some work. I could also include Morphic
here. But I also hope to replace the current Morphic in Cuis with
Morphic 3. And I also hope to be able to make Morphic 3 an optional
package for Squeak and Pharo.

Cheers,
Juan Vuletich

Andreas.Raab

Re: Package unload status

Juan Vuletich wrote:

> Andreas Raab wrote:
>> Juan Vuletich wrote:
>>> BTW, in Cuis, Morph will eventually have a lot less than 500 methods.
>>> I hope to get to about 200.
>>
>> Very nice. It's extremely valuable to have someone with a real
>> interest in making things smaller. Coincidentally, I'm quite okay with
>> the idea that Cuis will always have a smaller image than a core Squeak
>> image would be. I think the important part is to have reasonable
>> compatibility betweeen the two. I want compatible kernel interfaces,
>> compatible collection libraries, compatible morph protocols. In other
>> words, anything built for Cuis should run on top of Squeak without
>> changes.
>
> Interesting. So far I have only thought about how Cuis could support
> stuff meant for Squeak!

Sure, it does go both ways - but what I meant to say is that Squeak =
Cuis + X so naturally everything that works in Cuis will work in Squeak
but only stuff in Squeak that doesn't use X will be able to run in Cuis.
Where X might be something like MC + M17N + MorphicPlus or something
like that.

> WRT compatibility of apps with Squeak, I believe Cuis packages will fall
> in 3 categories:
>
> 1) Stuff that is identical (almost) to Squeak. For example, I took the
> current Compiler categories and Kernel-Methods to support closures.
> Kernel-Classes, Kernel-Objects, Kernel-Numbers and all Collections-
> categories could follow. These are parts of the system that are in good
> shape in Squeak, and have people doing great work there too. Stuff I
> can't really improve.

Agreed.

> 2) Stuff that I have somewhat modified. I removed lots of protocol. This
> obviously doesn't affect porting Cuis apps to Squeak. But I also removed
> arguments, making some messages shorter, and added some convenience
> methods. This is easy to address by adding an optional 'Cuis
> compatibility' package for Squeak.

Let's not. Let's make sure Squeak support these protocols natively and
build the next layer on top of it. In fact, that might be something you
could start helping with today. Remember, if we end up with Squeak =
Cuis + X then we can have our cake and eat it too - a nice, small
microkernel and more stuff built on top of it.

(if you feel more comfortable adding this as a Cuis extension, feel free
to do so, but I don't think it's necessary)

> 3) Stuff that is really different. For example TextStyle, and the new
> TextEditor application. (I'm not talking about the Editor hierarchy
> here. In Cuis do World/Open/Text Editor. I also have a fairly complete,
> not yet released, style based text editor.) These might need being
> ported to Squeak and will give some work. I could also include Morphic
> here. But I also hope to replace the current Morphic in Cuis with
> Morphic 3. And I also hope to be able to make Morphic 3 an optional
> package for Squeak and Pharo.

The one thing I'd recommend is not "reusing" existing namespaces. If you
have a new UI framework, don't call it "Morph" or "Morphic". This only
leads to confusion down the road since it can't be loaded side-by-side
with Morphic. Anything you do in a separate namespace won't be a problem
- we've already agreed how to deal with the underlying basics so
basically this is just another application on top of Cuis which can be
run on top of Squeak :-)

Cheers,
- Andreas

Andreas.Raab

Re: Package unload status

In reply to this post by Levente Uzonyi-2

Levente Uzonyi wrote:
>
> Good to know. It's funny that every fork has MIT license, but not squeak.
>

Well, we do. The problem we're facing is that we need the SFC lawyers to
agree that we've *proven* that we're fully MIT relicensed. And we just
don't want to announce the (MIT relicensed) 4.0 without also announcing
our joining the SFC which is what creates the delay.

BTW, the process is moving along. Slowly, but definitely moving.

Cheers,
- Andreas

Edgar J. De Cleene

Re: Re: Package unload status

In reply to this post by Igor Stasenko

On 1/5/10 8:36 PM, "Igor Stasenko" <[hidden email]> wrote:

> And what to do with all changes to Kernel being added recently to trunk?
> Or you want to deal with them later, in same fashion as Juan
> backported closure compiler?

Well, seems you don't know I working in reduced images for long time and for
two years lack understanding how 3.11 should be.

My last work this days is on MinimalMorphic which is only 7.3 Mb , could
load all 3.6 to 3.10 (no closures)

I develop several hacks for dealing with trunk, so only need polish as
Andreas polish my old ideas of unload in the ReleaseBuilderFor3dot11 class.

I attach some 3.11 still do not have and SqueakLight and Minimal use for a
while.

Having "repository" of classes and reduced image could load from here with
some code.

The complete for 3.7 to 3.10 was around for a while and could be loaded with
some like:

lookForClassIn3dot9: aClass
| inputStream cat path |
Missing3dot9
ifNil: [inputStream := HTTPLoader default retrieveContentsFor:
'ftp.squeak.org/various_images/SqueakLight//SLupdates/Organizer3dot9.obj'.
inputStream := (MultiByteBinaryOrTextStream with: inputStream
contents) reset.
inputStream setConverterForCode.
Smalltalk at: #Missing3dot9 put: inputStream
fileInObjectAndCode].
cat := Missing3dot9
at: aClass
ifAbsent: [^ self error: aClass , ' is not on server '].
^ path := 'http://squeakros.atspace.com/3dot9/' , cat , '/' , aClass
asString , '.sqz'

And MinimalMorphic is not a toy.
We use in SqueakRos sites
http://sn.im/srpier
http://sn.im/miaida

Keep in mind computer is not 7/24, so could be on or not

Edgar

ReleaseBuilderFor3dot11-sources managment.st (3K) Download Attachment

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Andreas.Raab

Andreas Raab wrote:

> Juan Vuletich wrote:
>> Andreas Raab wrote:
>>> Juan Vuletich wrote:
>>>> BTW, in Cuis, Morph will eventually have a lot less than 500
>>>> methods. I hope to get to about 200.
>>>
>>> Very nice. It's extremely valuable to have someone with a real
>>> interest in making things smaller. Coincidentally, I'm quite okay
>>> with the idea that Cuis will always have a smaller image than a core
>>> Squeak image would be. I think the important part is to have
>>> reasonable compatibility betweeen the two. I want compatible kernel
>>> interfaces, compatible collection libraries, compatible morph
>>> protocols. In other words, anything built for Cuis should run on top
>>> of Squeak without changes.
>>
>> Interesting. So far I have only thought about how Cuis could support
>> stuff meant for Squeak!
>
> Sure, it does go both ways - but what I meant to say is that Squeak =
> Cuis + X so naturally everything that works in Cuis will work in
> Squeak but only stuff in Squeak that doesn't use X will be able to run
> in Cuis. Where X might be something like MC + M17N + MorphicPlus or
> something like that.
>
>> WRT compatibility of apps with Squeak, I believe Cuis packages will
>> fall in 3 categories:
>>
>> 1) Stuff that is identical (almost) to Squeak. For example, I took
>> the current Compiler categories and Kernel-Methods to support
>> closures. Kernel-Classes, Kernel-Objects, Kernel-Numbers and all
>> Collections- categories could follow. These are parts of the system
>> that are in good shape in Squeak, and have people doing great work
>> there too. Stuff I can't really improve.
>
> Agreed.
>
>> 2) Stuff that I have somewhat modified. I removed lots of protocol.
>> This obviously doesn't affect porting Cuis apps to Squeak. But I also
>> removed arguments, making some messages shorter, and added some
>> convenience methods. This is easy to address by adding an optional
>> 'Cuis compatibility' package for Squeak.
>
> Let's not. Let's make sure Squeak support these protocols natively and
> build the next layer on top of it. In fact, that might be something
> you could start helping with today. Remember, if we end up with Squeak
> = Cuis + X then we can have our cake and eat it too - a nice, small
> microkernel and more stuff built on top of it.
>
> (if you feel more comfortable adding this as a Cuis extension, feel
> free to do so, but I don't think it's necessary)

This is easy to do in any way. I'd be changing a lot in Morphic during
the next months for Morphic 3, so I'd do that later, when protocols in
Cuis start to stabilize.

>> 3) Stuff that is really different. For example TextStyle, and the new
>> TextEditor application. (I'm not talking about the Editor hierarchy
>> here. In Cuis do World/Open/Text Editor. I also have a fairly
>> complete, not yet released, style based text editor.) These might
>> need being ported to Squeak and will give some work. I could also
>> include Morphic here. But I also hope to replace the current Morphic
>> in Cuis with Morphic 3. And I also hope to be able to make Morphic 3
>> an optional package for Squeak and Pharo.
>
> The one thing I'd recommend is not "reusing" existing namespaces. If
> you have a new UI framework, don't call it "Morph" or "Morphic". This
> only leads to confusion down the road since it can't be loaded
> side-by-side with Morphic. Anything you do in a separate namespace
> won't be a problem - we've already agreed how to deal with the
> underlying basics so basically this is just another application on top
> of Cuis which can be run on top of Squeak :-)

Mhhh! I think the name "Morphic 3" makes sense, as it all started after
suggestions from John Maloney (in SqueakNews) and Dan Ingalls (in "Where
is Squeak headed"). But I agree with your reasons too. So far, the name
of the framework is "Morphic 3" and the root class is M3Morph (which I
don't really like). Maybe I'd come up with a completely unrelated name.
Perhaps "CuisGraphics" or something... Suggestions welcome!

Cheers,
Juan Vuletich

> Cheers,
> - Andreas

Leandro Caniglia

Re: Re: Package unload status

Juan Vuletich wrote:

Mhhh! I think the name "Morphic 3" makes sense, as it all started after suggestions from John Maloney (in SqueakNews) and Dan Ingalls (in "Where is Squeak headed"). But I agree with your reasons too. So far, the name of the framework is "Morphic 3" and the root class is M3Morph (which I don't really like). Maybe I'd come up with a completely unrelated name. Perhaps "CuisGraphics" or something... Suggestions welcome!

Cheers,
Juan Vuletich

What about Morphicuis, which would also stand for MorphicUIs? (Not sure I'm serious about this!)

/Leandro

Karl Ramberg

Re: Re: Package unload status

On 2010-01-09 15:52, Leandro wrote:

Juan Vuletich wrote:
Mhhh! I think the name "Morphic 3" makes sense, as it all started after suggestions from John Maloney (in SqueakNews) and Dan Ingalls (in "Where is Squeak headed"). But I agree with your reasons too. So far, the name of the framework is "Morphic 3" and the root class is M3Morph (which I don't really like). Maybe I'd come up with a completely unrelated name. Perhaps "CuisGraphics" or something... Suggestions welcome!

Cheers,
Juan Vuletich

What about Morphicuis, which would also stand for MorphicUIs? (Not sure I'm serious about this!)

/Leandro
  

Or Cuistic ? Not that it's caustic or anything...

Karl

Casey Ransberger

Re: Package unload status

In reply to this post by Juan Vuletich-4

Isn't the focus of Morphic 3 scalable graphics? Maybe the name should
reflect that.

On Saturday, January 9, 2010, Juan Vuletich <[hidden email]> wrote:

> Andreas Raab wrote:
>
> Juan Vuletich wrote:
>
> Andreas Raab wrote:
>
> Juan Vuletich wrote:
>
> BTW, in Cuis, Morph will eventually have a lot less than 500 methods. I hope to get to about 200.
>
>
> Very nice. It's extremely valuable to have someone with a real interest in making things smaller. Coincidentally, I'm quite okay with the idea that Cuis will always have a smaller image than a core Squeak image would be. I think the important part is to have reasonable compatibility betweeen the two. I want compatible kernel interfaces, compatible collection libraries, compatible morph protocols. In other words, anything built for Cuis should run on top of Squeak without changes.
>
>
> Interesting. So far I have only thought about how Cuis could support stuff meant for Squeak!
>
>
> Sure, it does go both ways - but what I meant to say is that Squeak = Cuis + X so naturally everything that works in Cuis will work in Squeak but only stuff in Squeak that doesn't use X will be able to run in Cuis. Where X might be something like MC + M17N + MorphicPlus or something like that.
>
>
> WRT compatibility of apps with Squeak, I believe Cuis packages will fall in 3 categories:
>
> 1) Stuff that is identical (almost) to Squeak. For example, I took the current Compiler categories and Kernel-Methods to support closures. Kernel-Classes, Kernel-Objects, Kernel-Numbers and all Collections- categories could follow. These are parts of the system that are in good shape in Squeak, and have people doing great work there too. Stuff I can't really improve.
>
>
> Agreed.
>
>
> 2) Stuff that I have somewhat modified. I removed lots of protocol. This obviously doesn't affect porting Cuis apps to Squeak. But I also removed arguments, making some messages shorter, and added some convenience methods. This is easy to address by adding an optional 'Cuis compatibility' package for Squeak.
>
>
> Let's not. Let's make sure Squeak support these protocols natively and build the next layer on top of it. In fact, that might be something you could start helping with today. Remember, if we end up with Squeak = Cuis + X then we can have our cake and eat it too - a nice, small microkernel and more stuff built on top of it.
>
> (if you feel more comfortable adding this as a Cuis extension, feel free to do so, but I don't think it's necessary)
>
>
> This is easy to do in any way. I'd be changing a lot in Morphic during the next months for Morphic 3, so I'd do that later, when protocols in Cuis start to stabilize.
>
>
> 3) Stuff that is really different. For example TextStyle, and the new TextEditor application. (I'm not talking about the Editor hierarchy here. In Cuis do World/Open/Text Editor. I also have a fairly complete, not yet released, style based text editor.) These might need being ported to Squeak and will give some work. I could also include Morphic here. But I also hope to replace the current Morphic in Cuis with Morphic 3. And I also hope to be able to make Morphic 3 an optional package for Squeak and Pharo.
>
>
> The one thing I'd recommend is not "reusing" existing namespaces. If you have a new UI framework, don't call it "Morph" or "Morphic". This only leads to confusion down the road since it can't be loaded side-by-side with Morphic. Anything you do in a separate namespace won't be a problem - we've already agreed how to deal with the underlying basics so basically this is just another application on top of Cuis which can be run on top of Squeak :-)
>
>
> Mhhh! I think the name "Morphic 3" makes sense, as it all started after suggestions from John Maloney (in SqueakNews) and Dan Ingalls (in "Where is Squeak headed"). But I agree with your reasons too. So far, the name of the framework is "Morphic 3" and the root class is M3Morph (which I don't really like). Maybe I'd come up with a completely unrelated name. Perhaps "CuisGraphics" or something... Suggestions welcome!
>
> Cheers,
> Juan Vuletich
>
>
> Cheers,
> - Andreas
>
>
>
>

--
Ron

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Leandro Caniglia

Leandro wrote:

>
>
> Juan Vuletich wrote:
>> Mhhh! I think the name "Morphic 3" makes sense, as it all started
>> after suggestions from John Maloney (in SqueakNews) and Dan Ingalls
>> (in "Where is Squeak headed"). But I agree with your reasons too. So
>> far, the name of the framework is "Morphic 3" and the root class is
>> M3Morph (which I don't really like). Maybe I'd come up with a
>> completely unrelated name. Perhaps "CuisGraphics" or something...
>> Suggestions welcome!
>>
>> Cheers,
>> Juan Vuletich
>>
> What about Morphicuis, which would also stand for MorphicUIs? (Not
> sure I'm serious about this!)
>
> /Leandro
>

:)
I wonder how this would sound to people. I'm afraid it could be hard to
pronounce and spell...

Cheers,
Juan Vuletich

Juan Vuletich-4

Re: Re: Package unload status

In reply to this post by Karl Ramberg

Karl Ramberg wrote:

> On 2010-01-09 15:52, Leandro wrote:
>>
>>
>> Juan Vuletich wrote:
>>> Mhhh! I think the name "Morphic 3" makes sense, as it all started
>>> after suggestions from John Maloney (in SqueakNews) and Dan Ingalls
>>> (in "Where is Squeak headed"). But I agree with your reasons too. So
>>> far, the name of the framework is "Morphic 3" and the root class is
>>> M3Morph (which I don't really like). Maybe I'd come up with a
>>> completely unrelated name. Perhaps "CuisGraphics" or something...
>>> Suggestions welcome!
>>>
>>> Cheers,
>>> Juan Vuletich
>>>
>> What about Morphicuis, which would also stand for MorphicUIs? (Not
>> sure I'm serious about this!)
>>
>> /Leandro
>>
>>
> Or Cuistic ? Not that it's caustic or anything...
>
> Karl
>
>

What do others think?

Thanks,
Juan Vuletich

Igor Stasenko

Re: Re: Package unload status

>
> What do others think?
>

SmallMorphic

with accent on small. We really need something smaller than current morphic :)

> Thanks,
> Juan Vuletich
>
>

--
Best regards,
Igor Stasenko AKA sig.

Bert Freudenberg

Re: Re: Package unload status

On 10.01.2010, at 22:33, Igor Stasenko wrote:
>
>>
>> What do others think?
>>
>
> SmallMorphic
>
> with accent on small. We really need something smaller than current morphic :)

Microphic?

(Lessphic and Leastphic are already taken by VPRI's STEPS project ...)

- Bert -

Ken G. Brown

Re: Re: Package unload status

At 11:28 PM +0100 1/10/10, Bert Freudenberg apparently wrote:

>On 10.01.2010, at 22:33, Igor Stasenko wrote:
>>
>>>
>>> What do others think?
>>>
>>
>> SmallMorphic
>>
>> with accent on small. We really need something smaller than current morphic :)
>
>Microphic?
>
>(Lessphic and Leastphic are already taken by VPRI's STEPS project ...)
>
>- Bert -

<orphic? Orphic? Orfic? Morphicus? Lorphic? Norphic?

Ken G. Brown

Michael Haupt-3

Re: Re: Package unload status

Hi,

Am 10.01.2010 um 23:38 schrieb "Ken G. Brown" <[hidden email]>:

SmallMorphic ...

Microphic? ...

<orphic? Orphic? Orfic? Morphicus? Lorphic? Norphic?

Nophic, Leanphic ... I just realise I don't like the ...phic suffix.

"Gooey". :-)

Best,

Michael

Ken G. Brown

Re: Re: Package unload status

At 11:51 PM +0100 1/10/10, Michael Haupt apparently wrote:

>Hi,
>
>Am 10.01.2010 um 23:38 schrieb "Ken G. Brown" <<mailto:[hidden email]>[hidden email]>:
>
>>>>SmallMorphic ...
>>>>
>>>
>>>Microphic? ...
>>>
>>
>><orphic? Orphic? Orfic? Morphicus? Lorphic? Norphic?
>>
>
>Nophic, Leanphic ... I just realise I don't like the ...phic suffix.
>
>"Gooey". :-)
>
>Best,
>
>Michael

I think it would be good to keep the link to Morphic within the name somehow to keep the history. Unless of course it is a totally different animal now.

Ken G. Brown

Tom Rushworth-3

Re: Re: Package unload status

On 2010-Jan-10, at 15:02, Ken G. Brown wrote:

> At 11:51 PM +0100 1/10/10, Michael Haupt apparently wrote:
>> Hi,
>>
>> Am 10.01.2010 um 23:38 schrieb "Ken G. Brown"
>> <<mailto:[hidden email]>[hidden email]>:
>>
>>>>> SmallMorphic ...
>>>>>
>>>>
>>>> Microphic? ...
>>>>
>>>
>>> <orphic? Orphic? Orfic? Morphicus? Lorphic? Norphic?
>>>
>>
>> Nophic, Leanphic ... I just realise I don't like the ...phic suffix.
>>
>> "Gooey". :-)
>>
>> Best,
>>
>> Michael
>
> I think it would be good to keep the link to Morphic within the name
> somehow to keep the history. Unless of course it is a totally
> different animal now.
>
> Ken G. Brown
>

So if you don't like "phic", toss it and keep the "Mor.."

Morphoid? Morphene? Morphet? Morphect?

--
Tom Rushworth

Michael Haupt-3

Re: Re: Package unload status

Hi,

On Mon, Jan 11, 2010 at 4:40 AM, Tom Rushworth <[hidden email]> wrote:
> So if you don't like "phic", toss it and keep the "Mor.."
>
> Morphoid? Morphene? Morphet? Morphect?

Morphium! Mordor! Moria! Morfs! Morgue!

Not entirely serious,

Michael

lagudu

Re: Re: Package unload status

Morphlet ?

arul

On Mon, Jan 11, 2010 at 1:29 PM, Michael Haupt <[hidden email]> wrote:

> Hi,
>
> On Mon, Jan 11, 2010 at 4:40 AM, Tom Rushworth <[hidden email]> wrote:
>> So if you don't like "phic", toss it and keep the "Mor.."
>>
>> Morphoid? Morphene? Morphet? Morphect?
>
> Morphium! Mordor! Moria! Morfs! Morgue!
>
> Not entirely serious,
>
> Michael
>
>

Ken G. Brown

Re: Re: Package unload status

In reply to this post by Tom Rushworth-3

At 7:40 PM -0800 1/10/10, Tom Rushworth apparently wrote:

>On 2010-Jan-10, at 15:02, Ken G. Brown wrote:
>
>>At 11:51 PM +0100 1/10/10, Michael Haupt apparently wrote:
>>>Hi,
>>>
>>>Am 10.01.2010 um 23:38 schrieb "Ken G. Brown" <<mailto:[hidden email]>[hidden email]>:
>>>
>>>>>>SmallMorphic ...
>>>>>>
>>>>>
>>>>>Microphic? ...
>>>>>
>>>>
>>>><orphic? Orphic? Orfic? Morphicus? Lorphic? Norphic?
>>>>
>>>
>>>Nophic, Leanphic ... I just realise I don't like the ...phic suffix.
>>>
>>>"Gooey". :-)
>>>
>>>Best,
>>>
>>>Michael
>>
>>I think it would be good to keep the link to Morphic within the name somehow to keep the history. Unless of course it is a totally different animal now.
>>
>>Ken G. Brown
>>
>
>So if you don't like "phic", toss it and keep the "Mor.."
>
>Morphoid? Morphene? Morphet? Morphect?
>
>--
>Tom Rushworth

Of course one would want to check to make sure the name isn't already in use somewhere. I just by chance noticed there already is a Morpheus out there:
<http://my.smithmicro.com/mac/photoanimation/index.html>

Ken G. Brown