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

[Pharo-project] making #classVarNames answer a sorted Array

by Nicolas Cellier

Proposal is logged at http://code.google.com/p/pharo/issues/detail?id=1354 Recently in trunk

Oct. 21, 2009

[Pharo-project] make #keys answer an Array rather than a Set

by Nicolas Cellier

I made a proposal here: http://code.google.com/p/pharo/issues/detail?id=1353 feel free to comment about it

Oct. 21, 2009

Re: [Pharo-project] MC 1.6 status?

by Igor Stasenko

Another important aspect, which i missed. That LPF is a script. Its intentionally made so, that you could try adopt it and load MC into very obscure environment. Let me remind you, that our 'holy grail' of modularity is to have a minimal kernel with basic classes and compiler, while rest is optional. In this terms, LPF project is a highly valuable piece, which fits just well with such concept: you can build an image from first principles starting from kernel and then up to the image which could load MC packages and up to an image which having the rest in the squeak world. So, i really hope, that efforts which took by Keith and Matthew and other contributors will not be put in vane. And therefore making a call to a anyone who could volunteer to support and maintain this project for the benefit of both Pharo and Squeak communities, and many other forks. 2009/10/21 Igor Stasenko <siguctua(a)gmail.com>: > I had chat with Matthew today, and he said that he could turn his head > back on MC 1.6 for a bit. > But he doesn't guarantees that he can spend much time on it, so i > asked him first, to > write the small report - an overview, which lists the problems its > having and in what way they can be solved. > > Then, i hope, someone could pick up the task and make it available. > > Next thing is a clarification about LPF from its respectible developer(s): > LPF is an 'MC 1.6' , in terms that its a main tool which provides > means to load & install MC 1.6 in *your image*. > > By *your image* i meant that LPF is not targeted for a particular > squeak version or its fork - it attempts to target as many of them as > possible. > And this means, that LPF (along with MC 1.6) could serve as a common > ground for many existing squeak versions and its forks. > > And this means, in own turn, that it is in our best interests to make > it adopted. :) > > In a future, i suggest to use a better naming for a projects, like > LPF, or make name to be more elaborate (like LPF - the MC 1.6 > bootstrapper) because its confusing the people up to the point that > they don't understand why it is so good to have it. > > > 2009/10/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> I would love to have that. >> I started to migrate some 1.5 code (fast loading) from MC15 to pharo >> MC15 but nobody have a look >> at the slice I published >> >> >> Stef >> >>> Hello people, >>> >>> i'd like to see some answers about the fate of MC 1.6. and its current >>> situation. >>> >>> 1. I think everyone wants to have an atomic loading. >>> But according to my knowledge, MC 1.6. has some problems with Traits, >>> which prevets us from using it & fully replace the older version. >>> >>> 2. Besides of that, are there any other reasons to not have it? >>> >>> So, please, can we disscuss (friendly & constructive), what we might >>> need to have it integrated in Squeak and in Pharo, so >>> we could benefit from having an atomic loading? >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

Oct. 21, 2009

Re: [Pharo-project] MC 1.6 status?

by Igor Stasenko

I had chat with Matthew today, and he said that he could turn his head back on MC 1.6 for a bit. But he doesn't guarantees that he can spend much time on it, so i asked him first, to write the small report - an overview, which lists the problems its having and in what way they can be solved. Then, i hope, someone could pick up the task and make it available. Next thing is a clarification about LPF from its respectible developer(s): LPF is an 'MC 1.6' , in terms that its a main tool which provides means to load & install MC 1.6 in *your image*. By *your image* i meant that LPF is not targeted for a particular squeak version or its fork - it attempts to target as many of them as possible. And this means, that LPF (along with MC 1.6) could serve as a common ground for many existing squeak versions and its forks. And this means, in own turn, that it is in our best interests to make it adopted. :) In a future, i suggest to use a better naming for a projects, like LPF, or make name to be more elaborate (like LPF - the MC 1.6 bootstrapper) because its confusing the people up to the point that they don't understand why it is so good to have it. 2009/10/21 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > I would love to have that. > I started to migrate some 1.5 code (fast loading) from MC15 to pharo > MC15 but nobody have a look > at the slice I published > > > Stef > >> Hello people, >> >> i'd like to see some answers about the fate of MC 1.6. and its current >> situation. >> >> 1. I think everyone wants to have an atomic loading. >> But according to my knowledge, MC 1.6. has some problems with Traits, >> which prevets us from using it & fully replace the older version. >> >> 2. Besides of that, are there any other reasons to not have it? >> >> So, please, can we disscuss (friendly & constructive), what we might >> need to have it integrated in Squeak and in Pharo, so >> we could benefit from having an atomic loading? >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> 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 > -- Best regards, Igor Stasenko AKA sig.

