July 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] SUnit assert:equals:
by Oscar Nierstrasz July 8, 2009

July 8, 2009

Hi Folks, I seem to recall that we added TestCase>>assert:eauals: to SUnit, but now I cannot find it. It would be really useful to get decent error messages from equality tests (instead of "test failed", we would get "expected X but got Y"). Does anyone know what the story is? If it exists somewhere, I would like to add it to Pharo. If it doesn't exist anywhere, I would like to add it to Pharo. - on

3 10

Re: [Pharo-project] FFI problem
by Mariano Martinez Peck July 8, 2009

July 8, 2009

On Tue, Jul 7, 2009 at 10:04 PM, Andreas Raab <andreas.raab(a)gmx.de> wrote: > Mariano Martinez Peck wrote: > >> Andreas: can you see new comments here: >> http://code.google.com/p/pharo/issues/detail?id=908 >> >> What do you think? >> > > Close, but not quite right ;-) The problem with your theory is that > Smalltalk recreateSpecialObjectsArray is specifically called from a > postscript in FFI-Kernel so there shouldn't be a problem with it. > > Unless of course there is something wrong with Monticello in Pharo ... let > me see. Yup. Looks like that's it. I just added a halt to > recreateSpecialObjectsArray then used ScriptLoader loadFFI and it's just not > being called. > > It would be interesting to see if the postscript is executed when you load > the FFI on your Unix machine (the one where you said it didn't crash). Thanks Andreas. I tried in Linux and recreateSpecialObjectsArray is not called when evaluating ScriptLoader loadFFI. I attach 3 files: - FFIFirstTime.png The results of FFI tests after evaluating ScriptLoader loadFFI - FFISecondTime.png The results of executing again FFI tests - FFIAfterRecreate: The results of executing the test after evaluating recreateSpecialObjectsArray (manually). Any idea? Cheers, Mariano > > > In any case, looks like I was right and it isn't an FFI problem but rather > a problem with Monticello. The workaround with the explicit > recreateSpecialObjectsArray will work but of course any other packages that > use postscripts will likely have similar issues. > > Cheers, > - Andreas >

1 0

[Pharo-project] Clipboard startUp
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

Hi torsten you posted the following and I wanted to know whether we should not add something in the shutdown list. Stef initialize "SystemDictionary initialize" | oldList | oldList := StartUpList. StartUpList := OrderedCollection new. "These get processed from the top down..." #( Delay DisplayScreen Cursor InputEventFetcher ProcessorScheduler "Starts low space watcher and bkground." LanguageEnvironment FileDirectory "Enables file stack dump and opens sources." NaturalLanguageTranslator ShortIntegerArray ShortRunArray CrLfFileStream Clipboard ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: cls]. ]. oldList ifNotNil: [oldList do: [:className | Smalltalk at: className ifPresent: [:theClass | Smalltalk addToStartUpList: theClass]]]. #( ImageSegment PasteUpMorph "ControlManager" ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToStartUpList: cls]. ]. oldList := ShutDownList. ShutDownList := OrderedCollection new. "These get processed from the bottom up..." #( Delay DisplayScreen InputEventFetcher Form "ControlManager" PasteUpMorph StrikeFont Color FileDirectory SoundPlayer HttpUrl Password PWS MailDB ImageSegment ) do:[:clsName| Smalltalk at: clsName ifPresent:[:cls| Smalltalk addToShutDownList: cls]. ]. oldList ifNotNil: [oldList reverseDo: [:className | Smalltalk at: className ifPresent: [:theClass | Smalltalk addToShutDownList: theClass]]].

3 2

[Pharo-project] [ANN] 10372 and 10373
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

10372 ScriptLoader loadFFI should work please check better comment on ScriptLoader http://code.google.com/p/pharo/issues/detail?id=637 cleans out Undeclared 10373 Issue 943: fix polymorph cursor Polymorph Fix for colouring of submenu markers. W2K Improvements. Fix for drop-list button label in W2K theme. Support for adjustment of label inset for buttons when pressed. Added #setColor: to ColorPresenterMorph to enable use without a model. Quit gets back its normal behavior Issue 944: SUnit assert:equals SUnit assert equals + better feedback message Strange the cursor for submenu does not work... Next probably MouseOverHandler refactoring.... Stef

1 0

[Pharo-project] Just a little point
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

Hi guys After all the mails in Squeak-dev and all these nice words or explicit suggestions about us been assholes, destructors... whatever :) I would like to share with you my mindset to you. We do not want a war, nor world domination. :) We are doing pharo because Smalltalk deserves a good and beautiful opensource implementation. Our goal is not to kill Squeak. Our goal is to provide a vehicule on top of which people can invent their future been it - multimedia - seaside - kids - research We need a place to expand beauty. We want that students can get enthusiast about Smalltalk and not turned down by some ugly code. We want an agile system with lot of tests, comments, clean code, driven bit a lot of good software engineering practices. I really thank the people that trust us. Stef PS: I'm one the guy that wrote 3 squeak book, 1 seaside book (coming soon), translated etoys in french, so I'm laughing when people suggest that we are predators.

6 14

Re: [Pharo-project] [squeak-dev] Re: Just a little point
by Janko MivÅ¡ek July 7, 2009

July 7, 2009

