April 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Problem with window cycling (cmd + narrow)

by Mariano Martinez Peck

Thanks Henry. Gary, what do you think ? thanks mariano On Tue, Apr 13, 2010 at 5:37 PM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > My guess is the morph hooks into events at the wrong level (at least a > non-platform independent one). > It "works" on Windows VM, and sort of the 5.0 Mac series(does not select > at depress of command, but when a new button is pressed), and on 4.2.4 Mac > VM I see the behavior both you and 2289 describe. > > Cheers, > Henry > > > On Apr 13, 2010, at 5:04 17PM, Mariano Martinez Peck wrote: > > > I think there is a bug in the windows cycling. Or maybe I don't > understand it anymore. I remembered I used to press cmd + narrow and the > popup raised and then I could choose slowly which windows I wanted. > > > > But now, after pressing cmd + left arrow for example, the popup raise, > but very quickly disappear. Giving me now time even to look at the current > opened windows. > > > > I guess this is a bug. What do you think ? > > > > I tested in Pharo1.0 rc3 and Pharo 11309. > > > > I think this bug is different but related to issue 2289. > > > > Cheers > > > > Mariano > > > > _______________________________________________ > > 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 >

April 28, 2010

Re: [Pharo-project] Pharo sprint in Bern on June 5, 2010

by laurent laffont

I will be there too. Laurent Laffont On Wednesday, April 28, 2010, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Cool! I want to go. I want to visit Switzerland since a lot of time :)Â I want to go to the alps also. > > I will be with my wife, so I will probably go one day before and come and stay one day more after so that I can visit. > > Cheers > > Mariano > > On Tue, Apr 27, 2010 at 3:38 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > Hi all, > > We are planning again to do a sprint in Bern. Please add your name to the wiki if you plan to attend. > > http://code.google.com/p/pharo/wiki/PharoSprints > > Cheers, > Adrian > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- Laurent Laffont

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Henrik Johansen

Like Steph implied, search the nabble archive, and you will find the lengthy discussion which took place over a year ago. Cheers, Henry Den 28. apr. 2010 kl. 19.41 skrev Hannes Hirzel <hannes.hirzel(a)gmail.com>: > On 4/28/10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hannes >> >> We know pragmas since they appeared a while ago in VW. We are good >> metaprogrammers >> and know that annotation are good to a certain extent: I do not >> like the >> delegate annotation used >> by vassily in VW because they changed the semantics of the system. >> >> Now we got lengthy discussion a while ago in the pharo mailing-list >> and may >> be in the squeak one since I remember andreas presenting his view. We >> reached a consensus, alain changed his implementation to fit the >> result of >> the discussions and we are quite happy >> with it. >> - We can package setting in a package or outside (outside is better >> since we >> do not have dead code) >> when preferences are not loaded, but this is the choice of the >> package >> designer. >> - We use a builder so that we do not have to have a mini language >> interpreter for the pragmas. >> >> As I said we are happy with it and we hope to get rid of Preferences >> completely :). >> >> >> Stef >> > > StÃ©phane > > Thank you for your update on this issue. > Do you have a link to writeup what the consensus for Pharo is > regarding pragmas / method annotation / use of metadata? > > For which areas are they used? What are the conventions? For Squeak we > do not necessarily want to do something different unless we think it > is necessary because of shortcomings of your solutions (as perceived > from our point of view). > > And I think the discussion on the Squeak list seems to develop into a > direction where people want to get rid of the Preferences class like > you. > > --Hannes > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 28, 2010

[Pharo-project] Fwd: is it possible to know the memory occupation (bytes) of an object?

by Mariano Martinez Peck

