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

Re: [Pharo-project] Resize pharo window

by Denis Kudriashov

DisplayScreen depth: depthInteger width: widthInteger height: heightInteger fullscreen: aBoolean 2010/10/19 Adrien BARREAU <abarreau.dev(a)live.fr> > Hello, > > I try to understand how I can change the size of the Pharo window. > > I tried this: Display setExtent: 1000@700 depth: 32; beDisplay. > > That seems to work ... but only a few milliseconds. After this delay, the > window returns back to its previous size. > > Any suggestions? :) > > Adrien. > > _______________________________________________ > 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] pharo in a sport journal :)

by StÃ©phane Ducasse

fun Pharo got mentioned in l'equipe (THE french journal sport) because our sprinter is following lecture on oop :) Stef Begin forwarded message: > From: Damien Cassou <damien.cassou(a)gmail.com> > Date: October 19, 2010 6:35:17 PM GMT+02:00 > To: smalltalk-fr <smalltalk-fr(a)googlegroups.com> > Subject: Smalltalk et Pharo dans l'Ã©quipe d'aujourd'hui > Reply-To: smalltalk-fr(a)googlegroups.com > > Je n'y aurai pas cru si je ne l'avais vu de mes propres yeux. Le > journal l'Ãquipe parle de Smalltalk et Pharo dans ses colonnes : > > http://s3.e-monsite.com/2010/10/16/2480556article-jpg.jpg > > Quelqu'un connaÃ®t l'enseignant en question (Chritian Martel) ? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry

Oct. 19, 2010

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

by Eliot Miranda

Use method tags. See e.g. Travis Griggs' assets framework. You could use something like courierNewBoldttf <fontName: 'Courier New Bold.ttf' encoding: 'gzip' data: 'AAEAAAATAQAABAAwRFNJR0rTjTkACiUQAAAbgEdERUYTqQ1VAApAkAAAAkxHUE9T3wr9iAAK QtwAADeeR1NVQgwWqYIACnp8AAAT1k9TLzIQrF1xAAABuAAAAGBWRE1YNVhPeQAAGrwAABGU Y21hcHepKTsAACxQAAAhqmN2dCCka4hDAABqbAAACA5mcGdtUXaa9wAATfwAAAdZZ2FzcAAW AAkACiUAAAAAEGdseWbVwXRoAACjvAAI9Z5oZWFk05ZxuQAAATwAAAA2aGhlYQrAAZoAAAF0 .......... '. and extracting the data is easy. On Tue, Oct 19, 2010 at 4:06 AM, nullPointer <epicfan(a)gmail.com> wrote: > > 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. > > _______________________________________________ > 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] Comment in Behavior >> allMethods is wrong ?

by Mariano Martinez Peck

It says: Behavior >> allMethods "Return the collection of compiled method I am defining" "asArray is used to not bump into a bug when comparing compiled methods." ^ self allSelectors asArray collect: [ :s | self lookupSelector: s ] However...it answer not only the ones defined by itself, but also from superclasses. So...the comment is confusing for me. I am the only one ? cheers mariano

Oct. 19, 2010

[Pharo-project] Resize pharo window

by Adrien BARREAU

Hello, I try to understand how I can change the size of the Pharo window. I tried this: Display setExtent: 1000@700 depth: 32; beDisplay. That seems to work ... but only a few milliseconds. After this delay, the window returns back to its previous size. Any suggestions? :) Adrien.

Oct. 19, 2010

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

by Alain Plantec

