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

Re: [Pharo-project] OB annotation icons

by StÃ©phane Ducasse

hi antony can you explain the icons what the arrow up means ? and the others? Stef On Oct 22, 2008, at 10:27 AM, Antony Blakey wrote: > > On 22/10/2008, at 6:38 PM, Lukas Renggli wrote: > >> It is absolutely evil to display anything else than if there are >> super >> (up triangle) or sub implementations (down triangle) next to >> method. I >> just lost 10 minutes, because of these agressive green arrow that >> mark >> methods calling super. > > Whilst I agree that the 'calls super' is worse-than-useless, having > multiple annotations can be useful if they are appropriately > presented: http://linkuistics.com/ftp/Stardust-TraitAnnotation-2008-10-08.png > > A 'deprecated' marker would be useful in my environment. Then you'd > also want to find all senders of methods for which every > implementation is deprecated (or maybe just some?). > > Antony Blakey > -------------------------- > CTO, Linkuistics Pty Ltd > Ph: 0438 840 787 > > Reflecting on W.H. Auden's contemplation of 'necessary murders' in > the Spanish Civil War, George Orwell wrote that such amorality was > only really possible, 'if you are the kind of person who is always > somewhere else when the trigger is pulled'. > -- John Birmingham, "Appeasing Jakarta" > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by StÃ©phane Ducasse

On Oct 22, 2008, at 4:36 PM, Lukas Renggli wrote: >>> "Icons that show different concepts (and calling >>> super and overriding a method are entirely different concepts, as >>> well >>> as putting a breakpoint or deprecating a method) and that hide each >>> other are evil." >> >> Absolutely agree, hence that design. And in any case calling super >> is a >> stupid indicator, especially when you know that it doesn't check >> that the >> super call is a) to the same method or b) on every call path. The >> indicator >> actually means 'might call some method declared in a superclass', >> which of >> course you can easily do by calling a method that isn't overridden >> in the >> declaring class, so what the hell use is that? would be nice to know do whom I'm replying. But still there is a value in knowing that the method is doing a super call or not. The indicator means that the method use the keyword "super". So this is valuable. I really think that you are really kind of criticizing. When I browse code this arrow helps me. This is the same with the requireemnts analysis nathanael did in the old traits image Download the OOPSLA refactoring image and you can see that using is browser you can ****see**** methods sending messages not implemented. just in front of your nose. >> b) shouldn't include any action abstraction because that's best >> handled in a completely different and system-wide fashion; > > I disagree. OB provides this system-wide abstraction. It is the fault > of the other tools that don't use these abstractions. For example, > I've written a process browser, debugger, inspector and several other > tools in OB and they all benefit from the commands that already exist > and that other people write as extensions (e.g. open a hierarchy > browser from within the debugger). > > I agree that the abstraction is not optimal in all cases (e.g. text > commands, applicability tests, ...), but it is definitely better than > anything else I've seen so far. > >> different and system-wide fashion; c) is too messily tied to >> Morphic, with a >> number of hacks; and relatedly, d) shouldn't extend existing Morphic >> controls (such as lists) because they come with too much baggage >> (i.e. being >> all things to all people). > > Earlier versions of OB were entirely separated from Morphic. > Unfortunately it was tied to morphic over time as more and more people > joined the development. I guess this happend due to laziness and lack > of documentation and knowledge. Documentation more than anything else. I imagine that like most of colin code there is not one line of comments which is sad because people make mistakes. > Along the same lines: Every line of the model and view used to be > tested with in-depth SUnit-Tests. Unfortunately that is not the case > anymore either. People add features without writing tests. this is sad too. The problem is that if the system does not offer incentive and that you do not see the immediate benefits then you do not do it. This is why I would really like to see a package manifesto supporting design, styles rules checking, test regressions results so that the incentive to write code with documentation and tests is raised. > > > This is what happens, when an appealing and widely adapted projects > entirely lacks a form of leadership. > > At some point there was an AJAX based web view and a XUL interface. I > think somebody even made GTK view. Earlier versions of OB run in > GemStone, with the view running in Squeak Morphic. There is an ongoing > port for GST.

Oct. 22, 2008

Re: [Pharo-project] OB annotation icons

by StÃ©phane Ducasse

No please do not change the icons. No preference. We are building a visual vocabulary. Let us fix it instead. Stef On Oct 22, 2008, at 1:14 PM, David Roethlisberger wrote: > >>> I'm not a big defender of the super send icon, but what would >>> certainly have >>> helped in your use case is an icon that denotes whether you send >>> super to a >>> method with a different selector. Then you would have spotted this >>> problem >>> maybe even quicker than if it wouldn't have had any icon. >> Is it possible to put a configuration in the preferences so one can >> select what icons wants to be visible in the browser ? > > It is possible to do of course, but I'm not a friend of adding too > many preferences for this and that... > On the other hand, it seems to be impossible to find a set/ > configuration of icons that fits everyone's need and style. So maybe > it's indeed best to just let people configure the icons they want... > I will look into that. > > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008

