October 2008 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Package browser bugs

by David RÃ¶thlisberger

> The browser is getting really good. > may be one of thse days you should show to the people you multiple > methods functionality yes, I discussed with a couple of people about this multiple selection and we got the impression that we should adapt the approach a bit. For instance, it probably works better if the different panels are not horizontally but vertically arranged. Then we should extend multiple selection to all entities, not just methods. David > On Oct 3, 2008, at 3:32 PM, Alexandre Bergel wrote: > >> Excellent David, >> >> Thanks for your hard work. >> >> Alexandre >> >> On 3 Oct 2008, at 15:22, David RÃ¶thlisberger wrote: >> >>> Hi Stef, >>> >>> ok, I was able to reproduce this bugs and will fix them soon. >>> >>> David >>> >>>> 2 bugs: >>>> - when I select a class in a hierarchy when I click on package, the >>>> package is not selected >>>> - the drag and drop on a package does not work with me. >>>> Let me know if you need a more precise example >>>> 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 >>> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 6, 2008

Re: [Pharo-project] Package browser bugs

by David RÃ¶thlisberger

>> - when I select a class in a hierarchy when I click on package, the >> package is not selected I fixed this problem in OB-Enhancements-dr.221. >> - the drag and drop on a package does not work with me. For this I need a bit more time. Somehow drag & drop on trees doesn't work as expected. David

Oct. 6, 2008

Re: [Pharo-project] [ANN] Demo with both Truetype + Polymorph

by Marcus Denker

On 05.10.2008, at 18:50, Matthias Berth wrote: > Hi Marcus, > > how did you create the demo? I'd like to make a script that installs > these in pharo-web, but I am running into various problems when I try > to install Polymorph, or TrueType fonts. > 1) installed TT fonts. For this, used the package that Andy put together for Stef some time ago: > http://www.zen61439.zen.co.uk/ft_pharo/ft_pharo.zip 2) Polymoprh http://wiki.squeak.org/squeak/6005 Especially uncommenting the progressbar in MC is important. > Cheers > > Matthias > > On Sun, Sep 21, 2008 at 10:38 PM, Marcus Denker > <denker(a)iam.unibe.ch> wrote: >> >> Here is a Demo with TrueType fonts and Polymorph installed (only >> tested on >> Mac). >> >> https://gforge.inria.fr/frs/download.php/7268/Pharo0.1- >> PolymorphTT.zip >> >> >> 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 >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 6, 2008

Re: [Pharo-project] about class abtractness

by Simon Kirk

If the definition of abstraction is that one can't instantiate an instance of the abstract class (I'm cribbing the definition of it here a bit from Java/C#/etc where one can't instantiate abstract classes by restriction in the language) then how about overriding #new on the class side with an implementation which provides an exception from any send to #new on that class and implement an #isAbstract that looks for that exception? That's of course assuming that non-instantiability is a desired behaviour here. This could well be a bogus assumption on my part. Cheers, Simon On 6 Oct 2008, at 07:18, StÃ©phane Ducasse wrote: > this is why there is a or in my expression and this is why I still > would like to have a way to declare a class as abstract even if it > does not have abstract methods. > > stef > > On Oct 5, 2008, at 11:34 PM, Alexandre Bergel wrote: > >> 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 >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> 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 ****************************************************************************************************************************************** This email is from Pinesoft Limited. Its contents are confidential to the intended recipient(s) at the email address(es) to which it has been addressed. It may not be disclosed to or used by anyone other than the addressee(s), nor may it be copied in anyway. If received in error, please contact the sender, then delete it from your system. Although this email and attachments are believed to be free of virus, or any other defect which might affect any computer or IT system into which they are received and opened, it is the responsibility of the recipient to ensure that they are virus free and no responsibility is accepted by Pinesoft for any loss or damage arising in any way from receipt or use thereof. ******************************************************************************************************************************************* Pinesoft Limited are registered in England, Registered number: 2914825. Registered office: 266-268 High Street, Waltham Cross, Herts, EN8 7EA

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by Lukas Renggli

> which could make sense. Now I saw some other places where this is way to > avoid to be precise. Even if slightly longer, I find the following expression more readable a isNil or: [ a isEmpty ] than a isEmptyOrNil Especially with the long form I know at one glance what it *exactly* does. I don't think it is an advantage to introduce hundreds of control structures with unclear semantics. These things make porting code very hard too. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by StÃ©phane Ducasse