I Geert, in addition there is a bug when you enter a empty name from the setting. I will fix that issue (http://code.google.com/p/pharo/issues/detail?id=3128) Thanks for reporting Alain Le 19/10/2010 10:34, Geert Claes a Ã©crit : > 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. ok > 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 > >

Oct. 19, 2010

[Pharo-project] "ProfStef" vs "Pharo Tutorial"

by Alexandre Bergel

Hi! Some student asked me for a tutorial about Pharo, I guess they haven't seen ProfStef. Maybe Having "Pharo Tutorial" in the Help menu would be more explicit. Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Oct. 19, 2010

[Pharo-project] [ANN 1.2] pre-built 1.2Core#12199

by Marcus Denker

https://gforge.inria.fr/frs/download.php/27659/PharoCore-1.2-12199.zip -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Oct. 19, 2010

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by Guillermo Polito

On Tue, Oct 19, 2010 at 8:19 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr > wrote: > >> > >> > > > > Maybe Pharo runs some hidden AI process, which refactors and changes > > things under the hood? :) > > If we could educate it to autofix it this would be a clear win-win > situation :) > > Seriously guillermo how this code arrived in since it is not in CUIS? > I've no idea, hehe. I don't know when this change was introduced. I have a 1.2 Core version #12121 which already has this piece of code. But it's previous the SmalltalkEditor integration. I vote to remove that ugly autocompletion :). > Stef > _______________________________________________ > 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] [update 1.2] #12199

by StÃ©phane Ducasse

12199 ----- - Issue 3048: MC method cache fix. Thanks Igor Stasenko

Oct. 19, 2010

[Pharo-project] [update 1.2] #12198

by StÃ©phane Ducasse

12198 ----- initialize LongTestCase correctly

Oct. 19, 2010

[Pharo-project] [update 1.2] #12197

by StÃ©phane Ducasse

12197 ----- - Issue 3127: Missing Close in About Dialog. Thanks Alain Plantec. - Issue 3125: SharedQueue/Monitor cleans. Thanks levente. :)

Oct. 19, 2010

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

by Mariano Martinez Peck

On Tue, Oct 19, 2010 at 1:25 PM, Fernando olivero <fernando.olivero(a)usi.ch>wrote: > Just by curiosity, why does MethodDictionary>>at:put: has to send > #flushCache at all? > I am not sure, but I guess that cleaning. The method comment of CompiledMethod >> flushChache says: "Tell the interpreter to remove all references to this method from its method lookup cache, if it has one. This primitive must be called whenever a method is defined or removed" So...when you do a aClass methodDict at: #xxx put: aNewCompiledMethod nobody else "would" (Sometimes I think there are MCMethodDefinition instances pointing to methods that were even replaced by another ones) point to the original compiled method, at least no here. Thus....the vm cleans the cache for the method lookup. cheers mariano > > Fernando > > On Oct 19, 2010, at 1:14 PM, StÃ©phane Ducasse wrote: > > > 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 > > > > > > _______________________________________________ > > 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 >

Oct. 19, 2010

[Pharo-project] Fwd: [squeak-dev] SqueakSource are down

by StÃ©phane Ducasse

