- Pharo-dev - lists.pharo.org

[Pharo-project] inspector and auto-update
by John M McIntosh Jan. 11, 2010

Jan. 11, 2010

Hi I noticed that in the past (likely some current squeak image) When you brought up an inspector on an object it would auto-update the instance variables shown. However this behaviour is lacking in a PharoCore1.0rc1 Latest update: #10502 So is that what is expected? -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

5 4

[Pharo-project] [ANN] ClaseUseDiscovery tool
by Mariano Martinez Peck Jan. 11, 2010

Jan. 11, 2010

Hi folks: As part of my PhD I started to work with ImageSegment. This week I clean up all the stuff related to class discovery from there. I then wanted to put that extracted code in a separate class. I didn't like that code at all, so at the end I finished rewriting completely this stuff. The cool thing is that: - I remove all that stuff from ImageSegment (which has nothing to do with that) - I remove that stuff from classes like Behavior and ClassDescription - I put all these as an external package that can be perfectly loaded in core - I rewrote that in style that I like much more. At least for me, it is much more easy to understand and to use now - I wrote test cases - I wrote good class comment. The repository is: http://www.squeaksource.com/ClaseUseDiscovery and the license is MIT. It is a little project, but maybe someone find it useful. This project only works with Pharo images newer than 1.1 version 11142 I paste here the class comment of CUDClassesUseDiscoverer: Cheers Mariano A CUDClassesUseDiscoverer is a little class which can be used to discovering used and unused classes during a period of time. If you want to build minimal images, it is useful also to detect for example, the amount of classes that are used just to do a simple message invokating. It helps also when some classes are being used and you don't know why. Little examples of how to use it: | aDiscoverer | aDiscoverer := CUDClassesUseDiscoverer startDiscovery. ......DO SOMETHING HERE...... aDiscoverer stopDiscovery. After that, you can: aDiscoverer activeClassesDuringDiscovery. aDiscoverer inactiveClassesDuringDiscovery. aDiscoverer activeClassesByCategoryDuringDiscovery. aDiscoverer swapOutInactiveClassesDuringDiscovery. For more details, see the tests in class CUDClassesUseDiscovererTest. Explanation: The Virtual Machine pays attention not to crash totally when you put a nil in a Method Category. In addition, there is a possibility to force a MethodDictionary fault (message induceMDFault) with the message. This method copies the methodDict in the organization slot. Actually, it creates an Array with the methodDict and the organization and set it in the organization slot. Finally, it sets a nil to the methodDict instance variable. After this is done, when that class is used and the methodDict is asked (it is very important to acces the methodDict using the accessor) it checks whether it is nil or not. If it is nil, it will search for that methodDict in the Array of the organizaction it will then copy it to the methodDict instance variable and will log in Smalltalk at: #MDFaultDict. Sometimes you will see that you have classes that were used but you do not know why or who used it. To solve this question, we can have that log. But in order to have that trace, you have to use the message startDiscoveryWithTrace instead of startDiscovery. The log will be then put in that dictionary and you can inspect it after the discovery. Taking that explanation in mind, you can follow these steps: 1) Send the message CUDClassesUseDiscoverer startDiscovery or startDiscoveryWithTrace which forces a MethodDictionary fault in all classes. Yes! It sends the message induceMDFault to all classes except classes like Array, Object, Class, Message and MethodDictionary. After this, all classes but those ones, will have the methodDict with nil. 2) Do a few things, use the system for a while. Maybe even save and resume the image. 3) Stop the discovery. This will stop everything and restore all remaining MethodDictionary faults. It will also process which classes were active and which ones were not. 4) Now, it is easy. All classes that still have a nil in the mehodDict is because they were not used, and those who have something different from nil is because they were. With the message activeClassesDuringDiscovery or inactiveClassesDuringDiscovery you can and return the active or unactive classes respectively. There is also the message swapOutInactiveClassesDuringDiscovery which makes up segments by grouping unused classes by system category and write them to disk. There are some categories that are excluded because they have problems, like System and Kernel. If you started the discovery with the message startDiscoveryWithTrace, after doing all those steps you can then inspect Smalltalk at: #MDFaultDict and you will see that in the dictionary you will have an element per class. That element is a ByteString that contains all the stack trace. This shows you all the messages and why that class was used. This approach of swapping out inactive classes have two big problems: - The granularity is too high: the class. As soon as only one method is invoked, the whole class is recovered. - It is very common to recover all classes doing a simple action. For example, searching for implementors or senders of a certain method. Because of this, when you are developing in your Smalltalk image is very likely that all classes are recovered in less than 5 minutes of work. It is not useful. Browsing or editing code seems not to be a problem, thus. Maybe this approach has more sense in production images rather than development.

