- Pharo-dev - lists.pharo.org

Re: [Pharo-project] new look / monticello UI

by Gary Chambers

Seems MC has changed. Like OB it should really use PluggableButtonMorphPlus. Is ok on a 3.9 image with MC 1.0 (Watery2 has the label text greyed). Regards, Gary. ----- Original Message ----- From: "Michael Roberts" <mike(a)mjr104.co.uk> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> Sent: Saturday, December 20, 2008 3:39 PM Subject: [Pharo-project] new look / monticello UI > guys, I'm liking the new UI in Pharo. I've noticed in the Monticello > browser that the buttons now don't have an enabled/disabled state. Is > this intentional or noticed? > > thanks, > > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2008

Re: [Pharo-project] About the merging tool and "affordance"

by Gary Chambers

Hopefully I'll get some time in the new year to complete the diff tool to allow in-method merging (composited from either alternative along with manual editing). I'll take Damien's suggestion first to label the left & right panes with their origin. Regards, Gary. ----- Original Message ----- From: "Simon Denier" <Simon.Denier(a)inria.fr> To: <pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, December 17, 2008 3:50 PM Subject: [Pharo-project] About the merging tool and "affordance" > Hi all > > With Stef today, we kept scratching our head about how the new merging > tool works. Sure it looks cool, but it is not 100% intuitive. A few > suggestions: > > - above the compare panels, show which version is displayed (or which > one is the current, which one is the incoming) > - the direction of the arrow left/right, depending on whether we keep > the current or the incoming, seems wrong. Inverse it? > > -- > Simon > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2008

Re: [Pharo-project] Dictionary as a Set

by Igor Stasenko

There was a discussion about Dicts/Sets on squeak dev more than year ago http://lists.squeakfoundation.org/pipermail/squeak-dev/2007-June/117840.html IMO making Dictionary a subclass of Set was mistake. But there's little what can be done without risk of breaking many code. Some related problem - about letting Sets include nils and 'self' as elements, also was discussed on squeak-dev. It can be done w/o breaking much compatibility. 2008/12/30 nicolas cellier <ncellier(a)ifrance.com>: > Sorry to repost, seems that gmane did not like my first attempt... > > > StÃ©phane Ducasse <stephane.ducasse@...> writes: > > > > > > On Dec 29, 2008, at 12:23 PM, Alexandre Bergel wrote: > > > > > Dear List, > > > > > > I was wondering whether I am the only one shocked when I see this: > > > > > > (Set new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> true > > > (Set new add: #b -> 'B'; yourself) includes: 'B' ====> false > > > > this is correct > > > > > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' > > > ====> false > > > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> true > > > > we should check the semantics of includes: > > > > > Dictionary inherits from Set. This means that if Set would have a > > > contract, it would break in Dictionary. > > > IMO, we should have > > > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> > > > true > > > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> > false > > > > > > No? > > > > Dictionary and Set relationship is subclassing so a lot can be strange. > > We should fix that in Bloc. > > > > From the st80 origin, Dictionary is a Bag of values. > Each value of this Bag is indexed with a unique key. > > It is a Bag because: > a) multiple values can be in the dictionary: > (Dictionary new) at: 'one' put: 1; at: 'first' put: 1; yourself. > b) values are unordered: > | d1 d2 | > (d1 := Dictionary new: 3) at: 'one' put: 1; at: 'two' put: 2. > (d2 := Dictionary new: 4) at: 'one' put: 1; at: 'two' put: 2. > stream := (String new: 64) writeStream. > d1 do: [:v | stream print: v; cr]. > d2 do: [:v | stream print: v; cr]. > stream contents. > And as you can see, #do: does apply on values, as would #collect: > #select: #reject: #includes: etc... > > The fact that Dictionary is implemented with Associations could be seen > as a private implementation-defined feature. > Though, by tradition, associationsDo: has been made a public interface, > so as the possibility to directly add an Association. > > But semantically, Dictionary is not a Set of Associations. > Example: > (Set new) add: $a->65; add: $a->1; yourself. > (Dictionary new) add: $a->65; add: $a->1; yourself. > > Dictionary could be viewed as a Set of keys. > From that POV, it shared enough property with Set to be implemented as > a subclass. That's all. > I proposed once to detach Set and Dictionary and derive them from a > common ancestor just for > clarity... > > Nicolas > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Dec. 30, 2008

