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

[Pharo-project] Why some packages are rejected from Test Coverage?
by Mariano Martinez Peck Dec. 3, 2009

Dec. 3, 2009

Ok, I see that there are some packages that are not able to be selected to run test coverage. I noticed that they were big packages and then I saw the method: TestRunner >> promptForPackages where you can see it rejects packages like Kernel, Collections, System, etc. I guess because Test Coverage may take long time in those big packages....but I don't know if that's a good reason to disable them. Maybe a popup saying "Are you sure you want to run Test Coverage over this package? It will take a lot of time" is better. At least VisualWorks does something similar. What do you think ? Cheers, Mariano

4 5

[Pharo-project] Issue 1541: Settings integration part3
by Alain Plantec Dec. 3, 2009

Dec. 3, 2009

in InBox: SLICE-SettingsMigrationPart3-AlainPlantec.2 *added a menu entry in the world menu for the new setting browser. * added double-click handling in MorphTreeMorph * SystemSettingBrowser, double clicking on a row open a class browser on the method which declares the selected setting * do not update a SystemSettingBrowser if it is not viewed by an opened window (prevents updating of a closed but not yet garbaged window) * improved gradient background rendering (radial direction) * added System-Support-SystemSettings, Network-SystemSettings, Polymorph-SystemSettings and Monticello-SystemSettings packages * migrate all preferences from the old 'Browsing' preferences group * migrate existing http proxy preferences * migrate existing media preferences * add settings for network user name, password, blab email, author fullname * deprecation of some old preference methods Alain

1 0

[Pharo-project] small pharo success story
by Marcus Denker Dec. 3, 2009

Dec. 3, 2009

Hi, 2Denker now has it's first iPhone app deployed and in the store that uses a Pharo backend: http://2denker.de/findabike (german only) The app shows the bikes of DB (German Railway Company): http://en.wikipedia.org/wiki/Call_a_Bike On the phone, we use a standard Objective-C frontend. It gets the data via http from a pharo server. Marcus -- Marcus Denker -- marcus(a)2denker.de http://www.2denker.de 2denker UG (haftungsbeschrÃ¤nkt) Sitz KÃ¶ln Amtsgericht - Registergericht - KÃ¶ln, HRB 65065 GeschÃ¤ftsfÃ¼hrer: Christian Denker und Dr. Marcus Denker

2 2

[Pharo-project] StandardFonts vs Preferences
by Henrik Johansen Dec. 3, 2009

Dec. 3, 2009

Alain, could you deprecate (and remove entires from Parameters) all the set... and get... font-messages in Preferences? Would make it somewhat easier to make the transition from codebits using the Preferences methods for setting, which currently (in most cases) gives no feedback except not changing the fonts. (Like, say, the System Fonts-menu) Also, consider if the setDefaultFonts: / restoreDefaultFonts methods would be useful. Cheers, Henry

2 1

[Pharo-project] Very tiny fonts
by Marcus Denker Dec. 3, 2009

Dec. 3, 2009

Hi, While discussing Visualisations, we realized we want *really* tiny fonts... Here is a hand-drawn sub-pixel font that is just 5 pixels high... http://typophile.com/node/61920 Now we need to make a font for Pharo... Marcus

4 6

[Pharo-project] 64bit VMs some thoughts.
by John M McIntosh Dec. 3, 2009

Dec. 3, 2009

So you sit there smug about the fact you built a 64bit VM, likely for hosting on your 64bit Linux OS. {Or the unix one for Darwin, or that new fangled cocoa one} However it's possible that it's running 1/3 the performance of the 32bit VM. Did you check? Thought not... So let's talk. Are you using the gnuifed version of interp.c? If you don't know, well go check. Are you using GCC 4.1 or higher? The interpreter loop is highly tuned monster that suffers from compiler optimization issues. With careful tuning parms as found in the macintosh xcode build project for the carbon VM using gcc 4.0 you'll get the most optimum performance. GCC 4.2+ ? Michael Rueger and I spent a few days attempting to get good performance out of GCC 4.2 WITHOUT success. I think that can account for at least a 33% slowdown. So where does the other 33% slowdown come from? Well when we compile the VM in 64bit to use a 32bit image each reference to an oops requires us to add a 64bit memory start address to the 32bit oops number to resolve to a 64bit memory address. Unfortunately GCC 4.2 growls, and produces the lousiest code possible to do this. Maybe higher versions of GCC are better? Anyone care to test? So some solutions. (a) Ensure the squeak oops memory block loads within the 0-4GB address space. See pagezero size for Darwin. Then alter the logic a bit so that sqMemoryBase is zero and that the squeak memory accessors don't do the add of sqMemoryBase=0 to the oops address. Although you might have to use GCC 4.2 you'll run 100% faster. (b) Use the (non-free) Intel compiler -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

1 0

[Pharo-project] On issue Issue 1155: "Renaming of a class do not changes title of a System Browser"
by csrabak＠bol.com.br Dec. 3, 2009

Dec. 3, 2009

Pertaining the bug #1155 http://code.google.com/p/pharo/issues/detail?id=1155, it seems to me that we need to register the change for the class name so the SystemWindow gets updated: O2PackageBrowser class>>registerForNotifications Smalltalk at: #SystemChangeNotifier ifPresent: [:cls | (cls uniqueInstance) noMoreNotificationsFor: self; notify: self ofSystemChangesOfItem: #class change: #Added using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Modified using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Renamed using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Commented using: #classModified:; notify: self ofSystemChangesOfItem: #class change: #Recategorized using: #classMoved:; notify: self ofSystemChangesOfItem: #class change: #Removed using: #classModified:; notify: self ofSystemChangesOfItem: #method change: #Added using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Modified using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Recategorized using: #methodModified:; notify: self ofSystemChangesOfItem: #method change: #Removed using: #methodModified: ]. However I could not find how to assemble a #notify:chnage:using: message in order to have the model (O2PackageBrowser) notified. . . If some more knowledgeable on this hierarchy can enlighten me I think we can solve this easily, no? -- Cesar Rabak

1 0

[Pharo-project] is this correct ?
by Mariano Martinez Peck Dec. 2, 2009

Dec. 2, 2009

Hi! Look this peace of code: | instance | instance := TestCase new. Transcript show: TestCase allInstances size; cr. instance become: 'aString'. Transcript show: TestCase allInstances size; cr. The size of TestCase instances is always the same. Although I used become: (and changed to an instance of another class) to one of its instances. So, my main question is, is this correct ? Or the message allInstances to TestCase should not take into account the instance I sent the message become: ? Thanks in advance. Mariano

4 4

Dec. 2, 2009

> From: Damien Pollet <damien.pollet(a)inria.fr> > > > http://www.antigrain.com/research/font_rasterization/index.html#FONT_RASTER… > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > >

2 1

[Pharo-project] Issue # 1498 "Collections should not accept non integer indexes"
by csrabak＠bol.com.br Dec. 2, 2009

Dec. 2, 2009

I'm trying to follow the directions given at: http://code.google.com/p/pharo/wiki/HowToContribute. However, after the SLICE asks for the first comment, it freezes the image and the small window "Writing definitions" stays at 50% progress and nothing happens then. So I'll resort to the alternative plan, which is to send the changeset to this list. On a core image update #11067 the Collection tests are all green. Running all tests show one error and two failures not related to the changed methods. -- Cesar Rabak

3 5