- Pharo-dev - lists.pharo.org

[Pharo-project] [COTDC] 97 - CRCError

by sean＠clipperadams.com

96 classes done 799 classes remaining Continuing in Compression... Today: CRCError Comment Of The Day Contest - One Day One Comment Rules: #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). #2: If you cannot comment it, deprecate it. Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest p.s. this message was sent from a pharo image. Did you know you could easily do that?!

Dec. 14, 2011

[Pharo-project] [update 1.4] #14258

by StÃ©phane Ducasse

14258 ----- - Issue 5101: better, cleaner, more tests for SharedPool http://code.google.com/p/pharo/issues/detail?id=5101 less pop up from script loaderâ¦. what a relief. Not as good as I wantâ¦.getting there. Stef

Dec. 14, 2011

[Pharo-project] where we see that SharedPool management is still draft

by StÃ©phane Ducasse

Hi guys While I prefer sharedPool over pool dictionary and I like what andreas did back then. there are still places for improvements. If you file out a category with a pool and a class using it. If the pool is not created first, then the system automatically add a 'private' (pool named 'private') to the class the problem is that such pool is an empty dictionary and not a shared pool Gorgeous :) We will get there when we will start to surround the classBuilder and rewrite it from scratch. Stef

Dec. 14, 2011

[Pharo-project] [update 1.4] #14257

by StÃ©phane Ducasse

14257 ----- - Issue 5095: Monticello snapshotting does lots of unnecessary screen updates. Thanks Lukas and Stef :) http://code.google.com/p/pharo/issues/detail?id=5095 - Issue 5083: remove unused methods from SmartRefStream. Thanks Marcus Denker. http://code.google.com/p/pharo/issues/detail?id=5083

Dec. 14, 2011

Re: [Pharo-project] Better Gofer error messages

by StÃ©phane Ducasse

open a bug entry and we will fix that :) You could even provide the code and it will be faster > >>> Please please, let someone improve Gofer error messages, which are now >>> totally non-understandable. Check in advance if some package is there >>> and say "No package with that name", or even better, "no package with >>> expected name: Blabla6.xxx" or something. > >> can you point which messages are a problem > > Say you evaluate this script: > > Gofer new > squeaksource: 'Fuel'; > package: 'ConfigurationOFuel'; > load. > (Smalltalk at: #ConfigurationOfFuel) load. > > Did you notice a typo in script? Hardly. Now see what exception look like: > > Error: Unable to resolve ConfigurationOFuel > > GoferPackageReference(Object)>>error: > GoferPackageReference(GoferReference)>>resolveWith: > [:each | each resolveWith: self] in Gofer>>resolved > Array(SequenceableCollection)>>collect: > Gofer>>resolved > ... > > My thinking: What is it unable to resolve, what is to be resolved > anyway? But if error will be something like: > > "Unable to find or resolve package ConfigurationOFuel, check > the name. See Gofer class comment for more" > > It will certainly lead me to check for the typo first and only if > failed, go to class comment and find a wiki page. > >>> What it is now is unusable, sorry. To prepare a right script is a big >>> pain. Specially because there are nowhere rules how packages are >>> resolved by a name. It will help if in exception at least a link to the >>> some wiki with rules would be shown. > >> why don't you use metacello? >> there 45 pages documentation on it > > Gofer is needed for Metacello too and yes, Metacello has similar > problems with not very helpful error messages. > > See how Fuel guys improve error reporting in recent Fuel, after having > the same cryptic messages before. > > Best regards > Janko > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Dec. 14, 2011

Re: [Pharo-project] GUI Testing Library

by Sean P. DeNigris

Tudor Girba-2 wrote > > I think the best would be to add it externally from a configuration. So, I > created one: > Thanks! Of course if it's external no one will use it to test the image itself :( p.s. I added middle click and tests for all click types -- View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4196899.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2011

Re: [Pharo-project] 1.3, PBE and lab setups

by StÃ©phane Ducasse

Hi dave > I am trying to get our local admins to set up labs so students can use the latest Pharo. > > Currently we have 1.2 and PBE .image files and by removing the field in the INI file that specified the image, if you clicked on Pharo, you'd get a dialogue asking which image you wanted. All of these are on read-only mounts, so if you want to save to the image, you need to copy the image to your home directory and then you could navigate to that image file on startup. Dropping an image on the executable works fine, though. > > Additionally, the PBE book doesn't play well with 1.3 (things that the book says die when you try them). Apparently you can't open the PBE image from the 1.3 binary without it crashing, either. > > So I have 3 questions: > > 1) is 1.3 the system to use, or will 1.4 be stable soon? use 1.3 :) > 2) is the PBE book getting updated to work with a vanilla 1.3/1.4 image? No if nobody does it. We are focusing on PBE2 > 3) what is the timeline on these, as our semester starts Jan 10. :) I would love to see the exercises that you will ask them. > > Thanks ../Dave >

Dec. 14, 2011

Re: [Pharo-project] Better Gofer error messages

by Janko MivÅ¡ek

S, StÃ©phane Ducasse piÅ¡e: > On Dec 14, 2011, at 5:35 PM, Janko MivÅ¡ek wrote: >> Please please, let someone improve Gofer error messages, which are now >> totally non-understandable. Check in advance if some package is there >> and say "No package with that name", or even better, "no package with >> expected name: Blabla6.xxx" or something. > can you point which messages are a problem Say you evaluate this script: Gofer new squeaksource: 'Fuel'; package: 'ConfigurationOFuel'; load. (Smalltalk at: #ConfigurationOfFuel) load. Did you notice a typo in script? Hardly. Now see what exception look like: Error: Unable to resolve ConfigurationOFuel GoferPackageReference(Object)>>error: GoferPackageReference(GoferReference)>>resolveWith: [:each | each resolveWith: self] in Gofer>>resolved Array(SequenceableCollection)>>collect: Gofer>>resolved ... My thinking: What is it unable to resolve, what is to be resolved anyway? But if error will be something like: "Unable to find or resolve package ConfigurationOFuel, check the name. See Gofer class comment for more" It will certainly lead me to check for the typo first and only if failed, go to class comment and find a wiki page. >> What it is now is unusable, sorry. To prepare a right script is a big >> pain. Specially because there are nowhere rules how packages are >> resolved by a name. It will help if in exception at least a link to the >> some wiki with rules would be shown. > why don't you use metacello? > there 45 pages documentation on it Gofer is needed for Metacello too and yes, Metacello has similar problems with not very helpful error messages. See how Fuel guys improve error reporting in recent Fuel, after having the same cryptic messages before. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 14, 2011

Re: [Pharo-project] Better Gofer error messages

by Janko MivÅ¡ek

S, Lukas Renggli piÅ¡e: >> What it is now is unusable, sorry. To prepare a right script is a big >> pain. Specially because there are nowhere rules how packages are >> resolved by a name. It will help if in exception at least a link to the >> some wiki with rules would be shown. > > I assume you didn't even bother to check the class comment of Gofer, > because if you did you would have found a verbatim copy of the wiki > article. Sure I didn't and hardly anyone will come to this idea when seeing this cryptic error. Of course if error message would lead me to class comment, things would be different. This error is frequent, so error message should be more descriptive, this is my point. Best regards Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 14, 2011

Re: [Pharo-project] How turn on Halo's?

by Sean P. DeNigris

Sean P. DeNigris wrote > > Does anyone know where the functionality lived? > Found it! Add the so-commented two lines below to restore two-way halo cycling. Am I the only one who misses this or should I add a setting? Morph>>handlerForBlueButtonDown: anEvent "Return the (prospective) handler for a mouse down event. The handler is temporarily installed and can be used for morphs further down the hierarchy to negotiate whether the inner or the outer morph should finally handle the event. Note: Halos handle blue button events themselves so we will only be asked if there is currently no halo on top of us." self wantsHaloFromClick ifFalse:[^nil]. "Add next two lines to restore two-way halo cycling" anEvent handler ifNil:[^self]. (anEvent handler isKindOf: PasteUpMorph) ifTrue:[^self]. (anEvent shiftPressed) ifFalse:[^nil] "let outer guy have it" ifTrue:[^self] "let me have it" -- View this message in context: http://forum.world.st/How-turn-on-Halo-s-tp2227309p4196786.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Dec. 14, 2011