- Pharo-dev - lists.pharo.org

[Pharo-project] about class abtractness

by StÃ©phane Ducasse

I would really like to have a way to specify that a class is abstract. For example I would like to be able to write a test as follow self assert: (Collection allSubclasses reject: [:each each isAbstract ]) new isEmpty now saying that isAbstract is if a class has one method sending subclassResponsibility is not really good for me. May be we could have something like isAbstract ^ self declaredAsAbstract or: [ (self whichSelectorsReferToSymbol: #subclassResponsibility) isEmpty not] Stef

Oct. 5, 2008

[Pharo-project] about ifEmptyOrNil:

by StÃ©phane Ducasse

Hi I would like to have your take on that one: isEmpty "Answer whether the receiver contains any elements." ^self size = 0 Why do we need ifEmptyOrNil: isEmptyOrNil "Answer whether the receiver contains any elements, or is nil. Useful in numerous situations where one wishes the same reaction to an empty collection or to nil" ^ self isEmpty why can we use isEmpty: or ifEmpty: aBlock ifEmpty: aBlock "Evaluate the block if I'm empty" ^ self isEmpty ifTrue: aBlock Then from an implementation point of view ifEmptyOrNil: is bogus since it never returns nil (or should not and is also ill-specified). I checked ANSI and this is really a boolean. I'm the mood to deprecate this method. Stef

Oct. 5, 2008

[Pharo-project] about idiots :)

by StÃ©phane Ducasse

Hi marcus Try to stop thinking that making errors is bad. This is a christian ideology that may block your way of looking at the world in a open way. You know like "good and bad". (Watch for example Spirit away for example I'm always fascinated by the fact that we are looking for who are the good and bad). Oscar would say "live and learn". Making error is part of life. Period! Being stupid is when - you repeat errors without learning from them. - if you would not take action after. So introducing a bug is NOT A PROBLEM and nobody is stupid. We are dealing with a really complex program. We will do mistakes, many in fact. We may break the system and put it on its knees. But we will learn and fix or rollback. Easy in computer world we clone duplicate. Imagine it you would be a drawer on expensive paper with ink that you cannot erase!! Simple. So marcus dont be stupid to think that people making mistakes are idiots. They are not! You and me are far from stupid and we will do mistakes. For sure and we will learn from them. Pharo is the proof of it :) So do not let you fun gets spoiled by this oversimplistic view on the world. Stef PS: bookmark this mail because this is the last one on that topics.! When you feel idiots read it. PSPS: one young guy at IBM made IBM lost 1 Millions dollars, so he can to see his boss to resign. The boss said no way, we reject this, we invested on you 1 Million dollars. Nice!

Oct. 5, 2008

Re: [Pharo-project] Some clearifications

by Norbert Hartl

On Sat, 2008-10-04 at 23:29 +0200, Marcus Denker wrote: > Hi, > > Maybe I need to make some thing clear > > 1) There will be mistakes. > Yep, change includes mistake! > When integrating bugfixes and enhancements, it is impossible to not > make mistakes. > The problem is that one can not check every single fix, this is just > not possible. And even > if it would be checked line-by-line and very closely, there would be > new bugs. It is just impossible > that this does not happen. > > The problem is of course that the people doing the integration > everytime a bug is introduced look > (and feel) like idiots. > It would help if people would not strengthen this feeling... if I do > something where I feel like an > idiot most of the time, at some point I will stop. > Uhhh, is it that? I didn't read that much complaints on the list. Marcus, you are doing an incredible job!! And my feeling is that you are _really_ fast integrating stuff. Seeing that it is embarrassing for me as I don't find any time to do something for pharo at the moment. > 2) There is only limited time. > > We can not look at every submission directly, we can not fix every bug > (even those introduced recently) > very fast. This does not mean that we don't like the person who > submited something (or that this person > did something wrong). It *especially* does not mean to discriminate > againt projects. e.g. if Seaside can't > be loaded because of somet stupid bug, this does not mean that seaside > is not wanted or something like that. > > 3) There is a lot of stuff that should be done > ... and the only reason it is not done is lack of time. It's not > because we are idiots. > I think we should build this community on trust. Trusting submissions of community members is not something bad in my opinion. It's not your job to check everything very deeply. It is the job of everyone to review updates/changes and to test them. Taking all together I think we need to split upstream. As long as there is only one upstream you can't check that _before_ it gets published. And people see a version in the upstream as the next stable thing. So we need a side channel for integration and testing. Norbert

Oct. 5, 2008

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

On Oct 4, 2008, at 11:29 PM, Marcus Denker wrote: > Hi, > > Maybe I need to make some thing clear > > 1) There will be mistakes. > > When integrating bugfixes and enhancements, it is impossible to not > make mistakes. > The problem is that one can not check every single fix, this is just > not possible. And even > if it would be checked line-by-line and very closely, there would be > new bugs. It is just impossible > that this does not happen. > > The problem is of course that the people doing the integration > everytime a bug is introduced look > (and feel) like idiots. not really :) > It would help if people would not strengthen this feeling... if I do > something where I feel like an > idiot most of the time, at some point I will stop. no we know that this is ugly but necessary job. > 2) There is only limited time. > > We can not look at every submission directly, we can not fix every > bug (even those introduced recently) > very fast. This does not mean that we don't like the person who > submited something (or that this person > did something wrong). It *especially* does not mean to discriminate > againt projects. e.g. if Seaside can't > be loaded because of somet stupid bug, this does not mean that > seaside is not wanted or something like that. > > 3) There is a lot of stuff that should be done > ... and the only reason it is not done is lack of time. It's not > because we are idiots. We re certainly not idiots. May be put that on a wiki somewhere. Now when you feel bad just think that shit happens and that we did our best. Because this is like that. Stef > > > Marcus > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 5, 2008

