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

Re: [Pharo-project] Error when trying to create a package

by Matthew Fulmer

On Mon, May 11, 2009 at 07:58:48AM +0200, St?phane Ducasse wrote: > Keith > > do you if this is my version only or this is just a behavior that is > not supported: > here is my scenario: I loaded packages and now they are in my package > cache. > I run to cache the train and there I would like to rerun the script > but the system > tells me that the network is not present so I end up loading my hand > the packages that > are in my package cache. > I would like to add that kind of behavior to Installer > > Stef I added that ability to Installer ages ago. Installer cache install: 'Morphic'. Or you want it to search the cache without changing the script? hmm. good idea. I'll make that work -- Matthew Fulmer -- http://mtfulmer.wordpress.com/

May 20, 2009

[Pharo-project] [ANN] 10311

by StÃ©phane Ducasse

- Issue 819: argumentCount - stef fixing his methods (tests) - Issue 820: Re-implement Boolean>>#==> that was removed because it was not license clean - Issue 821: Preference to settings refactoring: #confirmFirstUseOfStyle case Stef

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

by Michael Roberts

> > Better would be to make it dependent on OSPlatform current. +1 Mike

May 20, 2009

[Pharo-project] preferences clean-up

by Alain Plantec

Hi all, I think we can remove following preferences: decorateBrowserButtons, menuButtonInToolPane, optionalButtons and smartUpdating. decorateBrowserButtons : always true menuButtonInToolPane : always false optionalButtons : always true smartUpdating: always true what do you think ? Cheers Alain decorateBrowserButtons "Governs whether certain buttons, such as the Inheritance button, should bear colors that provide user feedback on their applicability" menuButtonInToolPane "when true, button panes in the various tools will sport a button which brings up the message-list menu" optionalButtons "If true, then optional buttons will be used in certain standard tools, including browsers, message lists, fileLists, changeLists, and debuggers" smartUpdating "If true, then morphic tools such as browsers and inspectors will keep their contents up to date automatically, so that if something changes anywhere, the change will be reflected everywhere."

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiasedfonts

by Gary Chambers

I remember getting shot-down on squeak-dev for that suggestion a long time ago :-) Also, on windows, using a new vm used to toggle the vm button mapping. Not sure if that happens any more though! Regards, Gary ----- Original Message ----- From: "Adrian Lienhard" <adi(a)netstyle.ch> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, May 20, 2009 4:54 PM Subject: Re: [Pharo-project] New Pharo based on core 10309 with antialiasedfonts > > On May 20, 2009, at 16:30 , Damien Pollet wrote: > >> I use nearly the same script, except with the sans fonts, and a >> couple settings: >> >> Preferences >> enable: #halosEnabled; >> enable: #swapMouseButtons; >> disable: #gradientMenu. >> >> Most important to me is swapMouseButtons, because it puts menus back >> on the correct button. Apparently this setting is needed on macs and >> linux, so by the magic of (possibly biased) numbers, the exception is >> windows. Can we have #swapMouseButtons enabled by default ? > > Better would be to make it dependent on OSPlatform current. > > Adrian > > >> >> >> On Mon, May 18, 2009 at 10:45, Damien Cassou >> <damien.cassou(a)gmail.com> wrote: >>> On Mon, May 18, 2009 at 10:37 AM, Lukas Renggli <renggli(a)gmail.com> >>> wrote: >>>> That looks great, though I would prefer a sans-serif font (DejaVu >>>> Sans) instead of a serif font (DejaVu Serif) in the UI. >>>> Serif fonts add too much noise on the screen and are typically >>>> used in >>>> print only, not in user interfaces. >>> >>> If people agree with this, I can change that. The script I currently >>> use is the following one. If you have ideas on how to improve it, >>> please tell me. >>> >>> font := LogicalFont familyName: 'DejaVu Serif' pointSize: 10. >>> codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. >>> Preferences setListFontTo: font. >>> Preferences setMenuFontTo: font. >>> Preferences setCodeFontTo: codeFont. >>> Preferences setButtonFontTo: font. >>> Preferences setSystemFontTo: font. >>> font := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. >>> Preferences setWindowTitleFontTo: font. >>> >>> -- >>> Damien Cassou >>> http://damiencassou.seasidehosting.st >>> >>> "Lambdas are relegated to relative obscurity until Java makes them >>> popular by not having them." James Iry >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Damien Pollet >> type less, do more [ | ] http://people.untyped.org/damien.pollet >> >> _______________________________________________ >> 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

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