Hi folks. Sorry for the cross post this time, but I guess it is worth. In Pharo we were trying to get a way to know the amount of memory (bytes) that an objects is occupying in RAM memory. For such purpose, Adrian posposed 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 Do you think this is correct for all cases? Is there a way to know this but from the VM side also ? how ? I really need it from the VM side :( but I have no idea how to do it. Thanks Mariano ---------- Forwarded message ---------- From: Adrian Lienhard <adi(a)netstyle.ch> Date: Tue, Apr 27, 2010 at 1:19 PM Subject: Re: [Pharo-project] is it possible to know the memory occupation (bytes) of an object? To: Pharo-project(a)lists.gforge.inria.fr Its a simple method in Object: 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 Please also note the other mail I sent to this thread. Adrian On Apr 27, 2010, at 13:16 , Mariano Martinez Peck wrote: > On Tue, Apr 27, 2010 at 12:45 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > >> I once sent some code to the mailing list (search for thread named "Size of >> objects"). > > > Thanks Adrian...I couldn't find it. Can you forward it to me please? or > just send me the code... > > >> We should add this to the image. I think I named it #sizeInMemory. >> >> > There are only changes to the image side ? or the vm also ? > > Thanks > > Mariano > > > >> Adrian >> >> On Apr 27, 2010, at 12:03 , Mariano Martinez Peck wrote: >> >>> Hi. I don't know if "memory occupation" is the better name. I just want >> to >>> know the amount of memory that an object is occupying in RAM. I mean, the >>> amount of bytes. >>> >>> Is this possible ? if true, how ? I would like to do it from both >> sides: >>> image and VM. >>> >>> I checked both but I didn't find anything. >>> >>> Thanks in advance >>> >>> Mariano >>> _______________________________________________ >>> 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 _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 28, 2010

Re: [Pharo-project] Class>>rename:

by Mariano Martinez Peck

Hola Fernando. If you want something to be integrated, you should follow the rules. As an start, open a bug ticket, set the correct status and label, and commit to inbox. Otherwise, this mail will be forgotten. Cheers Mariano 2010/4/27 Fernando olivero <oliverof(a)lu.unisi.ch> > > Hi , please integrate this change to Class>>rename: > > > rename: aString > "The new name of the receiver is the argument, aString." > > | oldName newName | > (newName := aString asSymbol) = (oldName := self name) > ifTrue: [^ self]. > (self environment includesKey: newName) > ifTrue: [^ self error: newName , ' already exists']. > name := newName. > self environment renameClass: self from: oldName. > > (Undeclared includesKey: newName) > ifTrue: [self inform: 'There are references to, ' , aString > printString , ' > from Undeclared. Check them after this change.']. > > > I moved the (Undeclared..... ) statement to the end. > > To send #inform: after performing the actual change, and not before. > > In this way you can catch the ProvideAnswerNotification, and remove the > modal dialog that pops up and still perform the actual class rename! > > For example... > > [ self performRefactoring: refactoring ] on: ProvideAnswerNotification > do:[:err | " do not inform the user! " ]. > > > Please let me know if you agree, and will integrate it. > Saludos, > Fernando > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 28, 2010

Re: [Pharo-project] Pharo sprint in Bern on June 5, 2010

by Mariano Martinez Peck

Cool! I want to go. I want to visit Switzerland since a lot of time :) I want to go to the alps also. I will be with my wife, so I will probably go one day before and come and stay one day more after so that I can visit. Cheers Mariano On Tue, Apr 27, 2010 at 3:38 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > Hi all, > > We are planning again to do a sprint in Bern. Please add your name to the > wiki if you plan to attend. > > http://code.google.com/p/pharo/wiki/PharoSprints > > Cheers, > Adrian > > ___________________ > http://www.adrian-lienhard.ch/ > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Hannes Hirzel

On 4/28/10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hannes > > We know pragmas since they appeared a while ago in VW. We are good > metaprogrammers > and know that annotation are good to a certain extent: I do not like the > delegate annotation used > by vassily in VW because they changed the semantics of the system. > > Now we got lengthy discussion a while ago in the pharo mailing-list and may > be in the squeak one since I remember andreas presenting his view. We > reached a consensus, alain changed his implementation to fit the result of > the discussions and we are quite happy > with it. > - We can package setting in a package or outside (outside is better since we > do not have dead code) > when preferences are not loaded, but this is the choice of the package > designer. > - We use a builder so that we do not have to have a mini language > interpreter for the pragmas. > > As I said we are happy with it and we hope to get rid of Preferences > completely :). > > > Stef > StÃ©phane Thank you for your update on this issue. Do you have a link to writeup what the consensus for Pharo is regarding pragmas / method annotation / use of metadata? For which areas are they used? What are the conventions? For Squeak we do not necessarily want to do something different unless we think it is necessary because of shortcomings of your solutions (as perceived from our point of view). And I think the discussion on the Squeak list seems to develop into a direction where people want to get rid of the Preferences class like you. --Hannes

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by StÃ©phane Ducasse

