March 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] What are the ERROR messages in the Transcript Window in 10243?

by Adrian Lienhard

Seems a problem in OB: OBDBSuperSend sends #superSenderSelectors, which is not implemented. Adrian On Feb 28, 2009, at 19:06 , Rob Rothwell wrote: > Maybe I just wasn't able to follow the conversation properly, but if > you > open a Transcript in 10243 (dev) and, say, search for the class > "Morph," you > will get: > > ERROR: Morph class>>overridesSelectors > ERROR: Morph class>>superSenderSelectors > ERROR: Morph class>>conflictsSelectors > ERROR: Morph class>>overridesSelectors > ERROR: Morph class>>superSenderSelectors > ERROR: Morph class>>conflictsSelectors > > In fact, anytime you do anything (save a method, etc...), it seems > you get > these messages, and yet things seem to be working. > > Rob > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2009

Re: [Pharo-project] [squeak-dev] [Idea] method source with it

by Lukas Renggli

>> Not at the moment, I noticed myself several times that this would be >> useful. If I find time, I will have a look at it tomorrow. > > No problem. I was justÂ asking :) Update in this order: 1. AST-lr.164 2. Refactoring-Core-lr.40 3. OB-Refactory-lr.141 4. OB-Regex-lr.15 To get case insensitive matching when building environments/scopes make sure that the expression ends with "/i". All the commands include a regular expression example now, that should help you get started. Note, that this versions also reorganize the menus a bit, after a discussion with Stephane and David. Environments are now called scopes, but other than that it is the same. Lukas > >> >> > Suppose you have more than 1 match of what you are looking in the same >> > method, is there a way to go one after the other putting the color over >> > the >> > world ? >> >> Not without hacking into ParagraphEditor. There is unfortunately no >> easy way to highlight several occurrences. > > :(Â Ok. Thanks anyway for the tip. > >> >> Lukas >> >> -- >> Lukas Renggli >> http://www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

March 1, 2009

Re: [Pharo-project] [squeak-dev] [Idea] method source with it

by Nicolas Cellier

Lukas Renggli <renggli@...> writes: > > > Is it possible to configurate the search engine to case no sensitive ? > > Not at the moment, I noticed myself several times that this would be > useful. If I find time, I will have a look at it tomorrow. > > > Suppose you have more than 1 match of what you are looking in the same > > method, is there a way to go one after the other putting the color over the > > world ? > > Not without hacking into ParagraphEditor. There is unfortunately no > easy way to highlight several occurrences. > > Lukas > What I did once upon a time in VW: - add a #backgroundColor->ColorValue text emphasis - implement graphic rendering for this emphasis - change the runs for every piece of matching text to add #backgroundColor->(ColorValue yellow) (for example) A little bit more ellaborate than this basic idea: don't add directly the #backgroundColor emphasis... ...but rather use an indirect one, like #searchedText. Then let some custom-preferences translate to a real emphasis. Advantages: - customisable - easy to remove all #searchedText preserving other text formatting Nicolas

March 1, 2009

Re: [Pharo-project] Preference refactoring again

by Alain Plantec

StÃ©phane Ducasse a Ã©crit : > sounds cool. > For me the most important aspect is that preferenceCollector (our > current preference class should be a removable layer on top > of the system that are declaring preference. > > Is is correct that > > PreferenceCollector whenChanged: #gradientButtonLook inClass: > PrefProvider notify: self using: #gradientButtonLookIsNow: . > > means that PrefProvider will receive the message > gradientButtonLookIsNow: no, but see the code below: ----------- PrefListener>>initialize super initialize. PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . ----------- it means that a PrefListener instance will receive the #gradientButtonLookIsNow: message each time the preference #gradientButtonLook defined in class PrefProvider is changed. PrefListener and PrefProvider represent can be any class in the system. So, in order to read a preference value an object get it from the provider class by message sending, the provider is a class in a package which defines preferences (no need for PreferenceCollector to get the preference value). > > This way we can push preference to the tools yes > and thety do not have to query the information in the Collector at > run-time yes, Each package have its own preference set in it represented by a set of methods with pragma. When such a package is loaded, its preferences are automatically stored by PreferenceCollector. When a package is removed, its preferences are automatically removed from PreferenceCollector. PreferenceCollector is only here for supporting tools (cool UI ...) and for change notifications. > (hence we could remove Preference and have a more OO design). I guess yes. > > Sorry not to reply earlier (I was breaking yet another wall in our > "kitchen") bon courage :) alain > > Stef > > > On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote: > >> Hi all, >> >> joined Zoo package is a attempt to translate in code what we >> discussed here before about preference refactoring. >> >> The framework is made of 3 classes: PreferenceCollector, >> PreferenceDefinition and PreferenceValue. >> In Zoo there are also 2 classes for testing: PrefProvider and >> PrefChangeListener. >> PrefProvider class declares some preferences and PrefChangeListener >> is here to test preference change notification. >> >> PrefChangeListener>>initialize >> super initialize. >> PreferenceCollector whenChanged: #gradientButtonLook inClass: >> PrefProvider notify: self using: #gradientButtonLookIsNow: . >> PreferenceCollector whenChanged: #gradientButtonLook inClass: >> PrefProvider notify: self using: #gradientLook: >> >> PrefChangeListener class>>test >> "self test" >> PrefChangeListener new inspect. >> PrefProvider gradientButtonLook: PrefProvider gradientButtonLook >> value not. >> PrefProvider gradientButtonLook: PrefProvider gradientButtonLook >> value not. >> PrefProvider gradientButtonLook: PrefProvider gradientButtonLook >> value not. >> >> >> From PreferenceCollector comment: >> -------------------------------------- >> A PreferenceCollector automatically collects all preferences. >> A preference is represented by a PreferenceDefinition. >> All PreferenceDefinition are stored in the preferences instance >> variable. >> >> Instance Variables >> preferences: OrderedCollection of PreferenceDefinition >> >> preferences >> - contains all PreferenceDefinition which are automatically built >> from pragma found in preference getters >> >> >> ADDING A PREFERENCE >> PreferenceCollector makes use of the SystemChangeNotifier in order to >> automate the adding, the removing and the updating of preferences. >> See #PreferenceCollector>>event: to see how preferences update is >> implemented. >> >> Editing a new method with a preference pragma or inserting a >> preference pragma in an existing method are >> the two ways for preference definition adding. >> The only way to remove a preference definition is to remove the >> corresponding method. >> >> Example of a "blackAndWhite" preference. >> Methods below are defined by the preference provider >> APreferencePrivider class. >> Note that the value stored in BlackAndWhite class variable is an >> instance of PreferenceValue. >> In this example, the default value is directly given with the pragma: >> ------------- >> APreferencePrivider class>>blackAndWhite >> <preference: 'Use black and white' type: #Boolean set: >> #blackAndWhite: defaultValue: false description: 'Use black and white'> >> ^ BlackAndWhite >> ifNil: [BlackAndWhite := PreferenceValue value: false location: >> self selector: #blackAndWhite] >> >> APreferencePrivider class>>blackAndWhite: aBoolean >> self blackAndWhite value: aBoolean >> ------------- >> >> If a default value can't be specified in the pragma, another way >> consists in using a selector which >> represents the message to send to the class in order to get the >> default value: >> >> ------------- >> APreferencePrivider class>>standardFont >> <preference: 'The default system font' type: #LogicalFont set: >> #standardFont: default: #defaultStandardFont description: 'The >> default system font'> >> ^ StandardFont >> ifNil: [StandardFont := PreferenceValue value: self >> defaultStandardFont location: self selector: #standardFont] >> >> APreferencePrivider class>>standardFont: aFont >> self standardFont value: aFont >> APreferencePrivider class>>defaultStandardFont >> ^ LogicalFont >> familyName: 'Arial' >> fallbackFamilyNames: nil >> pointSize: 12 >> stretchValue: 5 >> weightValue: 400 >> slantValue: 0 >> ------------- >> >> LISTENING TO A PREFERENCE VALUE CHANGE >> Any object can register itself as a preference value change listener. >> See #PreferenceCollector class>>whenChanged: inClass:notify:using:. >> >> Each time a preference value is changed, #preference: >> inClass:changedWith: is sent to the PreferenceCollector class. >> >> Example of code a listener can implement in order to be notified each >> time a gradientButtonLook preference defined by a PrefProvider class >> is changed. >> In this example, the listener ask to be notified by a send of >> #gradientButtonLookIsNow: message. >> The argument given to gradientButtonLookIsNow: is the new preference >> value. >> ------------- >> .... >> PreferenceCollector whenChanged: #gradientButtonLook inClass: >> PrefProvider notify: self using: #gradientButtonLookIsNow:. >> .... >> ------------- >> >> What do you think ? >> >> cheers >> Alain >> >> >> <Zoo-alain_plantec.10.mcz>_______________________________________________ >> >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > >

March 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by Tudor Girba

I copied it to the repository of Lukas as well. Does anyone actually see a reason for not having the when:do: method in as an alias to on:do:? I do not see it. Cheers, Doru On 1 Mar 2009, at 10:19, StÃ©phane Ducasse wrote: > Where? > It was not on lukas source and in the pharo inbox > Then there is the question to be sure if we want it. > > > On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > >> Hi Stef, >> >>> Some more happy people :) >>> >>> - Announcements-lr.10 from souce.lukas-renggli.ch >>> Is when:do: not missing for compatibility with VW? >> >> I published a new version containing when:do: Announcements-tg.11. >> >> Cheers, >> Doru >> >> >>> >>> - Polymorph >>> Fix for button for currently selected window in tasklist not being >>> differentiated when using Watery 2 theme. >>> >>> - ContextPart argument >>> >>> - merged Issue 608: saveAsNewVersion uses deprecated method >>> >>> - Issue 614: >>> MessageTally broken when invoked from non-GUI process (e.g., in >>> Seaside code) >>> >>> >>> Now we should really kill more items for the milestone 1.0. >>> >>> Stef (now breakfast :) >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> -- >> www.tudorgirba.com >> >> "Yesterday is a fact. >> Tomorrow is a possibility. >> Today is a challenge." >> >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Be rather willing to give than demanding to get."

March 1, 2009

[Pharo-project] Fwd: Some personal thoughts and questions about Pharo

by StÃ©phane Ducasse

Begin forwarded message: > From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Date: February 28, 2009 2:07:42 PM CEST > To: Matthew Fulmer <tapplek(a)gmail.com> > Cc: Marcus Denker <denker(a)iam.unibe.ch> > Subject: Re: Some personal thoughts and questions about Pharo > > Hi matthew > > >> Hi. I stumbled across a rather interesting email while I was >> researching to write up my campaign platform for the squeak >> election. Stef wrote this email 4 years ago, and it challenged a >> lot of what I thought about Pharo: >> >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087532.… >> >> It prompted me to write this email, and lay out exactly what I >> think about Pharo, both good, bad, and not understood. > > Ok I think that this is important to have a look at what we did and > wrote in the past > to understand our attitude today. Lot of people judge without really > knowing. > > This is not the best email I sent. but it just gives a facett of the > problem > >>> From what I can tell, this email was written just before you >> guys started the 3.9 team. > > I imagine. > >> Firstly, I see that you have really cared about bug response >> latency for a long time. I'm really glad you care and do >> something about it. > > Yes. > We cared also about transparency and trust. > The idea is that I already said that to the squeakfoundation and I > gave up > long time ago. > If we do not give a chance to knowlegdaebale people to get a look then > we failed. Once janko which I trust sent a fix for network and I > thought that > we should integrate it but bert had a look and said it was not good. > So this makes me thing > a lot. So if an opensource movement we do not have communication > then nothing good > can happen. > > For 3.10 I proposed to ralph to help but he declined. They thought > we had no process > and when I explained him what we were doing he said that this is > what he planed to do. > I think that people thiught that ralph was Jesus but he was not. > >> Second, you solved this problem back then by releasing 3.9, >> and now you are solving it thru Pharo. Why did you choose to >> fork this time? >> >> If I may be blunt, I've long suspected that there are exactly >> two reasons why you forked: >> 1. Edgar J. De. Cleene >> 2. Andreas Raab > > You are not blunt > Been called a randomrefactorer is blunt. I do not want to tell more on > that but we are a solid group of people all getting the same feeling > nd this is not > because we are wash-brained. Just our experiences are following the > same line. > Ask mike why andreas does not talk to him. > >> Thirdly, I've heard Stef mention a number of times that "Marcus >> got burned", and therefore doesn't read squeak-dev, or no longer >> runs for board, or several things most squeak people do. >> However, this is by far the earliest mention of said burning >> I've ever seen. I had assumed the burning was people (Edgar and >> Andreas) complaining about Traits, but this was long before >> that. > > marcus was burnt to the point of been sick of smalltalk. > The problem is that marucs dreamt with us at bern about beauty and > a better world and that people like andreas were most of the time > negative and playing for themselves. Look at Tweak Andreas forked it > even people working in Sophie did not have access to his branch. > > >> What is it that happened to Marcus? If you are still bitter >> about something that happened over 4 years ago, perhaps it is >> time to forgive and re-join the squeak community. > > No we are not bitter. The squeak community has no vision except > toying with the past. > If I would be you I would not lose my time there. We harvested since > squeak > 3.6 and we did our best but it failed and it will fail. > >> As 3.11 release team leader, and Squeak board nominee, I'm >> really excited about what you guys are doing with Pharo. From my >> perspective, one thing you have done is take up the reigns for >> harvesting bugs, and left the release team free to consider a >> long-standing issue in the community: who is responsible for >> merging bug fixes from one distribution to another, and how can >> we make their lives easier > > No we did the only thing that make us breath again and not > jump into ruby or python or just hack in our little corner > stuff in VW or other. > Pharo is not an accident this is a survival reflex. > You know when you want to fix sometihng that a guy shout at you > because you push > a fix in his package.... Then after a while you stop this is why > there are some > fonts problem in 39 because we stop to harvest anything related to > andreas. > > >> Another valuable thing you have done is show the community that >> one image does not fit all; the monolithic image does not work >> for anybody. Squeakland showed it does not work for end-users >> Croquet showed it does not work for researchers. > > No Croquet shows nothing. Ask lombardi because he gave a presentation > last year at ESUG and we felt he was just alone lost. > And we are researcher much more than they :). Look at our > publication records. > Now we want a good Smalltalk and make evolve: first class slots, > packages.... > It will take time but we will do it. > >> And now Pharo >> shows that it does not work for developers. I really think that >> Pharo finishes painting that picture in the minds of the >> community, and you have thus paved the way for the release team >> and the squeak board to get away from the monolithic image, and >> toward modularity. I really think the community is ready now, >> and it's all thanks to you guys. I intend to exploit this >> opportunity. > > If you want. But I'm not sure that this is the right analysis. > >> I sent this email in private, because I don't think it would be >> appropriate to ask some of these questions publicly. However, >> feel free to reply to any of this in public, as you see fit. > > Sure I have no secret on that topic. > > >> >> >> -- >> Matthew Fulmer -- http://mtfulmer.wordpress.com/ >> >