Re: [Pharo-project] 10095: questions

by StÃ©phane Ducasse

Yo know this is really funny that I hear myself pronocing open... when I want to get mc browser and for a while I was looking for the open.... Stef On Oct 21, 2008, at 6:06 PM, Adrian Lienhard wrote: > The "recently logged changes" menu item has been reintroduced in the > world menu refactoring I did in a recent change (because as Lukas > said its a crucial feature). Please update, we currently are at > version 10101, so 10095 is already old ;) > > Also notice that the menu was redesigned from ground up. So the > organization is a bit different than the one in the previous menu > which may be strange for a moment for those of us that have > memorized the previous organization, but for newcomers it will be > much easier to understand. Also, the menu is optimized to make often > used tools accessible with only one click. > > Now, the previous item "recently logged changes" is in World->Tools- > >Recover lost changes... > > Cheers, > Adrian > > On Oct 21, 2008, at 16:21 , Gary Chambers wrote: > >> +1 on that... >> >> Gary. >> >> ----- Original Message ----- From: "Lukas Renggli" >> <renggli(a)gmail.com> >> To: "Pharo Development" <pharo-project(a)lists.gforge.inria.fr> >> Sent: Tuesday, October 21, 2008 2:14 PM >> Subject: Re: [Pharo-project] 10095: questions >> >> >> Another thing I missed in recent versions is the possibility to >> open a >> changes-list on the recently logged changes. This is an absolutely >> crucial feature for an image based system, to be able to restore >> after >> a crash. >> >> Cheers, >> Lukas >> >> On Tue, Oct 21, 2008 at 1:24 PM, Alexandre Bergel <alexandre(a)bergel.eu >> > wrote: >>> Excellent! >>> >>> Cheers, >>> Alexandre >>> >>> >>> On 21 Oct 2008, at 13:13, Damien Cassou wrote: >>> >>>> On Tue, Oct 21, 2008 at 1:02 PM, Alexandre Bergel >>>> <Alexandre.Bergel(a)inria.fr> wrote: >>>>> >>>>> Why is there only a simple change browser. Why not the double >>>>> one? I >>>>> always >>>>> found the simple one less useful. >>>> >>>> I think Adrian is aware of that and will replace the single one >>>> by the >>>> double one. In the meantime, you can still: DualChangeSorter open >>>> >>>>> How can I update Pharo ? Before the 'load update' in the left- >>>>> hand flap >>>>> provided it. >>>> >>>> World menu->system->uptade >>>> >>>> -- >>>> Damien Cassou >>>> Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good >>>> luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) >>>> _______________________________________________ >>>> 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 >>> >> >> >> >> -- >> 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 >

Oct. 22, 2008

Re: [Pharo-project] New pharo dev [10101]

by StÃ©phane Ducasse

tx damien! Stef On Oct 21, 2008, at 8:12 PM, Damien Cassou wrote: > New pharo-dev available at http://code.google.com/p/pharo/wiki/Downloads?tm=2 > . > > It only contains the packages you want > (http://code.google.com/p/pharo/wiki/Packages) > > -- > Damien Cassou > Peter von der AhÃ©: Â«I'm beginning to see why Gilad wished us good > luckÂ». (http://blogs.sun.com/ahe/entry/override_snafu) > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 22, 2008

Re: [Pharo-project] Looking for ImageSegment tests

by StÃ©phane Ducasse

>>>> Hi all >>>> >>>> if by any chance you have some code that could be turned into >>>> tests, or >>>> some tests or some time to write tests for image segments this >>>> would be great >>>> because etoy is really deep inside image segment and I would >>>> really like to keep this >>>> beautiful idea working :) >>> >>> yes please. We use this in production (like DabbleDB), and it >>> works very well. I just hope to never really need to understand >>> the code... >> >> really read the code because it is full of etoy related ugly hack >> (really ugly) > > I know... I imagine :) >> > I'll add it to my todo list I can help I would love to write a small chapter on imageSegment for the Volume 2 because I also found the idea so cool. stef > > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008

[Pharo-project] [ANN] Pharo Sprint, 26.10

by Marcus Denker

Hi, We are organizing a Pharo Sprint (that is: a hacking session) about Pharo this Sunday. Date: 26.10 Time: Starting 11h Where? Lille, France Depending on how many people want to come. Likely it will be at Stef's place. Please send me an email ASAP if you want to join. Then we decide about the place and organize some food. Marcus -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Oct. 22, 2008

Re: [Pharo-project] Size of objects

by StÃ©phane Ducasse

