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

Re: [Pharo-project] in 11233 merging is broken?

by GARY CHAMBERS

Something must be wrong with the script load somehow... Note that there are changes between working copy after load and Polymorph-Tools-Diff-StephaneDucasse.23.mcz. To fix for yourself at the moment, reload Polymorph-Tools-Diff-StephaneDucasse.23.mcz. Not an answer to why though... Regards, Gary. ________________________________ From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> To: Pharo-project Development <Pharo-project(a)lists.gforge.inria.fr> Sent: Thursday, 25 February, 2010 15:50:40 Subject: [Pharo-project] in 11233 merging is broken? Hi all I'm trying to integrate changes and apparently I cannot merge anymore nothing show up :). two questions: - do you get the behavior with 11233 or it is only me. - any idea of the potential problem - Issue 2071: subclasses and withAllSubclasses should return a array. - Issue 2076: Clean Exceptions. - Issue 2072: clean RealEstateAgent. Stef _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 25, 2010

[Pharo-project] in 11233 merging is broken?

by StÃ©phane Ducasse

Hi all I'm trying to integrate changes and apparently I cannot merge anymore nothing show up :). two questions: - do you get the behavior with 11233 or it is only me. - any idea of the potential problem - Issue 2071: subclasses and withAllSubclasses should return a array. - Issue 2076: Clean Exceptions. - Issue 2072: clean RealEstateAgent. Stef

Feb. 25, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by StÃ©phane Ducasse

cool! Stef On Feb 25, 2010, at 4:27 PM, Yanni Chiu wrote: > StÃ©phane Ducasse wrote: >> ... testserver, where are you? > > I have: > > http://hudson.jooshr.org/job/Pharo1.1/ > > which builds once a day. There are other builds on the site. I only use > the Pharo1.0-Seaside3.0 configuration. The others were set up when I was > trying to decide what to base my development on. > > The builds often break (Pharo 1.1 and Seaside 3.0), which is to be > expected. Usually the problem is some dialog pops up waiting for a user > response. It often takes me a few days before I get around to fixing > these build problems. Anyhow, it's there for the moment, if people want > to use the results. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 25, 2010

Re: [Pharo-project] Thread UI

by Lukas Renggli

> From a test-clarity (and robustness) POV though, you'd be much much > better by instead asserting properties of the morphs layout/colors than > sampling of display colors... > | morph | > > Â Â Â Â morph := Morph new. > Â Â Â Â morph doLayoutIn: someBounds. > Â Â Â Â self assert: whatIExpectedWithAboveBounds equals: morph someLayoutVariable Also have a look the OB and Glamour morphic tests. They mostly does not display the actual morph to test it. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 25, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by Yanni Chiu

StÃ©phane Ducasse wrote: > ... testserver, where are you? I have: http://hudson.jooshr.org/job/Pharo1.1/ which builds once a day. There are other builds on the site. I only use the Pharo1.0-Seaside3.0 configuration. The others were set up when I was trying to decide what to base my development on. The builds often break (Pharo 1.1 and Seaside 3.0), which is to be expected. Usually the problem is some dialog pops up waiting for a user response. It often takes me a few days before I get around to fixing these build problems. Anyhow, it's there for the moment, if people want to use the results. -- Yanni

Feb. 25, 2010

Re: [Pharo-project] Thread UI

by Henrik Johansen

Den 25.02.2010 15:05, skrev Alexandre Bergel: > Dear List, > > I am extending the current set of Mondrian tests. I would like to > force some system window to appear on the screen in order to properly > test the size of its composing morphs. However, I do not know how to > effectively make the morph show up on the screen in a test. > > For example, consider the following test with a contrived situation: > > testDummy > | morph c | > morph := Morph new openInWorld. > c := Display colorAt: 0@0. > morph delete. > self assert: c = morph color. > > If I run the test from a test runner, it will fail. However, if I open > a debugger and do a step by step, c = morph color is true. > > I guess the problem is that the morph is not actually displayed, since > the UI thread does not have the hand. Any idea how to force this? > > Cheers, > Alexandre > > You could insert World doOneCycle between the lines morph := and c := >From a test-clarity (and robustness) POV though, you'd be much much better by instead asserting properties of the morphs layout/colors than sampling of display colors... | morph | morph := Morph new. morph doLayoutIn: someBounds. self assert: whatIExpectedWithAboveBounds equals: morph someLayoutVariable Cheers, Henry

Feb. 25, 2010

Re: [Pharo-project] how to remove World?

by Henrik Johansen

Den 25.02.2010 13:49, skrev Esteban Lorenzano: > Ok, I tried passing a .st by command line: > > UIManager default: DummyUIManager new. > > Project uiProcess terminate. > > SmalltalkImage current snapshot: true andQuit: true. > > but I fail miserably :'( > (it stops do anything after "Project uiProcess terminate"... and the > same using "Project uiProcess suspend") > > Any idea of how can I proceed from here? (I confess: I'm totally lost here) > > Cheers, > Esteban > As Lukas already said, that's not very strange if the script is being executed by the uiProcess. (which it is if you're using the ProjectLauncher) You can't plan to kill yourself, then afterwards send a goodbye-letter to your friends, you need to get someone else to perform the actions if you want to be sure it happens. (ie. fork off the execution) Cheers, Henry

Feb. 25, 2010

Re: [Pharo-project] Diff tools

by GARY CHAMBERS

Done in Polymorph-Tools-Diff-gvc.23 on SqueakSource/UIEnhancements, includes (from version 22) keyboard shortcuts for existing menu items. ________________________________ From: StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> To: Pharo-project(a)lists.gforge.inria.fr Sent: Tuesday, 23 February, 2010 19:06:04 Subject: Re: [Pharo-project] Diff tools On Feb 23, 2010, at 7:04 PM, Gary Chambers wrote: > I'll give it a go (keyboard shortcuts included) in the next DiffTools > version... > I guess you won't want a warning dialog the "What you are choosing means > that any conflicts will be unchecked"... ;-) :) > So, "use incoming for all incoming conficts" and "use current for all > conflicts"? Yeap! _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 25, 2010

[Pharo-project] Thread UI

by Alexandre Bergel

Dear List, I am extending the current set of Mondrian tests. I would like to force some system window to appear on the screen in order to properly test the size of its composing morphs. However, I do not know how to effectively make the morph show up on the screen in a test. For example, consider the following test with a contrived situation: testDummy | morph c | morph := Morph new openInWorld. c := Display colorAt: 0@0. morph delete. self assert: c = morph color. If I run the test from a test runner, it will fail. However, if I open a debugger and do a step by step, c = morph color is true. I guess the problem is that the morph is not actually displayed, since the UI thread does not have the hand. Any idea how to force this? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 25, 2010

[Pharo-project] [update 1.1] #11231

by Marcus Denker

... late announce: - Issue 2053: New enh for polymorph widgets - Issue 2056: SmalltalkImage>>windowSystemName - Issue 2060: deprecate Number class>>#readExactlyFrom:'. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

Feb. 25, 2010