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

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

by Mariano Martinez Peck

> >> > > Ok, I will do that. Now, I would like to keep > #testAllClassesImplementSafeEqualsMethod somewhere for the future. But I > cannot find a good existing class/package for it? ideas? > forget about the test since it is not 100% accurate. We still need human intervation. Anywya, I publish a slice with the fixes to those classes I think that need to be fixed. If anyone can review: http://code.google.com/p/pharo/issues/detail?id=5997 cheers > >> and btw...the automatic #hash and #= generator, shouldn't use #species >> rather then #classes to? >> >> thanks >> >> Yes, I've never used those :) >> >> Cheers, >> Henry >> > > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Mariano http://marianopeck.wordpress.com

May 30, 2012

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

by Mariano Martinez Peck

On Wed, May 30, 2012 at 3:32 PM, 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. > > > Ok, I will do that. Now, I would like to keep #testAllClassesImplementSafeEqualsMethod somewhere for the future. But I cannot find a good existing class/package for it? ideas? > > and btw...the automatic #hash and #= generator, shouldn't use #species > rather then #classes to? > > thanks > > Yes, I've never used those :) > > Cheers, > Henry > -- Mariano http://marianopeck.wordpress.com

May 30, 2012

[Pharo-project] Glamorous Inspector

by Camillo Bruni

I'm trying to load the Glamorous Inspector in 2.0. Besides some difficulties with non-present versions in some Configs (RB and Co) I got the thing more or less running. However it doesn't find BorderedSubpaneDividerMorph, any chance where I might find this class? best cami

May 30, 2012

Re: [Pharo-project] Log framework

by Mariano Martinez Peck

see http://book.pharo-project.org/book/LanguageAndLibraries/LoggingTools/ On Wed, May 30, 2012 at 4:08 PM, Ben Coman <btc(a)openinworld.com> wrote: > Marcus Denker wrote: > >> On May 30, 2012, at 10:03 AM, Sven Van Caekenberghe wrote: >> >> >> >>> 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. >>> >>> >>> >> >> We should really think about promoting one framework to be the >> one-and-only to be used in the image itself... >> >> Marcus >> >> -- >> Marcus Denker -- http://marcusdenker.de >> >> >> >> >> > Or a defined API that can be swapped out underneath for different > implementations. > > -- Mariano http://marianopeck.wordpress.com

May 30, 2012

Re: [Pharo-project] Log framework

by Ben Coman

Marcus Denker wrote: > On May 30, 2012, at 10:03 AM, Sven Van Caekenberghe wrote: > > >> 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. >> >> > > We should really think about promoting one framework to be the one-and-only to be used in the image itself... > > Marcus > > -- > Marcus Denker -- http://marcusdenker.de > > > > Or a defined API that can be swapped out underneath for different implementations.

May 30, 2012

[Pharo-project] mixing open and closed source within Pharo

by Ben Coman

What ideas are floating around about mixing open source and closed source using Pharo? I am implementing an IEC Standard object model for electrical power systems to provide a platform for developing electrical applications. I am considering the case where a company may maintain the model of their electrical power distribution network in the open source platform, but then buy various commercial plug-ins perform different calculations upon the shared model. Here are the options I can imagine... 1. Using fuel to load binary packages within the one image without the source. Currently available technology but viewing and decompiling bytecode is still possible - but to what degree this enables reverse engineering I am not sure. 2. Having VM support for restricting displaying/decompiling bytecode. To avoid the ease of switching to another VM without this restriction, the fuel package could be encrypted with a key match one compiled inside the required VM. 3. Running multiple images on a single VM such that the VM passing message calls efficiently between the two images like an "enterprise bus*" - one open source and one closed source. Any common base objects between the images might be shared on a copy-on-write basis. What are your thoughts? cheers -ben

May 30, 2012

Re: [Pharo-project] Log framework

by Milan Mimica

On 30 May 2012 01:56, Santiago Bragagnolo <santiagobragagnolo(a)gmail.com>wrote: > Hi all. > > 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. > I was pointed to toothpick once: http://www.metaprog.com/Toothpick/index.html It resembles log4j and I like the API, but last time I check it didn't work out of the box on Pharo. -- Milan Mimica http://sparklet.sf.net

May 30, 2012

Re: [Pharo-project] Log framework

by Santiago Bragagnolo

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 30, 2012

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

by Henrik Sperre Johansen

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 <mailto:henrik.s.johansen@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 30, 2012

[Pharo-project] [update 2.0] #20101

by Marcus Denker

20101 ----- Issue 5987: Remove SARInstaller http://code.google.com/p/pharo/issues/detail?id=5987 Issue 5979: Method names containing shortcut broken http://code.google.com/p/pharo/issues/detail?id=5979 Issue 5696: Failing tests: Traits http://code.google.com/p/pharo/issues/detail?id=5696 -- Marcus Denker -- http://marcusdenker.de

May 30, 2012