I have the blame of it. I am who send emails to both list. So...this is my fault. Sorry about it. The main problem I have is that when I have questions, suggestions, ideas or whatever, I really don't know where to post it: if in squeak-dev or pharo. I really don't know If what I want to say depends on the VM, or the image or to packages that are shared between both of them. In addition, I think there are important people that are only in one of the list. So, perhaps I miss an answer If I only send emails in one list. And probably, the same discussion could be useful for both lists. What you think I should do ? which would be the better way so that not to cause the problem mentioned above? I am following Pharo very near because this really interest me. I really want to LIVE AND EAT using an open source smalltalk. I don't want smalltalk to play. I want to WORK with it. So, I think Pharo is the better approach for my intention. But, 90% the time I spend in Squeak is for SqueakDBX. And SqueakDBX doesn't work well in pharo. I have random segmentation faults trough FFI which I don't have in Squeak. I didn't want to spend many time trying to see what the problem is till 1.0 is releases. At that moment, I will look for the problem. When this is fixed, I will then really start using pharo 100%. Cheers, Mariano On Sun, Mar 1, 2009 at 7:46 PM, Sebastian Sastre <ssastre@seaswork.com>wrote:

Hi Stephane, I would not take it that seriously. Just focus that good energy you have and use it in getting things done in pharo and adding real value to it. Much it will receiver in return I'm sure of that. best, sebastian

...

-----Mensaje original----- De: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] En nombre de Stephane Ducasse Enviado el: Sunday, March 01, 2009 18:29 Para: Pharo Development Asunto: [Pharo-project] A point a.k.a excuse to you

Hi guys

I probably should not have forwarded to you the email I replied to matthew but I was thinking that other people can know that I was personally touched by the situation in Squeak. I'm sorry about.

We got a lot of bird names and others. Recently somebody was implying that marcus was bashing squeak because he sent an email on the pharo mailing-list stating that the situation for keyboard was worse in squeak. I'm fed up. I'm interested in pharo because I want to create free and good energy. We did a lot in the past and I want to continue. Now I unregistered from the squeak mailing-list and I will not justify anymore why I quit. Now I want pharo to be cool.

Stef

_______________________________________________ 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

...

I have random segmentation faults trough FFI which I don't have in Squeak. I didn't want to spend many time trying to see what the problem is till 1.0 is releases. At that moment, I will look for the problem. When this is fixed, I will then really start using pharo 100%.

Sure. Can you report your problem on FFI :) and add a bug report on pharo

I have being doing some tests with SqueakDBX and now It seems to work perfect. cheers, Mariano

On Sun, Mar 01, 2009 at 11:12:23PM -0500, Matthew Fulmer wrote:

I know this is deep stuff, but I believe an automated image builder will have several advantages, both for you, as Pharo developers, and for me, as an enthusiast for cross-squeak compatibility: - making releases is faster - Regression bugs are caught faster - the scripts serve as poor-man's code sharing between squeak distributions until we have real package-level sharing of core code between core

That should have been "sharing of core code between squeak distributions" -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

...

Let me apologize on behalf of the squeak-dev community. Not all of us feel so harshly toward you, but I did not speak up enough to convince you of our appreciation. You deserve better, and I'm sorry we did not deliver it.

Don't worry. I did not react because of harsh statements. I reacted because I could send your email while I should not and this indicating me that I was influenced by my reading on squeak-dev (you see this was meta). We have been there and we know what it is.

...

Making Pharo the best it can be will be a win for everyone, even if some do not see it that way at the time.

I plan to work with Pharo soon, probably once summer starts and school is out, to get Keith's tools debugged and working in the context of Pharo, especially Monticello 1.6 (My patches to MC1.5 to enable real atomic loading (= no more problems upgrading Polymorph), and Bob (the automated image builder and regression tester).

I know this is deep stuff, but I believe an automated image builder will have several advantages, both for you, as Pharo developers, and for me, as an enthusiast for cross-squeak compatibility: - making releases is faster - Regression bugs are caught faster - the scripts serve as poor-man's code sharing between squeak distributions until we have real package-level sharing of core code between core

Yes we know. BTW matthew could you run SmallLint on Installer. I was thinking to do that and fix what I could. May be we could pair on this one.

You may or may not know, but I am a core Cobalt developer, and I hope to bring Pharo and Cobalt much closer together. These two projects are hosting many core changes to the image, with little regard to backward compatibility. We may even get tweak to the level where it is a compelling replacement for Morphic, and I want Pharo to benefit from that if it does indeed happen. Too many improvements to Squeak happen in the dark (Newspeak, Spoon), and we can ill afford to estrange the truly open projects from each other (Pharo and Cobalt, IMO).

Cobalt is the open version of Croquet? You are working with Julian? We would be happy to evaluate changes made in Cobalt and retrofit them into pharo. Now for Tweak this is another story.

...

Thanks for doing this!

Yes, thank you Stef and Marcus for rekindling the passion for Smalltalk in many people. With luck, squeak.org may be a free, open, and useful product again. Too long has it been stuck, with nobody to bring it forward. Pharo has done much to re-awaken the love of smalltalk in many people, and that, if nothing else, is a gift beyond measure. As Squeak.org release team leader, you have my goodwill and my support. I will do what I can to spread the gifts of your efforts to the rest of squeak, and bring their efforts to you.

