May 2011 - Pharo-users - lists.pharo.org

Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173
by Mariano Martinez Peck May 2, 2011

May 2, 2011

On Wed, Apr 27, 2011 at 11:25 AM, Ted F.A. van Gaalen <tedvga(a)gmail.com>wrote: > Hi Marcus > As I wrote, I am thinking from the perspective > of an application developer, a typical pharo-user ? > imagine that I/we have hundreds of > apps written, will they run unchanged > say 5 years from now? > Probably not. We would like to improve the system and clean it. Unfortunately, sometimes there is no other way than loosing backward compatibility. What do you prefer? Pharo choose a better system. If you/companies do not even collaborate with updating your code (don't say even fixing bugs or submitting code) ...then don't expect anything from Pharo. Pharo is open-source, free and it is build in the free time. And I think Pharo is not the only one....out there most of the languages change a lot between versions, Python, blah. Cheers Mariano > > Regards > Ted > > On Wed, Apr 27, 2011 at 11:16 AM, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > > > > On Apr 27, 2011, at 10:59 AM, Ted F.A. van Gaalen wrote: > > > >> Good morning Mariano > >> > >> This is something I wrote to Adrian Lienhard, > >> when an image did not run, straight out of the box > >> so to speak, because of VM differences > >> Some thoughts about reliability, and, very important > >> IMHO, upward compatibility. > >> > >> Thanks & Regards > >> Ted > >> > >>>>> > >> ? > >> I did expect that, nota bene working with > >> the Seaside supplied one-click image and > >> the virtual machine supplied with it, > >> provided on the Seaside.st site itself, > >> that everything is (and remains) > >> 100% upward compatible, > >> no matter what VM is or will be used in the future. > > > > This is impossible and, in the end, not a good idea. > > > > We can not be compatible forever, was this would mean > > that we can not improve anything. > > > > e.g. imagine someone would fix the VM to be better. > > (e.g. a modern object format). > > > > Do you really request to then *not* do this change because > > this VM could not run old images? (and new images would > > not run on old VMs?). > > > > Do you want to have a Future or be compatible to the Past? > > > > Marcus > > > > > > -- > > Marcus Denker -- http://www.marcusdenker.de > > INRIA Lille -- Nord Europe. Team RMoD. > > > > > > > > -- Mariano http://marianopeck.wordpress.com

10 20

Re: [Pharo-users] Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173
by Marcus Denker May 2, 2011

May 2, 2011

On May 2, 2011, at 6:49 PM, Ted F.A. van Gaalen wrote: > > I might suggest. for instance: > - leave deprecated classes in. when ever possible! > if you can't, then rewrite them as a sort of emulation > encapsulation, thus a kind of shell, invoking your new > replacement class. We want a system that is understandable. Look at Squeak with Etoys. How can you do *anything* with that code base if you keep it 100% compatible? Look at Pharo. How do you think you can do anything of relevance in 2019 if you keep the system source level compatible to 100%? This is a running Museum! And a crappy one, even. Why do you select Pharo of 2011, why aren't we compatible to Smaltalk 80, the orginal one. Or Smallalk 76? 72? Why invent Smalltalk at all? Why not just be compatible to what was before? I would even argue that etoys got into the state that it is *exactly* because it was never refactored and cleaned up and pushed forward. The Projects that are parts-of-images kind of force etoys to be exactly what you want: binary compatible forever... that is why people didn't improve the one Button, but made their own Button, because "some project might use this class, I can not touch it". So maybe Squeak is the solution to your problem... I am 100% sure that Squeak in 2019 will be the same as it is now. But it will be 100% irrelevant, *because* it will be the same as it is now. (Or it will do what Pharo does, there is a reason for the light-house logo ;-) Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-users] Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173
by Marcus Denker May 2, 2011

May 2, 2011

On May 2, 2011, at 8:53 PM, Ted F.A. van Gaalen wrote: > Hi Marcus > Ok, that makes it certain that I really have > to move my packages to newer images > if I want to sustain through the years, > doesn't it? Or it would mean to change the meaning (or on some level: the implementation) of the concept of the Image... you could have something that is more a declarative specification of a frozen object graph. But without the low-level details, and then reconstruct the object graph of the image at startup. But, the VM that would allow that would *not* be able to run existing images of today. So I am actually not against what you want... I think that in 2019 we will actually have a system that can do exactly what you want. But the nirvana of a system that supports sofware evolution in a deep way can not be achieved with being compatible with what we have now. We need to change (and destructively improve) our system if we want to go there. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

Re: [Pharo-users] Backward compatibility [WAS] Re: [ANN] PharoDev-1.3-13173
by Marcus Denker May 2, 2011

May 2, 2011

On May 2, 2011, at 6:49 PM, Ted F.A. van Gaalen wrote: > Hi All instances of HumanBeing > > Then, another question remains: > > Will my image of 2011 still work correctly > on the VM of AD 2019 (the ones that than probably > run on Ubuntu 2019.10, Windows11 and AppleOS/X 2019)? > or the VM created for a newly emerged computer system? > If I can guarantee one thing, than it is this: the VM of 2019 (that I will use) will *not* be compatible to todays images. Because, this would mean this: 1) No 64bit. *Ever*. We would be 32 bit forever, even on your iPhone of 2019 with 128GB if RAM. 2) No better GC. *EVER*. 3) No support for good hashes. 4) No nothing. (multiple tag bits, immutatble objects...) 5) No support for more than one CPU, ever. ... this list is very long. And it would mean that we could never clean up the VM and simplify it. We would need to stay compatible to BitBlt from 1978 in 2018. Does that make sense? Do *you* want to maintain a backward compatible Balloon Pluging in 2015? Pharo is not relevant today. (I actually think it's not.). Now if we *require* to *never* change the VM, then this guarantees complete uselessness very soon. Do you really want to make any progress on the VM side impossible? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[COTDC] 57 - ColorMap
by laurent laffont May 2, 2011

May 2, 2011

Today: ColorMap Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest Laurent

1 0

become:
by info＠tomsik.cz May 2, 2011

May 2, 2011

I've heard that become: is considered to be magic and should be avoided and replaced by either AOP or proxies, I googled a little but I couldn't find anything more concrete. Does anybody have any link or opinion about that? I'd be glad to hear something more about it. Thx -- Tato zprÃ¡va byla vytvoÅena pÅevratnÃ½m poÅ¡tovnÃm klientem Opery: http://www.opera.com/mail/

7 13

An small "interactive art" project in Pharo, from a newbie
by Offray Vladimir Luna CÃ¡rdenas May 2, 2011

May 2, 2011

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, First thanks for Pharo. Is a really nice clean innovative environment I have just pointed it to some java teachers/users and they like the overall look and feel. Now some small context: I had taken a short seminar on interactive art. We have used vvvv[1] to make some small experiments and the idea was to use arduino with it, but being it windows only I though in exploring something easy to use and then I found Physical Etoys from Richo's team. [1] http://vvvv.org [2] http://tecnodacta.com.ar/gira/projects/physical-etoys/arduino/ We don't make any further work arduino, but the essence of the seminar was overlapping meanings to create new meanings. So my idea is to make some images appear and vanish slowly after a while and also put some microblogging flux of information. I started with etoys, but after seeing that the tile language will not give me the proper expressiveness to create this project I have "go down" to Smalltalk using Pharo. I'm a total newbie but I have found some ways to load images (using SketchMorph). Now I want to make them vanish slowly and also load the microblogging stream (from Twitter and Identica, containing an special hashtag). This is supposed to be a small week project but is taking longer. I have asked in the Squeakland and SqueakNewbies mailing list and I got an answer from the etoys perspective but is not what I need so any pointer to the proper documentation will be appreciated (hopefully on Sunday :-P) Meanwhile I will keep reading the Pharo by Example book trying to get the spirit of development process and waiting for your kindly help :), to hopefully get some prototype on Monday. Cheers, Offray -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNs4TsAAoJEGiex2828ICwbfMIALJlY2LqVCYA0s1wJReveeL5 SWNpnoGEnbwvnZIdn9x6IKkXnEBcd6XDOL09aZtcnSpOIABqsYD65vw5+O9FINnI 7WRQKmYag+0dlvifrJY5/eAlMuJ++5c90sqB2VuPxruD4Npkwcui3aVZUHLFHSIl Y+PdO8S2cw6+dObS4lLIy3YmhdNp14ZIsWDFZdKMpofaT1dsDt1gEXzDUz/HaPKA Ft0lFUsT6jHLUNE9Pd2O9XcjUeOwwZDHNyvm0Ij/wcJ+HEH9v5OsuXa1C0ayiQb6 0gQJhT8OjYgwRh1GfNKL+nCczUs/uetgZ4z0twY8GT6eCFrJbva516eoJ0UVutk= =Y2AY -----END PGP SIGNATURE-----

4 5