- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Some clearifications

by Bill Schwab

Stef, Would you not simply fix B2? I could easily be missing something; perhaps B2 is an external package that works in Squeak but clobbers Pharo?? Is it something else? FWIW, I envision a stable release and active development, much as happens on Squeak, just consistent with the Pharo frame of mind. New contributions would tend to go into the development release, some that are of near-term interest could be tested and "back-ported" (aka installed in the next stable release). Every so often, I would further envision doing some type of export of all my stable-version Pharo code and loading into the development release to look for problems or to verify that all is well. Making that export/import cycle as simple as possible will be a useful step in helping people test the development images. Understanding the existing tools is one of my next goals. For Dolphin, I wrote a tool called Migrate that helped to sniff out my packages and overrides and get them loaded in a new image. I would like to find that there is something so slick that Migrate is not needed for Pharo. Failing that, I will port it over, once I figure out what it should do. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/05/08 5:41 PM >>> > > 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. This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4 and there is a problem we cannot really cancel B2 just add B5 to fix it. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

Re: [Pharo-project] About reusing tests via traits

by Bill Schwab

Stef, Dumb question: are traits essential to it, or simply a way of achieving it? Just curious, as I am still trying to put traits in perspective. They strike me (so far, right or wrong) as a form of multiple inheritance, which I have assumed (right or wrong) is often not needed with clever aggregation/composition of single-inheritance objects. One very slick use of multiple inheritance in C++ provides an easy way to implement COM objects with multiple interfaces - not that I have any desire to do that, but it is slick for C++. Whether that says something about multiple inheritance's strengths or about C++'s weaknesses, I'm not sure :) Pearls of wisdom will be eagerly assimilated. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/05/08 5:37 PM >>> Hi guys I did a fun coding session in the train to brest. I started to code collection tests as traits (as damien did for stream) and this is reallllly cool. I could write some tests and apply them to OrderedCollection, Set, Bag, Interval..... I will publish that and continue. I imagine that the coverage for Collection is increase a lot. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by Bill Schwab

Stef, I suspect your mood is appropriate. Most likely, it masks a failure to initialize something to a collection. Unless there is a performance argument (e.g. many are created, few are actually used, or something like that??), then it probably should go. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> stephane.ducasse(a)inria.fr 10/05/08 5:31 AM >>> 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

> > 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. This sounds like a good idea. Now I do not know if this could work because if we integrate B1 B2 B3 B4 and there is a problem we cannot really cancel B2 just add B5 to fix it. Stef

Oct. 5, 2008

[Pharo-project] About reusing tests via traits

by StÃ©phane Ducasse

Hi guys I did a fun coding session in the train to brest. I started to code collection tests as traits (as damien did for stream) and this is reallllly cool. I could write some tests and apply them to OrderedCollection, Set, Bag, Interval..... I will publish that and continue. I imagine that the coverage for Collection is increase a lot. Stef

Oct. 5, 2008

Re: [Pharo-project] [update] 10087

by StÃ©phane Ducasse

I will because I want to know my mistake. So if you can report that too it would help. I will really start to code a lot using traits :) Stef > >> 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 :) > > or wait until I finish it... it's on my todo list (like the world > menu). Since I already worked on it I think it makes more sense I > finish it and we do not put additional load on Marcus. When its > done, however, I would appreciate another person having a look over > the changes. > > Adrian > _______________________________________________ > 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] about class abtractness

by Alexandre Bergel

A class is said to be abstract if its not reasonable to instantiate it. An abstract class may perfectly have no abstract method. Cheers, Alexandre On 5 Oct 2008, at 11:49, StÃ©phane Ducasse wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 5, 2008

Re: [Pharo-project] SqueakSource dns

by Michael Roberts

ok thanks, i'll keep checking. Mike

Oct. 5, 2008

Re: [Pharo-project] SqueakSource dns

by Adrian Lienhard

It works for me, also if I ask one of its three name servers directly. The domain name has recently been transferred, so it could be that there is a problem. Maybe not all changes have been propagated yet. Adrian On Oct 5, 2008, at 20:25 , Michael Roberts wrote: > folks, squeaksource.com resolves for me but www.squeaksource.com does > not. Could anyone else verify/counter this? It's causing the latest > update to stall for me. > > thanks, > > Mike > > _______________________________________________ > 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] SqueakSource dns

by Alexandre Bergel

Hi Mike, squeaksource.com and www.squeaksource.com works in an equal manner for me. Cheers, Alexandre On 5 Oct 2008, at 20:25, Michael Roberts wrote: > folks, squeaksource.com resolves for me but www.squeaksource.com does > not. Could anyone else verify/counter this? It's causing the latest > update to stall for me. > > thanks, > > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 5, 2008