-- Matthew Fulmer -- http://mtfulmer.wordpress.com/

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Mon, Mar 02, 2009 at 11:46:47AM +0000, Keith Hodges wrote:

...

I believe you are correct, but not everybody sees Pharo that way. Edgar and Keith in particular, sometimes see it as non-appreciation of their work, which is similar in spirit, but not as well managed.

Matthew,

My response to pharo is based upon the ironic situation.

I say for 3.11 "Lets promote a process to enable integration and sharing of the contributions of the community, accross the diverse range of images that we use" Pharo team says "Lets go off and do our own thing", and Edgar says the same. I find this totally ironic and sad, since you couldn't create more fragmentation of the main squeak protagonists if you tried.

Well, for one thing, our tools were not ready for mainstream use when Pharo/Sapphire was announced. From what I can tell, the tools are just now coming to that point. We cannot expect that everybody will stop what they are doing just to alpha-test our tools. If they do, great, but if not, don't be mellow over it.

Now of course the whole point of the tools we have been working on, for 3.11 Bob etc, is to allow diversification, so we should welcome all of pharos efforts and innovations, and any like it. You seem puzzled as to why I don't appreciate pharo.

Do you appreciate Pharo?

The problem arises when no-sharing is done of the fundamental components that make the sharing possible. For example SUnit needs to be a common piece. It has to be there is no option. So if you do a fork and within your fork you fork your own version of SUnit, you are snubbing the rest of the community, and any possibility of working with the rest of the community, either by ignorance or on purpose.

Not everything needs to be "for the community". If we insist that it be so, we lose developers due to restrictive policy. It is more important that those who are good at fixing code (Pharo) do so, and leave the "giving it back to the community" to those who really care about it, like you and me. Pharo is providing a valuable service as a test-bed for new ideas and things that are not backward compatible. We will be providing a service to bring more commonality to the community. Both are important, and neither should halt on behalf of the other.

This has to be a managed policy decision, from the top. It is precisely because the pharo project is not managed and planned with any such principles in mind, that I stress my point, and will continue to do so.

The lack of such concern is a good thing.

In reference to recent discussions about Preferences how am I going to write any common code between pharo and squeak, if the preferences api is different, between squeak and pharo? Note that the tools and preference system can be as different as you like, but the API has to be common at some level for any sharing to be possible. We either keep the same api we have, or design a new one, and provide a basic specification that can be implemented in both environments.

Or, put both in for a release or two, where the old is deprecated, then remove the old after a release or two.

What we cant accept is any proposals or discussion about such an important API without appreciating that it will be expected to support code that comes from both environments.

Such a restrictive policy is the best way to ensure that nothing will ever change, and that somebody will fork to get away from such management overhead.

The fact that 'Author' exists only as a global in the Pharo environment and prevents code which uses it from loading in squeak is all the proof I need that the pharo process needs a rethink.

It can be backported, or ported in full, if it is a win. Traits are a win, and we backported them to 3.8 for Monticello 1.5. I don't see why we can't do that again. We can provide the service of backporting good ideas to other distributions. It will be easier when Pharo adopts Bob to some degree, but nothing prevents us from doing it now. There is a reason that Linux distributions are made of packages that are not maintained by the original coders, and that is because distribution of packages takes time. If somebody is better at coding, they should code. If somebody is better at packaging, they should package. Specialization is a good thing; everybody is more productive in the end, and has more fun, because each one is adding value while doing what they love. Always have fun. If you have fun on Pharo, than do Pharo. If you have fun on tools, then do tools. There are enough people in the world that somebody will have fun working with both, and will bridge whatever gap has formed. I believe I am such a person. -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

Michael Roberts wrote:

Keith, your email implies that you believe Pharo should be backwards compatible at some level with Squeak. Part of the Pharo manifesto is not to be compatible. So if you want to write code or have apis that work in a backwards direction from Pharo to Squeak, that's great. I don't believe it's a goal for Pharo though. The pharo process doesn't need a rethink at all as far as I'm concerned.

thanks,

Mike