may be compare with the vw version I remember that lomg time ago in book of the guy doing june there was some code to do that http://www.sra.co.jp/people/aoki/ in freedocument then Smalltalk Idioms in English then chapter 3 Here let me introduce a program that finds the size in bytes of an arbitrary object. Finding the size of an object is the quickest route toward understanding the internal structure of objects. "Calculate the size in bytes of an arbitrary object." | byteSizeOfObject | byteSizeOfObject := [:anObject | | bytesInOTE bytesInOOP aClass indexableFieldSize instVarFieldSize byteSize | bytesInOTE := ObjectMemory current bytesPerOTE. bytesInOOP := ObjectMemory current bytesPerOOP. aClass := anObject class. aClass isPointers ifTrue: [instVarFieldSize := aClass instSize * bytesInOOP. aClass isVariable ifTrue: [indexableFieldSize := anObject basicSize * bytesInOOP] ifFalse: [indexableFieldSize := 0]] ifFalse: [instVarFieldSize := 0. aClass isVariable ifTrue: [indexableFieldSize := anObject basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP negated] ifFalse: [indexableFieldSize := 0. aClass hasImmediateInstances ifTrue: [bytesInOTE := 0]]]. byteSize := bytesInOTE + instVarFieldSize + indexableFieldSize. byteSize yourself]. ^byteSizeOfObject value: (OrderedCollection new: 10) have a look at the book. now in VW numOopsNumBytes "Answer an Array containing the number of objects in the system and the number of bytes they occupy. This method is implementation dependent." "ObjectMemory current numOopsNumBytes" | nobjects nbytes class bytesInHeader bytesInOOP | nobjects := nbytes := 0. bytesInHeader := self bytesPerOTE. bytesInOOP := self bytesPerOOP. self class allObjectsDo: [:object | nobjects := nobjects + 1. nbytes := nbytes + bytesInHeader. (class := object class) isBits ifTrue: [nbytes := nbytes + (object basicSize + (bytesInOOP - 1) bitAnd: bytesInOOP negated)] ifFalse: [nbytes := nbytes + (class instSize * bytesInOOP). class isVariable ifTrue: [nbytes := nbytes + (object basicSize * bytesInOOP)]]]. ^Array with: nobjects with: nbytes On Oct 21, 2008, at 6:15 PM, Adrian Lienhard wrote: > Hi FrÃ©dÃ©ric > > Nice to see you on the Pharo mailing list! > > Just the other day I needed this too and I implemented the following > method: > > Object>>sizeInMemory > "Returns the number of bytes used by this object in memory > (including its header)" > > | headerSize instanceSize | > headerSize := (self class indexIfCompact > 0 ifTrue: [ 4 ] ifFalse: > [ 8 ]). > instanceSize := (self class isVariable > ifFalse: [ self class instSize * Smalltalk wordSize ] > ifTrue: [ (self basicSize * (self class isBytes > ifTrue: [ 1 ] ifFalse: [ Smalltalk wordSize ])) ]). > ^ headerSize + instanceSize > > > BTW, I think that would be a meaningful addition. Could somebody > quickly check the method to verify that I didn't do any > miscalculation? > > Cheers, > Adrian > > On Oct 21, 2008, at 17:58 , Frederic Pluquet wrote: > >> Hello, >> >> For an experimentation, I need to know the size in bytes of any >> object. Is there a way to obtain this information in Pharo ? >> >> FrÃ©d >> >> -- >> FrÃ©dÃ©ric Pluquet >> UniversitÃ© Libre de Bruxelles (ULB) >> Assistant >> http://www.ulb.ac.be/di/fpluquet >> _______________________________________________ >> 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. 22, 2008

Re: [Pharo-project] Looking for ImageSegment tests

by Adrian Lienhard

On Oct 22, 2008, at 22:04 , StÃ©phane Ducasse wrote: > > On Oct 21, 2008, at 5:25 PM, Adrian Lienhard wrote: > >> >> On Oct 21, 2008, at 16:05 , StÃ©phane Ducasse wrote: >> >>> Hi all >>> >>> if by any chance you have some code that could be turned into >>> tests, or >>> some tests or some time to write tests for image segments this >>> would be great >>> because etoy is really deep inside image segment and I would >>> really like to keep this >>> beautiful idea working :) >> >> yes please. We use this in production (like DabbleDB), and it works >> very well. I just hope to never really need to understand the code... > > really read the code because it is full of etoy related ugly hack > (really ugly) I know... > I would not rely on that. > So we should really write some tests. This is really important. yes, especially if we make changes in this area. I fear this a bit... > I never used imageSegment but someone with experience should do that. > at least start. I'll add it to my todo list Adrian

Oct. 22, 2008

Re: [Pharo-project] Looking for ImageSegment tests

by StÃ©phane Ducasse

On Oct 21, 2008, at 5:25 PM, Adrian Lienhard wrote: > > On Oct 21, 2008, at 16:05 , StÃ©phane Ducasse wrote: > >> Hi all >> >> if by any chance you have some code that could be turned into >> tests, or >> some tests or some time to write tests for image segments this >> would be great >> because etoy is really deep inside image segment and I would really >> like to keep this >> beautiful idea working :) > > yes please. We use this in production (like DabbleDB), and it works > very well. I just hope to never really need to understand the code... really read the code because it is full of etoy related ugly hack (really ugly) I would not rely on that. So we should really write some tests. This is really important. I never used imageSegment but someone with experience should do that. at least start. stef > > > Adrian > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Oct. 22, 2008