There is a typical usage fileOutSoundLibrary: aDictionary "File out the given dictionary, which is assumed to contain sound and instrument objects keyed by their names." "Note: This method is separated out so that one can file out edited sound libraries, as well as the system sound library. To make such a collection, you can inspect AbstractSound sounds and remove the items you don't want. Then do: 'AbstractSound fileOutSoundLibrary: self' from the Dictionary inspector." | fileName refStream | fileName := UIManager default request: 'Sound library file name?'. fileName isEmptyOrNil ifTrue: [^ self]. refStream := SmartRefStream fileNamed: fileName, '.sounds'. refStream nextPut: aDictionary. refStream close. which could make sense. Now I saw some other places where this is way to avoid to be precise. Stef On Oct 6, 2008, at 8:28 AM, StÃ©phane Ducasse wrote: > > On Oct 6, 2008, at 3:47 AM, David Pennell wrote: > >> Stef, >> >> I would expect to see another implementation of ifEmptyOrNil on >> UndefinedObject that returns true. >> I've seen it used productively for defensive coding in frameworks, >> where you may get nil instead of an empty collection passed to you. > > Hi david > > Good suggestion. I learned something. > > UndefinedObject>>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" > ^ true > > I still find that somehow ugly. Fixing the cause not the problem. > > 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 StÃ©phane Ducasse

you can achieve the same with copy and paste or code generation. What is nice with traits is that they represent a bloc of coherent behavior that can be parametrized. Load the latest Collection-Tests from the pharo source. This is just the start but this is quite cool. Check TEmptyTest. It is applied to OrderedCollection, Basg, Set, Array, Interval (and could be to others too). Yesterday I got a really nice presentation of Miro by alain plantec and he is also using traits. Stef On Oct 6, 2008, at 3:35 AM, Bill Schwab wrote: > 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 > > > _______________________________________________ > 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 StÃ©phane Ducasse

On Oct 6, 2008, at 3:47 AM, David Pennell wrote: > Stef, > > I would expect to see another implementation of ifEmptyOrNil on > UndefinedObject that returns true. > I've seen it used productively for defensive coding in frameworks, > where you may get nil instead of an empty collection passed to you. Hi david Good suggestion. I learned something. UndefinedObject>>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" ^ true I still find that somehow ugly. Fixing the cause not the problem. Stef

Oct. 6, 2008

Re: [Pharo-project] about ifEmptyOrNil:

by StÃ©phane Ducasse

Yes sorry I was in the train and this is isEmptyOrNil: > I don't have an ifEmptyOrNil: in my image only isEmptyOrNil and that > is specified for Collection and UndefinedObject. > > Did I miss something? No

Oct. 6, 2008

Re: [Pharo-project] Some clearifications

by StÃ©phane Ducasse

On Oct 6, 2008, at 7:22 AM, Norbert Hartl wrote: > On Sun, 2008-10-05 at 23:41 +0200, StÃ©phane Ducasse wrote: >>> >>> 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. >> > I think there are cases where you have to redo B2, e.g. if it is not > loadable. Yes but there are case where you have to redo B3 if it depends/is based on B3 > Then just redo it and post it to the list. Everyone using a > development upstream should read the list. > Removing B2 is not necessary because B5 undoes the problem of B2. And > that is exactly the reason for doing an development upstream. You can > undo things before merging the whole thing into the official upstream. > The official one does not contain anything faulty from B2. What might > be a problem is that version numbers on dev are getting larger faster > than on the official one (if you use a single number). > > So the usual development case is that you take the latest official > release S1 and do subsequent D1, D2, D3, D4 enhancements. If you > think everything is stable and worth publishing you merge D4 into S1 > and create S2. Based on that you do D5, D6, D7 and so on. This is already what we do somehow with publishing an image. But we do not have two streams. > > About the naming scheme I'm not sure. I would prefer something like > stable version 1 and development version 1.1, 1.2, 1.3 than stable > version 2 and development 2.1, 2.2. So there is no doubt which > development version belongs to which stable version. > > But I don't know how much work it will be to get it work that way. I do not know. What we can do is to have enough time and testers using the up stream. :) > > > Norbert > > > > _______________________________________________ > 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