Hannes We know pragmas since they appeared a while ago in VW. We are good metaprogrammers and know that annotation are good to a certain extent: I do not like the delegate annotation used by vassily in VW because they changed the semantics of the system. Now we got lengthy discussion a while ago in the pharo mailing-list and may be in the squeak one since I remember andreas presenting his view. We reached a consensus, alain changed his implementation to fit the result of the discussions and we are quite happy with it. - We can package setting in a package or outside (outside is better since we do not have dead code) when preferences are not loaded, but this is the choice of the package designer. - We use a builder so that we do not have to have a mini language interpreter for the pragmas. As I said we are happy with it and we hope to get rid of Preferences completely :). Stef > Hello Stephane > > On the Squeaklist there was a discussion ongoing since Monday how to > use to use pragmas in an extended way. > > We agreed that they are in fact method annotations or method > properties which may be used for various purposes. > > The name 'pragma' evocates compiler only related things which is true > but it is not limited to that. > > Andreas had a good writeup in his blog (WORTHHILE READING) > > 'Annotations for Service Discovery' > http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-disc… > > So we want to go for pragmas (=method annotations = method properties) > to implement the discovery mechanism for populating the menus. > > My question was: Why not do it like the Pharo people did? > > Andreas' answer is copied in below. I.e. we want to learn from the > Pharo experience. > > > Regards > Hannes > > > ---------------------------------------------------------------------------------------------------------------- > On 4/27/2010 12:00 PM, Nicolas Cellier wrote: > > 2010/4/27 Hannes Hirzel<hannes.hirzel(a)gmail.com>: > > What are the reasons for not going for the Pharo solution? > > > Andreas just put it nicely. > There is a different philosophy, and that is important to discuss > first, and weight pros and cons. > The difference is that package maintainers should care of system > evolutions in Pharo, but won't care of building details anymore in > Squeak. > Of course, this is at the price of restricting functionalities. > > > Indeed. But I consider that a Good Thing (tm). It means that we only > need to support what we explicitly agree on. One important thing to > keep in mind is that my take on annotations for service discovery is > not a "strict" requirement - for example you *can* use Preferences > directly if you need to do something unusual that isn't covered by the > simple preference annotation. You're simply losing the implied > contract with the community to keep your stuff running without your > own help (which is current practice). By voluntarily restricting > yourself to use the annotation we can support your work going forward, > but if you need more, please go ahead. > > This is also why in the menu discussion the argument about "but you > need every possible permutation of menu creation" is simply a false > assertion. We don't. We can restrict ourselves to the subset that we > want to support. We then support it. If you need something that is not > part of the supported subset you have to modify the menu directly. > Can't be helped, because we don't support it. > > We're doing this for preferences now (exactly one preference > annotation and not every conceivable permutation) and from what I see > it works great. I have no doubt that we will be able to support this > for many, many years because it's so simple. KISS, in short. > > But the most important question to ask ourselves is: What problem are > we trying to solve here? If the problem is exclusively about > extensibility, then the Pharo solution would work fine. If it is about > making this so that people don't have to play catch-up every time > something changes, I think you'll find that the Pharo approach has > difficulties in this regard for reasons explained in my blog post at > [1] (new with fixed code font! :-) > > I find the evolution of Pharo fascinating in this regard. First, there > was the desire to provide extensibility and loose coupling, so the > systemsettings annotation with builders were introduced. Then it was > probably considered too much bloat to keep all of this unused code in > the core classes, to the "Settings" package was created (I have no > reference for why the Settings package was created, if anyone has a > pointer I'd appreciate that). So now all the preferences builder code > has been removed from the places where the preferences are and into a > separate package. At this point you're not only maintaining the > entities in two different places (the domain code and the settings > package), you also loose the last reason for using annotations. There > is no good reason why Settings shouldn't depend on the builder > framework - after all it's a separate package, and it makes no sense > to even load it if you don't have the builder. And having the class > initializer register the preference is more obvious than having some > 'magic' discovery under the hoods. It might be "cool" but it addresses > no discernible problem. > > In short, if you're willing to split your code into domain and > settings packages you might as well declare the dependency of your > settings package on the settings framework. That's a perfectly legit > way of dealing with the specific dependencies, but at that point the > use of annotations becomes pointless. > > [1]http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-di… > > Cheers, > - Andreas > > > > > On 4/28/10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> Hi brent >> >> >> On Apr 28, 2010, at 5:47 PM, Brent Pinkney wrote: >> >>> Hi all,+ >>> >>> Could those in the know comment on how this <...> proposal is (or is not) >>> consistent with the fundamental Smalltalk principles >> >> >> Sorry but I do not have the time to read squeak-dev. so what is <...> the >> use of pragmas? >> Or is there something else? >> >> >>> that: >>> >>> 1. "an object is send a message and responds with an object" >>> 2. there is no other "magic" in the system. >>> >>> Are we proposing a break fromv this ? If so, IMO we need to really get it >>> right before we commit. >>> >>> Thanks >>> >>> Brent >>> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

April 28, 2010

Re: [Pharo-project] [squeak-dev] Re: Menu Registries

by Hannes Hirzel