No that is not what I am saying at all. Perhaps examples would help. Take Rio. Rio was designed from ground up to be a replacement for a the present non-modular kernel facility FileDirectory. It is a discrete loadable module. Wild and horrible uses of FileDirectory are spread around the image in lots of places, so one thing that Rio tries to do is to anticipate use cases, so that the users of Rio dont have to implement File handling code in their stuff, and so we help to keep the module boundary clear. For example you can ask Rio to get you the next version of a file - 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in itself potentially lightens SmalltalkImage. If you want to read Xml files, you can subclass File, with FileXML, define the #validExtensions that it handles, and implement contents/contents: This means that your code only needs to send, 'myfile.xml' asFile contents, to get the model. There are all sorts of things like that. With Rio as a front end to File and Socket streams it is perfectly possible to innovate on them without users of Rio being any the wiser. If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it was Squeak streams Nile or Flow behind the scenes. 'http://www.google.com' asFile contents, now means that I dont have to care about whether HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or HTTPClient returning a MultiByteStream thingy in 3.8 or some other new facility. So, Rio demonstrates that it is possible to innovate, on a kernel module, and you dont need to break anything to do it. Secondly by thinking about APIs and module interface abstractions in this way, you can define specific interfaces and bottlenecks, that potentially turn the ball of tangled string into something designed and architected. There are perhaps hundreds of other modules that could use the same treatment. Rio loads into all squeak images I have tried it in, so this then means that any of my file handling code will work in all images. This benefit comes from managing Rio as module external to the main image. Rio also comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller images in mind. Having done this, the question of moving the kernel over to make use of the new code arises, this also can be achieved without breaking anything for users that have had Rio available for 2 years in every image that their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar, Magma, Etoys, can all migrate their file handling code to the new Rio API now, even if they are using Squeak 3.7/3.8, without having to upgrade to the latest squeak. When they do update, they will be pleased to find that their file handling code works, as well as their gzipping/archiving/remote file handling/and website accessing code. Installer follows the same principles, abstracting an api, freeing the backend to be either old code or new code. If you dont have Universes loaded, then defining Installer>>#universes to call #sake as a fall back would use Sake/Packages and get identical results, your users would be none the wiser. If you dont have SqueakMap loaded, then defining Installer>>#squeakmap to call #websqueakmap instead, would again give your users identical results. and you thought that Installer was just for loading things. Edgar has pointed out that you could use CodeLoader for that, but thats not the point of installer, Installer is providing a DSL for loading things that provides an architectural layer of isolation, and thus both inherrent forward and backward compatibility. I expect my image building scripts to work identically with Monticello2 in squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7. Scripter (who here even knows that Scripter exists?) does the same, if you want to write code to close or tile all the windows, after the installing process has left a mess. Scripter can be the interface to whatever backend GUI there happens to be whether it is ToolBuilder/Tweak/Morphic. Same again with Logging, is a front end abstraction to all of the three+ logging backends out there. I can remove the hardwired calls to Transcript that scatter the image and replace them with a single api to multiple backends, both past (Transcript) present (Syslog) and future (seaside per-user session logging framework). Oh, and again with Sake/Packages.... why does Sake/Packages define class tasks? You can write a task that depends upon a task which removes certain method selectors. You could just call Behaviour direct. Its another architectural layer, that frees up the back end to be old or new code as far as Sake task writers are concerned. I can write a task that says, "if you find this Class with a method categorised as so, then it needs to be recategorised as such", in such a way as this task would run in all images. Oh and again SystemEditor... another layer of abstraction for compiling and loading code atomically. So if you think about it, those who know about the compiler could be considering how to write their stuff, so that it logs to the Kernel Logging API (which is valid even if Logging isnt Loaded). They might consider connecting to SystemEditor in preference to providing a direct api, and another abstracted pluggable Module is needed to handle source code files (replacing RemoteString/ChangeSets etc), with Rio as the local/remote file API. Do you get the idea now? For the same treatment to be available for more significant chunks of squeak, we would need atomic loading to work. Now the code to provide atomic loading for everyone has been available for over a year, and it works if you dont use traits. So where is the expertise to really get it working for everyone with traits? The only difficulty with this approach is that you might need slightly different bits to make your NEW code load into older images. This problem is reasonably easily addressed with Installer-Scripts (LevelPlayingField+) and Sake/Packages. I fully agree with Matthew about core packages like Collections. BUT and this is the big but. If you are going to do that kind of thing, you need to think about it, plan it, and create and participate in a process that supports everyone is diverse images using and testing that package. From what I have seen there is only one person on the Pharo team that understands what LevelPlayingField is for, and how to use it. The biggest risk to this approach is if some other folks decide to fork some significant architectural component in a completely incompatible manner, without thinking about any bigger picture at all. Matthew's comment about how our tools are only just getting there isnt that relevant to the point that I am making. I didnt need a test and build server to innovate Rio for everyone rather than just for the image I am using (trouble was I was using 3 different images), all I needed was an inclusive attitude rather than an exclusive attitude. cheers Keith

I suggest making the socket as pluggable as possible, because I suspect we will see SSL sooner rather than later. Call it a hunch. Another thing that I would like to see is #readStream and #writeStream to lazily initialize appropriate streams on sockets. Dolphin has had that for a long time, and it works very nicely. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Monday, March 02, 2009 9:17 PM To: Pharo-project@lists.gforge.inria.fr; The general-purpose Squeak developers list Subject: Re: [Pharo-project] A point a.k.a excuse to you

build server to innovate Rio for everyone rather than just for the image I am using (trouble was I was using 3 different images), all I needed was an inclusive attitude rather than an exclusive attitude.

