- Pharo-dev - lists.pharo.org

[Pharo-project] Major shrinks

by Mariano Martinez Peck

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 ].

March 23, 2010

Re: [Pharo-project] bug in the code of CompiledMethod >> =

by StÃ©phane Ducasse

> On Mon, Mar 22, 2010 at 2:54 PM, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > You might also want to check last code published in trunk. > > I saw that. You're eliminating closeTo: for float comparison which seems fine to me :) Thanks Nicolas! > However, it is indicative that a recompile all is necessary after redefining the number scanning facilities. I guess that this is part of the standard release build process. If not, we should add it. I saw the following but I could not see the float issue you mentioned. Where it is? analogousCodeTo: aMethodProperties | bs | (aMethodProperties isKindOf: MethodProperties) ifTrue: [^aMethodProperties analogousCodeTo: self]. (bs := self basicSize) ~= aMethodProperties basicSize ifTrue: [^false]. 1 to: bs do: [:i| ((self basicAt: i) analogousCodeTo: (aMethodProperties basicAt: i)) ifFalse: [^false]]. ^true hasAtLeastTheSamePropertiesAs: aMethodProperties "Answer if the recever has at least the same properties as the argument. N.B. The receiver may have additional properties and still answer true." aMethodProperties keysAndValuesDo: [:k :v| (v isKindOf: Pragma) "ifTrue: [Pragmas have already been checked]" ifFalse: [ (self includes: k->v) ifFalse: [^false]]]. ^true On Mar 22, 2010, at 10:54 PM, Nicolas Cellier wrote: > You might also want to check last code published in trunk. > > Nicolas > > 2010/3/22 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Mon, Mar 22, 2010 at 2:25 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> eliot >>> >>> Your changes fixed some of the problems. Now I tried to fix the test >>> testAnalogousCodeTo in MethodPropertiesTest and >>> the expression returns false. >>> >>> (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false >>> >>> (#zork->'hello') = (#zork->'hello') -> true >> >> For me >> #(#zork -> 'hello') size 3 >> In Pharo is it true that >> #(#zork -> 'hello') size 1 >> ??!?! >> In that case I would implement analogousCodeTo: in Association, e.g. >> analogousCodeTo: anObject >> ^anObject class == self class >> and: [key = anObject key >> and: [value = anObject value]] >> >> But if Association isn't a literal I would simply check >> MethodPropertiesTests. It could be obsolete. >>> >>> Stef >>> >>> On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: >>> >>>> Oops. Find attached. >>>> >>>> 2010/3/22 Cyrille Delaunay <cy.delaunay(a)gmail.com> >>>> try in a Pharo-1.0-10515-rc3 image : >>>> >>>> |set| >>>> set := Set new. >>>> Collection withAllSubclasses do: [:aClass | >>>> set addAll: aClass methods >>>> ]. >>>> >>>> It will raise an exception telling: "MessageNotUnderstood: >>>> ByteSymbol>>analogousCodeTo:". >>>> Indeed, in the code of CompiledMethod >> = , the message >>>> 'analogousCodeTo:' is send to a >>>> symbol. >>>> >>>> >>>> I opened an Issue: >>>> http://code.google.com/p/pharo/issues/detail?id=2185 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> <Object-analogousCodeTo.st>_______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

[Pharo-project] [GSoC] Call for mentors!!!

by Mariano Martinez Peck

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/

March 23, 2010

Re: [Pharo-project] Question about HostMenuSystem

by Mariano Martinez Peck

> > > > Adrian any idea ? > > > > I removed them when they where broken. We should enable them again: > > http://code.google.com/p/pharo/issues/detail?id=1876 > > Ahh okok. Yes, please, we need to enable it :) > > Maybe there is a problem with the Smalltalk startUpList ? I know it has > been changed in previous updates. > > > > so if you remove this strange all=error swallowing wrappter in > HostSystemMenus>>#startUp: > > [self setDefaultMenuProxyClass] ifError: [:err :rcvr | ]. > > > you will get a DNU at image startup that shows that we need to fix the menu > building code as it used > the world menu. It should build it's menu using the menu builder framework. > Ok....I don't have too much time now (and I don't know anything about the WorldMenu). But when this is working I can continue to make it loadable in a clean way. Thanks Mariano > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

March 23, 2010

Re: [Pharo-project] Question about HostMenuSystem

by Marcus Denker

On Mar 22, 2010, at 12:32 AM, Mariano Martinez Peck wrote: > Thanks Michael. Now I have another question. In the latests PharoCore 1.1 I cannot see the VM menu. I only see the options "Squeak VM" and "Edit". > > But the HostMenuSystem was only removed in Pharo 1.0 with the ifPresent: in processMenuEvent: > In 1.1 that method is correct. > > Then....I don't understand why I don't see the VM menus like Tools, Debug, etc. Should I see them ? > > Adrian any idea ? > I removed them when they where broken. We should enable them again: http://code.google.com/p/pharo/issues/detail?id=1876 > Maybe there is a problem with the Smalltalk startUpList ? I know it has been changed in previous updates. > so if you remove this strange all=error swallowing wrappter in HostSystemMenus>>#startUp: [self setDefaultMenuProxyClass] ifError: [:err :rcvr | ]. you will get a DNU at image startup that shows that we need to fix the menu building code as it used the world menu. It should build it's menu using the menu builder framework. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] SystemDictionary has one corrupted entry in 1.1 core 11284 image