March 1, 2009

Re: [Pharo-project] Preference refactoring again

by StÃ©phane Ducasse

sounds cool. For me the most important aspect is that preferenceCollector (our current preference class should be a removable layer on top of the system that are declaring preference. Is is correct that PreferenceCollector whenChanged: #gradientButtonLook inClass: PrefProvider notify: self using: #gradientButtonLookIsNow: . means that PrefProvider will receive the message gradientButtonLookIsNow: This way we can push preference to the tools and thety do not have to query the information in the Collector at run-time (hence we could remove Preference and have a more OO design). Sorry not to reply earlier (I was breaking yet another wall in our "kitchen") Stef On Mar 1, 2009, at 10:05 AM, Alain Plantec wrote: > Hi all, > > joined Zoo package is a attempt to translate in code what we > discussed here before about preference refactoring. > > The framework is made of 3 classes: PreferenceCollector, > PreferenceDefinition and PreferenceValue. > In Zoo there are also 2 classes for testing: PrefProvider and > PrefChangeListener. > PrefProvider class declares some preferences and PrefChangeListener > is here to test preference change notification. > > PrefChangeListener>>initialize > super initialize. > PreferenceCollector whenChanged: #gradientButtonLook inClass: > PrefProvider notify: self using: #gradientButtonLookIsNow: . > PreferenceCollector whenChanged: #gradientButtonLook inClass: > PrefProvider notify: self using: #gradientLook: > > PrefChangeListener class>>test > "self test" > PrefChangeListener new inspect. > PrefProvider gradientButtonLook: PrefProvider gradientButtonLook > value not. > PrefProvider gradientButtonLook: PrefProvider gradientButtonLook > value not. > PrefProvider gradientButtonLook: PrefProvider gradientButtonLook > value not. > > > From PreferenceCollector comment: > -------------------------------------- > A PreferenceCollector automatically collects all preferences. > A preference is represented by a PreferenceDefinition. > All PreferenceDefinition are stored in the preferences instance > variable. > > Instance Variables > preferences: OrderedCollection of PreferenceDefinition > > preferences > - contains all PreferenceDefinition which are automatically built > from pragma found in preference getters > > > ADDING A PREFERENCE > PreferenceCollector makes use of the SystemChangeNotifier in order > to automate the adding, the removing and the updating of preferences. > See #PreferenceCollector>>event: to see how preferences update is > implemented. > > Editing a new method with a preference pragma or inserting a > preference pragma in an existing method are > the two ways for preference definition adding. > The only way to remove a preference definition is to remove the > corresponding method. > > Example of a "blackAndWhite" preference. > Methods below are defined by the preference provider > APreferencePrivider class. > Note that the value stored in BlackAndWhite class variable is an > instance of PreferenceValue. > In this example, the default value is directly given with the pragma: > ------------- > APreferencePrivider class>>blackAndWhite > <preference: 'Use black and white' type: #Boolean set: > #blackAndWhite: defaultValue: false description: 'Use black and > white'> > ^ BlackAndWhite > ifNil: [BlackAndWhite := PreferenceValue value: false > location: self selector: #blackAndWhite] > > APreferencePrivider class>>blackAndWhite: aBoolean > self blackAndWhite value: aBoolean > ------------- > > If a default value can't be specified in the pragma, another way > consists in using a selector which > represents the message to send to the class in order to get the > default value: > > ------------- > APreferencePrivider class>>standardFont > <preference: 'The default system font' type: #LogicalFont set: > #standardFont: default: #defaultStandardFont description: 'The > default system font'> > ^ StandardFont > ifNil: [StandardFont := PreferenceValue value: self > defaultStandardFont location: self selector: #standardFont] > > APreferencePrivider class>>standardFont: aFont > self standardFont value: aFont > APreferencePrivider class>>defaultStandardFont > ^ LogicalFont > familyName: 'Arial' > fallbackFamilyNames: nil > pointSize: 12 > stretchValue: 5 > weightValue: 400 > slantValue: 0 > ------------- > > LISTENING TO A PREFERENCE VALUE CHANGE > Any object can register itself as a preference value change listener. > See #PreferenceCollector class>>whenChanged: inClass:notify:using:. > > Each time a preference value is changed, #preference: > inClass:changedWith: is sent to the PreferenceCollector class. > > Example of code a listener can implement in order to be notified > each time a gradientButtonLook preference defined by a PrefProvider > class is changed. > In this example, the listener ask to be notified by a send of > #gradientButtonLookIsNow: message. > The argument given to gradientButtonLookIsNow: is the new preference > value. > ------------- > .... > PreferenceCollector whenChanged: #gradientButtonLook inClass: > PrefProvider notify: self using: #gradientButtonLookIsNow:. > .... > ------------- > > What do you think ? > > cheers > Alain > > > <Zoo-alain_plantec. > 10.mcz>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 1, 2009

Re: [Pharo-project] Fwd: [ANN] 10245

by StÃ©phane Ducasse

Where? It was not on lukas source and in the pharo inbox Then there is the question to be sure if we want it. On Mar 1, 2009, at 9:56 AM, Tudor Girba wrote: > Hi Stef, > >> Some more happy people :) >> >> - Announcements-lr.10 from souce.lukas-renggli.ch >> Is when:do: not missing for compatibility with VW? > > I published a new version containing when:do: Announcements-tg.11. > > Cheers, > Doru > > >> >> - Polymorph >> Fix for button for currently selected window in tasklist not being >> differentiated when using Watery 2 theme. >> >> - ContextPart argument >> >> - merged Issue 608: saveAsNewVersion uses deprecated method >> >> - Issue 614: >> MessageTally broken when invoked from non-GUI process (e.g., in >> Seaside code) >> >> >> Now we should really kill more items for the milestone 1.0. >> >> Stef (now breakfast :) >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 1, 2009