Oct. 21, 2009

Re: [Pharo-project] [squeak-dev] Re: Issue with traits

by Ken.Dickey

Why not share the code? Â Just use a "cell" to hold the class and have methodClass accessor do the indirection. If you have a bit in the method header, the VM could use it as a 0/1 index into the code to call to do (or not do) the extra indirection. Â Just think of the a trait method as a closure which is parameterized on the class. Am I missing something deep here? -KenD > Message: 7 > Date: Wed, 21 Oct 2009 09:41:08 +0200 > From: Adrian Lienhard <adi(a)netstyle.ch> > Subject: Re: [Pharo-project] [squeak-dev] Re: Issue with traits > To: The general-purpose Squeak developers list > Â Â Â Â Â Â Â Â <squeak-dev(a)lists.squeakfoundation.org>, Â Â Â Â Â Â Â Pharo Development > Â Â Â Â Â Â Â Â <pharo-project(a)lists.gforge.inria.fr> > Message-ID: <3C7E5C51-21A8-483A-81A0-40854430A43B(a)netstyle.ch> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > I've fixed this issue in Pharo a couple of months ago. CompiledMethods Â > are not shared anymore, so methodClass returns the expected class. At Â > the time I implemented traits (2004?), there were no method properties Â > and hence sharing compiled methods worked -- of course except for Â > super sends in which case the method was always recompiled (so the Â > answer to Andreas' question below is b)). > > Cheers, > Adrian

Oct. 21, 2009

Re: [Pharo-project] Issue 1351: OCompletion doesn't guess instVar in debugger context

by CÃ©drick BÃ©ler

Cool Thanks Johan 2009/10/21 Johan Brichau <johan.brichau(a)uclouvain.be> > The problem here is that the instvar #debuggerMap is only referenced > from this method. It is not intialized nor used anywhere else in > Debugger. > > If you replace this with 'self selectedContext debuggerMap', it works. > > I will submit the fix. > > On 21 Oct 2009, at 12:03, CÃ©drick BÃ©ler wrote: > > > When coding in the debugger, and accessing directly an instvar, > > writing > > code after the instvar raises a Message not understood as the > > debugger map > > is nil. > > > > http://code.google.com/p/pharo/issues/detail?id=1351 > > > > -- > > CÃ©drick > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > ---------------------------- > Johan Brichau > johan.brichau(a)uclouvain.be > > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- CÃ©drick

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by csrabak＠bol.com.br

There are two subjects here. Let me start with Oscar's query first. Since protocols in Smalltalk are a suggestion but not enforceable, I tend to avoid (ii) as much as possible and use instance variable methods with lazy initialization as much as possible to have short initialize methods. Pertaining to Gerben's question, I think an authoritative answer will be still needing: Looking at the class hierarchy from SimpleButtonMorph up, you'll see that bounds ivar is defined in Morph class and indeed there is a method Morph>>bounds:, but it is in geometry protocol (meaning is not in accessing protocol). Notice that Morph>>bounds: does not update bounds ivar directly, but rather indirectly via Morph>>extent:! So in this particular case using the accessor method would not work the same way as the code in the book (caveat emptor, I did not test this assertion!) Em 21/10/2009 10:12, Oscar Nierstrasz < oscar(a)iam.unibe.ch > escreveu: > > Hi Gerben, > It is really a question of style. Some people promote the use of > accessors aggressively for all instance variable access. The down > sides are (i) proliferation of accessor methods, and (ii) exposure > of private state to other objects. If you do decide to use > accessors, you should be sure to put them in a protocol called > "private" to make clear that they are only intended for use by the > object itself. > I am curious what other people tend to do -- do you use accessors > for inherited ivars, or access them directly? > - on > > > On 21 Oct 2009, at 11:45, Gerben van de Wiel wrote: > > > Hi, > > I am very new to Pharo and Smalltalk in general. When reading > > through the excellent PBE book i was wondering about something on > > page 32. In that piece of code the LOCell class is using some > > instance variables from it's super classes, and i was wondering if > > it isn't best practice to use message to self using the accessing > > methods so instead of. > > bounds := 0@0 corner: 16@16. using self bounds: (0@0 corner: > > 16@16). > > or is good to use both or is there something i don't know (maybe > > it is faster to use instance vars then sending a new message and > > traverse the inheritance tree). > > regards, > > Gerben van de Wiel

