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

Re: [Pharo-project] moving Finder up to first level of World menu

by StÃ©phane Ducasse

>> >> Examples than pattern. >> because Pattern to me measn something else. > > I know :) But some people argue the opposite so I just picked :) > >> >> We should also give us access to update spec and nautilus directly because like that we are not the bottleneck. > > What o you mean ? that you should commit directly your changes to nautilus and spec and that we do not have to do it. But right now focus on the paper. Can you create a svn repo? Stef > > Ben > >> Stef >> >> On May 30, 2012, at 6:12 PM, Benjamin wrote: >> >>> +1 :) >>> >>> You can also use the finder plugin for Nautilus made by Damien Cassou :) >>> >>> Ben >>> >>> On May 30, 2012, at 11:43 AM, Ben Coman wrote: >>> >>>> >>>> Has any consideration been given to moving World > Tools > Finder up to World > Finder. >>>> I find this is core to my work flow and I it is used much more often than any of System Browser, Workspace, Test Runner or Monticello Browser - and I wonder if anyone finds the same? >>>> >>>> cheers -ben >>>> >>> >>> >> >> > >

May 31, 2012

Re: [Pharo-project] [ANN] NativeBoost 1.2 version released (#development)

by StÃ©phane Ducasse

thanks a lot for all that good work. On May 31, 2012, at 2:33 AM, Igor Stasenko wrote: > Update: > i synchronized Athens Cairo backend with latest changes in NativeBoost. > > ConfigurationOfAthens version 1.2 > is now working with NB v 1.2 > > (same version numbers are just coincidence) > > > -- > Best regards, > Igor Stasenko. >

May 31, 2012

Re: [Pharo-project] Log framework

by Santiago Bragagnolo

Hi again Im already add several classes to the logger. http://ss3.gemstone.com/ss/PaulLePulp the way to use it still primitive, but is a nice draft. If you look at LogConfiguration configuration (class method) you'll find something like this self for:[ :builder | builder forClass:LogTestObject useLevel:#info showingLogAs: ('[%pid | %tstmp | %tag] #%class >> %selector' asPatternFormatter) into: Transcript asLogWriter retain:true. builder forKey:'default' useLevel:#error. ] then, with LogTestObject, if you send it "error", "warn" or "info", all you send there (blocks, strings, symbols or what-understand-value) will be showed at Transcript. (im didnt test on file or stdout yet) Finally retain:true adds the log to LogHolder, which responds to LogHolder instance select:[ :log | log whatYouWantToTest ]. Ill be testing tomorrow and fixing, but, if you want to see and advise me, you are welcome :) Ok, is 4am, im going to sleep 2012/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I would like a logging mechanism that manipulate objects that then are > printed in various format. > The compiler could use such logger > > I did not look at the code of toothpick probably extending LoggingEvent > should do it. > > Stef > > > On May 30, 2012, at 3:41 PM, Santiago Bragagnolo wrote: > > > Ok, i'll take what i need from the marianito's and zn and fork them in > an other package, add what i need for massive loggin (like levels of > loggin) and make a log-framework. > > > > Any names? clairvoyant :3? > > > > Then, is any easy aspect fwk that could i use for the logger? (sometimes > i need just trace runtime, or i dont want to add a log line one by one) > that works in pharo 2.0 ? :P? > > > > > > 2012/5/30 Sven Van Caekenberghe <sven(a)beta9.be> > > > > On 30 May 2012, at 01:56, Santiago Bragagnolo wrote: > > > > > Im looking for a log framework with configurable levels. Theres any > stable and useful? I browsed the list and didn't find nothing but > something like 'every body has its own logging framework'. > > > > > > I wrote a small logging fwk for my project, but if is any more > complete, it would be great. > > > > There is one logging framework already in your image: Zinc-HTTP-Logging. > > It is based on Announcments. Although it is part of Zn, it is general > purpose. > > What is special is that it logs the process ID as well, which is useful > to debug multiprocess applications. > > See the Zn documentation for more info. > > > > Sven > > > > > > > > >

May 31, 2012

Re: [Pharo-project] omni browser

by Milan Mimica

On 31 May 2012 00:27, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Thats because it loads the default group. > > Try with this script after loading the configuration from > MetacelloRepository: > > Gofer it > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfOmniBrowser'; > load. > > (ConfigurationOfOmniBrowser > project version: #stable) load: #( 'Dev' 'Dev Tests'). > Ah! Took me two days. Bye bye Nautilus! -- Milan Mimica http://sparklet.sf.net

May 31, 2012

Re: [Pharo-project] Classes that implement unsafe #=

by Frank Shearar

On 31 May 2012 04:37, Chris Muller <asqueaker(a)gmail.com> wrote: > Another flexible option could be to test it respondsTo: each attribute > being used for comparison. This works quite well, and preserves "dynamic-ness": instead of checking for class membership or set-of-class membership (#species), you're saying "things that speak the same protocol/language might be equal, but definitely not if they don't speak the same language". That would permit non-transparent proxies to be #= to the things they proxy, for instance. (I use non-transparent proxies quite a lot, for instance as a means of providing an immutable pointer (Ref) to something _apparently_ immutable, but which I can change willy nilly without affecting anything pointing to the Ref.) frank > On Wed, May 30, 2012 at 8:32 AM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> On 30.05.2012 15:02, Mariano Martinez Peck wrote: >> >> >> >> On Wed, May 30, 2012 at 2:37 PM, Henrik Sperre Johansen >> <henrik.s.johansen(a)veloxit.no> wrote: >>> >>> On 30.05.2012 14:05, Mariano Martinez Peck wrote: >>>> >>>> Hi guys. I found a problem while working with FuelPreview where we store >>>> objects of the graph in a Set. While doing a collect, there was an error >>>> because an implementation of #= was assuming that the argument was of a >>>> certain shape. Of course, that should answer false instead. So I wrote this >>>> test to see all existing wrong implementations: >>>> >>>> testAllClassesImplementSafeEqualsMethod >>>> "This tests that all classes in the system that implements #= do it in a >>>> way that they don't throw error when passing as an argument something >>>> different from expected. The correct behavior is that #= answers false." >>>> Â Â | wrongClasses | >>>> Â Â wrongClasses := IdentityDictionary Â new. >>>> Â Â ((SystemNavigation default allImplementorsOf: #=) >>>> Â Â Â Â Â Â collect: [:each | each methodClass]) >>>> Â Â Â Â Â Â do: [:each | >>>> Â Â Â Â Â Â Â Â | instance | >>>> Â Â Â Â Â Â Â Â "Some classes like CompiledMethod override basicNew to >>>> throw an error. >>>> Â Â Â Â Â Â Â Â In any case, the comparison will be false, so no problem" >>>> Â Â Â Â Â Â Â Â [instance := each basicNew] on: Error do: []. >>>> Â Â Â Â Â Â Â Â [instance = Object new] >>>> Â Â Â Â Â Â Â Â Â Â on: Error >>>> Â Â Â Â Â Â Â Â Â Â do: [: err | wrongClasses at: each put: err ]]. >>>> Â Â self assert: wrongClasses isEmpty >>>> >>>> >>>> The result is: {Magnitude. WideCharacterSet. KMKeymap. MCMockDefinition. >>>> ScaledDecimal. MCSnapshot} >>>> >>>> So, my I think we should change #= in those classes by adding: >>>> >>>> Â Â self == aKeymap >>>> Â Â Â Â ifTrue: [ ^ true ]. >>>> Â Â self class = aKeymap class >>>> Â Â Â Â ifFalse: [ ^ false ]. >>>> >>>> at the beginning of the #= >>>> >>>> what do you think? Â if agree, I open an issue. >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>> I'd test against self species rather than self class, since it gives >>> greater flexibility for user-defined instances to potentially = classes in >>> the system. >>> >>> In other word, #class has a very strict meaning which would hinder >>> extensibility, #species less so. >>> >> >> Ok, I see. But the classes are only a few (five). So you recommend you use >> self species instead of self class even if we "analyze" those 5 classes to >> see if it is worth it or not (for example, we check if they do override >> #species or not) ? >> >> Yes. >> The default implementation of #species in Object uses the class primitive >> directly, so there's no overhead. >> >> The benefit is that I could write a custom MyMagnitude class, override >> species: >> species >> Â Â Â ^Magnitude >> >> and not have to override the base system Magnitude = implementation in order >> to compare with MyMagnitude instances and have a true result. >> In other words, using species in #= even if it's not needed, is setting a >> good example. >> >> >> >> and btw...the automatic #hash and #= generator, shouldn't use #species >> rather then #classes to? >> >> thanks >> >> Yes, I've never used those :) >> >> Cheers, >> Henry >

May 31, 2012

Re: [Pharo-project] Classes that implement unsafe #=

by Chris Muller

Good catch Mariano -- I have run your test on Squeak and fixed a couple of instances there too. On Wed, May 30, 2012 at 7:05 AM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi guys. I found a problem while working with FuelPreview where we store > objects of the graph in a Set. While doing a collect, there was an error > because an implementation of #= was assuming that the argument was of a > certain shape. Of course, that should answer false instead. So I wrote this > test to see all existing wrong implementations: > > testAllClassesImplementSafeEqualsMethod > "This tests that all classes in the system that implements #= do it in a way > that they don't throw error when passing as an argument something different > from expected. The correct behavior is that #= answers false." > Â Â Â | wrongClasses | > Â Â Â wrongClasses := IdentityDictionaryÂ new. > Â Â Â Â ((SystemNavigation default allImplementorsOf: #=) > Â Â Â Â Â Â Â Â Â collect: [:each | each methodClass]) > Â Â Â Â Â Â Â Â Â do: [:each | > Â Â Â Â Â Â Â Â Â Â Â Â | instance | > Â Â Â Â Â Â Â Â Â Â Â Â "Some classes like CompiledMethod override basicNew to throw > an error. > Â Â Â Â Â Â Â Â Â Â Â Â In any case, the comparison will be false, so no problem" > Â Â Â Â Â Â Â Â Â Â Â Â [instance := each basicNew] on: Error do: []. > Â Â Â Â Â Â Â Â Â Â Â Â [instance = Object new] > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â on: Error > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â do: [: err | wrongClasses at: each put: err ]]. > Â Â Â self assert: wrongClasses isEmpty > > > The result is: {Magnitude. WideCharacterSet. KMKeymap. MCMockDefinition. > ScaledDecimal. MCSnapshot} > > So, my I think we should change #= in those classes by adding: > > Â Â Â self == aKeymap > Â Â Â Â Â Â ifTrue: [ ^ true ]. > Â Â Â self class = aKeymap class > Â Â Â Â Â Â ifFalse: [ ^ false ]. > > at the beginning of the #= > > what do you think?Â if agree, I open an issue. > > > -- > Mariano > http://marianopeck.wordpress.com >

May 31, 2012

Re: [Pharo-project] Classes that implement unsafe #=

by Chris Muller

Another flexible option could be to test it respondsTo: each attribute being used for comparison. On Wed, May 30, 2012 at 8:32 AM, Henrik Sperre Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 30.05.2012 15:02, Mariano Martinez Peck wrote: > > > > On Wed, May 30, 2012 at 2:37 PM, Henrik Sperre Johansen > <henrik.s.johansen(a)veloxit.no> wrote: >> >> On 30.05.2012 14:05, Mariano Martinez Peck wrote: >>> >>> Hi guys. I found a problem while working with FuelPreview where we store >>> objects of the graph in a Set. While doing a collect, there was an error >>> because an implementation of #= was assuming that the argument was of a >>> certain shape. Of course, that should answer false instead. So I wrote this >>> test to see all existing wrong implementations: >>> >>> testAllClassesImplementSafeEqualsMethod >>> "This tests that all classes in the system that implements #= do it in a >>> way that they don't throw error when passing as an argument something >>> different from expected. The correct behavior is that #= answers false." >>> Â Â | wrongClasses | >>> Â Â wrongClasses := IdentityDictionary Â new. >>> Â Â ((SystemNavigation default allImplementorsOf: #=) >>> Â Â Â Â Â Â collect: [:each | each methodClass]) >>> Â Â Â Â Â Â do: [:each | >>> Â Â Â Â Â Â Â Â | instance | >>> Â Â Â Â Â Â Â Â "Some classes like CompiledMethod override basicNew to >>> throw an error. >>> Â Â Â Â Â Â Â Â In any case, the comparison will be false, so no problem" >>> Â Â Â Â Â Â Â Â [instance := each basicNew] on: Error do: []. >>> Â Â Â Â Â Â Â Â [instance = Object new] >>> Â Â Â Â Â Â Â Â Â Â on: Error >>> Â Â Â Â Â Â Â Â Â Â do: [: err | wrongClasses at: each put: err ]]. >>> Â Â self assert: wrongClasses isEmpty >>> >>> >>> The result is: {Magnitude. WideCharacterSet. KMKeymap. MCMockDefinition. >>> ScaledDecimal. MCSnapshot} >>> >>> So, my I think we should change #= in those classes by adding: >>> >>> Â Â self == aKeymap >>> Â Â Â Â ifTrue: [ ^ true ]. >>> Â Â self class = aKeymap class >>> Â Â Â Â ifFalse: [ ^ false ]. >>> >>> at the beginning of the #= >>> >>> what do you think? Â if agree, I open an issue. >>> >>> >>> -- >>> Mariano >>> http://marianopeck.wordpress.com >>> >> I'd test against self species rather than self class, since it gives >> greater flexibility for user-defined instances to potentially = classes in >> the system. >> >> In other word, #class has a very strict meaning which would hinder >> extensibility, #species less so. >> > > Ok, I see. But the classes are only a few (five). So you recommend you use > self species instead of self class even if we "analyze" those 5 classes to > see if it is worth it or not (for example, we check if they do override > #species or not) ? > > Yes. > The default implementation of #species in Object uses the class primitive > directly, so there's no overhead. > > The benefit is that I could write a custom MyMagnitude class, override > species: > species > Â Â Â ^Magnitude > > and not have to override the base system Magnitude = implementation in order > to compare with MyMagnitude instances and have a true result. > In other words, using species in #= even if it's not needed, is setting a > good example. > > > > and btw...the automatic #hash and #= generator, shouldn't use #species > rather then #classes to? > > thanks > > Yes, I've never used those :) > > Cheers, > Henry

May 31, 2012

Re: [Pharo-project] [ANN] NativeBoost 1.2 version released (#development)

by Igor Stasenko

Update: i synchronized Athens Cairo backend with latest changes in NativeBoost. ConfigurationOfAthens version 1.2 is now working with NB v 1.2 (same version numbers are just coincidence) -- Best regards, Igor Stasenko.

May 31, 2012

Re: [Pharo-project] omni browser

by Guillermo Polito

On Wed, May 30, 2012 at 11:58 PM, Milan Mimica <milan.mimica(a)gmail.com>wrote: > On 30 May 2012 23:07, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com>wrote: > >> try this: >> >> #. MetacelloConfigurationBrowser open. >> #. select ConfigurationOfOmniBrowser-* >> #. right click on "load configuration and stable version" >> > > I get an OmniBrowser without syntax highlight and without > code completion working. > Thats because it loads the default group. Try with this script after loading the configuration from MetacelloRepository: Gofer it squeaksource: 'MetacelloRepository'; package: 'ConfigurationOfOmniBrowser'; load. (ConfigurationOfOmniBrowser project version: #stable) load: #( 'Dev' 'Dev Tests'). cheers, Guille > > more info, >> >> http://stackoverflow.com/questions/10518095/install-script-for-omnibrowser-… >> >> > "OmniBrowser is unlikely to ever be supported in Pharo 1.4" > > Kind a sums it up. Hello Nautilus! > > > -- > Milan Mimica > http://sparklet.sf.net >

May 30, 2012

Re: [Pharo-project] omni browser

by Milan Mimica

On 30 May 2012 23:07, Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com>wrote: > try this: > > #. MetacelloConfigurationBrowser open. > #. select ConfigurationOfOmniBrowser-* > #. right click on "load configuration and stable version" > I get an OmniBrowser without syntax highlight and without code completion working. more info, > > http://stackoverflow.com/questions/10518095/install-script-for-omnibrowser-… > > "OmniBrowser is unlikely to ever be supported in Pharo 1.4" Kind a sums it up. Hello Nautilus! -- Milan Mimica http://sparklet.sf.net

May 30, 2012