by Adrian Lienhard

On May 20, 2009, at 16:30 , Damien Pollet wrote: > I use nearly the same script, except with the sans fonts, and a > couple settings: > > Preferences > enable: #halosEnabled; > enable: #swapMouseButtons; > disable: #gradientMenu. > > Most important to me is swapMouseButtons, because it puts menus back > on the correct button. Apparently this setting is needed on macs and > linux, so by the magic of (possibly biased) numbers, the exception is > windows. Can we have #swapMouseButtons enabled by default ? Better would be to make it dependent on OSPlatform current. Adrian > > > On Mon, May 18, 2009 at 10:45, Damien Cassou > <damien.cassou(a)gmail.com> wrote: >> On Mon, May 18, 2009 at 10:37 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >>> That looks great, though I would prefer a sans-serif font (DejaVu >>> Sans) instead of a serif font (DejaVu Serif) in the UI. >>> Serif fonts add too much noise on the screen and are typically >>> used in >>> print only, not in user interfaces. >> >> If people agree with this, I can change that. The script I currently >> use is the following one. If you have ideas on how to improve it, >> please tell me. >> >> font := LogicalFont familyName: 'DejaVu Serif' pointSize: 10. >> codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. >> Preferences setListFontTo: font. >> Preferences setMenuFontTo: font. >> Preferences setCodeFontTo: codeFont. >> Preferences setButtonFontTo: font. >> Preferences setSystemFontTo: font. >> font := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. >> Preferences setWindowTitleFontTo: font. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 20, 2009

Re: [Pharo-project] Tracing changes in MC

by Keith Hodges

Lukas Renggli wrote: >> A problem of implementing this is that you have to download each >> version of a repository and analyze it, which can take a considerable >> amount of time. >> > > Such a search is not really practicable. Even if you have the versions > stored locally you need to load and calculate the difference between > the snapshots. Furthermore you might have versions missing that are > required to accurately answer the question. Different branches make > the search even more complicated. > > Monticello 2 can answer such questions efficiently. > > Lukas > > MC1.5 reinstates the in-memory "dictionary" repository to speed up such analyses. The "dual changes" sorter puts two repositories, (or the same repository) on both sides, and the delta's in the middle. There is supposed to be a "report" function which generates a step by step description of thechanges between two repos. This report is supposed to be displayed in the middle. Keith

May 20, 2009

Re: [Pharo-project] New Pharo based on core 10309 with antialiased fonts

by Damien Pollet

I use nearly the same script, except with the sans fonts, and a couple settings: Preferences enable: #halosEnabled; enable: #swapMouseButtons; disable: #gradientMenu. Most important to me is swapMouseButtons, because it puts menus back on the correct button. Apparently this setting is needed on macs and linux, so by the magic of (possibly biased) numbers, the exception is windows. Can we have #swapMouseButtons enabled by default ? On Mon, May 18, 2009 at 10:45, Damien Cassou <damien.cassou(a)gmail.com> wrote: > On Mon, May 18, 2009 at 10:37 AM, Lukas Renggli <renggli(a)gmail.com> wrote: >> That looks great, though I would prefer a sans-serif font (DejaVu >> Sans) instead of a serif font (DejaVu Serif) in the UI. >> Serif fonts add too much noise on the screen and are typically used in >> print only, not in user interfaces. > > If people agree with this, I can change that. The script I currently > use is the following one. If you have ideas on how to improve it, > please tell me. > > font := LogicalFont familyName: 'DejaVu Serif' pointSize: 10. > codeFont := LogicalFont familyName: 'DejaVu Sans Mono' pointSize: 9. > Preferences setListFontTo: font. > Preferences setMenuFontTo: font. > Preferences setCodeFontTo: codeFont. > Preferences setButtonFontTo: font. > Preferences setSystemFontTo: font. > font := LogicalFont familyName: 'DejaVu Serif' pointSize: 11. > Preferences setWindowTitleFontTo: font. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by Lukas Renggli