by StÃ©phane Ducasse

Thanks we were looking for it. Stef On Mar 23, 2010, at 1:35 AM, Martin McClure wrote: > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

Re: [Pharo-project] Getting the website ready for 1.0

by Marcus Denker

On Mar 22, 2010, at 9:45 AM, Adrian Lienhard wrote: >>> If there is one-click images for Pharo, it might be easier for newbies. >>> >>> >> There is, but experimental: >> >> look in https://gforge.inria.fr/frs/?group_id=1299 >> "One-Click Experiments" >> >> Adrian offered him self also to do a new one for 1.0 > > Did I? I think that was Marcus :). But anyway, yes, we want to do 1-click images for the release. > I will do that today... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 23, 2010

Re: [Pharo-project] bug in the code of CompiledMethod >> =

by StÃ©phane Ducasse

> On Mon, Mar 22, 2010 at 2:25 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > eliot > > Your changes fixed some of the problems. Now I tried to fix the test testAnalogousCodeTo in MethodPropertiesTest and > the expression returns false. > > (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false > > (#zork->'hello') = (#zork->'hello') -> true > > For me > > #(#zork -> 'hello') size 3 > > In Pharo is it true that > > #(#zork -> 'hello') size 1 I get #(#zork -> 'hello') size 3 > In that case I would implement analogousCodeTo: in Association, e.g. > > analogousCodeTo: anObject > ^anObject class == self class > and: [key = anObject key > and: [value = anObject value]] > > > But if Association isn't a literal I would simply check MethodPropertiesTests. It could be obsolete. > > > Stef > > On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: > > > Oops. Find attached. > > > > 2010/3/22 Cyrille Delaunay <cy.delaunay(a)gmail.com> > > try in a Pharo-1.0-10515-rc3 image : > > > > |set| > > set := Set new. > > Collection withAllSubclasses do: [:aClass | > > set addAll: aClass methods > > ]. > > > > It will raise an exception telling: "MessageNotUnderstood: ByteSymbol>>analogousCodeTo:". > > Indeed, in the code of CompiledMethod >> = , the message 'analogousCodeTo:' is send to a > > symbol. > > > > > > I opened an Issue: > > http://code.google.com/p/pharo/issues/detail?id=2185 > > > > > > > > _______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > <Object-analogousCodeTo.st>_______________________________________________ > > Pharo-project mailing list > > Pharo-project(a)lists.gforge.inria.fr > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

Re: [Pharo-project] bug in the code of CompiledMethod >> =

by StÃ©phane Ducasse

Where? > You might also want to check last code published in trunk. > > Nicolas > > 2010/3/22 Eliot Miranda <eliot.miranda(a)gmail.com>: >> >> >> On Mon, Mar 22, 2010 at 2:25 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr> wrote: >>> >>> eliot >>> >>> Your changes fixed some of the problems. Now I tried to fix the test >>> testAnalogousCodeTo in MethodPropertiesTest and >>> the expression returns false. >>> >>> (#zork->'hello') analogousCodeTo: (#zork->'hello') -> false >>> >>> (#zork->'hello') = (#zork->'hello') -> true >> >> For me >> #(#zork -> 'hello') size 3 >> In Pharo is it true that >> #(#zork -> 'hello') size 1 >> ??!?! >> In that case I would implement analogousCodeTo: in Association, e.g. >> analogousCodeTo: anObject >> ^anObject class == self class >> and: [key = anObject key >> and: [value = anObject value]] >> >> But if Association isn't a literal I would simply check >> MethodPropertiesTests. It could be obsolete. >>> >>> Stef >>> >>> On Mar 22, 2010, at 6:20 PM, Eliot Miranda wrote: >>> >>>> Oops. Find attached. >>>> >>>> 2010/3/22 Cyrille Delaunay <cy.delaunay(a)gmail.com> >>>> try in a Pharo-1.0-10515-rc3 image : >>>> >>>> |set| >>>> set := Set new. >>>> Collection withAllSubclasses do: [:aClass | >>>> set addAll: aClass methods >>>> ]. >>>> >>>> It will raise an exception telling: "MessageNotUnderstood: >>>> ByteSymbol>>analogousCodeTo:". >>>> Indeed, in the code of CompiledMethod >> = , the message >>>> 'analogousCodeTo:' is send to a >>>> symbol. >>>> >>>> >>>> I opened an Issue: >>>> http://code.google.com/p/pharo/issues/detail?id=2185 >>>> >>>> >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>> >>>> >>>> <Object-analogousCodeTo.st>_______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

March 23, 2010

[Pharo-project] SystemDictionary has one corrupted entry in 1.1 core 11284 image

by Martin McClure

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

March 23, 2010