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

Re: [Pharo-project] Little change for Objects As Methods

by StÃ©phane Ducasse

Hi mariano I do not really like your solution. Implementing flushCache is not that bad in your class. It is not a bad compromise. May be it should be better documented. Stef > When you are using Objects as methods, MethodWrappers, or whatever with run:with:in, you have to implement not only that method, but also flushCache doing nothing because it is used in: > > MethodDictionary >> at: put: > > at: key put: value > "Set the value at key to be value." > | index | > index := self findElementOrNil: key. > (self basicAt: index) == nil > ifTrue: > [tally := tally + 1. > self basicAt: index put: key] > ifFalse: > [(array at: index) flushCache]. > array at: index put: value. > self fullCheck. > ^ value > > > Ok, I can implement that in my classes, and in MethodWrappers, but I think it would be nicer and cleanly if you only have to implement run:with:in: since flushChache doesn't make sense for normal objects. > > So, I would like to change that code to > > at: key put: value > "Set the value at key to be value." > | index | > index := self findElementOrNil: key. > (self basicAt: index) == nil > ifTrue: > [tally := tally + 1. > self basicAt: index put: key] > ifFalse: > [(array at: index) isCompiledMethod ifTrue: [flushCache]]. > array at: index put: value. > self fullCheck. > ^ value > > > Yes, yes, I know the if is ugly, but it gives us a cleaner way to define objects as methods. > The other option is to implement flushCache in Object doing nothing but I like it less than this. > > opinions? > > thanks > > mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 19, 2010

[Pharo-project] Best way for embed a file on Smalltalk image method

by nullPointer