> > > > > On Oct 19, 2010, at 12:50 AM, Igor Stasenko wrote: > >> Hello, >> >> :( >> >> Guys, are there a reason , why we can't address this problem once and for all? > > time and money - ESUG is planning to support a rewrite of squeaksource. > I imagine. > INRIA told me that they will set up and maintain a webdav server that we could use for squeak and pharo. > Now we will not have the nice features of squeaksource. > I'm just waiting for it. > > Stef > > >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > >

Oct. 19, 2010

Re: [Pharo-project] [squeak-dev] SharedQueue does scale (was: Re: SharedQueue doesn't scale)

by StÃ©phane Ducasse

On Oct 18, 2010, at 10:03 PM, Levente Uzonyi wrote: > On Mon, 18 Oct 2010, StÃ©phane Ducasse wrote: > >>> >>> This benchmark is the real concurrent stress test. 100 processes are adding 10,000 elements to the queue while another 100 are reading from it. It clearly shows that Igor's queues are an order of magnitude faster. Also 200 concurrent processes cause much less slowdown compared to the sequential tests for them. >>> >>> So, even though SharedQueue is now faster than SharedQueue2, both will have to go IMHO. :) >> >> Hi Levente >> >> Naively why? > > Did you see the benchmarks? > >> and replace by what? > > By Igor's new collections. Though the name should be kept for compatibility reasons. Ok I was confused... too many emails and threads. So yes! Stef

Oct. 19, 2010

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

by Fernando olivero

Just by curiosity, why does MethodDictionary>>at:put: has to send #flushCache at all? Fernando On Oct 19, 2010, at 1:14 PM, StÃ©phane Ducasse wrote: > 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 > > > _______________________________________________ > 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

Re: [Pharo-project] Speeding up Pharo 1.1

by StÃ©phane Ducasse

Thanks I added that to our agenda! December and january will be busy. We will have fun! Stef On Oct 19, 2010, at 9:24 AM, Henrik Sperre Johansen wrote: > 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 > > _______________________________________________ > 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

Re: [Pharo-project] Stack should be reimplemented with Array

by StÃ©phane Ducasse

On Oct 19, 2010, at 1:23 AM, Igor Stasenko wrote: > On 19 October 2010 00:25, Levente Uzonyi <leves(a)elte.hu> wrote: >> On Mon, 18 Oct 2010, Igor Stasenko wrote: >> >>> Stephane, i could say more: >>> - i don't like how LinkedList implemented. >>> >>> I don't see why it should mimic things like #at: #at:put: at all.. >> >> It's not mimicing those methods. A list usually support things like this, >> but the user should know the consequences. >> > > The consequences of such approach is much more far-reaching: leads to > bad design practices, crappy application performance, > and then tons of bugs and workarounds. > >>> IMO this protocol should be pruned from it, to not provoke uses which >>> completely do not fit for given data structure. >> >> I'm not sure if it's okay to remove features, because users lacking really >> basic CS knowledge may use them the wrong way. >> > > Imo, we should prohibit this from the beginning. Standard, core > classes should not contain an API, which could lead to > careless, abusive programming techniques. Yes and we should have comments comments comments and comments. > IMO, a kernel APIs should serve not only as an implementation of basic > system funcionality, it also must serve as guide, > how to best use these facilities, so people will learn what is the > right way to use it. > > We should teach users to use right tools for things they need. > > >>> >>> Removing/inserting into the middle of list is quite ineffective >>> operation (O(n)), >> >> As long as you don't give away the link objects, it's O(n), otherwise it can >> be O(1). > > giving away link objects... oh, that's the worst thing, which could > possibly happen :) > >> >>> while inserting at the begginning/end of list is O(1). >>> >>> Lists are sequenceable.. but sequenceable ~~ indexable. Period. >> >> Sequenceable is indexable, but good performance is not guaranteed. >> > Unless you representing an infinite collection(s). > Streams are good example of sequenceable, however non-indexable containers. > > >> >> Levente >> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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

Re: [Pharo-project] Stack should be reimplemented with Array

by StÃ©phane Ducasse

one point at a time :) I'm talking about stack :) On Oct 18, 2010, at 10:49 PM, Igor Stasenko wrote: > Stephane, i could say more: > - i don't like how LinkedList implemented. > > I don't see why it should mimic things like #at: #at:put: at all.. > IMO this protocol should be pruned from it, to not provoke uses which > completely do not fit for given data structure. > > Removing/inserting into the middle of list is quite ineffective > operation (O(n)), > while inserting at the begginning/end of list is O(1). > > Lists are sequenceable.. but sequenceable ~~ indexable. Period. > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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

Re: [Pharo-project] bad bracket autocompletion in Pharo Core 1.2

by StÃ©phane Ducasse

>> >> > > Maybe Pharo runs some hidden AI process, which refactors and changes > things under the hood? :) If we could educate it to autofix it this would be a clear win-win situation :) Seriously guillermo how this code arrived in since it is not in CUIS? Stef

Oct. 19, 2010

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