[ANN] PharoDev-1.3-13173
Locked
12
12
[ANN] PharoDev-1.3-13173
 
|
Hi. IMPORTANT: This is not the final 1.3 release, it just one simple snapshot and one point. We all want a rock-solid Pharo 1.3 release, but that doesn't happens automagically. We all need to start using and testing the image before they are release. It is for the better of all of us. The more we test the more stable will be the release. So...we need your help. What you can do?
1) test test test test test. Use it. Take this image and use it for your regular work. 2) report bugs: http://www.pharo-project.org/community/issue-tracking 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute 4) Fix errors/failures tests 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is released and then ask "uuhh what happened to XXX? you removed? ohhh but I use it". 6) Do you maintain Metacello configurations? ok, if you test your project and works correctly in Pharo 1.3, please update (or create if you don't yet have it) the #stable, 7) Do you maintain packages included in Pharo? please check we are using the correct versions 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, DBXTalk, Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog I recommend to download the last one from Eliot's page: http://www.mirandabanda.org/files/Cog/VM/ Two little warnings: - The Transcript is read only....and it will probably be roll backed to the previous one - if text editing looks weird....it is Lukas's fault ;) http://www.youtube.com/watch?v=fTMX1f8Lu5w Ok, the image is here: https://gforge.inria.fr/frs/download.php/28517/Pharo-1.3-13173.zip And it was build by Hudson: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ Best regards, -- Mariano http://marianopeck.wordpress.com |
|
|
Thanks, Mariano!
We will move the latest Moose development build to this Pharo version next week. Cheers, Doru On 27 Apr 2011, at 10:21, Mariano Martinez Peck wrote: > Hi. IMPORTANT: This is not the final 1.3 release, it just one simple snapshot and one point. We all want a rock-solid Pharo 1.3 release, but that doesn't happens automagically. We all need to start using and testing the image before they are release. It is for the better of all of us. The more we test the more stable will be the release. So...we need your help. What you can do? > > 1) test test test test test. Use it. Take this image and use it for your regular work. > 2) report bugs: http://www.pharo-project.org/community/issue-tracking > 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > 4) Fix errors/failures tests > 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is released and then ask "uuhh what happened to XXX? you removed? ohhh but I use it". > 6) Do you maintain Metacello configurations? ok, if you test your project and works correctly in Pharo 1.3, please update (or create if you don't yet have it) the #stable, > 7) Do you maintain packages included in Pharo? please check we are using the correct versions > 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, DBXTalk, Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > > Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog I recommend to download the last one from Eliot's page: http://www.mirandabanda.org/files/Cog/VM/ > > Two little warnings: > - The Transcript is read only....and it will probably be roll backed to the previous one > - if text editing looks weird....it is Lukas's fault ;) http://www.youtube.com/watch?v=fTMX1f8Lu5w > > Ok, the image is here: https://gforge.inria.fr/frs/download.php/28517/Pharo-1.3-13173.zip > > And it was build by Hudson: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ > > Best regards, > > -- > Mariano > http://marianopeck.wordpress.com > -- www.tudorgirba.com "Sometimes the best solution is not the best solution." |
|
|
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. So, that application builders are assured that the things they create will run unchanged for even years to come. In an industrial environment, this is vital. For example: on IBM mainframes. many Cobol or PL/1 programs/modules made more than 30 years ago run unchanged and without recompilation/linking. This is actually an industrial requirement, without it e.g. the complete IT environment of banks etc. would collapse. Even your bank account very probably relies on modules programmed way back in the seventies.. ( i won't mention the chaos with years of legacy code here, but this could also occur years later with Smalltalk apps) but back to image compatibility As a workaround, wouldn't it be a good idea: - if some shell script on the Seaside hosting site somehow scans/checks the image and start it with an appropriate VM either COG or another? or: provide a standard unchanged clean Seaside image in the file directory as default, so the only thing one has to do is to load Monticello package(s) into it? This is written from the somewhat traditional, industrial and pragmatic perspective of a typical application developer, who is not really involved in the more underlying system "details" :o) It would be almost a night mare in a large production environment if e.g. classes are removed where applications rely on. It would mean and unnecessary rewriting of a lot of code. Please observe: No pun or harsh negative criticism intended here, I do really appreciate what is currently going on with Smalltalk! I''ll copy this to Pharo-users, currently seen that Mariano is touching a bit similar things. On Wed, Apr 27, 2011 at 10:36 AM, Tudor Girba <[hidden email]> wrote: > Thanks, Mariano! > > We will move the latest Moose development build to this Pharo version next week. > > Cheers, > Doru > > > On 27 Apr 2011, at 10:21, Mariano Martinez Peck wrote: > >> Hi. IMPORTANT: This is not the final 1.3 release, it just one simple snapshot and one point. We all want a rock-solid Pharo 1.3 release, but that doesn't happens automagically. We all need to start using and testing the image before they are release. It is for the better of all of us. The more we test the more stable will be the release. So...we need your help. What you can do? >> >> 1) test test test test test. Use it. Take this image and use it for your regular work. >> 2) report bugs: http://www.pharo-project.org/community/issue-tracking >> 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute >> 4) Fix errors/failures tests >> 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 is released and then ask "uuhh what happened to XXX? you removed? ohhh but I use it". >> 6) Do you maintain Metacello configurations? ok, if you test your project and works correctly in Pharo 1.3, please update (or create if you don't yet have it) the #stable, >> 7) Do you maintain packages included in Pharo? please check we are using the correct versions >> 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, DBXTalk, Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. >> >> Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog I recommend to download the last one from Eliot's page: http://www.mirandabanda.org/files/Cog/VM/ >> >> Two little warnings: >> - The Transcript is read only....and it will probably be roll backed to the previous one >> - if text editing looks weird....it is Lukas's fault ;) http://www.youtube.com/watch?v=fTMX1f8Lu5w >> >> Ok, the image is here: https://gforge.inria.fr/frs/download.php/28517/Pharo-1.3-13173.zip >> >> And it was build by Hudson: https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ >> >> Best regards, >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > -- > www.tudorgirba.com > > "Sometimes the best solution is not the best solution." > > > |
|
|
In reply to this post by Tudor Girba
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. |
Re: [Pharo-project] [ANN] PharoDev-1.3-13173
|
|
In reply to this post by Tudor Girba
On Wed, Apr 27, 2011 at 10:36 AM, Tudor Girba <[hidden email]> wrote: Thanks, Mariano! Thanks Doru, Moose is always the best Pharo beta tester :) I don't know who do you expect to download Moose from Hudson, but be aware, as always that this image MIGHT be unstable, and that's exactly what you are trying to solve :) So...not only you, but everybody should now that. This is not perfect, it is just one milestone. Cheers, -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Marcus Denker-4
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? Regards Ted On Wed, Apr 27, 2011 at 11:16 AM, Marcus Denker <[hidden email]> 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. > > > |
Re: [ANN] PharoDev-1.3-13173
|
|
In reply to this post by TedVanGaalen
On Wed, Apr 27, 2011 at 10:59 AM, Ted F.A. van Gaalen <[hidden email]> wrote: Good morning Mariano Good morning Thanks & Regards Unfortunatly that's now of the the goals of Pharo. You have two real/practical ways: 1) don't make progress, stay in the museum (like stef says), and live happy with that. 2) Improve, make progress, and unfortunatly, make some incompatibility to the past. Pharo choose 2). Please, for further discussion, use another thread with a clear subject, not this one. So, that application builders are assured that Not necessary. Several mainstream languages changes a lot among different versions and people just update their code.
yes, maybe. Ask seaside people :) Pharo images can be used iwth both VMs
That's the problem. It is not "unnecessary". In fact, it IS necessary if you want to make progress, clean, improve, etc. Please observe: No pun or harsh negative criticism intended here, No problem, any feedback is welcome :) we can always discuss. I''ll copy this to Pharo-users, -- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Marcus Denker-4
On Apr 27, 2011, at 11:25 AM, Ted F.A. van Gaalen 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? Yes, using the old version of Pharo that you used when you implemented them. Like MacOS 9 programs run on MacOS 9. If you want to run your MacOS 9 Program on MacOSX, there is for a time an emulator, and for a time some source compatibility. But in the end, the only option is to port. There is no magic. You can select between -> Inventing the Future -> Be compatible to the Past at any cost. If what you have in the Past is valuable, selecting the second option makes sense. (IBM, Microsoft). If not, then it's idiotic. We will improve this a bit in the future, but this is research, so no promises. You can read some high-level talk abot it here, for example: http://scg.unibe.ch/archive/papers/Nier08aSelfAwareEternal.pdf Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. |
Re: [ANN] PharoDev-1.3-13173
|
On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker <[hidden email]> wrote:
[...] > Yes, using the old version of Pharo that you used when > you implemented them. > Like MacOS 9 programs run on MacOS 9. > > If you want to run your MacOS 9 Program on MacOSX, there > is for a time an emulator, and for a time some source compatibility. > But in the end, the only option is to port. > > There is no magic. > > You can select between > > -> Inventing the Future > -> Be compatible to the Past at any cost. > > If what you have in the Past is valuable, selecting the second option > makes sense. (IBM, Microsoft). If not, then it's idiotic. > > We will improve this a bit in the future, but this is research, so no promises. So, we mission-critical users should probably disregard the mission statement on the web page misleading: "... By providing a stable and small core system, excellent dev tools, and maintained releases, Pharo is an attractive platform to build and deploy mission critical Smalltalk applications." I'm sorry that I don't have time right at the moment to address this properly, because I do respect the efforts of the Pharo developers, I fully appreciate the challenges of a FOSS project, and I like some of the results I've seen (very nice developer UI features, movement towards announcements, the collaboractive book, and so on). I am interested, only, in offering constructive criticism, so please don't mistake my tone. The short version of my concern is this: As a "mission critical" user of Pharo, I will trade backward compatibility for improvement, if, as you say, you provide "maintained releases". Those last two words are the most important and incur a great burden of responsibility. I don't think the Pharo project has fully considered the responsibility of using those two words. The short version of my recommendation is this: Have a look at the FreeBSD release engineering process. They break backward compatibility all the time, but, if I have a mission critical application running on 4.5, I will still get essential bug and security fixes for a few years, and I can run trials with 8.0 on my other servers. Moreover, they have an updated documented roadmap that I can look at to determine that I should continue to run 4.5 on that one box while testing 8.0 on the others. Best regards, Mike |
|
|
In reply to this post by Marcus Denker-4
Hi Markus & Mariano
Thanks, will read the PDF later. Would like to contribute to this project later, when I am more proficient with Smalltalk and have things that might be useful. Have to think a lot about all this, before I get an identity crisis, therefore I am taking a "long" walk to Ravensburg (15 km) Always surrounded by many impressive DNA-based objects (Birds,Trees,Grass, Flowers) that also change at times, all by themselves. All the time in the world to do so, currently no job. Will no longer pollute this thread :o) Later Ted On Wed, Apr 27, 2011 at 11:47 AM, Marcus Denker <[hidden email]> wrote: > > On Apr 27, 2011, at 11:25 AM, Ted F.A. van Gaalen 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? > > Yes, using the old version of Pharo that you used when > you implemented them. > Like MacOS 9 programs run on MacOS 9. > > If you want to run your MacOS 9 Program on MacOSX, there > is for a time an emulator, and for a time some source compatibility. > But in the end, the only option is to port. > > There is no magic. > > You can select between > > -> Inventing the Future > -> Be compatible to the Past at any cost. > > If what you have in the Past is valuable, selecting the second option > makes sense. (IBM, Microsoft). If not, then it's idiotic. > > We will improve this a bit in the future, but this is research, so no promises. > You can read some high-level talk abot it here, for example: > > http://scg.unibe.ch/archive/papers/Nier08aSelfAwareEternal.pdf > > Marcus > > > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > |
Re: [ANN] PharoDev-1.3-13173
|
|
In reply to this post by Michael J. Forster
On Wed, Apr 27, 2011 at 1:10 PM, Michael Forster <[hidden email]> wrote: On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker <[hidden email]> wrote: It doesn't say anything about backward compatibility. As marcus said, we want a stable system. That means it is stable. Few bugs, robust, etc. If you use that system for the next 5 years, it will continue to be stable. You understood stable in the sense that it won't change among releases? if so, yes, the text is misleading and we need to fix it. I'm sorry that I don't have time right at the moment to address this Please, go ahead. And don't mistake my tone neither. I am just nicely discussing :)
We did Pharo 1.1.1 and we are planning Pharo 1.2.2. And they are "maintained releases". Of course, don't expect now for example, a maintained release in Pharo 1.0. At least not from me. This is open-source. Nobody pays. Resources are limited. So...if you need something in Pharo.1.0 NOW, you take the image and you integrate the fix by yourself. Or you can kindly ask. Crucial bugs are always included and integrated.
how many developers are working in FreeBSD? how much money they receive? It is not that we do this because we want. Resources are limited and we need to use where we think they are used better. They break backward If people ask us, we are not going to do a new release for Pharo 1.0. However, if someone comes and say, "hey, please, can you consider create a Pharo 1.0.XX with the fixed issues A B C F R". Sure we can do it. What you should not expect is: - new developments to be included in old version - non critical bugs to be included in old versions - that you won't have to change anything in your apps in order to upgrade to a new pharo version Moreover, they have an updated documented roadmap that We don't need to exaggerate. Pharo position about this topic was from the VERY beginning. In fact, it was created just because of that. Now...it is already like 3 years and 3 big releases. I am not aware of someone who needs to migrate and couldn't. So...it is working fine for the moment.
-- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Mariano Martinez Peck
Thanks for the initiative Mariano!
Some things I have seen in the few minutes I have used it: - The zip includes the __MACOSX folder on the same level that the uncompressed Pharo-1.3-13173 - The browser is way to small I think. Most names aren't shown complete. The user has to resize it almost every time to be useful. - The System -> Update is activated. Is this correct for Pharo (not PharoCore) images? Currently testing the ConfigurationOfMagma in it. If something shows up I will report it also. Cheers El mié, 27-04-2011 a las 10:21 +0200, Mariano Martinez Peck escribió: > Hi. IMPORTANT: This is not the final 1.3 release, it just one simple > snapshot and one point. We all want a rock-solid Pharo 1.3 release, > but that doesn't happens automagically. We all need to start using and > testing the image before they are release. It is for the better of all > of us. The more we test the more stable will be the release. So...we > need your help. What you can do? > > 1) test test test test test. Use it. Take this image and use it for > your regular work. > 2) report bugs: http://www.pharo-project.org/community/issue-tracking > 3) propose fixes: http://code.google.com/p/pharo/wiki/HowToContribute > 4) Fix errors/failures tests > 5) Load your OWN packages and projects now. Don't wait until Pharo1.3 > is released and then ask "uuhh what happened to XXX? you removed? ohhh > but I use it". > 6) Do you maintain Metacello configurations? ok, if you test your > project and works correctly in Pharo 1.3, please update (or create if > you don't yet have it) the #stable, > 7) Do you maintain packages included in Pharo? please check we are > using the correct versions > 8) I would like to see people testing AidaWeb, Magma, Fuel, Moose, > DBXTalk, Seaside and all its friends, Zinc, FileSystem, etc, etc, etc. > > Pharo-1.3-13173 should work with Interpreter VM and with Cog. For Cog > I recommend to download the last one from Eliot's page: > http://www.mirandabanda.org/files/Cog/VM/ > > Two little warnings: > - The Transcript is read only....and it will probably be roll backed > to the previous one > - if text editing looks weird....it is Lukas's fault ;) > http://www.youtube.com/watch?v=fTMX1f8Lu5w > > Ok, the image is here: > https://gforge.inria.fr/frs/download.php/28517/Pharo-1.3-13173.zip > > And it was build by Hudson: > https://pharo-ic.lille.inria.fr/hudson/view/Pharo/job/Pharo%201.3/111/ > > Best regards, > > -- > Mariano > http://marianopeck.wordpress.com > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Re: [ANN] PharoDev-1.3-13173
|
|
On Wed, Apr 27, 2011 at 5:32 PM, Miguel Cobá <[hidden email]> wrote: Thanks for the initiative Mariano! uhh yes, I zip it ;) For official/hudson image I think that doesn't happens. - The browser is way to small I think. Most names aren't shown complete. The browser resizes automatically to the size of the OS windows. If the main windows is bigger, then the default size is bigger. - The System -> Update is activated. Is this correct for Pharo (not mmmm no :) Thanks for reporting, can you open a ticket ? Currently testing the ConfigurationOfMagma in it. If something shows up cool, thanks!
-- Mariano http://marianopeck.wordpress.com |
|
|
In reply to this post by Mariano Martinez Peck
+1
El mié, 27-04-2011 a las 13:27 +0200, Mariano Martinez Peck escribió: > > > On Wed, Apr 27, 2011 at 1:10 PM, Michael Forster <[hidden email]> > wrote: > On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker > <[hidden email]> wrote: > [...] > > Yes, using the old version of Pharo that you used when > > you implemented them. > > Like MacOS 9 programs run on MacOS 9. > > > > If you want to run your MacOS 9 Program on MacOSX, there > > is for a time an emulator, and for a time some source > compatibility. > > But in the end, the only option is to port. > > > > There is no magic. > > > > You can select between > > > > -> Inventing the Future > > -> Be compatible to the Past at any cost. > > > > If what you have in the Past is valuable, selecting the > second option > > makes sense. (IBM, Microsoft). If not, then it's idiotic. > > > > We will improve this a bit in the future, but this is > research, so no promises. > > > > So, we mission-critical users should probably disregard the > mission > statement on the web page misleading: > > "... By providing a stable and small core system, excellent > dev > tools, and maintained releases, Pharo is an attractive > platform > to build and deploy mission critical Smalltalk > applications." > > > It doesn't say anything about backward compatibility. > As marcus said, we want a stable system. That means it is stable. Few > bugs, robust, etc. If you use that system for the next 5 years, it > will continue to be stable. > You understood stable in the sense that it won't change among > releases? if so, yes, the text is misleading and we need to fix it. > > I'm sorry that I don't have time right at the moment to > address this > properly, because I do respect the efforts of the Pharo > developers, I > fully appreciate the challenges of a FOSS project, and I like > some of > the results I've seen (very nice developer UI features, > movement > towards announcements, the collaboractive book, and so on). I > am > interested, only, in offering constructive criticism, so > please don't > mistake my tone. > > Please, go ahead. And don't mistake my tone neither. I am just nicely > discussing :) > > > The short version of my concern is this: As a "mission > critical" user > of Pharo, I will trade backward compatibility for improvement, > if, as > you say, you provide "maintained releases". Those last two > words are > the most important and incur a great burden of > responsibility. I > don't think the Pharo project has fully considered the > responsibility > of using those two words. > > We did Pharo 1.1.1 and we are planning Pharo 1.2.2. And they are > "maintained releases". Of course, don't expect now for example, a > maintained release in Pharo 1.0. > At least not from me. This is open-source. Nobody pays. Resources are > limited. So...if you need something in Pharo.1.0 NOW, you take the > image and you integrate the fix by yourself. > Or you can kindly ask. Crucial bugs are always included and > integrated. > > > The short version of my recommendation is this: Have a look > at the > FreeBSD release engineering process. > > how many developers are working in FreeBSD? how much money they > receive? > It is not that we do this because we want. Resources are limited and > we need to use where we think they are used better. > > They break backward > compatibility all the time, but, if I have a mission critical > application running on 4.5, I will still get essential bug and > security fixes for a few years, and I can run trials with 8.0 > on my > other servers. > > If people ask us, we are not going to do a new release for Pharo 1.0. > However, if someone comes and say, "hey, please, can you consider > create a Pharo 1.0.XX with the fixed issues A B C F R". > Sure we can do it. What you should not expect is: > > - new developments to be included in old version > - non critical bugs to be included in old versions > - that you won't have to change anything in your apps in order to > upgrade to a new pharo version > > Moreover, they have an updated documented roadmap that > I can look at to determine that I should continue to run 4.5 > on that > one box while testing 8.0 on the others. > > > We don't need to exaggerate. Pharo position about this topic was from > the VERY beginning. In fact, it was created just because of that. > Now...it is already like 3 years and 3 big releases. I am not aware > of someone who needs to migrate and couldn't. So...it is working fine > for the moment. > > > > > Best regards, > > Mike > > > > > -- > Mariano > http://marianopeck.wordpress.com > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
|
|
In reply to this post by Michael J. Forster
Aside from the bank examples, that I have never personally been involved
in any way, I have to see a system that can survive several years between versions without requiring some amount of patching/upgrading/care. Even big $$$ systems like Oracle RDBMS, MS SQL Server, big Unix/linux deployments require some amount of work in order to upgrade existing apps to new versions of them. Anyway if you have an app that is so important to be running flawlessly over the years and have no chance for failure then you have the $$$ to maintain it that way, either by you yourself patching the old version so that remains useful to you or by extensively testing the old app in the new version. That is something that banks have, that is sure. And that is something that any FOSS project almost never have. Even Red Hat (with corporate $$$) or linux kernel (with tons of developers paid and pro-bono) can't. They sometime have to let behind some release and concentrate effort in new versions and new users. Pay attention that most users doesn't need a 100% backwards compatible platform so there is no reason to slow down or stop improvement for the most in the name of the few. Not that is something personal to the few either. It just a practical issue. Cheers El mié, 27-04-2011 a las 06:10 -0500, Michael Forster escribió: > On Wed, Apr 27, 2011 at 4:47 AM, Marcus Denker <[hidden email]> wrote: > [...] > > Yes, using the old version of Pharo that you used when > > you implemented them. > > Like MacOS 9 programs run on MacOS 9. > > > > If you want to run your MacOS 9 Program on MacOSX, there > > is for a time an emulator, and for a time some source compatibility. > > But in the end, the only option is to port. > > > > There is no magic. > > > > You can select between > > > > -> Inventing the Future > > -> Be compatible to the Past at any cost. > > > > If what you have in the Past is valuable, selecting the second option > > makes sense. (IBM, Microsoft). If not, then it's idiotic. > > > > We will improve this a bit in the future, but this is research, so no promises. > > > So, we mission-critical users should probably disregard the mission > statement on the web page misleading: > > "... By providing a stable and small core system, excellent dev > tools, and maintained releases, Pharo is an attractive platform > to build and deploy mission critical Smalltalk applications." > > I'm sorry that I don't have time right at the moment to address this > properly, because I do respect the efforts of the Pharo developers, I > fully appreciate the challenges of a FOSS project, and I like some of > the results I've seen (very nice developer UI features, movement > towards announcements, the collaboractive book, and so on). I am > interested, only, in offering constructive criticism, so please don't > mistake my tone. > > The short version of my concern is this: As a "mission critical" user > of Pharo, I will trade backward compatibility for improvement, if, as > you say, you provide "maintained releases". Those last two words are > the most important and incur a great burden of responsibility. I > don't think the Pharo project has fully considered the responsibility > of using those two words. > > The short version of my recommendation is this: Have a look at the > FreeBSD release engineering process. They break backward > compatibility all the time, but, if I have a mission critical > application running on 4.5, I will still get essential bug and > security fixes for a few years, and I can run trials with 8.0 on my > other servers. Moreover, they have an updated documented roadmap that > I can look at to determine that I should continue to run 4.5 on that > one box while testing 8.0 on the others. > > > Best regards, > > Mike > -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
|
|
In reply to this post by Mariano Martinez Peck
El mié, 27-04-2011 a las 17:47 +0200, Mariano Martinez Peck escribió:
> > mmmm no :) Thanks for reporting, can you open a ticket ? > Done! http://code.google.com/p/pharo/issues/detail?id=4103 -- Miguel Cobá http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx |
Re: [ANN] PharoDev-1.3-13173
|
|
In reply to this post by Michael J. Forster
Mike and other
How many engineers are payed to deliver freeBSD? How many active committers and packages responsible are actively commiting and taking responsibility for packages? We need also stability but right now not changing is just been dead. I think that lot of people do not read the code of pharo else they would see why we are changing. We do not change for the fun. THIS IS NOT FUN TO write boring code to fix ugly situation. We would prefer to write hyper cool sexy app and be fancy to impress girls but this is not like that. Network is bad, compiler is bad, file is ugly.... Once this will be fixed then we will not change for the sake of it. Now comparing Smalltalk to cobol is silly (sorry but it is). Right we are fighting with python, ruby, javascript (in fact we are not fighting since we do not even exist in the radar). If we want to get a chance, we should move way faster and be really aggressive to make sure that you can write hyper cool application. Now why would you need to upgrade all the time to new versions if your system is working. Metacello and versioning systems are your friends: maintain difference streams and versions if you want to share between different versions. Stef |
|
|
Hi Stef
I was not really comparing on a language level Smalltalk and Cobol, but more about systems in general. Those legacy systems are around for many years: people have learned the hard way about compatibility, reliability etc. on the other hand, legacy is often a chaotic [some words removed] mess.. I have worked on programs modified over a period of 20 years by 10 or more programmers.. This is also no fun, on the contrary, often a nightmare. I did those ancient languages (Cobol Fortran, and more) for many years and still will do with these procedural languages, because I have to make a living. But don't worry: to me, it sometimes gives the same fun as e.g. a technician who likes working on old steam locomotives in a railway museum :o) The whole environment is however painstakingly difficult (not the language) and needs discipline. I could give you a sightseeing on a mainframe site, but it would make you weep :o) btw. May I introduce myself? look at my CV at : http://tedvg.seasidehosting.st/seaside/TGCVSite (very beta, my first Smalltalk/Seaside app. my picture is a bit formal even wearing a tie:o) I tried in the last 15 years or so to get work with more modern OOP systems e.g. Smalltalk, Java C#. even Delphi. mostly I dindn't succeed. I studied all of this intensively in my free time. I would (if I could) rather have written all these past software in Smalltalk.. Would have saved me a lot of headaches But back then systems were too slow, it was all "too academic" and Smalltalk had just being invented. In those years me, and many others too, had almost no notion of what object technology really is.. Now, today, I see my long existing dreams actually getting fulfilled! I can use Smalltalk because now it works and is fast enough too. I like it very much and hope to get work with it if get more proficient with it. Pharo looks good, is stable and a please to work with. I really hope Pharo / Smalltalk establishes itself, because it is clean, pure, fun and I can concentrate on fast application building instead of many nitty gritty language details. I am still a rookie on Smalltalk steroids, will contribute if I get better with it. Thanks all for all the work. Perhaps it is comforting to know that even people like me, coming from totally different IT fields believe in Smalltalk, maybe it is exactly because we can compare to what we already know. Ted Jikes! too much text. Too much time. I need to get a job soon. On Wed, Apr 27, 2011 at 7:42 PM, Stéphane Ducasse <[hidden email]> wrote: > Mike and other > > How many engineers are payed to deliver freeBSD? > How many active committers and packages responsible are actively commiting and taking > responsibility for packages? > > We need also stability but right now not changing is just been dead. > I think that lot of people do not read the code of pharo else they would see why we are > changing. We do not change for the fun. THIS IS NOT FUN TO write boring code > to fix ugly situation. We would prefer to write hyper cool sexy app and be fancy to > impress girls but this is not like that. Network is bad, compiler is bad, file is ugly.... > Once this will be fixed then we will not change for the sake of it. > > Now comparing Smalltalk to cobol is silly (sorry but it is). Right we are fighting > with python, ruby, javascript (in fact we are not fighting since we do not even exist in the radar). > If we want to get a chance, we should move way faster and be really aggressive to make sure > that you can write hyper cool application. > > Now why would you need to upgrade all the time to new versions if your system > is working. > > Metacello and versioning systems are your friends: maintain difference streams > and versions if you want to share between different versions. > > Stef > |
|
|
In reply to this post by Stéphane Ducasse
Stef,
I'm with you!! Keep hacking away at Pharo and make it the cleanest, nicest Smalltalk environment. Backwards compat talk this early in Pharo's life is premature. Besides, one of Smalltalk's best features is discovery and refactoring. This makes it much easier to migrate and rewrite when things break. Thanks for all your work!! I'm only "playing" with pharo these days but keep looking for U.S. clients where I can plug it in. ~Jon On 04/27/2011 01:42 PM, Stéphane Ducasse wrote: > Mike and other > > How many engineers are payed to deliver freeBSD? > How many active committers and packages responsible are actively commiting and taking > responsibility for packages? > > We need also stability but right now not changing is just been dead. > I think that lot of people do not read the code of pharo else they would see why we are > changing. We do not change for the fun. THIS IS NOT FUN TO write boring code > to fix ugly situation. We would prefer to write hyper cool sexy app and be fancy to > impress girls but this is not like that. Network is bad, compiler is bad, file is ugly.... > Once this will be fixed then we will not change for the sake of it. > > Now comparing Smalltalk to cobol is silly (sorry but it is). Right we are fighting > with python, ruby, javascript (in fact we are not fighting since we do not even exist in the radar). > If we want to get a chance, we should move way faster and be really aggressive to make sure > that you can write hyper cool application. > > Now why would you need to upgrade all the time to new versions if your system > is working. > > Metacello and versioning systems are your friends: maintain difference streams > and versions if you want to share between different versions. > > Stef |
|
|
Em 27-04-2011 18:41, Jon Hancock escreveu:
> Stef, > I'm with you!! Keep hacking away at Pharo and make it the cleanest, > nicest Smalltalk environment. Backwards compat talk this early in > Pharo's life is premature. Besides, one of Smalltalk's best features > is discovery and refactoring. This makes it much easier to migrate > and rewrite when things break. > > Thanks for all your work!! I'm only "playing" with pharo these days > but keep looking for U.S. clients where I can plug it in. > ~Jon Backwards compatibility would make sense only if there were widespread use applications. Except for seaside I cannot mention (I'm not being rude, neither willing to hurt feelings) other pharo/squeak artifact that's used in a scale enough to demand back compat. Small scale applications or stand alone solutions don't require updates/upgrades. I agree with Stef & others: the important thing at the moment is having a platform. Pharo isn't it yet. At current pace it will be soon. When it happens and people see the value to deliver mass solutions, then a requirement for back compat will appear. It's interesting but many complaints about compatibility are done regarding to packages that aren't even maintained anymore. And that happens in part because of platform deficiencies pointed by Stef. My 0,99c here... CdAB |
«
Return to Pharo Smalltalk Users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |