[Cuis-dev] Porting from Pharo

Gerald Klix cuis.01 at klix.ch
Mon May 3 05:59:49 PDT 2021



On 2021-05-03 01:59, Rafael Ignacio Matías Sniechowski via Cuis-dev wrote:
>>
>> On 2021-05-02 19:45, Hilaire Fernandes via Cuis-dev wrote:
>>> Le 02/05/2021 à 13:49, Gerald Klix a écrit :
>>>> There is no use in not forking Pharo Code,
>>>> because you have to fork your code just to
>>>> be compatible between the different Pharo
>>>> versions.
>>>
>>> True, but the differences between one version of Pharo and the next one
>>> are not that important. Well it depends on the iteration. But it is true
>>> it always requires your code to be adjusted more or less importantly.
>> Right now I am under the impression, that the
>> differences between various versions of Pharo
>> are es big as the differences between Python 2.7
>> and Python 3.x. Ok it is Pharo 5.x, 6.x, 7.x. I
>> should have been warned, they take semantic
>> versioning seriously.
>>
> 
> Couldn't agree more. Unfortunately it seems that Pharo decided to take the
> same path as Squeak.
> Adding complexity, and frameworks over frameworks, Code base is giant, and
> the number of classes is massive.
> That's why I really love Cuis. I am determined to understand it, and  I
> have hope I will.
> Having a simple image, base, clean, with no more than 600 classes makes me
> feel comfortable.
> I have some code developed in Pharo 4 and 5 and no longer works in Pharo 8.
There's a real problem I have no solution for.
Goal 1:
Create an understandable platform, for research and experiments.
Goal 2:
Support your customer's code for longer periods
and over versions.
Goal 3:
Provide a platform for the usable and sometimes
really cool results of your customer's
experiments.

Even if you take the Cuis way, a simple core
with lots of extension packages, it sometimes
goes wrong:
I implemented a WriteBarriers package, Cuis has
a package named Immutability and both are incompatible. I did not push 
mine hard enough.

http://cuis-smalltalk.org/pipermail/cuis-dev_cuis-smalltalk.org/2019-February/004113.html

https://github.com/Cuis-Smalltalk/Cuis-Smalltalk-Dev/blob/master/Packages/System/Immutability.pck.st

https://hg.sr.ht/~cy-de-fect/HaverOnCuis/browse/haver/transactions/WriteBarrier.pck.st

Mine has some features, that I use in my transactions package:

https://hg.sr.ht/~cy-de-fect/HaverOnCuis/browse/haver/transactions/Transactions.pck.st

So at least Haver has to incompatible packages
for the same purpose.

Python has similar issues:
https://docs.python.org/3/library/getopt.html
https://docs.python.org/3/library/optparse.html
https://docs.python.org/3/library/argparse.html

> 
> 
> 
>>> In the other hand, porting DrGeo from Pharo to Cuis is a far more
>>> important challenge. The most important is the departure from Polymorph,
>>> developed by Gary Chamber for Squeak and adopted by Pharo. Then of
>>> course the motivation challenge in the port, which is to redo what was
>>> already done.
>> Ah yes, NIH is also one of Pharo's virtues.
>> We have Spec, Spec2, Bloc, Glamorous ... what
>> did I miss? Ah yes, Morphic!
>> (Stop ranting, Gerald!)
>>
>> If I look at this collection of screenshots:
>> https://www.flickr.com/photos/12018791@N06/sets/72157601659393251/
>>
>> Polymorph is an impressive piece of software.
>> I was not aware of it's existence.
>> Which features do you need for Dr.Geo?
>>
> 
> Pharo has great tools: Roassal, and a lot of features. But too much too
> soon and a lot of classes that are deprecated and are still there...
> I love Polymorph, it was really impressive. If I am not mistaken Pharo had
> it in the first versions...
Yes, after looking at Dr. Geo's code, it dawned to me, that Hilaire 
probably meant PolygonMorph,
at least there is a class in Dr.Geo named
DrGPolylineMorph derived form it.

I like Dr. Geo, it is easy to use, has
impressive examples and it's still Smalltalk
(and therefore it will never make it to Apple's
AppStore ... mumble, rant. swear).

Coming back to Polymorph, there are a lot of
cool ideas in it, like this overflow button thingy. For end user 
software this is a better solution than shortening the button
labels.


Just my 0.01€,

Gerald


More information about the Cuis-dev mailing list