Dear All, I was trying to implement FileHttpExecutive in Rio today, I wanted to perform a GET, and have Rio informed of the File size as soon as the headers have been downloaded. As an alternative it would also be nice to be able to send a HEAD request prior to getting the whole file. I also want to read the stream as it is coming in, since Rio already can buffer ftp reads direct to a file, or other destination. About 5 minutes looking at the code showed me that this was pretty impossible. There was no clean way to subclass HTTPSocket and have it hold a handle on my file instance and report that information to me, since most of the business is performed on the class side (why do people do that?) My only option is probably to subclass HTTPSocket, inserting some Notifications in there, and use exception handlers to collect the data. So... would anyone out there be willing to rewrite HTTPSocket/Client from scratch so that it is well designed and so on from the ground up? Assuming that Socket will remain common between Squeak/Pharo etc, it could also provide an abstraction onto the Curl plugin as well. This new module would of course be for the benefit of all. Has anyone done/is anyone doing this already? thanks in advance Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Which, pluggable sockets or streams? -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Monday, March 02, 2009 9:47 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you Schwab,Wilhelm K wrote:

I suggest making the socket as pluggable as possible, because I suspect we will see SSL sooner rather than later. Call it a hunch. Another thing that I would like to see is #readStream and #writeStream to lazily initialize appropriate streams on sockets. Dolphin has had that for a long time, and it works very nicely.

Bill

what does that give you? Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Keith we understand your point. This is why I proposed to clean Installer and run SmallLint on it. and clean it again (no subclass references in superclass and other). Now did you said the same to Croquet, Sophie, Etoy people? why only to us? Then we have the right not to be happy with your infrastructural choices. Consider Pharo as insignificant and that squeak is the future. This way you do not have to blame us and we are happy. Stef On Mar 3, 2009, at 2:06 AM, Keith Hodges wrote:

Michael Roberts wrote:

...

Keith, your email implies that you believe Pharo should be backwards compatible at some level with Squeak. Part of the Pharo manifesto is not to be compatible. So if you want to write code or have apis that work in a backwards direction from Pharo to Squeak, that's great. I don't believe it's a goal for Pharo though. The pharo process doesn't need a rethink at all as far as I'm concerned.

thanks,

Mike

No that is not what I am saying at all. Perhaps examples would help.

Take Rio. Rio was designed from ground up to be a replacement for a the present non-modular kernel facility FileDirectory. It is a discrete loadable module.

Wild and horrible uses of FileDirectory are spread around the image in lots of places, so one thing that Rio tries to do is to anticipate use cases, so that the users of Rio dont have to implement File handling code in their stuff, and so we help to keep the module boundary clear. For example you can ask Rio to get you the next version of a file - 'myfile.2.txt' asFile nextVersion = 'myFile.3.txt. That facility in itself potentially lightens SmalltalkImage. If you want to read Xml files, you can subclass File, with FileXML, define the #validExtensions that it handles, and implement contents/contents: This means that your code only needs to send, 'myfile.xml' asFile contents, to get the model. There are all sorts of things like that.

With Rio as a front end to File and Socket streams it is perfectly possible to innovate on them without users of Rio being any the wiser. If I do 'myFile.3.txt' asFile contents, it wouldn't care whether it was Squeak streams Nile or Flow behind the scenes. 'http://www.google.com' asFile contents, now means that I dont have to care about whether HttpSocket is doing the work with a RWBinaryOrTextStream in 3.7 or HTTPClient returning a MultiByteStream thingy in 3.8 or some other new facility.

So, Rio demonstrates that it is possible to innovate, on a kernel module, and you dont need to break anything to do it. Secondly by thinking about APIs and module interface abstractions in this way, you can define specific interfaces and bottlenecks, that potentially turn the ball of tangled string into something designed and architected. There are perhaps hundreds of other modules that could use the same treatment.

Rio loads into all squeak images I have tried it in, so this then means that any of my file handling code will work in all images. This benefit comes from managing Rio as module external to the main image. Rio also comes in two sizes, a Rio-Kernel, and a Rio-Base, with smaller images in mind.

Having done this, the question of moving the kernel over to make use of the new code arises, this also can be achieved without breaking anything for users that have had Rio available for 2 years in every image that their code was running in. I.e. Sophie, Croquet, Seaside, Gjallar, Magma, Etoys, can all migrate their file handling code to the new Rio API now, even if they are using Squeak 3.7/3.8, without having to upgrade to the latest squeak. When they do update, they will be pleased to find that their file handling code works, as well as their gzipping/archiving/remote file handling/and website accessing code.

Installer follows the same principles, abstracting an api, freeing the backend to be either old code or new code. If you dont have Universes loaded, then defining Installer>>#universes to call #sake as a fall back would use Sake/Packages and get identical results, your users would be none the wiser. If you dont have SqueakMap loaded, then defining Installer>>#squeakmap to call #websqueakmap instead, would again give your users identical results. and you thought that Installer was just for loading things. Edgar has pointed out that you could use CodeLoader for that, but thats not the point of installer, Installer is providing a DSL for loading things that provides an architectural layer of isolation, and thus both inherrent forward and backward compatibility. I expect my image building scripts to work identically with Monticello2 in squeak 3.16 as they do now with Monticello 1.5 in Squeak 3.7.

Scripter (who here even knows that Scripter exists?) does the same, if you want to write code to close or tile all the windows, after the installing process has left a mess. Scripter can be the interface to whatever backend GUI there happens to be whether it is ToolBuilder/Tweak/Morphic.