4 4

[Pharo-project] [update 1.1] #11151
by Marcus Denker Jan. 11, 2010

Jan. 11, 2010

11150 ----- Issue 1593 : Packages: strange MC packages in need of cleanup (again) MC lost lots of classes... so this loads all affected packages (the settings ones).

4 3

[Pharo-project] Mac VM 5.3b1 ships
by John M McIntosh Jan. 11, 2010

Jan. 11, 2010

I've push the latest cocoa based 32/64bit macintel/powerpc VM 5.3b1 Various users pointed out that option-arrow key did not work, plus there was a crash due to a draw locking issue. I spent a few hours looking into the complexity of keyboard management in Cocoa and left-overs from NeXTStep. I likely still have more hours of testing for extended keyboards but it should now work for the enter/return, esc, delete, page up/down, and arrows keys with the various combinations of shift, function, control, option, and apple. The crash was related to a race condition in the os-x drawing logic. I refactored it to a more simplistic code base shared between the iPhone and OSX. As a bonus the non-complex code is actually faster than the Carbon Drawing logic found in the 3.x/4.x series of VMs, and much faster than the previous complex/broken logic. Look for the folder experimental/64bits in the regular places found via http://smalltalkconsulting.com/squeak.html or ftp://ftp.smalltalkconsulting.com/experimental/64bit/32bitImage*64bitVM/ or http://homepage.mac.com/johnmci/FileSharing.html click to experimental, 64bits , 32bitImage*64bitVM file name: Squeak 64-32 5.3b1.app.zip This *beta* VM runs in 32 or 64 bit mode on macIntel, and 32bit mode on powerpc to support Squeak 32bit images. Includes the freetype plugin, and requires os-x 10.5 or higher. -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

2 1

[Pharo-project] Categorizing method extension with pragma
by CÃ©drick BÃ©ler Jan. 11, 2010

Jan. 11, 2010

Hi, Just a 2 cents thought on method extension. Why not associating a pragma instead of using the package name prefixed by a star ? Say there is a package named MyPackage and I override a method in String or add a new one. What I'd like is keeping the original method category name (or find an appropriate one) instead of using *mypackage. For instance: String>>aMethod <package: MyPackage> ... ... ^result Then, we would have to adapt monticello for that purpose. We could also use dynamic protocols to get the list of extension method by package. What does other think ? I find it could be a good starting point to deal with packages. -- CÃ©drick

4 6

[Pharo-project] problem installing Nile
by Mariano Martinez Peck Jan. 11, 2010

Jan. 11, 2010

I don't know why, but (sometimes) I have errors trying to install Nile-All in PharoCore. This is weird becuase it says that it didn't found a version, but the version really exists. I attach screenshots. Any idea? cheers mariano

2 5

[Pharo-project] Pharo-beginner mailing list ?
by StÃ©phane Ducasse Jan. 11, 2010

Jan. 11, 2010

Hi all I remember that the squeak-beginner mailing-list (our ideas) was a huge success since it enabled people to ask questions and have less mails. So a question to you: do you think that it would be good to have a pharo-beginner mailing list? Stef

13 26

[Pharo-project] [ANN] Hudson continuous integration server support
by Yanni Chiu Jan. 10, 2010

Jan. 10, 2010