Re: [Pharo-project] Retracting changes for checking variable naming?

by StÃ©phane Ducasse

Sure remove it Noury will have to make another one. :) Stef > Hi, > > We harvested something: > > http://code.google.com/p/pharo/issues/detail?id=15 > > Instance variable names hould not be capitalized and should be > different from class variables names > > The problem is that this > > a) makes code unloadable that is already out there. not good. > > and > > b) it's buggy. > > At first, I fixed one bug: > > Issue 174: XMLSupport can't be loaded into latest Pharo image > http://code.google.com/p/pharo/issues/detail?id=174 > > Then there was another: > > Issue 202: Pier-Model can not be loaded into Pharo > http://code.google.com/p/pharo/issues/detail?id=202 > > which I thought I fixed, but that fix does not work either: > > Issue 219: Cryptography does not load into Pharo > http://code.google.com/p/pharo/issues/detail?id=219 > > Would somebody be againt retracting the orginal "enhancement" to > classbuilder? > This has already cost me *hours* and I really don't want anymore. > > Marcus > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 5, 2008

[Pharo-project] Some clearifications

by Marcus Denker

Hi, Maybe I need to make some thing clear 1) There will be mistakes. When integrating bugfixes and enhancements, it is impossible to not make mistakes. The problem is that one can not check every single fix, this is just not possible. And even if it would be checked line-by-line and very closely, there would be new bugs. It is just impossible that this does not happen. The problem is of course that the people doing the integration everytime a bug is introduced look (and feel) like idiots. It would help if people would not strengthen this feeling... if I do something where I feel like an idiot most of the time, at some point I will stop. 2) There is only limited time. We can not look at every submission directly, we can not fix every bug (even those introduced recently) very fast. This does not mean that we don't like the person who submited something (or that this person did something wrong). It *especially* does not mean to discriminate againt projects. e.g. if Seaside can't be loaded because of somet stupid bug, this does not mean that seaside is not wanted or something like that. 3) There is a lot of stuff that should be done ... and the only reason it is not done is lack of time. It's not because we are idiots. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 4, 2008

[Pharo-project] Retracting changes for checking variable naming?

by Marcus Denker

Hi, We harvested something: http://code.google.com/p/pharo/issues/detail?id=15 Instance variable names hould not be capitalized and should be different from class variables names The problem is that this a) makes code unloadable that is already out there. not good. and b) it's buggy. At first, I fixed one bug: Issue 174: XMLSupport can't be loaded into latest Pharo image http://code.google.com/p/pharo/issues/detail?id=174 Then there was another: Issue 202: Pier-Model can not be loaded into Pharo http://code.google.com/p/pharo/issues/detail?id=202 which I thought I fixed, but that fix does not work either: Issue 219: Cryptography does not load into Pharo http://code.google.com/p/pharo/issues/detail?id=219 Would somebody be againt retracting the orginal "enhancement" to classbuilder? This has already cost me *hours* and I really don't want anymore. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 4, 2008

Re: [Pharo-project] does anybody got the changes to the old browser to add traits?

by StÃ©phane Ducasse

Adrian this is available in the OB. Stef On Oct 4, 2008, at 12:31 PM, Adrian Lienhard wrote: > At some point in the past, methods from traits were also shown in > italic. I added this to the old browser because it is the most > fundamental info (else you always override methods from traits when > changing a method in a class). I think we should add this back too. > > Adrian > > On Oct 4, 2008, at 12:02 , StÃ©phane Ducasse wrote: > >> Then I would like to know where are the addtrait menuitem that were >> once >> in the old browser? >> >> Stef >> >> _______________________________________________ >> 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 >

Oct. 4, 2008

Re: [Pharo-project] [update] 10087

by StÃ©phane Ducasse

Excellent I will continue the etoy curving and look at kernel extension. Marcus it would be good if you could have a look at the traits fixes Apparently adrian told me that I made a mistake :) Also the enhancements proposed by gary and simon. Issue: 218 Stef > Issue 80: 7130 PluggableListMorphFix > Issue 41: 7091 PluggableListMorphfix (M4719) > Issue 98: 7152 Form-isAllWhiteandFormTest-ar > Issue 57: 7107 IntervalReverseDoFix (M6438) > -> used Nicolas fix from http://bugs.squeak.org/view.php?id=6456 > Issue 202: Pier-Model can not be loaded into Pharo > > (please no question about "we need a prebuilt image, we need a TT/ > Plymorph image. If you want > to ask that question, just pretent that I did not do this update...) > > -- > Marcus Denker -- denker(a)iam.unibe.ch > http://www.iam.unibe.ch/~denker > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 4, 2008