Hello Stephane On the Squeaklist there was a discussion ongoing since Monday how to use to use pragmas in an extended way. We agreed that they are in fact method annotations or method properties which may be used for various purposes. The name 'pragma' evocates compiler only related things which is true but it is not limited to that. Andreas had a good writeup in his blog (WORTHHILE READING) 'Annotations for Service Discovery' http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-disc… So we want to go for pragmas (=method annotations = method properties) to implement the discovery mechanism for populating the menus. My question was: Why not do it like the Pharo people did? Andreas' answer is copied in below. I.e. we want to learn from the Pharo experience. Regards Hannes ---------------------------------------------------------------------------------------------------------------- On 4/27/2010 12:00 PM, Nicolas Cellier wrote: 2010/4/27 Hannes Hirzel<hannes.hirzel(a)gmail.com>: What are the reasons for not going for the Pharo solution? Andreas just put it nicely. There is a different philosophy, and that is important to discuss first, and weight pros and cons. The difference is that package maintainers should care of system evolutions in Pharo, but won't care of building details anymore in Squeak. Of course, this is at the price of restricting functionalities. Indeed. But I consider that a Good Thing (tm). It means that we only need to support what we explicitly agree on. One important thing to keep in mind is that my take on annotations for service discovery is not a "strict" requirement - for example you *can* use Preferences directly if you need to do something unusual that isn't covered by the simple preference annotation. You're simply losing the implied contract with the community to keep your stuff running without your own help (which is current practice). By voluntarily restricting yourself to use the annotation we can support your work going forward, but if you need more, please go ahead. This is also why in the menu discussion the argument about "but you need every possible permutation of menu creation" is simply a false assertion. We don't. We can restrict ourselves to the subset that we want to support. We then support it. If you need something that is not part of the supported subset you have to modify the menu directly. Can't be helped, because we don't support it. We're doing this for preferences now (exactly one preference annotation and not every conceivable permutation) and from what I see it works great. I have no doubt that we will be able to support this for many, many years because it's so simple. KISS, in short. But the most important question to ask ourselves is: What problem are we trying to solve here? If the problem is exclusively about extensibility, then the Pharo solution would work fine. If it is about making this so that people don't have to play catch-up every time something changes, I think you'll find that the Pharo approach has difficulties in this regard for reasons explained in my blog post at [1] (new with fixed code font! :-) I find the evolution of Pharo fascinating in this regard. First, there was the desire to provide extensibility and loose coupling, so the systemsettings annotation with builders were introduced. Then it was probably considered too much bloat to keep all of this unused code in the core classes, to the "Settings" package was created (I have no reference for why the Settings package was created, if anyone has a pointer I'd appreciate that). So now all the preferences builder code has been removed from the places where the preferences are and into a separate package. At this point you're not only maintaining the entities in two different places (the domain code and the settings package), you also loose the last reason for using annotations. There is no good reason why Settings shouldn't depend on the builder framework - after all it's a separate package, and it makes no sense to even load it if you don't have the builder. And having the class initializer register the preference is more obvious than having some 'magic' discovery under the hoods. It might be "cool" but it addresses no discernible problem. In short, if you're willing to split your code into domain and settings packages you might as well declare the dependency of your settings package on the settings framework. That's a perfectly legit way of dealing with the specific dependencies, but at that point the use of annotations becomes pointless. [1]http://squeakingalong.wordpress.com/2010/04/27/annotations-for-service-di… Cheers, - Andreas On 4/28/10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > Hi brent > > > On Apr 28, 2010, at 5:47 PM, Brent Pinkney wrote: > >> Hi all,+ >> >> Could those in the know comment on how this <...> proposal is (or is not) >> consistent with the fundamental Smalltalk principles > > > Sorry but I do not have the time to read squeak-dev. so what is <...> the > use of pragmas? > Or is there something else? > > >> that: >> >> 1. "an object is send a message and responds with an object" >> 2. there is no other "magic" in the system. >> >> Are we proposing a break fromv this ? If so, IMO we need to really get it >> right before we commit. >> >> Thanks >> >> Brent >>

April 28, 2010

Re: [Pharo-project] Pharo Sprint in Argentina

by Mariano Martinez Peck

be aware of the time difference ;) FIVE hours :( On Wed, Apr 28, 2010 at 6:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > This is good I would like to try to be on irc to help you. > > On Apr 28, 2010, at 3:39 PM, Alexandre Bergel wrote: > > > Hi! > > > > I would like to organize a Pharo Sprint during May 17 and May 23. > > An entry has been added to the page > http://code.google.com/p/pharo/wiki/PharoSprints > > Please, add your name if you wish to participate. > > > > The date and the location hasn't been defined yet. Some people proposed > to do it in Rosario instead of Buenos Aires? > > I set up two doodle: > > Choose the day: > > http://www.doodle.com/fhb84vcu2df2amkq > > > > Choose the location: > > http://www.doodle.com/tte9fwnbnqk6ekbz > > > > Cheers, > > Alexandre > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > 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 > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

April 28, 2010