Sorry Keith, but I must say this: The obvious reason Pharoers reject your contributions are not contributions as such but your attitude as the contributor. And I'd do the same, reject them, because they are dangerous. Because they bring you and your attitude with them. Please think that way a bit. For the sake of Squeak community and our progress. And for the sake of your work at the end. Changing your attitude will change the acceptance of your work too, be sure! Best regards Janko Keith Hodges pravi: >> If find it weird that 2 Smalltalk implementations/communities, so >> close to each other like Squeak and Pharo, go to great lengths at >> flaming each other... > > No they don't, it's just me. > > Please don't tar the mostly polite squeak-dev with my brush. > > I spent a lot of time working on stuff that pharo could use, > particularly because a lot of it was Stephane's idea in the first place, > going back to August 2006. > > My two main points of contention are Monticello and SUnit but as you can > see there are others. > > Monticello: I put a LOT, read LOTS of effort into joining the 3+ > Monticello forks into one, and assuring that it loads in to all forks of > squeak, as a strategic approach for the whole community to have common > tools everywhere. > Pharo has made that effort a waste of time, simply because they wont use > or contribute to the merged uber-Monticello. > > SUnit: I put a second lot of effort into improving SUnit so that it > could support multiple forks of squeak simultaneously. I also wrote a > non Gui test runner for automated testing. SUnit is a public resource > and is maintained in a public repository. Pharo have needlessly forked > SUnit. > > Several things that wind me up, one is wasted effort, and another is > duplicated effort, and the third is making plans to duplicate effort on > purpose. >> that will only leave us isolated, both in our own camps ? I'm >> puzzled! What do I do if I like both? Choose my camp or abandon them >> both ? > If you like both, then please encourage them to make parts that could be > common common. For example I maintain ProcessSpecific for Logging, Pharo > has integrated ProcessSpecific but has made no attempt to pick or offer > feedback to version that was maintained. This is one of numerous example > of subsystems that could easily be mutually maintained. > > There are many initiatives in the pharo camp, that could be developed > and deployed into both camps. I spent all that time on Monticello in > order to ensure that this could happen, but pharo only develops > initiatives for itself, therefore Pharo is effectively planning for > duplicated effort. > > One more example, Pharo could come up with an initiative to fix the > sources/changes file mess. This would be very benefitcial to me. However > its no good if I cant load it into squeak where a lot of my code runs. > So at some point someone would have to duplicate the effort for Squeak. > All it would take is a little thought and planning. > > When I took the initiative to write Rio as a replacement for > FileDirectory, I did it in such a way as anyone could benefit. > When I took the initiative to write Logging as a potential core feature > for Kernel/Server images I did it so that anyone could benefit. > When I wrote the TestReporter as a text based tool for testing I did it > so that anyone could benefit. > When I wrote Bob for automated image building and testing I have done it > so that it can build any image. > When I wrote Sake for rake like functionality it loads into any image. > When I wrote Sake/Packges for managing packges dependencies I did it so > that any image can benefit. > > I dont know what initiatives pharo has completed, but, and please do > correct me if I am wrong. I havent seen a single initiative from pharo > that has been developed and deployed so that everyone could benefit. > > best regards > > Keith -- Janko MivÅ¡ek AIDA/Web Smalltalk Web Application Server http://www.aidaweb.si

2 1

[Pharo-project] Fwd: about sensor vs. InputSensor in primitiveError:
by StÃ©phane Ducasse July 7, 2009

July 7, 2009

> > > should not this method use InputSensor? > > primitiveError: aString > "This method is called when the error handling results in a > recursion in > calling on error: or halt or halt:." > > | context | > (String > streamContents: > [:s | > s nextPutAll: '***System error handling failed***'. > s cr; nextPutAll: aString. > context := thisContext sender sender. > 20 timesRepeat: [context == nil ifFalse: [s cr; print: > (context := context sender)]]. > s cr; nextPutAll: '-------------------------------'. > s cr; nextPutAll: 'Type CR to enter an emergency evaluator.'. > s cr; nextPutAll: 'Type any other character to restart.']) > displayAt: 0 @ 0. > [Sensor keyboardPressed] whileFalse. > Sensor keyboard = Character cr ifTrue: [Transcripter > emergencyEvaluator]. > World install "init hands and redisplay" > > >

2 2

July 7, 2009

Hi I wanted to integrate some fixes but apparently the network here does not let me use MC... so probably later tonight. Stef

1 0

[Pharo-project] OB, Completion and class variables (when used on the class side)
by Torsten Bergmann July 7, 2009

July 7, 2009

Hi there, try the following in the new pharo-dev: - create a package in OBBrowser - create a class "Foo" and add a class variable "Bar" to it - start typing a class side method by typing initBar "a class side method to init the class variable" Bar directly after "Bar" hit space and then press Tab to start with the completion. -> you get a DNU (Undefined object DNU #classPool) in ECClassVarTypeGuesser>>MethodRefs ... Bye Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

2 1

[Pharo-project] Image overwrite warning
by Torsten Bergmann July 7, 2009

July 7, 2009

Is it just me or does the latest pharo(-dev) not warn anymore if you save the image to an image file that already exist (when using "save as")? Also why are the arrows in folded menus now white? Black was better visible on the light background. Thanks Torsten -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate fÃ¼r nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02

4 7