[Pharo-project] Fwd: Some personal thoughts and questions about Pharo

by StÃ©phane Ducasse

For the ones that were not there at that time. Study history as always been a way to understand the present :) Begin forwarded message: > From: Matthew Fulmer <tapplek(a)gmail.com> > Date: February 28, 2009 6:26:00 AM CEST > To: Marcus Denker <denker(a)iam.unibe.ch>, St?phane Ducasse <stephane.ducasse(a)inria.fr > > > Cc: Matthew Fulmer <tapplek(a)gmail.com> > Subject: Some personal thoughts and questions about Pharo > > Hi. I stumbled across a rather interesting email while I was > researching to write up my campaign platform for the squeak > election. Stef wrote this email 4 years ago, and it challenged a > lot of what I thought about Pharo: > > http://lists.squeakfoundation.org/pipermail/squeak-dev/2005-January/087532.… > > It prompted me to write this email, and lay out exactly what I > think about Pharo, both good, bad, and not understood. > >> From what I can tell, this email was written just before you > guys started the 3.9 team. > > Firstly, I see that you have really cared about bug response > latency for a long time. I'm really glad you care and do > something about it. > > Second, you solved this problem back then by releasing 3.9, > and now you are solving it thru Pharo. Why did you choose to > fork this time? > > If I may be blunt, I've long suspected that there are exactly > two reasons why you forked: > 1. Edgar J. De. Cleene > 2. Andreas Raab > > Thirdly, I've heard Stef mention a number of times that "Marcus > got burned", and therefore doesn't read squeak-dev, or no longer > runs for board, or several things most squeak people do. > However, this is by far the earliest mention of said burning > I've ever seen. I had assumed the burning was people (Edgar and > Andreas) complaining about Traits, but this was long before > that. > > What is it that happened to Marcus? If you are still bitter > about something that happened over 4 years ago, perhaps it is > time to forgive and re-join the squeak community. > > > As 3.11 release team leader, and Squeak board nominee, I'm > really excited about what you guys are doing with Pharo. From my > perspective, one thing you have done is take up the reigns for > harvesting bugs, and left the release team free to consider a > long-standing issue in the community: who is responsible for > merging bug fixes from one distribution to another, and how can > we make their lives easier > > > Another valuable thing you have done is show the community that > one image does not fit all; the monolithic image does not work > for anybody. Squeakland showed it does not work for end-users > Croquet showed it does not work for researchers. And now Pharo > shows that it does not work for developers. I really think that > Pharo finishes painting that picture in the minds of the > community, and you have thus paved the way for the release team > and the squeak board to get away from the monolithic image, and > toward modularity. I really think the community is ready now, > and it's all thanks to you guys. I intend to exploit this > opportunity. > > I sent this email in private, because I don't think it would be > appropriate to ask some of these questions publicly. However, > feel free to reply to any of this in public, as you see fit. > > -- > Matthew Fulmer -- http://mtfulmer.wordpress.com/ >

March 1, 2009

[Pharo-project] About pharo cut and paste email on Squeak-dev

by StÃ©phane Ducasse

Hi guys I think that we should pay attention that people do not say stupid stuff on us on squeak-dev (even if this is not that important ;) ). Stef

March 1, 2009