- Pharo-dev - lists.pharo.org

[Pharo-project] feedback about the "new inspector"
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

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

8 11

[Pharo-project] release image 11011 for 1.1-alpha on the inria web site
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

Hi I released image 11011 for 1.1-alpha on the inria web site Stef

1 0

[Pharo-project] The package of ParagraphEditor
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

I never understood why a User Interface class was in the Kernel I'm curious to know what Pavel think about it ! Squeak/trunk put it to a better place: ParagraphEditor ( snip ) category: 'ST80-Controllers' Shouldn't Pharo follow this re-classification ? Nicolas

2 1

[Pharo-project] [update 1.1 ] #11011
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

11011 ----- - Issue 1357: use includesSelector: rather than selectors includes: Rationale for using #includesSelector: - a single message is better than two - an optimized method is better than a slow one The method is optimized because it directly ask methodDict includesKey: rather than creating an unecessary intermediate collection.

1 0

[Pharo-project] making #classVarNames answer a sorted Array
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

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

2 2

[Pharo-project] found a mac magsafe power adapter
by StÃ©phane Ducasse Oct. 22, 2009

Oct. 22, 2009

one of the pharo sprinter forgot his adaptor :) let me know that we ship it by post Stef

3 3

[Pharo-project] Question about PBE book by newbie, instance variables
by Gerben van de Wiel Oct. 22, 2009

Oct. 22, 2009

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

6 8

[Pharo-project] thanks to all the sprinters
by stephan＠stack.nl Oct. 22, 2009

Oct. 22, 2009

> could organize one at Fosdem but this is just the beginning of > winter holiday in france :( > > Stef FOSDEM would be good. Saturday 6 and sunday 7 februari 2010, Brussels. Stephan

1 0

[Pharo-project] make #keys answer an Array rather than a Set
by Nicolas Cellier Oct. 22, 2009

Oct. 22, 2009

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

2 1

[Pharo-project] issue 429: collapseAll
by Laval Jannik Oct. 22, 2009

Oct. 22, 2009

Hi all, In issue 429, when we do a "collapse all windows" PasteUpMorph>>collapseAll is invoked. This method collapse non window elements. But, when we do an "expand all windows", only windows are expanded. So my question is: Do we want to collapse all non window elements ? If yes, we must to expand them in "expand all windows" If no, I remove this behavior. Cheers, --- Jannik Laval PhD Student - Rmod Team - INRIA Certified Project Management Associate (IPMA) http://www.jannik-laval.eu http://rmod.lille.inria.fr ---

1 0