- Pharo-dev - lists.pharo.org

[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

[Pharo-project] [GSoC] Call for mentors!!!
by Mariano Martinez Peck March 23, 2010

March 23, 2010

Hi folks. We wanted to let you know that we are calling for mentors. As you can see in the ideas page: http://gsoc2010.esug.org/ideas There are some projects that still don't have mentors. Furthermore, it would be GREAT if each project can have also a second mentor. This is very important as they can complement each other, be backup, etc. So, please, if you want to be mentor or second mentor, just let us know. If you want to be second mentor of a project, it would be a good idea to talk with the first mentor so that both agree about that (we don't want problems!!!). Remember ALL mentors and second mentors have to register to our website as soon as possible. To register: http://gsoc2010.esug.org/registration All mentors have to register to the mailing list: http://groups.google.com/group/smalltalk-gsoc-mentors Janko is doing an excellent work with the website as you can see. Here you can see, for example, the list of the current mentors: http://gsoc2010.esug.org/mentors After mentors (when I say mentors are both, included second mentors), students will have to apply. Of course, we will let you know when. Cheers GSoC admin team esug.gsoc.adm2010(a)gmail.com http://gsoc2010.esug.org/

1 0

[Pharo-project] Question about HostMenuSystem
by Mariano Martinez Peck March 23, 2010

March 23, 2010

Hi folks. I want to remove HostMenuSystem from PharoCore image. Probably, I can put it on PharoDev image but of course, it will be accesible also from squeaksource to download it. I don't this is a "core" package. In order to do that, I found the following problem. Look to InputEventSensor >> processMenuEvent: evt | handler localCopyOfEvt | localCopyOfEvt := evt shallowCopy. handler := (HostSystemMenus defaultMenuBarForWindowIndex: (localCopyOfEvt at: 8)) getHandlerForMenu: (localCopyOfEvt at: 3) item: (localCopyOfEvt at: 4). handler handler value: localCopyOfEvt There is the only place where HostSystemMenus is used. Now I am trying to see the best way to remove this. The first approach that came to my mind, which may not be the best to implement this method as follows: processMenuEvent: evt "By default the menu events are not handled. In case you want to handle them you should override this method" And of course, in the package HostSystemMenus we override that method with the original code. Then I though some kind of notification or oberser pattern, where someone can register as an "observer" and then, then this menu events occurs, these guys are notified. Maybe using Announcments? My skills here are quite limited. What do you think ? Can you help me ? Cheers Mariano

6 14

[Pharo-project] SystemDictionary has one corrupted entry in 1.1 core 11284 image
by Martin McClure March 23, 2010

March 23, 2010

Applying the 11281-11284 updates seems to leave exactly one entry in the SystemDictionary in the wrong place (too high by one) in the array. Which entry depends on the image. In the downloadable 11284 image it's #MCPTest. I haven't been able to determine how this happens, but executing: Smalltalk globals rehash seems to clean it up. Regards, -Martin

2 1