> self collect: #abs Yes, that looks cool. However it is difficult to understand what it does for #(-2 3 4) - Does it collect the literal #abs for all the values of the collection? --> #(abs abs abs) - Does it collect the values of performing #abs on the collection? --> #(2 3 4) With #value:value: you even have more freedom, and it is even less clear how the result is obtained. The implementation given by the original poster might work in one (common) case, but this is definitely not the only way to use a symbol for evaluation. In Seaside 2.9 there are the classes WADelayedSend, WABoundDelayedSend and WAUnboundDelayedSend that are polymorphic to block closures and that reify different forms of message sends as first class objects. GNU Smalltalk has a similar construct built into their core library. I think that using symbols is a rather poor approach to model message sends. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

May 20, 2009

Re: [Pharo-project] Symbol>>value:value:

by Tudor Girba

Hi, (I apologize for the length of this email, but I did not know how to write it shorter) My reasons for Symbol>>value: and similar selectors are as follows. A Symbol is already used for several things, like a key in an identity dictionary. But it is also used for parameterizing a mapping to a piece of behavior via a #symbol stored in a selector instance variable. Later on, this behavior is invoked as: receiver perform: selector. This is for example what happens in Morphic, and as a result I am forced to create a Model class for a custom Morph, even if the customization is minimal. This is a hurdle when you are in prototype mode. Instead I would like to have the possibility to prototype faster using blocks instead of creating a class. This is possible right now for unary methods when the framework does not directly do a perform:, but instead it does: selector value: receiver. Ideally, we could have in the entire image only one place in which perform: is called explicitly: in the Symbol>>value:. In this way, I will be able to pass a block everywhere a unary method is now used. This is something we do when we want to use Smalltalk for scripting (Mondrian and Glamour do that) The same case goes for Symbol>>value:value: . These two methods would already cover the large majority of performs, but I would argue for adding all possibilities of evaluating blocks and of performing messages. If you are asking what do Symbol have to do with blocks from a conceptual point of view, I will answer that when the Symbol is used as a selector, it does nothing else but point to a piece of behavior. Given that a Block does a similar thing, you can as well treat them in a polymorphic fashion. The only question that remains in my mind is: does a modification like this has the possibility of harming? I am not aware of a case in which it is harmful, but who knows. Cheers, Doru On 20 May 2009, at 15:27, StÃ©phane Ducasse wrote: > value from Object and value: from Symbol are different > with value: on Symbol you can do > > self collect: #abs > > :) > > On May 20, 2009, at 2:48 PM, Gabriel Cotelli wrote: > >> +1 to the removal of value: from Symbol.... >> >> On Wed, May 20, 2009 at 3:18 AM, Lukas Renggli <renggli(a)gmail.com> >> wrote: >>> Given that in Pharo we have Symbol>>value:, are there any reasons >> not >>> to have also >>> >>> Symbol>>value: anObject value: anotherObject >>> ^ anObject perform: self with: anotherObject >> >> While Symbol>>#value: is at the border of being readable, >> Symbol>>#value:value: is even worse. It is not immediately obvious >> what it does. The order of receiver and arguments is hardcoded and >> thus the construct cannot be applied in most cases without rewriting >> the code. Fixed arguments cannot be given. >> >> Instead of adding new #value: variants, we should rather try to >> remove >> Object>>#value which is a real nightmare ;-) >> >> Cheers, >> 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 > > > _______________________________________________ > 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 "Problem solving efficiency grows with the abstractness level of problem understanding."

May 20, 2009