Re: [Pharo-project] FreeType scanning Font folders

by Gary Chambers

A scan would be needed when the image is moved to a different platform (Linux vs Win32, say). Just saying as I develop on Win for a Linux end-user application. After making the deployment image it was neccessary to load on Linux and save again to get the correct fonts. Might be different now in the latest FreeType since TextStyles are no longer used... Regards, Gary. ----- Original Message ----- From: Rob Rothwell To: Pharo-project(a)lists.gforge.inria.fr Sent: Monday, December 15, 2008 11:22 PM Subject: Re: [Pharo-project] FreeType scanning Font folders I just removed the #startup: method, and everything still works fine for fonts ALREADY loaded...even the font selection dialog box. Maybe just a button to rescan on demand? Take care, Rob On Mon, Dec 15, 2008 at 3:31 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: would be nice indeed. Stef On Dec 15, 2008, at 4:02 PM, Marcus Denker wrote: > > On 14.12.2008, at 12:02, Hilaire Fernandes wrote: > >> Hello all, >> >> I am preparing a new istoa public release with latest Pharo. I am >> only >> using two fonts and I would like FreeType to only scan the Font >> folder >> along the .image. >> Can someone point me where to look to prevent FreeType scanning the >> host system folders at start up? >> > > The font reading is done in FreeTypeFontProvider class>>startUp: > > I really don't like this font scanning... I wonder if we can delay > that somehow. > e.g. to the point where the font-chooser is actually opened? > > 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 ------------------------------------------------------------------------------ _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2008

Re: [Pharo-project] Polymorph sound theme

by Gary Chambers

Indeed, but might be useful for deployed applications... Regards, Gary. ----- Original Message ----- From: "Ramon Leon" <ramon.leon(a)allresnet.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, December 15, 2008 4:12 PM Subject: Re: [Pharo-project] Polymorph sound theme >> I also never use sound (imagine an office with 5 people each >> playing a >> sound when opening a browser window ;)). >> If there is sound I would turn it off by default. >> >> Adrian > > Ditto. I need nor want sound from my programming environment. > > Ramon Leon > http://onsmalltalk.com > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2008

Re: [Pharo-project] the button of the last watery are gorgeous!

by Gary Chambers

Thanks. Might get the buttons to honour the cornerStyle property for more flexibility (will choose from rounded or squarer form sets). Trouble with button sizes is down to use of proportional layout for button areas (essentially fixed size). Would be better to use table layouts and setting offests from minimum height etc. Hope you all have had a nice Christmas break. Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, December 14, 2008 8:33 PM Subject: [Pharo-project] the button of the last watery are gorgeous! > It is amazing as a nice look already change a lot. > Now I have a question? do you plan to get the buttons (pkgs hier. > Smart groups a bit bigger). > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 30, 2008

[Pharo-project] Dictionary as a Set

by nicolas cellier