I've created a project at: http://www.squeaksource.com/HudsonBuild.html You can automate a build through a shell script run by Hudson, and view the SUnit test results through Hudson. The first example runs the unit tests in the PharoCore image, and the second example loads Pier and runs its unit tests. The examples derive from Lukas' Gofer scripts, but you could set things up to use Metacello. The build scripts are attached to this message as a zip file. A howto.txt is included in the zip, and pasted below. -- Yanni Chiu ========= howto.txt ========= ====== PART A - Prepare image and adjust build scripts ====== Unzip the build scripts - choose a build home directory, and unzip the files there - there should be an empty "images" directory Create an initial build image - get a distribution image (e.g. http://www.pharo-project.org/pharo-download) - put the image in the images directory - start the image, and refresh Gofer using: <code> Utilities updateFromServer. [ Gofer gofer load ] on: Error do: [ :err | err retry ]. Gofer gofer recompile. </code> - this update should be part of the build script, but it was not working for me when it's run from a startup script. - save the image as "core" Adjust build scripts - edit the core.sh and pier.sh scripts, setting suitable values for: SQUEAK_VM IMAGES_HOME SCRIPTS_HOME - you may have to adjust the repository locations too These sample build scripts are just a starting point for creating your own build scripts for your project. The core.sh script does not actually load any packages, it just runs the test cases in the PharoCore image. The pier.sh script loads Seaside/Magritte/Pier into the core image, then runs the test cases. ====== PART B - Integrate with Hudson ====== Download hudson.war from http://hudson-ci.org/ Start the Hudson server. - run something like: WARFILE=$HOME/apps/hudson/hudson.war LOGFILE=hudson.log nohup java -jar $WARFILE --httpPort=9090 > $LOGFILE 2>&1 & - port 9090 is used to avoid conflict with Seaside on 8080 - goto the Hudson dashboard at http://localhost:9090 Add new Hudson job - from Hudson dashboard, select "New Job" - fill in a job name, e.g. "Core" - choose the "Build a free-style software project" radio button - click on OK Configure the new job - you should be sent to the job configuration screen, after the previous step - in the "Build" section, click "Add build step", select "Execute shell" from dropdown menu - in the Command textarea that appears, type the full path to the build script: e.g. /Users/yanni/work/public/Core/pier.sh - in the "Post-build Actions" section, enable "Publish JUnit test result report" - enter "test-reports/*.xml" into the text input labelled "Test report XMLs" that appears. - save the configuration changes (i.e. click "Save"). Run the build job - after saving the new job, you should already be in the new job's control screen. If not, you can navigate there from the dashboard. - start a build by clicking on the "Build Now" link ===== HINTS ===== 1. Click on "Workspace" to see the "Wipe Out Workspace" link. If a PharoDebug.log file is generated, it will be more easy to spot, if the workspace was originally cleaned out. 2. Test your build script in a headful image beforehand. Any flaw will cause the build to stall, and you'll need to abort it (using the Hudson interface), then look at the PharoDebug.log to figure out what went wrong. 3. If the package-cache directory known to your build image still exists, then it will be used (and your packages will appear there, instead of in the Hudson workspace). If it does not exist, then a new package-cache directory will be created in the Hudson job workspace. 4. Monitor the package-cache in the Workspace, to get an idea of the progress of the build. The pier.sh build runs in a 3.5 minutes, building from a local file repository, on a MacBook. 5. Hudson timeout plugin - I've not tried this yet, but if you have a build script error, your build does not abort on its own (or, I've not waited long enough).

7 23

[Pharo-project] how to import an icon
by Tudor Girba Jan. 10, 2010

Jan. 10, 2010

Hi, I would like to import icons from external files in the image. These should be used for menus and buttons. How should I do that? What format should be used? What size? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow."

2 1

[Pharo-project] [update 1.1] #11147
by Marcus Denker Jan. 10, 2010

Jan. 10, 2010

11147 ----- Issue 1761: Unloadable-reloadable Services-Base + DeprecatedPreferences packages (part 1 - 3) ... some packages are dirty. This will be fixed next, together with part 4 and a cleanup of packages that are defined wrongly. Marcus

5 9