Same again with Logging, is a front end abstraction to all of the three+ logging backends out there. I can remove the hardwired calls to Transcript that scatter the image and replace them with a single api to multiple backends, both past (Transcript) present (Syslog) and future (seaside per-user session logging framework).

Oh, and again with Sake/Packages.... why does Sake/Packages define class tasks? You can write a task that depends upon a task which removes certain method selectors. You could just call Behaviour direct. Its another architectural layer, that frees up the back end to be old or new code as far as Sake task writers are concerned. I can write a task that says, "if you find this Class with a method categorised as so, then it needs to be recategorised as such", in such a way as this task would run in all images.

Oh and again SystemEditor... another layer of abstraction for compiling and loading code atomically.

So if you think about it, those who know about the compiler could be considering how to write their stuff, so that it logs to the Kernel Logging API (which is valid even if Logging isnt Loaded). They might consider connecting to SystemEditor in preference to providing a direct api, and another abstracted pluggable Module is needed to handle source code files (replacing RemoteString/ChangeSets etc), with Rio as the local/remote file API.

Do you get the idea now?

For the same treatment to be available for more significant chunks of squeak, we would need atomic loading to work. Now the code to provide atomic loading for everyone has been available for over a year, and it works if you dont use traits. So where is the expertise to really get it working for everyone with traits?

The only difficulty with this approach is that you might need slightly different bits to make your NEW code load into older images. This problem is reasonably easily addressed with Installer-Scripts (LevelPlayingField+) and Sake/Packages.

I fully agree with Matthew about core packages like Collections. BUT and this is the big but. If you are going to do that kind of thing, you need to think about it, plan it, and create and participate in a process that supports everyone is diverse images using and testing that package. From what I have seen there is only one person on the Pharo team that understands what LevelPlayingField is for, and how to use it.

The biggest risk to this approach is if some other folks decide to fork some significant architectural component in a completely incompatible manner, without thinking about any bigger picture at all.

Matthew's comment about how our tools are only just getting there isnt that relevant to the point that I am making. I didnt need a test and build server to innovate Rio for everyone rather than just for the image I am using (trouble was I was using 3 different images), all I needed was an inclusive attitude rather than an exclusive attitude.

cheers

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On 03.03.2009, at 20:47, Keith Hodges wrote:

Stéphane Ducasse wrote:

...

Keith we understand your point. This is why I proposed to clean Installer and run SmallLint on it. and clean it again (no subclass references in superclass and other).

Now did you said the same to Croquet, Sophie, Etoy people? why only to us? Then we have the right not to be happy with your infrastructural choices.

The croquet people namely (andreas) are on my case, and he clearly gets this concept since he based his "running for the board" email on it.

The cobalt people = matthew and others, they "get it", and are using some of the tools, and proposing common libraries.

Bertf has expressed an interest in etoys moving up to 3.10+ if the transition can be eased.

So interestingly, all these peope never had *any* interest in cooperating on anything. Etoys ignored 3.9 *completely*. (and all my activity to merge etoys back before that was always done not with that much enthusiasm from their side. I got some bit of help from Bert and Michael, but the activity always came from my side). Andreas disapeared for years (just to pee on us for a good laugh on and off). So I really wonder why they all changed their mind suddenly. Seriously. Marcus -- Marcus Denker -- denker@acm.org http://www.marcusdenker.de

2009/3/4 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Fun enough I got the same feeling. Do you remember this etoy 3.8 release that should have been done fast and last more than a couple of month and after no communication with 3.9 at all. Or the fork of Croquet. So Marcus do not worry I can tell you that we are not paranoid and I will not let anybody damage us. And now we are even considered as the bad guy not wanted to merge.... I believe that people gets afraid by Pharo or have time to show us that we are wrong (of course some may want to really collaborate).

let's say (hope) this is a question of favorable conjecture (which you hadn't back when you took 3.9)... I think Matthiew and Keith... and some others, really pushed the idea to live with forks (instead of building another image)... After a year or two, people start to go in their way... + people have maybe more time to collaborate. IMO, the arrival of Igor and Eliot is also a big win... I think 2008 was a good smalltalk year... Pharo is a good choice though because you offer something to developer that was simply absent before and moreover, "people" were really reluctant to go in that direction for squeak hence all your problems... So still, even if there's a resurgence of squeak development collaboration, Pharo has its place for the everyday developer (even people like me who like to do simple stuffs ... but in smalltalk). I see Pharo as the Smalltalk oriented to developers, where you experience good development practices (and invent new one) whereas squeak is more global, touch at everything, experiment in all directions... Pharo decision process will be anyway quicker than squeak (even with Andreas proposal)... You can't imagine how much a little change like the menu shrinking is important to me (and looked impossible to ask for in squeak...). Maybe you won't totally reinvent Smalltalk but you already provide a solid smalltalk basis for everyday work (nb: I'm interested in first class slots ;) ). Anyway I find the present synergy around smalltalk/squeak/pharo/gs... really cool. Even if I understand your frustration, it might be important to try to stay in sync as much as possible. Keep the really good work :) My 2 cents,