Sorry to repost, seems that gmane did not like my first attempt... StÃ©phane Ducasse <stephane.ducasse@...> writes: > > > On Dec 29, 2008, at 12:23 PM, Alexandre Bergel wrote: > > > Dear List, > > > > I was wondering whether I am the only one shocked when I see this: > > > > (Set new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> true > > (Set new add: #b -> 'B'; yourself) includes: 'B' ====> false > > this is correct > > > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' > > ====> false > > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> true > > we should check the semantics of includes: > > > Dictionary inherits from Set. This means that if Set would have a > > contract, it would break in Dictionary. > > IMO, we should have > > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> > > true > > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> false > > > > No? > > Dictionary and Set relationship is subclassing so a lot can be strange. > We should fix that in Bloc. > From the st80 origin, Dictionary is a Bag of values. Each value of this Bag is indexed with a unique key. It is a Bag because: a) multiple values can be in the dictionary: (Dictionary new) at: 'one' put: 1; at: 'first' put: 1; yourself. b) values are unordered: | d1 d2 | (d1 := Dictionary new: 3) at: 'one' put: 1; at: 'two' put: 2. (d2 := Dictionary new: 4) at: 'one' put: 1; at: 'two' put: 2. stream := (String new: 64) writeStream. d1 do: [:v | stream print: v; cr]. d2 do: [:v | stream print: v; cr]. stream contents. And as you can see, #do: does apply on values, as would #collect: #select: #reject: #includes: etc... The fact that Dictionary is implemented with Associations could be seen as a private implementation-defined feature. Though, by tradition, associationsDo: has been made a public interface, so as the possibility to directly add an Association. But semantically, Dictionary is not a Set of Associations. Example: (Set new) add: $a->65; add: $a->1; yourself. (Dictionary new) add: $a->65; add: $a->1; yourself. Dictionary could be viewed as a Set of keys. From that POV, it shared enough property with Set to be implemented as a subclass. That's all. I proposed once to detach Set and Dictionary and derive them from a common ancestor just for clarity... Nicolas

Dec. 30, 2008

Re: [Pharo-project] Dictionary as a Set

by nicolas cellier

StÃ©phane Ducasse <stephane.ducasse@...> writes: > > > On Dec 29, 2008, at 12:23 PM, Alexandre Bergel wrote: > > > Dear List, > > > > I was wondering whether I am the only one shocked when I see this: > > > > (Set new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> true > > (Set new add: #b -> 'B'; yourself) includes: 'B' ====> false > > this is correct > > > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' > > ====> false > > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> true > > we should check the semantics of includes: > > > Dictionary inherits from Set. This means that if Set would have a > > contract, it would break in Dictionary. > > IMO, we should have > > (Dictionary new add: #b -> 'B'; yourself) includes: #b -> 'B' ====> > > true > > (Dictionary new add: #b -> 'B'; yourself) includes: 'B' ====> false > > > > No? > > Dictionary and Set relationship is subclassing so a lot can be strange. > We should fix that in Bloc. > >From the st80 origin, Dictionary is a Bag of values. Each value is indexed with a unique key. It is a Bag because: a) multiple values can be in the dictionary: (Dictionary new) at: 'one' put: 1; at: 'first' put: 1; yourself. b) values are unordered: | d1 d2 | (d1 := Dictionary new: 3) at: 'one' put: 1; at: 'two' put: 2. (d2 := Dictionary new: 4) at: 'one' put: 1; at: 'two' put: 2. stream := (String new: 64) writeStream. d1 do: [:v | stream print: v; cr]. d2 do: [:v | stream print: v; cr]. stream contents. And as you can see, #do: does apply on values, as would #collect: #select: #reject: #includes: etc... The fact that Dictionary is implemented with Associations could be seen as a private implementation defined feature. Though, by tradition, associationsDo: has been made a public interface, so as the possibility to directly add an Association. But semantically, Dictionary is not a Set of Associations. Example: (Set new) add: $a->65; add: $a->1; yourself. (Dictionary new) add: $a->65; add: $a->1; yourself. Dictionary could be viewed as a Set of keys. >From that POV, it shared enough property with Set to be implemented as a subclass. That's all. I proposed once to detach Set and Dictionary from a common ancestor just for clarity... Nicolas

Dec. 30, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by StÃ©phane Ducasse

Thanks janko Stef On Dec 29, 2008, at 6:00 PM, Janko MivÅ¡ek wrote: > Hi Stef, > > StÃ©phane Ducasse wrote: > >> I checked and >> - pharo does not complain for what seems good. So no bugs from our >> side. >> >> - SwazooBenchmarks seems to have an instance class variable with >> uppercase >> Singleton >> >> can you check and confirm. I tried to load beta2.2 >> Thanks > > Yep, that's it! And it seems it comes from VW definition, where since > 7.x you don't have class variables anymore but just shared ones. It > seems I wrongly put this Singleton as the class instance variable and > porting to Squeak ported that mistake too. > > Sorry for that and the error will be corrected in the next release. In > the meantime you can safely just ignore it. > > Best regards > Janko > > > >> >> On Dec 29, 2008, at 5:16 PM, Janko MivÅ¡ek wrote: >> >>> Hi Ramon, >>> >>> Ramon Leon wrote: >>> >>>>>> Yes I contacted Janko if he can fix that >>>>> I can fix of course but I'm a bit surprised that in Squeak the >>>>> class >>>>> variables are supposed to be lower case. I have in mind back >>>>> from 1996 >>>>> that they must be uppercase. >>>> Janko, I'm pretty sure Lukas was talking about a class instance >>>> variable, >>>> not a class variable. Class instance variables should be lowercase >>>> while >>>> class vars are uppercase. Swazoo apparently contains a class- >>>> instance >>>> variable that is uppercased, which regardless of the outcome of >>>> this >>>> discussion, should probably be fixed. >>> Here is the exact definition of a Swazoo class in question: >>> >>> Object subclass: #SwazooServer >>> instanceVariableNames: 'sites servers watchdog' >>> classVariableNames: 'Singleton' >>> poolDictionaries: '' >>> category: 'Swazoo-Core' >>> >>> And here the same definition of Swazoo SiteRegistry in VW 3.0 back >>> from >>> 2000: >>> >>> Object subclass: #SiteRegistry >>> instanceVariableNames: 'sites servers ' >>> classVariableNames: 'Singleton ' >>> poolDictionaries: '' >>> category: 'Swazoo' >>> >>> So, this is obviously a class variable definition and not an >>> instance >>> one. Where is the problem then? I don't find any class instance >>> variables in other classes and in any way the Singleton should be >>> only >>> class variable in use in Swazoo. >>> >>> Best regards >>> Janko > > > -- > Janko MivÅ¡ek > AIDA/Web > Smalltalk Web Application Server > http://www.aidaweb.si > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 30, 2008

Re: [Pharo-project] On not unnecessarily closing down the language

by Vassili Bykov

I don't think you guys see that what Lukas is proposing is not necessarily a change of the language, but a better stratification of the system. Arguments don't have to be writable in a Smalltalk program if tradition dictates they shouldn't be. But a good language platform would still support that under the hood. Janko already pointed out that VisualWorks suggests but does not enforce variable capitalization rules. VisualWorks also supports assigning to method arguments. It's a compiler flag, and it's off by default when compiling Smalltalk methods, but you can implement a different language with different rules and still use the same code generator simply by flipping that switch. The VM supports that too, despite being much more advanced. And let me once again explain that this has nothing to do with the ability to restart a context. As long as a message is sent by computing argument values and pushing them on the stack in the sender context, and as long as there is a context reflection facility (and I can't imagine a decent implementation without one regardless of how the contexts are really managed), the debugger can always restore the original values from the sender context. --Vassili On Mon, Dec 29, 2008 at 2:20 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > I agree and to me looks like a change for a change. > There are so much things I would like to see better in Pharo... > > > On Dec 29, 2008, at 2:51 AM, Igor Stasenko wrote: > >> 2008/12/29 Alexandre Bergel <Alexandre.Bergel(a)inria.fr>: >>> Frankly speaking, I am left unconvinced that allowing argument to be >>> writable will increase the quality of Pharo. >>> >> me too. >> It would be better to keep distinction between arguments and temps and >> do not rely on implementation. >> I think that in stack-based VM , an assignable arguments could be >> problematic, because if you want to restart a method, you will be >> unable to recover original values because they are not copied in >> context but lying on stack. >>

Dec. 29, 2008