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

[Pharo-project] Move MetaObjectTools from core to PharoDev
by Mariano Martinez Peck March 23, 2010

March 23, 2010

This package should be removed from core but it should still be loadable. Thus, when needed, they can be easily installed. On the other hand, it could be in PharoDev image. - MetaObjectTools: This package is moved to PharoDev. It doesnt have any users in PharoCore To fix, evaluate: (MCPackage named: 'ObjectMetaTools') unload. I created and put such code in http://www.squeaksource.com/ObjectMetaTools<http://www.squeaksource.com/MetaObjectTools> To load it again in a Pharo image: Gofer new squeaksource: 'ObjectMetaTools'; package: 'ObjectMetaTools'; load. During the week I will analyze the CUIS' ProtocolCatcher and see if it make sense to put it there too. Cheers Mariano

2 7

[Pharo-project] Here's my problems...
by Igor Stasenko March 23, 2010

March 23, 2010

I was working with changesets (manipulating them), then unexpectably, i got an error, and image hangs and starts consuming 100% CPU. I attempted to interrupt it - it shows a debugger, but still unresponsible.. This is a tail of PharoDebug.log: THERE_BE_DRAGONS_HERE Error: There is no free space in this set! 19 March 2010 10:37:13 am VM: Win32 - IX86 - NT - Squeak3.10.2 of '5 June 2008' [latest update: #7179] Image: PharoCore1.1ALPHA [Latest update: #11112] WeakIdentityKeyDictionary(Object)>>error: Receiver: a WeakIdentityKeyDictionary(a ChangeList->an IdentityDictionary(#getCompletionController->...etc... Arguments and temporary variables: Before that , i were able to fileout the changeset (see attached file) but then, when i tried to file it in from a file browser i got MessageNotUnderstood: receiver of "methodsFor:stamp:" is nil and again, unable to continue working and had to close image, because it unresponsive. What is interesting , that if i clicking 'changes' in a file browser, and then select everything and file it in, no errors happen and everything works just fine. But if i doing 'install' without looking at changeset details, i got the above error. -- Best regards, Igor Stasenko AKA sig.

5 16

[Pharo-project] GSoC next steps
by Mariano Martinez Peck March 23, 2010

March 23, 2010

Hi folks. We received several mails asking questions for the next step. So I think it is a good idea to clarify it a bit. Mentors and students, will have to register in Google GSoC website, but first we want them to be registered in our ESUG GSoC website. Why? Several reasons: 1. We are trying to approach this year GSoC on a more organized way, 2. that's why we are building that special Smalltalk GSoc website, 3. to support you, the students and the projects as best as possible. We are developing this registration in our website and it was almost finish. We will call for mentors first. We created a mailing list for all the mentors. If you are mentor, you should be there. If you are not, please contact us. We had already sent an email to mentors mailing list to invite them to register as mentors in our ESUG GSoC website. If we discover bugs during that period, they will be fixed. Once after all mentors have been successfully registered and the registration process is working correctly, then we will invite students to register also. After that, students and mentors will be registered in our website, each of them will have each other's contact information, each will have their own page for the project, etc. Once all of this is done, then mentors and students will register in the Google GSoC webpage. Finally, mentors will vote and choose the projects to be selected. Even more, if there is more than one student for the same project, the mentor will have to choose. Cheers GSoC admin team esug.gsoc.adm2010(a)gmail.com http://gsoc2010.esug.org/

4 7

[Pharo-project] [ANN 1.1] pre-built Core#11291
by Marcus Denker March 23, 2010

March 23, 2010

https://gforge.inria.fr/frs/download.php/26702/PharoCore-1.1-11291-UNSTABLE… -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [update 1.1] #11291
by Marcus Denker March 23, 2010

March 23, 2010

11291 ----- Issue 1973: PluggableTreeMorph class#on:list:selected:changeSelected: inconsistency - call #cleanUpForRelease -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] [update 1.1] #11289
by Marcus Denker March 23, 2010

March 23, 2010

11289 ----- Issue 296: Logo inside Pharo window should be locked ... Issue 2196: Better cleanupForProduction -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

3 4

[Pharo-project] [update 1.1] #11290
by Marcus Denker March 23, 2010

March 23, 2010

11290 ----- Issue 2160: Removal of requires calculation code -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

2 1

[Pharo-project] Major shrinks
by Mariano Martinez Peck March 23, 2010

March 23, 2010

Hi folks. I was playing a bit trying to shrink a little a PharoCore image. My idea was to think a shrink that was be acceptable for the most common scenario: a runtime (production) environment where. Of course, some of the things I do in the shrinks has side effects, but most of the times, you can deal with that in such scenarios. Some of the things came from my mind, others from an OLD version of SystemDictionary >> majorShrink, others from Pavel's PharoKernel, etc. So...I will post the little code here. I am not completely sure about the side effects of each piece, so if you know, please let me know :) On the other hand, I wanted to ask you if you think something of this make sense to be part of ScriptLoader >> cleanUpForProduction Taking a PharoCore 1.1 11277 of 13 MB I get an image of 9 MB...so 4 MB less and I can still even browse code. When running the image before the shrink I get 25MB in use and with the image shrinked I get 20MB. Cheers Mariano "Compact all MethodDictionary instances" | oldInstances newInstances | oldInstances := MethodDictionary allInstances. newInstances := oldInstances collect: [ :md | (MethodDictionary new: md size) compactCopyFrom: md; yourself]. oldInstances elementsForwardIdentityTo: newInstances. "To put all all classes with the default category. Still can browse and recompile the whole image. Most production enviroments don't care about categories...this make sense when developing." Smalltalk allClassesAndTraitsDo: [:each | each zapOrganization ]. "Different cleanUps" TextStyle allSubInstancesDo: [:ts | ts newFontArray: (ts fontArray copyFrom: 1 to: (2 min: ts fontArray size))]. "Clean all Monticello related stuff. You won't be able to browse packages for example" MCWorkingCopyBrowser allInstancesDo: [:each | each flushAllCaches ]. MCWorkingCopy allInstancesDo:[:wc| SystemChangeNotifier uniqueInstance noMoreNotificationsFor: wc. wc unregister]. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCPackageManager. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: MCWorkingCopy. "Most application don't need sound" SoundService default: nil. SoundService unregister: DummySoundSystem. SystemChangeNotifier uniqueInstance noMoreNotificationsFor: (Smalltalk at: #RecentMessageSet). TranscriptStream newTranscript: ThreadSafeTranscript new. ImageSegment classPool at: #RecentlyRenamedClasses put: Dictionary new. ExternalSettings classPool at: #RegisteredClients put: Set new. Locale classPool at: #LocaleChangeListeners put: nil. "Clean all the changes" ChangeSet resetCurrentToNewUnnamedChangeSet. ChangeSet current initialize. ChangeSet classPool at: #AllChangeSets put: (OrderedCollection with: ChangeSet current). Symbol rehash. 3 timesRepeat: [ Smalltalk garbageCollect. Symbol compactSymbolTable ].

6 13

[Pharo-project] Implementing MethodWrappers in Smalltalk
by Mariano Martinez Peck March 23, 2010

March 23, 2010

Hi folks. I was reading the PBE chapter about reflection where it talks a little about Method Wrappers. Then, I took a look at TestCoverage implementation. After that, I took a look at http://www.squeaksource.com/ObjectsAsMethodsWrap The main difference between both approaches are: TestCoverage - Just extends from ProtoObject, implement doesNotUnderstand: , run: aSelector with: anArray in: aReceiver , etc - To install and uninstall the wrappers uses methodDictionary at: xxx put: yyy - Just for test coverage. ObjectAsMethodWrapper - Is more generic, support pre and post closures, and you can subclass and create you own wrapper - To install and uninstall the wrappers it uses Class >> addSelector: self selector withMethod: self So...what I did ?? I created a TestCoverage but creating a subclass of ObjectAsMethodWrapper called TestCoverageMethodWrapper which just implements a 1 or 2 methods. I mean, I reused the generic ObjectAsMethodWrapper. It seems to work ok. I did some test running TestCoverage with both implementation and it seems mine (TestCoverageMethodWrapper) is 30% much slower than the original. Trying to understand why, I think it is because the original one uses just methodDictionary at: xxx put: yyy but mine uses Class >> addSelector: self selector withMethod: self. In this last method, there are all the notifications, add to localSelectors...etc Now...I have two questions: 1) For a generic approach to method wrappers, which of those two ways would you use ? should I care about notifying, adding to localSelectors, etc? Or at is just temporal, I don't care ? which are the pros and cons you see with each alternative ? 2) Do you think it make sense to the package ObjectsAsMethodsWrap in PharoCore as a "library" to create lightweight proxies ? It is just 4 classes and it would be cool to change TestCoverage to that implementation. Then, you only don't have the library, but also some real examples. Of course, this can be done if we eleiminate the 30% of slowleness. so...what do you think ? Cheers Mariano

3 5

[Pharo-project] [update 1.1] #11288
by Marcus Denker March 23, 2010

March 23, 2010

11288 ----- Issue 2195: fix the toolbuilder GUI Issue 1011: Monticello snapshot browser does not display class side definitions Issue 2192: x11FontLegalNotices Issue 2193: SequenceableCollection>>reverse -> reversed Issue 2189: MCPTest/ MethodNames gives DNU -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0