For now I will not discuss that point anymore on this list because we do not make any progress and we do not have to justify ourselves.

...

...

...

The croquet people namely (andreas) are on my case, and he clearly gets this concept since he based his "running for the board" email on it.

The cobalt people = matthew and others, they "get it", and are using some of the tools, and proposing common libraries.

Bertf has expressed an interest in etoys moving up to 3.10+ if the transition can be eased.

I'm curious to see what they would gain. And as if merging two streams would be that easy.

...

...

So interestingly, all these peope never had *any* interest in cooperating on anything.

Etoys ignored 3.9 *completely*. (and all my activity to merge etoys back before that was always done not with that much enthusiasm from their side. I  got some bit of help from Bert and Michael, but the activity always came from  my side).

Andreas disapeared for years (just to pee on us for a good laugh on   and off).

So I really wonder why they all changed their mind suddenly. Seriously.

      Marcus

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Cédrick

2009/3/4 Stéphane Ducasse <stephane.ducasse@inria.fr>:

tx perl hacker :)

Stef

actually, I did only 2 weeks of Perl and I'm back to Pharo since... :) Thanks to smalltalk, the very good point is I've nearly finished something that is due in june !!! (I mean minus the 20% that takes most of the time plus all the fancy stuffs I'd like to do around diagrams). I think I did the main skeleton in a week :) (it a planer prototype) whereas my supervisor asked me for a class diagram... I just did in st and used OB to draw the diagram... and two days later it was nearly working :) I think that's just impossible in another language (with the same developer ;) ). 2 bad points though... - people let me do it but nobody even look at the code :( - don't know yet how to deploy ... Here I'd really like a micro image... I might do with Pavel image or even think to use gnu-st... Last solution is to port in perl mainly for people to maintain it if I leave. Still don't know but I'll come back with question when necessary... See you, Cédrick

It strikes me (disagree if you feel the need) that Pharo can do all of the fun-goofy-crazy stuff that people want to protect (at cost) in Squeak. I forget who it was, but one Squeaker essentially said to me "don't break our toy." All I wanted was what Pharo is rapidly becoming: a robust system with good tools and themed feel. You want focus jumping all over - fine, just make it optional so my users don't have to live with it. Pharo is doing just that and more. This will really stir the pudding in some minds: I think the best thing that could happen is that Squeak 6.0 == Pharo 3.0 plus packages to do whatever Squeak needs that Pharo does not provide. I certainly do not want to break anyone's toy - I want to put a good GUI and toolset underneath it. Thanks to all for the great work! Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Cédrick Béler Sent: Wednesday, March 04, 2009 8:57 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you 2009/3/4 Stéphane Ducasse <stephane.ducasse@inria.fr>:

Fun enough I got the same feeling. Do you remember this etoy 3.8 release that should have been done fast and last more than a couple of month and after no communication with 3.9 at all. Or the fork of Croquet. So Marcus do not worry I can tell you that we are not paranoid and I will not let anybody damage us. And now we are even considered as the bad guy not wanted to merge.... I believe that people gets afraid by Pharo or have time to show us that we are wrong (of course some may want to really collaborate).

let's say (hope) this is a question of favorable conjecture (which you hadn't back when you took 3.9)... I think Matthiew and Keith... and some others, really pushed the idea to live with forks (instead of building another image)... After a year or two, people start to go in their way... + people have maybe more time to collaborate. IMO, the arrival of Igor and Eliot is also a big win... I think 2008 was a good smalltalk year... Pharo is a good choice though because you offer something to developer that was simply absent before and moreover, "people" were really reluctant to go in that direction for squeak hence all your problems... So still, even if there's a resurgence of squeak development collaboration, Pharo has its place for the everyday developer (even people like me who like to do simple stuffs ... but in smalltalk). I see Pharo as the Smalltalk oriented to developers, where you experience good development practices (and invent new one) whereas squeak is more global, touch at everything, experiment in all directions... Pharo decision process will be anyway quicker than squeak (even with Andreas proposal)... You can't imagine how much a little change like the menu shrinking is important to me (and looked impossible to ask for in squeak...). Maybe you won't totally reinvent Smalltalk but you already provide a solid smalltalk basis for everyday work (nb: I'm interested in first class slots ;) ). Anyway I find the present synergy around smalltalk/squeak/pharo/gs... really cool. Even if I understand your frustration, it might be important to try to stay in sync as much as possible. Keep the really good work :) My 2 cents,

For now I will not discuss that point anymore on this list because we do not make any progress and we do not have to justify ourselves.

...

...

...

The croquet people namely (andreas) are on my case, and he clearly gets this concept since he based his "running for the board" email on it.

The cobalt people = matthew and others, they "get it", and are using some of the tools, and proposing common libraries.

Bertf has expressed an interest in etoys moving up to 3.10+ if the transition can be eased.

I'm curious to see what they would gain. And as if merging two streams would be that easy.

...

...

So interestingly, all these peope never had *any* interest in cooperating on anything.