Oct. 21, 2009

Re: [Pharo-project] Question about PBE book by newbie, instance variables

by Esteban A. Maringolo

As said, it is a matter of style. I rather use accessor methods (private mostly) because of lazy initialization. If you don't use lazy initialization, and always have valid objects in the instance variables, then you can use direct variable access or simply a message send. I also choose message sends because I can track local senders, and refactor mercilessly. But it also depends on the tool set you have, in some refactoring browsers you can see which methods "read" an inst var and also refactor inst var names on a whole hierarchy (or package). Best regards, Esteban A. Maringolo

Oct. 21, 2009

Re: [Pharo-project] Issue 1351: OCompletion doesn't guess instVar in debugger context

by Johan Brichau

The problem here is that the instvar #debuggerMap is only referenced from this method. It is not intialized nor used anywhere else in Debugger. If you replace this with 'self selectedContext debuggerMap', it works. I will submit the fix. On 21 Oct 2009, at 12:03, CÃ©drick BÃ©ler wrote: > When coding in the debugger, and accessing directly an instvar, > writing > code after the instvar raises a Message not understood as the > debugger map > is nil. > > http://code.google.com/p/pharo/issues/detail?id=1351 > > -- > CÃ©drick > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Oct. 21, 2009

Re: [Pharo-project] feedback about the "new inspector"

by Johan Brichau

I agree that we need to refine the ideas in the inspector. Is Frederic on this list? I also understood from Niko on monday that he is working on an alternative inspector that very much ressembles the one from Visualworks (which I very much like). The expandable tree 'infinite inspector' is a good idea for exploring an object's state but it should probably not be applied to everything that one can navigate to from within the object (i.e. not for methods). Getting to the methods from within the inspector is cool but if they expand in the same tree as the state, you quickly end up with a tree that does not show you anything anymore. After a couple of expansions, I often get a tree mixing state and behavior on different levels, with long method lists that require me to scroll through the tree and close levels again to see what I want. In the end, I have no easy way of navigating the object structure anymore because opening/ closing the tree levels to see what I want in a single window becomes not manageable. Here is what I would like to see happening (and I'm willing to help to get there too!): - Double clicking on an item in the tree on the left should open a new inspector window on that item (I really do not like adding it as a root in the same window: I find it confusing having two roots). This will already allow me to open up another view on the same structure or keep a window open on certain structure so I can return to it afterwards. - Do not make the methods expandable in the tree but rather open a list of methods in the right-hand pane that can be selected (and 'send' to the object if it's a unary message). Right now, selecting methods will give the list of selectors, which is not so useful. - Use visual icons instead of 'Class' and 'Methods' (duno if this is possible in the treemorph?) - Do not 'inspect/explore' the class as a normal object but make it jump to a browser instead On 21 Oct 2009, at 15:54, StÃ©phane Ducasse wrote: > Hi guys > > we tried to use and force you to use the new inspector and it does not > fly that well. > I'm sure that frederick is open to suggestion so please send your > remarks. Here were mine :) > > Stef > > > Hello Stef, > > > > here what is really strange and annoying is that we cannot see the > collection elements in the right pane > > Now it is fixed. > > on the left Elements is confusing. because this is not clear the > relationship with array, firstInd.... > It shows only elements of any kind of collection (it is simply a > collect: [:o | o] on the collection). > > on the right this is also frustrating that we cannot modify, touch the > elements. > > Ok... but you can expand the Elements, select the element you want to > change, put the new value in the description pane and accept it. > > I'm not sure that we want to see the class (in an expandable manner). > For the methods may be you want to stop and show the methods but > expandabel > may be by defualt you should not show the class and methods as > expandable and have a menu entry doing that (expand) > > I'm not sure to understand what you want. For me the NewInspector it > is a like an infinite inspector: if you want to go into an object, you > can. So if you want to inspect a class or the methods, you should have > the possibility to do it. > > FrÃ©d > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project ---------------------------- Johan Brichau johan.brichau(a)uclouvain.be

Oct. 21, 2009