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

[Pharo-project] loading nautilus
by Tudor Girba March 3, 2012

March 3, 2012

Hi, I am trying to load Nautilus in 1.4, but there seems to be a problem with the configuration. I run: Gofer it url: 'http://ss3.gemstone.com/ss/Nautilus'; package: 'ConfigurationOfNautilus'; load. (Smalltalk at: #ConfigurationOfNautilus) loadRelease. But, the Growl dependency is incorrect: spec project: 'Growl' with:[ spec repository: 'http://www.squeaksource.com/Growl'; package: 'Growl' ]. We could create a ConfigurationOfGrowl, or just load the package directly: spec package: 'Growl' with: [spec repository: 'http://www.squeaksource.com/Growl' ]. Which one do you prefer? Btw, the Moose build is failing because of this :). Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

1 1

[Pharo-project] Just a thought... default inspector window title
by Ben Coman March 3, 2012

March 3, 2012

Just a random idea as I am inspecting variables from the debugger as I trace through the code execution. The default window title of the inspector is the class being inspected however I end up with several windows of the same class and it is hard to distinguish between them. It would be nice (in this particular circumstance of mine) if the inspector window title was the item being inspected rather than the class being inspected. For instance, if the debugger shows variables 'innerRectangle' & 'outerRectangle' each holding a Rectangle, the when I inspect each, each window title would be 'innerRectance' & 'outerRectangle' rather than currently each being 'Rectangle'. I actually have been setting these manually using the halos but wondered a change to the default behvaiour might be considered. Taking this further, if I inspect code 'innerRectangle offset' in the debugger, then the window title of the inspector would be 'innerRectangle offset' rather than currently being a third window titled 'Rectangle'. The lost 'class type' information from the inspector title bar might be reinstated as a hover over 'self'. This might also end up useful where classes override their default printOn: behaviour such that the class is not shown in the inspector. I've not given thought to any downsides of this - particularly with respect to difficulty to implement or expected conventions - but I thought the current behaviour might be something just taken for granted. cheers, -ben

1 0

[Pharo-project] [update 1.4] #14372
by Marcus Denker March 3, 2012

March 3, 2012

14372 ----- Issue 4145: PluggableButtonButtonMorph>>#target http://code.google.com/p/pharo/issues/detail?id=4145 Issue 3403: should remove addServices2:for:extraLines: http://code.google.com/p/pharo/issues/detail?id=3403 Issue 2520: sourceMatchesBytecodeAt http://code.google.com/p/pharo/issues/detail?id=2520 Issue 5206: better api for browser http://code.google.com/p/pharo/issues/detail?id=5206 -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] odd gotcha in workspace code for squeak and pharo
by Lawson English March 3, 2012

March 3, 2012

A discussion in IRC prompted me to try several things. In a nutshell, execute these two lines with two separate doits and you get an error. Select both lines and doit and you don't: a := [^true]. a value. I assume there is a valid reason for the difference in behavior, but it DOES remind one that workspace behavior isn't always the same as method behavior, even for something as simple as the above. L.

1 0

Re: [Pharo-project] Sender of or: Boolean method
by Fernando Olivero March 3, 2012

March 3, 2012

Ciao Dario, i dont understand the question. You are stating that there's an error , because you know for sure that #or: has more then 10 senders in the Pharo1.0? Fernando pd: By the way, i advice to use a later version of Pharo, manyyy things were improved since then! On Sat, Mar 3, 2012 at 1:02 PM, Dario Trussardi <dario.trussardi(a)tiscali.it> wrote: > Ciao, > > Â Â Â Â i work with: > > Â Â Â Â Â Â Â Â Pharo-1.0 > Â Â Â Â Â Â Â Â Latest update: #10517. > > Â Â Â Â ( but i found the same answer into > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Pharo1.2.2 > Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Latest update: #12353 Â ) > > > > I have a browser open on Boolean class. > > > When i select the Â Â Â Â Â Â Â Â or: Â Â Â Â Â Â method Â and click on Â the Â Â Â sender button Â the system answer only Â ten Â methods. > > > Because ? > > > Thank, > > Â Â Â Â Â Â Â Â Dario

2 1

[Pharo-project] Sender of or: Boolean method
by Dario Trussardi March 3, 2012

March 3, 2012

Ciao, i work with: Pharo-1.0 Latest update: #10517. ( but i found the same answer into Pharo1.2.2 Latest update: #12353 ) I have a browser open on Boolean class. When i select the or: method and click on the sender button the system answer only ten methods. Because ? Thank, Dario

2 1

Re: [Pharo-project] Sender of or: Boolean method
by Marcus Denker March 3, 2012

March 3, 2012

On Mar 3, 2012, at 1:02 PM, Dario Trussardi wrote: > Ciao, > > i work with: > > Pharo-1.0 > Latest update: #10517. > > ( but i found the same answer into > Pharo1.2.2 > Latest update: #12353 ) > > > > I have a browser open on Boolean class. > > > When i select the or: method and click on the sender button the system answer only ten methods. > > > Because ? > It is compiled to jumps, the message send is optimized away. e.g "true or: [false]" is compiled to: 17 <71> pushConstant: true 18 <99> jumpFalse: 21 19 <71> pushConstant: true 20 <90> jumpTo: 22 21 <72> pushConstant: false 22 <7C> returnTop This means that then in the compiledmethod, there is no symbol needed for or: to execute the code. It is omited for space reasons (keep in mind that the original target machine of this system had 512 Kb of RAM maximum) The "senders of" iterates over all methods and looks if a symbol is there, it does not look at source code. (that's why it is so fast and works even without sources...) These days where a $25 computer is shipped witth 256MB of RAM, of course adding in 1000 methods pointers to a symbol is not that of a problem, and therefore, in 1.4, the selector of optimized-away messages is now added to the literalframe (if there is space), even though it's pure waste from the execution point of view. So now, senders of #or: gives you 1092 methods. Same for ifTrue: and all the other inlined methods. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0

[Pharo-project] [TODO] things tagged 1.4
by Marcus Denker March 3, 2012

March 3, 2012

Hi, Even though peope hate it, I think we just can't affort to not priorityze what we need to do... So I, evil as I am, started to remove 1.4 tags to get a feeling for what we really really need to fix and integrate... I should repeat that this un-tagging is not meant to judge on the submitter of the report, it does not mean that the issue should not be worked on at all, it just means that nobody needs to stay awake all night to fix it before we release 1.4... http://code.google.com/p/pharo/issues/list?can=2&q=Milestone%3D1.4+&colspec… 43 issues, 30 of those open, 13 already to be integrated. It does not mean that the list is complete, nor correct, nor that we really will fix all the issues for 1.4. It meant as a tool for you and me to have a manageble list of things that need attention. I personally need this, others do not. Those are invited to look at the complete list of reports: http://code.google.com/p/pharo/issues/list?can=2&q=&colspec=ID+Type+Status+… Here 446 Issues are listed *ALL* of them important to be fixed. Marcus -- Marcus Denker -- http://marcusdenker.de

2 1

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 3, 2012

March 3, 2012

On Mar 3, 2012, at 12:03 PM, Tudor Girba wrote: > Hi, > > I did not manage to explain myself, so let me try again with a longer email. > > We all want to get to a small kernel. To get there, we should have a process that makes the progress possible in small increments. At this point, I would just be interested in putting in place a simple job that takes a seed image, and builds the image in which the core team works in. > > As far as I understood, the only reason why we now have a single image is that the old Core image had poor tools, and building the Distribution was long. However, now, you do not have RB in there anymore. Removing RB was the right decision, because it means it can evolve rather independently. This also means that to do your work you would benefit from another image. > > So, the simplest thing at this point, would be to start with just making the current image to be the seed and build another one with RB (and maybe Nautilus?) inside where you do your work. And then we try to see how it goes in terms your process. If it works Ok, we can start pulling out other packages. > > For example, currently, there are at least two other parts that are not required to be in the seed image: AST and Filesystem. Of course, when OPAL will arrive, the AST will have to go in the seed image, but until then, it does not have to. The same with Filesystem: at this moment, it does not have to be in. > > One thing that we need to watch for though is the process of including something in the Distribution. The old Dev image failed because the policy was one of "it looks interesting -> it should be in". Instead, the Distribution should be focused on providing a small set of extras that make development better. > > In the end, the goal is not to come up with the kernel now, but it would be to have the infrastructure and process in place that enables us to remove things from the seed image gradually, and still get the core team to have a good toolset. > > Would that be Ok? > What we need: -> One Artefact of release. *This is Pharo* (and yes, there is a small core somewhere, but that's for specialists) - The goal in that is to have everything just once. Not a "crapy X for the Core, but everyone uses Y". - No need to manage bugs for Full and Core differently - Stable. No "Dev now is different and I don't know why, nobody changed anything" (as happend with 1.3, again...) (stable in the sense: two builds of the same version should not magically be different) -> The development happens in that one release. Developers and integrators can just use that. No thinking. -> The way to commit is the same. What killed me in the Dev image approach is that it was different and difficult *in addtion* to a difficult and boring aproach for the core. (e.g. editing Metacello config by hand for every trivial change.. and breaking something every time). -> I can press "update system to latest" to update the image, no need to always download a fresh image for every trivial change. -- Marcus Denker -- http://marcusdenker.de

1 0

Re: [Pharo-project] pharo-seed and pharo
by Marcus Denker March 3, 2012

March 3, 2012

> > > For example, currently, there are at least two other parts that are not required to be in the seed image: AST and Filesystem. FileSystem is needed. It replaced the old Filesystem in some places already. e.g. in FileList. Marcus -- Marcus Denker -- http://marcusdenker.de

1 0