Etoys ignored 3.9 *completely*. (and all my activity to merge etoys back before that was always done not with that much enthusiasm from their side. I  got some bit of help from Bert and Michael, but the activity always came from  my side).

Andreas disapeared for years (just to pee on us for a good laugh on   and off).

So I really wonder why they all changed their mind suddenly. Seriously.

      Marcus

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Cédrick _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Ramon, +10 as we say. However, I welcome the toys on top of the tool, as long as they go away if I choose not to play. I would like to think that a "live and let code" attitude is what distinguishes us from "them." Bill ________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Ramon Leon Sent: Wednesday, March 04, 2009 9:20 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you

I forget who it was, but one Squeaker essentially said to me "don't break our toy.

That's the attitude that infuriates me about Squeak, "toy" name, "toy" UI, and "toy" attitude. I'm so glad Pharo was started so I can work with something that isn't a "toy" but a real professional "tool" who's name can be spoken aloud. Ramon Leon http://onsmalltalk.com

The problem with it is that Pharo will have a Pharo package system, a Pharo SUinit, a Pharo Compiler, and a Pharo GUI, and none of the packages will work between squeak and pharo.

Why should it run on Squeak, if I have all my code running in Pharo? Sorry, I couldn't resist. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Lukas Renggli wrote:

...

The problem with it is that Pharo will have a Pharo package system, a Pharo SUinit, a Pharo Compiler, and a Pharo GUI, and none of the packages will work between squeak and pharo.

Why should it run on Squeak, if I have all my code running in Pharo?

We have two equal and opposite questions you could ask. I would ask "Why shouldn't it run on squeak?".... Keith

Schwab,Wilhelm K wrote:

Keith,

Call it Squeak or Pharo, I (and apparently many others here) want a clean Smalltalk. Kernel+packages is fine; I could also live with a well-factored big image from which I simply chop out things I do not need. If the system is good, I will adapt to the ways people chose to give it to me.

You apparently want Squeak. No I dont want squeak, I want an environment in which contributions and concepts are appreciated, and shareable. I want this "not invented here" attitude scrapped.

To be clear, I wrote SUnit-improved 3 years ago. I wasn't so arrogant as to say it is "The" SUnit. that everyone should use, I offered it as an alternativeand it has remained loadable from universes. The code may not be perfect but the concepts were perfectly reasonable: 1. Non GUI Test Runner, for use in an automated remote build system. 2. Classification of tests - for a world in which there are different forks images etc so that test suites can be a shared knowledge base of what works where. 3. A flexible test suite building interface that can be used to run other test suites like SSpec within the same tools. 4. A Cleaner Organisation under the category "Testing" e.g. "Testing-Common, Testing-Commmon-GUI, Testing-SUnit-Tests, Testing-SSpec-Tests etc. So... along comes pharo, and without any discussion at all in the general SUnit users forum, starts to "do their own thing with SUnit". Well thanks for nothing, it really makes you feel like contributing. Its not squeak that is the black hole, squeak isn't actively snubbing contributions. Keith

I think Matthiew and Keith... and some others, really pushed the idea to live with forks (instead of building another image)... After a year or two, people start to go in their way... + people have maybe more time to collaborate. IMO, the arrival of Igor and Eliot is also a big win...0

But note Igor and Elliot are folks thinking in an inclusive manner. Neither are they simply squeak/pharo focused.

I think 2008 was a good smalltalk year... Pharo is a good choice though because you offer something to developer that was simply absent before and moreover, "people" were really reluctant to go in that direction for squeak hence all your problems... So still, even if

Actually no, I did not see any reluctance to go in that direction at all. In fact the tabled proposals for 3.11+ had identical goals to pharo's but a different way of getting there. The Pharo team required that they have full control, whereas the 3.11 team assumes that they dont have control, they are facilitating through tools.

there's a resurgence of squeak development collaboration, Pharo has its place for the everyday developer (even people like me who like to do simple stuffs ... but in smalltalk). I see Pharo as the Smalltalk oriented to developers, where you experience good development practices (and invent new one) whereas squeak is more global, touch at everything, experiment in all directions...

Pharo decision process will be anyway quicker than squeak (even with Andreas proposal)... You can't imagine how much a little change like the menu shrinking is important to me (and looked impossible to ask for in squeak...). Why? We have had a mechanism for proposing and loading such changes for 3 years. If you wanted to try new menus you could submit the changeset to mantis and make that available for everyone. You didnt have to ask anyone. I would happily use such a contribution.

What we have been lacking is the build infrastructure for testing and harnessing such contributions. This was on the road map for 3.10 but never happened, because the 3.10 team continued to be focussed on the image as a deliverable rather than the process. Keith

Keith, I respectfully disagree on one fundamental point: the processes fed into a black hole. Ideas were ignored, well intentioned people were ridiculed. What Stef et al. have done (beyond a lot of great work) is fix that problem. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Wednesday, March 04, 2009 9:37 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you

I think Matthiew and Keith... and some others, really pushed the idea to live with forks (instead of building another image)... After a year or two, people start to go in their way... + people have maybe more time to collaborate. IMO, the arrival of Igor and Eliot is also a big win...0

