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

[Pharo-project] Getting Shout in Pharo 1.1

by Alexandre Bergel

Hi Andy, Little needs to be done to have a preliminary version of Pharo 1.1. One of remaining things is the method SHWorkspace class >> initialize which uses the former registration mechanism. Would it be possible to replace this method by: initialize ((TheWorldMenu respondsTo: #registerOpenCommand:) and: [((TheWorldMenu class >>#registerOpenCommand:) sendsSelector: #deprecated:) not]) ifTrue: [TheWorldMenu registerOpenCommand: {'Shout Workspace'. {self. #open}}] and add: menuCommandOn: aBuilder <worldMenu> (aBuilder item: #'SH Workspace') parent: #Tools; action:[ self new open ]; icon: self taskbarIcon. I guess this change are squeak compatible. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 6, 2010

[Pharo-project] [ENH] Added CompiledMethod>>isDeprecated

by Alexandre Bergel

SLICE-DeprecationTestMethod-Alexandre_Bergel.1 is in the inbox. It simply add a isDeprecated test method on CompiledMethod. A test has been added to CompiledMethodTest. http://code.google.com/p/pharo/issues/detail?id=2390 It would be great to have this slice in the image. I am working to produce Pharo 1.1. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

May 6, 2010

Re: [Pharo-project] Set + collect:

by GermÃ¡n Leiva

2010/5/3 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > Hi, this is my first post (please be gentle xD) > > Thanks! > > xD > > > > The #collect: message commonly return a new collection like the receiver, > but this is really unpractical in some cases > > > > e.g. > > col := Set with: 'one'->1 with: 'two'->2 with: 'dos'->2. > > (col collect: [:each | each value ]) sum > > In VW you get the same. > > Yes > In this example #sum will return 3 instead of 5 (I searched a test for > #sum but I didnÂ´t find it). > > > > Ok, I can use the message #asBag (or something like that) but does the > second line have to depend on the type of the receiver (i.e. the type of > col)? > > I think that this is the invariant for collect: ? > > I didnÂ´t understand that. I'll like that this line (col collect: [:each | each value ]) sum always returns 5 independently of the class of col (if col has the elements 'one'->1 , 'two'->2 and 'dos'->2). > For example, the implementation of #collect: in SortedCollection returns > an OrderedCollection (in the current image) > > in VW too > > Yes, I like that. I just put the example to show that* #collect:* not always returns a new collection like the receiver. > and in other dialects the message #collect: when the receiver is a Set > returns a Bag ... > > which ones? > > In IBM VisualAge 6.0 returns a Bag (in Instantiations VA 7.5.2 returns a Set). > Basically, what do you think of an implementation like this? > > > > Set >> collect: aBlock > > "Evaluate aBlock with each of the receiver's elements as the argument. > > Collect the resulting values into a Bag. Answer the new collection." > > | newBag | > > newBag := Bag new: self size. > > array do: [:each | each ifNotNil: [newBag add: (aBlock value: each)]]. > > ^ newBag > 2010/5/4 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> > True.It can be impractical, but no need to change #collect: > Please use #detectSum: > > (Set with: 'one'->1 with: 'two'->2 with: 'dos'->2) detectSum: [:e |e > value]. > or #collect:as: > > ((Set with: 'one'->1 with: 'two'->2 with: 'dos'->2) collect: [:e |e > value] as: Array) sum. > > Nicolas Nice =) I didn't know those messages (although IMHO the name #detectSum: is not pretty - I'm thinking aloud here ... *#acummulateSum:* or: directly * #sum:* ...?) The reason I'm proposing to change the *Set >> #collect:* implementation is because the only situtation when you need that *#collect:* returns a Set is when you didn't want duplications and for that is really nice to explicity send the message asSet. In all other cases a Bag is all you need as response to collect (when collect is sended to a Set). If you say this is counterproductive and the change will generate more headaches than happiness I understand xD Cheers, > > 2010/5/3 GermÃ¡n Leiva <leivagerman(a)gmail.com>: > > Hi, this is my first post (please be gentle xD) > > > > The #collect: message commonly return a new collection like the receiver, > > but this is really unpractical in some cases > > e.g. > > col := Set with: 'one'->1 with: 'two'->2 with: 'dos'->2. > > (col collect: [:each | each value ]) sum > > In this example #sum will return 3 instead of 5 (I searched a test for > #sum > > but I didnÂ´t find it). > > > > Ok, I can use the message #asBag (or something like that) but does the > > second line have to depend on the type of the receiver (i.e. the type of > > col)? > > For example, the implementation of #collect: in SortedCollection returns > an > > OrderedCollection (in the current image) and in other dialects the > message > > #collect: when the receiver is a Set returns a Bag ... > > > > Basically, what do you think of an implementation like this? > > > > Set >> collect: aBlock > > "Evaluate aBlock with each of the receiver's elements as the argument. > > Collect the resulting values into a Bag. Answer the new collection." > > | newBag | > > newBag := Bag new: self size. > > array do: [:each | each ifNotNil: [newBag add: (aBlock value: each)]]. > > ^ newBag > > Cordially, > > -- > > GermÃ¡n Leiva > > LeivaGerman(a)gmail.com > > > > _______________________________________________ > > 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 > -- GermÃ¡n Leiva LeivaGerman(a)gmail.com

May 6, 2010

Re: [Pharo-project] Metacello questions

by Andreas Raab

On 5/5/2010 11:36 PM, Torsten Bergmann wrote: > Just have a look at ConfigurationOfSQLite3 for a simple > example. This one has a "project dependency" on ConfigurationOfFFI. > > If you want Help system project to be loaded in your configurartion > you need to define it in the baselineXXX method and set a specific > version of the project in your own #versionXXX method Thanks. Does that mean the documentation is just wrong then? It says MetacelloReferenceConfig>>baseline10: "... snip ..." spec "Create or update a project reference" project: 'UI Support' with: [ "One or more of the following attributes may be defined or changed" spec "Name of config class (i.e., ConfigurationOfXXX)" className: 'ConfigurationOfUI'; "Version of project to be loaded. if theversionString is not specified, then the latest version of the project is used." versionString: '1.0'; This last comment made me assume that not providing a version would be enough to make Metacello load the latest version. Also, the reference config has no #version: anywhere related to the project dependency. Oh, and what's the difference between #version: (SQLite3) and #versionString: (MetacelloReferenceConfig)? Cheers, - Andreas

May 6, 2010

Re: [Pharo-project] gettext package

by Hilaire Fernandes

Philippe Marschall a Ã©crit : >>> The protocol I have in mind for Seaside is something like: >>> >>> html translate: >> aString translated "return the translating in the current locale." > > Nope sorry, in a server the current locale in the one of the request or > session, not a global variable. Seaside can figure this out Yes, it makes sense. So in some way you need to specify the locale to use for translation, and it was not how was intended String>>translated, so definitely not your friend. > automatically which is why I need some layer over gettext. But I also Right. > need a way to make the gettext exporter aware of this, basically looking > for more selectors. Yes, we should adapt the protocol to the need. I would like to clean it a and remove some classes as the NaturalLanguageEditor and InternalTranslator so we can simplify the whole package. > >>> html translate:to: >> >> NaturalLanguageTranslator >> translate: 'This point %1' >> toLocaleID: (LocaleID isoLanguage: 'fr') >> inDomain: 'DrGeoII' >> -> 'Ce point %1' >> 'DrGeoII' is the name of the catalog to look for the translation. > > Which would be the Seaside application name. This can be looked up > automatically without a need to repeat yourself every time you want to > have a string translated. Yes, it makes sense. > >> Wth this message you also avoid some overhead as your directly specify >> the translation catalog. The system does not need to figure out the >> catalog to search the translation (done by figuring out from which class >> - then class category - the String>>translated message was sent). >> >> >> Your register a domain from classes prefix: >> TextDomainManager registerCategoryPrefix: 'DrGeoII' domain: 'DrGeoII'. > > I would need to hock into that. So that a domain has a "scope" of only > several class categories and has a given value there. Is there a way to > do this? Yes, execute: TextDomainManager registerCategoryPrefix: 'Seaside-MyShop' domain: 'MyShop'. Then a new domain is created, at startup, the relevant .mo file are loaded (I guess, not sure how it is handled in detail). Is it what you were asking? >> Then you export the .po file for translation: >> GetTextExporter2 exportTemplate. >> >> Then you compile your .po translation as .mo and move it in >> locale/fr/LC_MESSAGES/DrGeo.mo >> >> >> Some documentation in the PBE2 could be written once stuff is stabilized. >> In the Etoys ml, Bert proposed to move the domain in the method >> properties to get a more efficient translation look-up >> >>> What would the way to hook into GetTextExporter(2) to make it pick >>> that up? This I really don't know. Hilaire

May 6, 2010

Re: [Pharo-project] customizing tab looks in watery2

by Richard Durr

Take a Look at: UITheme >> newTabGroupIn: aThemedMorph for: labelsAndControls On Thu, May 6, 2010 at 1:32 AM, Tudor Girba <tudor.girba(a)gmail.com> wrote: > Hi, > > I would like to change slightly the default Watery2 theme. For starters, I > would like to change the tab widget: > - to make it look like a group box > - use a smaller font > > However, I did not figure out how to do that. Could anyone point me in the > right direction? > > Cheers, > Doru > > -- > www.tudorgirba.com > > "Problem solving efficiency grows with the abstractness level of problem > understanding." > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

May 6, 2010

[Pharo-project] Settings Browser

by Geert Claes

I have to say that the new Settings Browser in 1.1 is a huge improvement over the old Preference Browser. It's just that I can't seem to figure out how to save the settings I have changed? I did noticed the "Style > New/Update/Load/Browse/Remove". I managed to create a new style, but when selecting "Style>Update" I get this tiny window titled "Choose" with a wee white box and a Cancel button? Am I missing something? ps. What is the "Blab email" in the Network section? -- View this message in context: http://forum.world.st/Settings-Browser-tp2132556p2132556.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2010

[Pharo-project] Settings Browser

by Geert Claes

I have to say that the new Settings Browser in 1.1 is a huge improvement over the old Preference Browser. It's just that I can't seem to figure out how to save the settings I have changed? I did noticed the "Style > New/Update/Load/Browse/Remove". I managed to create a new style, but when selecting "Style>Update" I get this tiny window titled "Choose" with a wee white box and a Cancel button? Am I missing something? ps. What is the "Blab email" in the Network section? http://n4.nabble.com/file/n2132539/Settings_Browser.png -- View this message in context: http://forum.world.st/Settings-Browser-tp2132539p2132539.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

May 6, 2010

Re: [Pharo-project] [Vm-dev] About CompactClasses and their future [WAS] how many free bits we have in Object Header?

by Mariano Martinez Peck

On Thu, May 6, 2010 at 12:14 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > For measuring, I wouldn't look at the current process' memory consumption > because the VM has some headroom to not have to allocate new memory too > often. Depending on when memory is grown or shrunken, this may yield very > different results. What I would do is to GC and save the image to disk and > then compare the size of the .image files. I wouldn't run the tests either. > > Thanks. I have just did that. > Making more classes compact, may make sense. But I doubt that you get 3 or > even 5 MB. That sounds way too good ;) > > hahhaa 3mb was too much, maybe 300kb ;) These are the results: Seaside 3.0 one click: original: 21MB compact: 20.2 Pharo 1.0 original: 15MB compacted: 14.6 PharoCore 1.1 original: 13.6 compacted: 13.3 So...those are the results. If you want I can create an issue and commit the script. Cheers Mariano > Cheers, > Adrian > > > On May 6, 2010, at 11:24 , Mariano Martinez Peck wrote: > > > Hi folks. I was just trying to understand this optimization of the > Compact > > Classes. If I understood correctly, most objects needs a second word > there > > they have 30 bits of OOP of their class and 2 for the header type. > > > > There are classes that have a LOT of instances. For those cases we have > > compact classes where their instances have a number using those 5 bits in > > the first word of the header, and thus, they don't need a second header. > > Then, less memory is used. > > > > So...I understood ok ? > > > > Now, if that is the situation. I have evaluated Smalltalk > > compactClassesArray and I see that in the array there are a lot of nils. > 16 > > classes in Squeak and 15 in Pharo. The rest of the 31, are just nil. > > > > Now I wonder if it is worth to do anything with that : > > > > a) Use 4 bits instead of 5 and free one more bit in the OH > > b) remove completely CompactClasses as Adrian said > > c) Let 5 bits but then add more classes (up to 31) so that we can get > > benefits of that. Do you know if there are side effects of > becomingCompact a > > class ? > > > > If I evaluate SpaceTally new printSpaceAnalysis I get something like > this: > > > > Class code space # instances inst space > percent > > ByteString 2217 71317 3621735 > 19.3 > > CompiledMethod 21064 56057 3517772 > 18.7 > > Bitmap 3893 2256 3424604 > 18.2 > > Array 2478 71108 2198420 > 11.7 > > ByteSymbol 959 37896 962465 > 5.1 > > ByteArray 2778 317 778297 > 4.1 > > MethodDictionary 1819 5964 449252 > 2.4 > > MCVersionInfo 1313 10369 414760 > 2.2 > > DateAndTime 6974 13793 331032 > 1.8 > > WeakArray 827 286 326900 > 1.7 > > Association 749 26784 321408 > 1.7 > > UUID 1528 10370 248880 > 1.3 > > Float 11442 16450 197400 > 1.1 > > ClassOrganizer 1398 5964 190848 > 1.0 > > ODatedEntry 263 7049 169176 > 0.9 > > Time 5530 10369 165904 > 0.9 > > Duration 3025 10290 164640 > 0.9 > > Date 3167 10289 164624 > 0.9 > > LargePositiveInteger 2515 14340 118169 > 0.6 > > Metaclass 4250 2876 115040 > 0.6 > > Point 6404 8476 101712 > 0.5 > > GlyphForm 307 2030 73080 > 0.4 > > FreeTypeCacheEntry 536 2238 71616 > 0.4 > > SpaceTallyItem 651 2509 60216 > 0.3 > > OrderedCollection 5351 2831 56620 > 0.3 > > FreeTypeFileInfo 797 321 30816 > 0.2 > > FreeTypeFontFamilyMember 1274 537 25776 > 0.1 > > Color 21202 1255 25100 > 0.1 > > TraitComposition 2651 2013 24156 > 0.1 > > Set 3510 1358 21728 > 0.1 > > Dictionary 5742 1344 21504 > 0.1 > > RemoteString 1533 1236 19776 > 0.1 > > SparseLargeTable 2376 2 18708 > 0.1 > > WordArray 1821 30 18608 > 0.1 > > SoundBuffer 3299 3 18508 > 0.1 > > Pragma 1558 862 17240 > 0.1 > > Preference 1534 379 16676 > 0.1 > > EventHandler 3216 125 14500 > 0.1 > > MorphExtension 3249 277 14404 > 0.1 > > Character 6428 939 11268 > 0.1 > > SortedCollection 1496 462 11088 > 0.1 > > AdditionalMethodState 2576 859 10304 > 0.1 > > ISOLanguageDefinition 18114 402 9648 > 0.1 > > TimeStamp 861 392 9408 > 0.1 > > > > > > So...for this quick evaluation, maybe we can become compact also the > > following classes for example: > > > > Smalltalk compactClassesArray > > > > #( ByteSymbol ByteArray MethodDictionary "Association" "WeakArray" > > "Metaclass" DateAndTime UUID Time Duration Date "MethodDictionary" > > ClassOrganizer Metaclass Pragma OrderedCollection RemoteString WordArray > > Color Character ) > > do: [:each | (Smalltalk at: each) becomeCompact] > > > > Do this make sense ? How could I measure this? I took a Pharo image and > > compare the memory used by the VM running all test before and after those > > new compact classes. From the "Activity monitor" I noticed between 3 and > 5 > > MB less used with these new compact classes. > > > > Thanks in advance > > > > Mariano > > > > > > On Tue, May 4, 2010 at 2:12 PM, Adrian Lienhard <adi(a)netstyle.ch> wrote: > > > >> > >> Hi Mariano, > >> > >> I see two solutions > >> - make the identityHash (even) smaller > >> - remove compact classes > >> > >> The former would probably not be hard to implement (just change some bit > >> masks and then rehash all sets). I've brought up the idea about the > latter > >> some time ago on this mailing list. The idea is to remove compact > classes to > >> get a larger identityHash (trading memory against speed). After the > removal, > >> only two header types are left and hence you gain a spare bit. I think > this > >> shouldn't be too much work either, but I haven't come around to > implementing > >> it (yet). > >> > >> Good luck ;) > >> Adrian > >> > >> On May 4, 2010, at 13:13 , Mariano Martinez Peck wrote: > >> > >>>>> > >>>>> Now...the question is, is there another free bit in the object header > ? > >> I > >>>>> need another one :( > >>>> > >>>> Based on the comment at the bottom of > Interpreter>>internalIsImmutable: > >>>> I suspect that somebody else has their eye on that last available bit > >>>> also ;-) > >>>> > >>>> > >>> Yes, I know :( But for the moment I don't care to "integrate" my > stuff. > >> I > >>> just want to play and experiment. And even for that, I need 2 bits :( > >>> Of course, if I once make something good to integrate, I will have > double > >>> problem :( > >>> > >>> So...no solution ? > >> > >> > >

May 6, 2010

[Pharo-project] another fun case for Linked>>add:

by StÃ©phane Ducasse

LinkedList>>add: aLinkOrObject "Add aLink to the end of the receiver's list. Answer aLink." ^self addLast: aLinkOrObject LinkedList>>addLast: aLinkOrObject "Add aLink to the end of the receiver's list. Answer aLink." |aLink| aLink := aLinkOrObject asLink. self isEmpty ifTrue: [firstLink := aLink] ifFalse: [lastLink nextLink: aLink]. lastLink := aLink. ^aLink Object>>asLink "Answer a string that represents the receiver." ^ ValueLink value: self In squeak there is no such asLink.... We need a database with all the history to know which change introduced this change. Henrik do you remember why you introduce this change? Stef

May 6, 2010