Hi IÂ´m doing a class for embed files in class methods. I want know if exists a best way for do that task than IÂ´m using... I do something like that... codeSource := CLStringBuilder new. codeSource appendLine: nameOfResource; tab; appendFormat: '^''{1}'' -> ''' withValues: {fileName}. readStream := FileStream readOnlyFileNamed: aFilePath. base64Contents := (Base64MimeConverter mimeEncode: readStream binary) contents. codeSource append: base64Contents asString. codeSource append:''''. CLSystem createMessageInClass: self withCodeSource: (codeSource asString) inProtocol: 'resources' inClassSide: true. I get the next result: courierNewBoldttf ^'Courier New Bold.ttf' -> 'AAEAAAATAQAABAAwRFNJR0rTjTkACiUQAAAbgEdERUYTqQ1VAApAkAAAAkxHUE9T3wr9iAAK QtwAADeeR1NVQgwWqYIACnp8AAAT1k9TLzIQrF1xAAABuAAAAGBWRE1YNVhPeQAAGrwAABGU Y21hcHepKTsAACxQAAAhqmN2dCCka4hDAABqbAAACA5mcGdtUXaa9wAATfwAAAdZZ2FzcAAW AAkACiUAAAAAEGdseWbVwXRoAACjvAAI9Z5oZWFk05ZxuQAAATwAAAA2aGhlYQrAAZoAAAF0 .......... '. Exists a enhanced way for do that? My main problem is the image grow very much. When I export to Monticello I get a file of 900 KB. When embed a file of 600KB the final size on Monticello file is 2MB!! and almost 4MB of difference in size of image :( Many thanks for the help -- View this message in context: http://forum.world.st/Best-way-for-embed-a-file-on-Smalltalk-image-method-t… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 19, 2010

[Pharo-project] Little change for Objects As Methods

by Mariano Martinez Peck

When you are using Objects as methods, MethodWrappers, or whatever with run:with:in, you have to implement not only that method, but also flushCache doing nothing because it is used in: MethodDictionary >> at: put: at: key put: value "Set the value at key to be value." | index | index := self findElementOrNil: key. (self basicAt: index) == nil ifTrue: [tally := tally + 1. self basicAt: index put: key] ifFalse: [(array at: index) flushCache]. array at: index put: value. self fullCheck. ^ value Ok, I can implement that in my classes, and in MethodWrappers, but I think it would be nicer and cleanly if you only have to implement run:with:in: since flushChache doesn't make sense for normal objects. So, I would like to change that code to at: key put: value "Set the value at key to be value." | index | index := self findElementOrNil: key. (self basicAt: index) == nil ifTrue: [tally := tally + 1. self basicAt: index put: key] ifFalse: [(array at: index) isCompiledMethod ifTrue: [flushCache]]. array at: index put: value. self fullCheck. ^ value Yes, yes, I know the if is ugly, but it gives us a cleaner way to define objects as methods. The other option is to implement flushCache in Object doing nothing but I like it less than this. opinions? thanks mariano

Oct. 19, 2010

[Pharo-project] Pharo full name screen ...

by Geert Claes

I noticed the screen where the user is asked for their full name (see attached) has a few usability issues: The window title "Information Required" is probably not descriptive enough. The user name is also specified in the Settings browser as the "Author identification" in the "Code browsing > Editing" section, so there should be some sort of consistency. Should it actually be possible to save a name using characters which are to be avoided as people tend to not read text? Should these characters really be avoided and if so why? How about asking for the author's full name and when typing the full name, unwanted characters will be stripped from the user name? http://forum.world.st/file/n3001669/startGSPharo3.png -- View this message in context: http://forum.world.st/Pharo-full-name-screen-tp3001669p3001669.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Oct. 19, 2010

Re: [Pharo-project] call for scripting idea

by Lukas Renggli

On 19 October 2010 09:10, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > why not :) > could you send them to the list so that we can see them? http://github.com/renggli/builder Lukas -- Lukas Renggli www.lukas-renggli.ch

Oct. 19, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

On 19.10.2010 09:17, StÃ©phane Ducasse wrote: > How can we make progress on this issue? > > Stef As far as I can tell (again, I haven't actually experienced this slowdown), any of: - Port Levente's WeakKeyDictionary, which is much faster. - Wait for new VM's supporting Igors finalization scheme, which should be much faster (haven't tested it personally) - Rewrite the MC package caching to not use weak collections/ be smarter about what it keeps. Cheers, Henry

Oct. 19, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by Henrik Sperre Johansen

On 19.10.2010 09:14, StÃ©phane Ducasse wrote: > On Oct 18, 2010, at 10:19 PM, Nicolas Cellier wrote: > >> 2010/10/17 Levente Uzonyi<leves(a)elte.hu>: >>> On Sat, 16 Oct 2010, Bart Veenstra wrote: >>> >>>> Hi list, >>>> >>>> I have been working with Pharo for almost a month now, and I suspect >>>> that the performance is degrading fast. UI tasks takes several seconds >>>> to react to my keyboard. >>> That kind of sluggishness is probably related to finalization/gc. Please >>> send us the result of the following expression: >>> >>> (WeakArray classPool at: #FinalizationDependents) >>> select: [ :each | each notNil ] >>> thenCollect: [ :each | each class -> each size ] >>> >> While updating pharo 1.2, after an EndOfCentralDirectory error, I got >> a very unresponsive image... > can you reproduce it? > Which image ? > Which vm ? > Never heard about this error before If he means "Error: can't find EOCD position", that happens when squeaksource is down while you try updating. (If you inspect the zip stream it's trying to read, you'll see the request returned an html page containing the string: " SqueakSource is currently down. We are sorry for the inconvenience and working on the problem. In the meantime you can still commit to a directory repository on your disk and later copy the versions to SqueakSource." rather than the actual zip) I got it too when updating yesterday, my resulting image wasn't very unresponsive though. Cheers, Henry

Oct. 19, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by StÃ©phane Ducasse

How can we make progress on this issue? Stef

Oct. 19, 2010

Re: [Pharo-project] Speeding up Pharo 1.1

by StÃ©phane Ducasse

On Oct 18, 2010, at 10:19 PM, Nicolas Cellier wrote: > 2010/10/17 Levente Uzonyi <leves(a)elte.hu>: >> On Sat, 16 Oct 2010, Bart Veenstra wrote: >> >>> Hi list, >>> >>> I have been working with Pharo for almost a month now, and I suspect >>> that the performance is degrading fast. UI tasks takes several seconds >>> to react to my keyboard. >> >> That kind of sluggishness is probably related to finalization/gc. Please >> send us the result of the following expression: >> >> (WeakArray classPool at: #FinalizationDependents) >> select: [ :each | each notNil ] >> thenCollect: [ :each | each class -> each size ] >> > > While updating pharo 1.2, after an EndOfCentralDirectory error, I got > a very unresponsive image... can you reproduce it? Which image ? Which vm ? Never heard about this error before > ((WeakArray classPool at: #FinalizationDependents) as: Array) > select: [ :each | each notNil ] > thenCollect: [ :each | each class -> each size] > -> > {(WeakIdentityKeyDictionary->22370). (WeakRegistry->0). > (WeakRegistry->0). (WeakRegistry->0). (WeakRegistry->2)} > > I tried to inspect it 5 minutes ago, but hey, answer in another email... > Ah, OK, cmd+shift+. just worked. I had to interrupt > #finalizationProcess itself finally... > Oh inspect is sorting the keys... unusable. > So what's in the array ? Things like > > (ScriptLoader>>#update12125 "a CompiledMethod(0)")->a > MCMethodDefinition(ScriptLoader>>update12125) > (PragmaCollector>>#release "a CompiledMethod(964689920)")->a > MCMethodDefinition(PragmaCollector>>release) > (Float>>#arcSin "a CompiledMethod(358088704)")->a > MCMethodDefinition(Float>>arcSin) > > I don't understand yet, but I begin to gather clues why updating pharo > goes so badly... Thanks. Any progress in that direction is welcome. May be this is related to change proposed by igor on weak finalization explicit call in MC that may not be fully integrated. Stef

Oct. 19, 2010

Re: [Pharo-project] Some questions about pharo

by StÃ©phane Ducasse

This is neat. Thanks for the information. Stef On Oct 18, 2010, at 10:41 PM, Alexander LazareviÄ wrote: > 2010/10/18 Adrien BARREAU <abarreau.dev(a)live.fr>: >> - If I run a headless Pharo, is it possible to display the graphical >> interface after? (for example, if something raises an exception, I want to >> open the GUI and use the debugger) > > It depends. If your headless Pharo image is running on a unix VM you > could utilize the genius OSProcess/XDisplayControl plugin available > for this VM. Load the appropriate packages from [1] into your Pharo > image and then you can close and reopen the window even on another > machine if it's running X11. For example this > > OSProcess thisOSProcess closeXDisplay. > (Delay forSeconds: 5) wait. > OSProcess thisOSProcess displayOnXServer: ':0.0'. > > will close the Window (headless) and reopen it (headful) again on the > local X server after five seconds. > If you're using Seaside in that image you could trigger window > open/close via Seaside or you could change the default handler for > errors to make the window open on the local display as a default, ... > > Alex > > [1] http://www.squeaksource.com/OSProcess > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Oct. 19, 2010