But note Igor and Elliot are folks thinking in an inclusive manner. Neither are they simply squeak/pharo focused.

I think 2008 was a good smalltalk year... Pharo is a good choice though because you offer something to developer that was simply absent before and moreover, "people" were really reluctant to go in that direction for squeak hence all your problems... So still, even if

Actually no, I did not see any reluctance to go in that direction at all. In fact the tabled proposals for 3.11+ had identical goals to pharo's but a different way of getting there. The Pharo team required that they have full control, whereas the 3.11 team assumes that they dont have control, they are facilitating through tools.

there's a resurgence of squeak development collaboration, Pharo has its place for the everyday developer (even people like me who like to do simple stuffs ... but in smalltalk). I see Pharo as the Smalltalk oriented to developers, where you experience good development practices (and invent new one) whereas squeak is more global, touch at everything, experiment in all directions...

Pharo decision process will be anyway quicker than squeak (even with Andreas proposal)... You can't imagine how much a little change like the menu shrinking is important to me (and looked impossible to ask for in squeak...). Why? We have had a mechanism for proposing and loading such changes for 3 years. If you wanted to try new menus you could submit the changeset to mantis and make that available for everyone. You didnt have to ask anyone. I would happily use such a contribution.

What we have been lacking is the build infrastructure for testing and harnessing such contributions. This was on the road map for 3.10 but never happened, because the 3.10 team continued to be focussed on the image as a deliverable rather than the process. Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Plonk

...

But Bill,

you are criticising the OLD process, which is the process that Stef and Marcus were custodians of for two years. It was they who made it more difficult to process by managing the image in packages without the needed tools.

The pharo process is exactly the same black hole with exactly the same "not invented here attitude".

In squeak land we have an all new process and some of us have been working on that all new process for 2+ years,

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Keith, I have never met Stef; I know him only through correspondence, direct and otherwise. Come to think of it, I probably know him pretty well. I *never* got any sense that he was the problem with Squeak. I don't buy it; I saw him trying to fix the problems I have described, and failing that, he started Pharo. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Keith Hodges Sent: Wednesday, March 04, 2009 11:05 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you Schwab,Wilhelm K wrote:

Keith,

I respectfully disagree on one fundamental point: the processes fed into a black hole. Ideas were ignored, well intentioned people were ridiculed. What Stef et al. have done (beyond a lot of great work) is fix that problem.

Bill

But Bill, you are criticising the OLD process, which is the process that Stef and Marcus were custodians of for two years. It was they who made it more difficult to process by managing the image in packages without the needed tools. The pharo process is exactly the same black hole with exactly the same "not invented here attitude". In squeak land we have an all new process and some of us have been working on that all new process for 2+ years, Keith _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/3/4 Keith Hodges <keith_hodges@yahoo.co.uk>:

Schwab,Wilhelm K wrote:

...

Keith,

I have never met Stef; I know him only through correspondence, direct and otherwise.  Come to think of it, I probably know him pretty well.  I *never* got any sense that he was the problem with Squeak.  I don't buy it; I saw him trying to fix the problems I have described, and failing that, he started Pharo.

Bill

I didnt say that he "was" the problem. I said he was the custodian of the process (one development team bottleneck) that you called a black hole.

I saw them more as prisoners, not custodians... you can object in Pharo, it's the same as squeak but... not the same size, same interests and again... a quick decision process, quick integration... Let's see what BPP will do but meanwhile, I'm happy with the reactivity... last one for me on this thread... time to go ;) bye

Keith

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

-- Cédrick

Stef, I agree that it is time to politely and unapologetically stick to the job of making Pharo a lean fast open Smalltalk with a robust IDE. I too think that Pharo is very upsetting to some people - it is turning into a success. You are wise to give others credit for wanting to collaborate, but finishing the cleaning seems the best approach. Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Wednesday, March 04, 2009 8:26 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] A point a.k.a excuse to you Fun enough I got the same feeling. Do you remember this etoy 3.8 release that should have been done fast and last more than a couple of month and after no communication with 3.9 at all. Or the fork of Croquet. So Marcus do not worry I can tell you that we are not paranoid and I will not let anybody damage us. And now we are even considered as the bad guy not wanted to merge.... I believe that people gets afraid by Pharo or have time to show us that we are wrong (of course some may want to really collaborate). For now I will not discuss that point anymore on this list because we do not make any progress and we do not have to justify ourselves.

...

...

The croquet people namely (andreas) are on my case, and he clearly gets this concept since he based his "running for the board" email on it.

The cobalt people = matthew and others, they "get it", and are using some of the tools, and proposing common libraries.

Bertf has expressed an interest in etoys moving up to 3.10+ if the transition can be eased.

I'm curious to see what they would gain. And as if merging two streams would be that easy.

...

So interestingly, all these peope never had *any* interest in cooperating on anything.

Etoys ignored 3.9 *completely*. (and all my activity to merge etoys back before that was always done not with that much enthusiasm from their side. I got some bit of help from Bert and Michael, but the activity always came from my side).

Andreas disapeared for years (just to pee on us for a good laugh on and off).

So I really wonder why they all changed their mind suddenly. Seriously.

Marcus

_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project