[Pharo-project] Squeak 4.x should adopt Pharo 1.0
Dear All, As far as I see it the only sensible way ahead for squeak 3.11 is to adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to begin a series of initiatives to promote compatibility with squeak pieces that pharo doesn't support. The previous squeak 3.11 vision accepted, and now rejected, by the squeak board was to develop a process that would allow squeak to harvest the contributions of all the other forks, or other major initiatives, and for significant contributions to be shared by all the forks. All of a sudden there was an "oh no pharo is ahead of us" panic that ensued last month as a result of new squeak-dev people that were not involved in, nor seemed aware of the goals of the 3.11 process. Within this process Pharo may simply be viewed as a research project carried out on behalf of the wider squeak community, that will be harvestable in good time. However now that this idea is no longer going to be developed, we need to limit the number of diverging active forks as much as possible, rather than creating new ones ("trunk" makes the problem worse not better). Once the output of "trunk" is released in whatever form we will then have yet another base image to manage code for, and I don't think that that is an acceptable outcome. When it comes to the elections next year, if there is anyone who would like to run on the "Squeak to adopt Pharo" ticket, then I will vote for them. best regards Keith p.p.s. Bob is not going to be released as open source, if you would like the ability to build your images daily, and run the test suites against your deliverables, then please do email me for licensing terms.
El lun, 10-08-2009 a las 21:07 +0100, Keith Hodges escribió:
Dear All,
As far as I see it the only sensible way ahead for squeak 3.11 is to adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to begin a series of initiatives to promote compatibility with squeak pieces that pharo doesn't support.
The previous squeak 3.11 vision accepted, and now rejected, by the squeak board was to develop a process that would allow squeak to harvest the contributions of all the other forks, or other major initiatives, and for significant contributions to be shared by all the forks.
All of a sudden there was an "oh no pharo is ahead of us" panic that ensued last month as a result of new squeak-dev people that were not involved in, nor seemed aware of the goals of the 3.11 process. Within this process Pharo may simply be viewed as a research project carried out on behalf of the wider squeak community, that will be harvestable in good time.
I don't agree with you on this point. Pharo has its own merits to exists and it didn't fork as a "research project" for the squeak community. As its web page states, its goal is: "to deliver a clean, innovative, open-source *Smalltalk*" emphasis mine. Not a clean Squeak. As the day pass the foundations grow stronger and itself gains more and more identity and independence. This, if nothing really big happens on Squeak, will attract more developers and new users. There is no date yet to deliver a new version of Squeak, and this, together with the Pharo 1.0 release, will be less energy to try to maintain code for several forks and several packages will choose to support the one with more *apparent* users. What I want to say is, there is, as each day pass, less homesick for the past and more joy for the future.
However now that this idea is no longer going to be developed, we need to limit the number of diverging active forks as much as possible, rather than creating new ones ("trunk" makes the problem worse not better).
This is a point that I have never accepted of your thesis. There is no way to put all the "forks" in the same process/mindshare/goals/repositories. It is impossible. Even if they do it just for upsetting people. This isn't going to happen. The forks, as the young people, want to be free, independents, of its parents. They don't want to be like their parents project but a little different. They WANT to be better (whatever this means to the fork) and independent. They want to learn their own lessons. If for accident they happen to be compatible good, but if not, well, as the Linux community can show, there can not be a single distro neither a single code base that runs in every distro. How they solved it, by assinging mainteiner of each package that tracks the upstream project and adapt it to the specific distro. Something like this will happen with squeak/pharo/cuis. The upstream developers will have its development platform but someone else will adapt it to other platforms.
Once the output of "trunk" is released in whatever form we will then have yet another base image to manage code for, and I don't think that that is an acceptable outcome.
When it comes to the elections next year, if there is anyone who would like to run on the "Squeak to adopt Pharo" ticket, then I will vote for them.
If this happen, then good for both of the communities. But until this happen, most new users will learn by the lists about pharo and when trying and comparing it to squeak, will make its choice. Some of them will stay with squeak, some of them will try again squeak when a new release is made and some of them will stay with pharo for ever. One (at least me) can't be jumping or using several smalltalk versions (the same way that I don't like to administer linux of several flavors, it add unnecessary complexity and work).
best regards
Keith
p.p.s. Bob is not going to be released as open source, if you would like the ability to build your images daily, and run the test suites against your deliverables, then please do email me for licensing terms.
This is really a sad thing to read. Of course it is your decision, bad for us as it sound as Bob was a very good piece of software. On the other side, this sounds also like a emotional response more than a rational one. But if the community can't use your code, well, like the BitKeeper on the Linux kernel code case, someone will have to think something. -- Miguel Cobá http://miguel.leugim.com.mx
good summary :) We started pharo because we could not move anymore. We will continue to pay attention to what they other forks are doing. Stef On Aug 10, 2009, at 11:10 PM, Miguel Enrique Cobá Martinez wrote:
El lun, 10-08-2009 a las 21:07 +0100, Keith Hodges escribió:
Dear All,
As far as I see it the only sensible way ahead for squeak 3.11 is to adopt Pharo 1.0 as the next base version of squeak (i.e. 4.0), and to begin a series of initiatives to promote compatibility with squeak pieces that pharo doesn't support.
The previous squeak 3.11 vision accepted, and now rejected, by the squeak board was to develop a process that would allow squeak to harvest the contributions of all the other forks, or other major initiatives, and for significant contributions to be shared by all the forks.
All of a sudden there was an "oh no pharo is ahead of us" panic that ensued last month as a result of new squeak-dev people that were not involved in, nor seemed aware of the goals of the 3.11 process. Within this process Pharo may simply be viewed as a research project carried out on behalf of the wider squeak community, that will be harvestable in good time.
I don't agree with you on this point. Pharo has its own merits to exists and it didn't fork as a "research project" for the squeak community. As its web page states, its goal is:
"to deliver a clean, innovative, open-source *Smalltalk*"
emphasis mine. Not a clean Squeak. As the day pass the foundations grow stronger and itself gains more and more identity and independence. This, if nothing really big happens on Squeak, will attract more developers and new users. There is no date yet to deliver a new version of Squeak, and this, together with the Pharo 1.0 release, will be less energy to try to maintain code for several forks and several packages will choose to support the one with more *apparent* users. What I want to say is, there is, as each day pass, less homesick for the past and more joy for the future.
However now that this idea is no longer going to be developed, we need to limit the number of diverging active forks as much as possible, rather than creating new ones ("trunk" makes the problem worse not better).
This is a point that I have never accepted of your thesis. There is no way to put all the "forks" in the same process/mindshare/goals/repositories. It is impossible. Even if they do it just for upsetting people. This isn't going to happen.
The forks, as the young people, want to be free, independents, of its parents. They don't want to be like their parents project but a little different. They WANT to be better (whatever this means to the fork) and independent. They want to learn their own lessons.
If for accident they happen to be compatible good, but if not, well, as the Linux community can show, there can not be a single distro neither a single code base that runs in every distro. How they solved it, by assinging mainteiner of each package that tracks the upstream project and adapt it to the specific distro. Something like this will happen with squeak/pharo/cuis. The upstream developers will have its development platform but someone else will adapt it to other platforms.
Once the output of "trunk" is released in whatever form we will then have yet another base image to manage code for, and I don't think that that is an acceptable outcome.
When it comes to the elections next year, if there is anyone who would like to run on the "Squeak to adopt Pharo" ticket, then I will vote for them.
If this happen, then good for both of the communities. But until this happen, most new users will learn by the lists about pharo and when trying and comparing it to squeak, will make its choice. Some of them will stay with squeak, some of them will try again squeak when a new release is made and some of them will stay with pharo for ever.
One (at least me) can't be jumping or using several smalltalk versions (the same way that I don't like to administer linux of several flavors, it add unnecessary complexity and work).
best regards
Keith
p.p.s. Bob is not going to be released as open source, if you would like the ability to build your images daily, and run the test suites against your deliverables, then please do email me for licensing terms.
This is really a sad thing to read. Of course it is your decision, bad for us as it sound as Bob was a very good piece of software. On the other side, this sounds also like a emotional response more than a rational one. But if the community can't use your code, well, like the BitKeeper on the Linux kernel code case, someone will have to think something.
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
good summary :) We started pharo because we could not move anymore. We will continue to pay attention to what they other forks are doing.
BTW, some of us Second LIfe types are starting to play with Pharo/Seaside and various little issues keep popping up. I'm a total Smalltalk noob, but when I can't work through an example from the Squeak by Example book, that suggests there's some interesting features that should be looked at... Lawson
BTW, some of us Second LIfe types are starting to play with Pharo/Seaside and various little issues keep popping up. I'm a total Smalltalk noob, but when I can't work through an example from the Squeak by Example book, that suggests there's some interesting features that should be looked at...
A new version of SBE named pharo by example is under preparation. Now do not hesitate to ask question even if you think that they look silly. Silly questions do not exist. Stef
Stéphane Ducasse wrote:
BTW, some of us Second LIfe types are starting to play with Pharo/Seaside and various little issues keep popping up. I'm a total Smalltalk noob, but when I can't work through an example from the Squeak by Example book, that suggests there's some interesting features that should be looked at...
A new version of SBE named pharo by example is under preparation. Now do not hesitate to ask question even if you think that they look silly. Silly questions do not exist.
Stef
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder. Says that is EVIL. I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason. L
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder.
Says that is EVIL.
Interesting bug. The problem comes from the deprecation of String>>asCharacter http://code.google.com/p/pharo/issues/detail?id=1062
I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason.
Apparently, a number of deprecations in String are problematic Try: 'abc' . 'd'. 'abcd' Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Alexandre Bergel wrote:
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder.
Says that is EVIL.
Interesting bug. The problem comes from the deprecation of String>>asCharacter
http://code.google.com/p/pharo/issues/detail?id=1062
I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason.
Apparently, a number of deprecations in String are problematic
Try: 'abc' . 'd'. 'abcd'
Alexandre
I get ByteString(SequenceableCollection)>>upTo: has been deprecated. Use #copyUpTo: Lawson
Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them. Stef On Aug 11, 2009, at 11:58 PM, Lawson English wrote:
Alexandre Bergel wrote:
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder.
Says that is EVIL.
Interesting bug. The problem comes from the deprecation of String>>asCharacter
http://code.google.com/p/pharo/issues/detail?id=1062
I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason.
Apparently, a number of deprecations in String are problematic
Try: 'abc' . 'd'. 'abcd'
Alexandre
I get ByteString(SequenceableCollection)>>upTo: has been deprecated. Use #copyUpTo:
Lawson
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Stéphane Ducasse wrote:
Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them.
Stef
Pharo0.1 Latest update: #10343 will try running updater. Likely that I downloaded a pristine copy and started using it without updating first. Lawson
Oops that old. I suggest you to download a more recent version Mine is already old :) Let us know if you still have problem. It may be one package loaded in the pharo (non core) that is doing something fishy. Stef On Aug 12, 2009, at 12:10 AM, Lawson English wrote:
Stéphane Ducasse wrote:
Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them.
Stef
Pharo0.1 Latest update: #10343
will try running updater. Likely that I downloaded a pristine copy and started using it without updating first.
Lawson
Doing an update. This is the version found in teh one-click installer package at: http://www.seaside.st/download/squeak Stéphane Ducasse wrote:
Oops that old. I suggest you to download a more recent version Mine is already old :) Let us know if you still have problem. It may be one package loaded in the pharo (non core) that is doing something fishy.
Stef
Pharo1.0beta latest update: #10413. BTW: it's not possible to copy text from the About this System Dialog... Em 11/08/2009 19:05, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them. Stef On Aug 11, 2009, at 11:58 PM, Lawson English wrote: > Alexandre Bergel wrote: >>> Great to hear. However, pharo gets upset by putting 'eureka'. >>> 'EUREKA' >>> into the method finder. >>> >>> Says that is EVIL. >>> >> >> Interesting bug. The problem comes from the deprecation of >> String>>asCharacter >> >> http://code.google.com/p/pharo/issues/detail?id=1062 >> >> >>> I gotta assume that that is just a simple bug, right, or is that >>> facility no longer to be supported for some reason. >>> >> >> Apparently, a number of deprecations in String are problematic >> >> Try: 'abc' . 'd'. 'abcd' >> >> Alexandre >> > > > I get ByteString(SequenceableCollection)>>upTo: has been > deprecated. > Use #copyUpTo: > > > Lawson > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Tue, Aug 11, 2009 at 9:10 PM, <csrabak@bol.com.br> wrote:
Pharo1.0beta latest update: #10413.
BTW: it's not possible to copy text from the About this System Dialog...
Here in Linux works using ctrl + c not only to a workspace (inside image) but also to an external program.
Em 11/08/2009 19:05, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu:
Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them.
Stef
On Aug 11, 2009, at 11:58 PM, Lawson English wrote:
> Alexandre Bergel wrote: >>> Great to hear. However, pharo gets upset by putting 'eureka'. >>> 'EUREKA' >>> into the method finder. >>> >>> Says that is EVIL. >>> >> >> Interesting bug. The problem comes from the deprecation of >> String>>asCharacter >> >> http://code.google.com/p/pharo/issues/detail?id=1062 >> <http://code.google.com/p/pharo/issues/detail?id=1062%0A>>>; >> >>> I gotta assume that that is just a simple bug, right, or is that >>> facility no longer to be supported for some reason. >>> >> >> Apparently, a number of deprecations in String are problematic >> >> Try: 'abc' . 'd'. 'abcd' >> >> Alexandre >> > > > I get ByteString(SequenceableCollection)>>upTo: has been > deprecated. > Use #copyUpTo: > > > Lawson > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Mariano what do you mean that you cannot copy?
Pharo1.0beta latest update: #10413.
BTW: it's not possible to copy text from the About this System Dialog...
Here in Linux works using ctrl + c not only to a workspace (inside image) but also to an external program.
Em 11/08/2009 19:05, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu:
Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them.
Stef
On Wed, Aug 12, 2009 at 6:28 AM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Mariano what do you mean that you cannot copy?
Someone said that he couldn't copy and I just said that here in Linux I can perfectly copy and paste :)
Pharo1.0beta latest update: #10413.
BTW: it's not possible to copy text from the About this System Dialog...
Here in Linux works using ctrl + c not only to a workspace (inside image) but also to an external program.
Em 11/08/2009 19:05, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu:
Which image are you using? Because on mine = core 10371 deprecatedWarning = on I do not get them.
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Aug 11, 2009, at 11:35 PM, Alexandre Bergel wrote:
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder.
Says that is EVIL.
Interesting bug. The problem comes from the deprecation of String>>asCharacter
http://code.google.com/p/pharo/issues/detail?id=1062
I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason.
Apparently, a number of deprecations in String are problematic
Try: 'abc' . 'd'. 'abcd'
I get 'abc' , 'd' first -->'abcd' with 10371 and deprecation on.
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 12 Aug 2009, at 00:06, Stéphane Ducasse wrote:
Apparently, a number of deprecations in String are problematic
Try: 'abc' . 'd'. 'abcd'
I get 'abc' , 'd' first -->'abcd' with 10371 and deprecation on.
Alex's code works on 10431 Stef's code not (but it's consistent with VW and Squeak that way - you did mean to append a char to a string, did you?) ---------------------------- Johan Brichau johan.brichau@uclouvain.be
'eureka' . ' EUREKA' I get no single method.... On Aug 11, 2009, at 11:22 PM, Lawson English wrote:
Stéphane Ducasse wrote:
BTW, some of us Second LIfe types are starting to play with Pharo/Seaside and various little issues keep popping up. I'm a total Smalltalk noob, but when I can't work through an example from the Squeak by Example book, that suggests there's some interesting features that should be looked at...
A new version of SBE named pharo by example is under preparation. Now do not hesitate to ask question even if you think that they look silly. Silly questions do not exist.
Stef
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder.
Says that is EVIL.
I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason.
L
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
If you proceed when getting evil and afterwards the warning that the method shouldn't be used don't you get String>>asUppercase? Em 11/08/2009 19:03, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu: 'eureka' . ' EUREKA' I get no single method.... On Aug 11, 2009, at 11:22 PM, Lawson English wrote: > Stéphane Ducasse wrote: >>> BTW, some of us Second LIfe types are starting to play with >>> Pharo/Seaside and various little issues keep popping up. I'm a total >>> Smalltalk >>> noob, but when I can't work through an example from the Squeak by >>> Example book, that suggests there's some interesting features that >>> should >>> be looked at... >>> >> >> A new version of SBE named pharo by example is under preparation. >> Now do not hesitate to ask question even if you think that they look >> silly. >> Silly questions do not exist. >> >> Stef >> >> > > Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' > into the method finder. > > Says that is EVIL. > > > I gotta assume that that is just a simple bug, right, or is that > facility no longer to be supported for some reason. > > > L > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
strange yesterday it said that there is no method and now find asUppercase..... Apparently stringVersion in MethodReference is broken. Stef On Aug 12, 2009, at 2:07 AM, csrabak@bol.com.br wrote:
If you proceed when getting evil and afterwards the warning that the method shouldn't be used don't you get String>>asUppercase?
Em 11/08/2009 19:03, Stéphane Ducasse < stephane.ducasse@inria.fr > escreveu:
'eureka' . ' EUREKA'
I get no single method....
On a 1.0betaCore-10401, I have the evil error.
'eureka' . ' EUREKA'
I get no single method....
If I proceed, I also have no single method. There is something broken since: 'eureka' asUppercase =>'EUREKA' Apparently, MethodFinder does not find it in the last version. In a 10343, MethodFinder raises the evil error, but finds #asUppercase Alexandre
On Aug 11, 2009, at 11:22 PM, Lawson English wrote:
Stéphane Ducasse wrote:
BTW, some of us Second LIfe types are starting to play with Pharo/Seaside and various little issues keep popping up. I'm a total Smalltalk noob, but when I can't work through an example from the Squeak by Example book, that suggests there's some interesting features that should be looked at...
A new version of SBE named pharo by example is under preparation. Now do not hesitate to ask question even if you think that they look silly. Silly questions do not exist.
Stef
Great to hear. However, pharo gets upset by putting 'eureka'. 'EUREKA' into the method finder.
Says that is EVIL.
I gotta assume that that is just a simple bug, right, or is that facility no longer to be supported for some reason.
L
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
participants (8)
-
Alexandre Bergel -
csrabak＠bol.com.br -
Johan Brichau -
Keith Hodges -
Lawson English -
Mariano Martinez Peck -
Miguel Enrique Cobá Martinez -
Stéphane Ducasse