At one stage in Dolphin's development, I had a very similar problem. IIRC, I solved it by having my code wait on a semaphore that I signaled from a deferred action (which meant the code then waited for the GUI to get going). It worked nicely, and continued to do so after Object Arts did a nicer fix in a subsequent version.
________________________________________ From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.duca...@inria.fr] Sent: Sunday, June 05, 2011 4:29 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] testing ui errors in headless mode this is probably related also with the problem that hilaire got with DrGeo. I did some experiences and we will check that with igor. Probably the command line is executed at startup but before the UI thread is launched. So we should fix that for 1.3 Stef On Jun 5, 2011, at 10:09 PM, Lukas Renggli wrote: > Not sure --- I didn't read the whole thread and I am not sure if I > understand the problem --- but did you try: > > WorldState addDeferredUIMessage: [ 1 inspect ] > > AFAIK, code filed-in at startup does not run in the GUI process > causing problems when the code expects to run in the GUI process > and/or a GUI process to be present (it might not be resumed on startup > yet). > > Lukas > > > On 5 June 2011 21:07, Tudor Girba <tu...@tudorgirba.com> wrote: >> Hi, >> >> I would need a bit of help with this one :). >> >> I tried: >> >> testStartup >> self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]] >> raise: Error >> >> This still fails. Is there a way around it? >> >> You can try using the attached st file. >> >> Cheers, >> Doru >> >> >> >> Begin forwarded message: >> >>> From: Tudor Girba <tu...@tudorgirba.com> >>> Date: 31 May 2011 23:08:03 CEST >>> To: Pharo-project@lists.gforge.inria.fr >>> Subject: Re: [Pharo-project] testing ui errors in headless mode >>> >>> Hi, >>> >>> On 31 May 2011, at 22:32, Igor Stasenko wrote: >>> >>>> On 31 May 2011 23:15, Tudor Girba <tu...@tudorgirba.com> wrote: >>>>> Hi Igor, >>>>> >>>>> Sorry for the late reply. >>>>> >>>>> >>>>> >>>>> On 26 May 2011, at 17:48, Igor Stasenko wrote: >>>>> >>>>>> On 26 May 2011 17:03, Tudor Girba <tu...@tudorgirba.com> wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I tried several ways to get my head around this problem, but I do not >>>>>>> know how to proceed. Can anyone help? >>>>>>> >>>>>>> Cheers, >>>>>>> Doru >>>>>>> >>>>>>> >>>>>>> On 25 May 2011, at 21:21, Tudor Girba wrote: >>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> We have some smoke tests in Moose that basically spawn a UI and check >>>>>>>> for Error. >>>>>>>> >>>>>>>> This used to work when running headless in Pharo 1.2 but now they fail >>>>>>>> in Pharo 1.3. I believe this has to do with the new changes in the UI >>>>>>>> Manager, but I do not know what to do. >>>>>>>> >>>>>>>> To reproduce the problem, you can simply call a Pharo-1.3.image in >>>>>>>> headless mode and file in the attached st file that: >>>>>>>> >>>>>>>> - installs a simple test: >>>>>>>> HeadlessTest>>testStartup >>>>>>>> self shouldnt: [1 inspect] raise: Error >>>>>> >>>>>> Tudor, your test is wrong. >>>>>> During image startup and in headless mode calling inspector will and >>>>>> should raise an error. >>>>>> Because inspecting object requires a presence of UI. >>>>>> But there's no UI in headless mode and prohibited from use during >>>>>> image startup phase, because >>>>>> you cannot start asking questions from user before properly >>>>>> initializing everything related to startup. >>>>>> Startup is called startup on purpose: is should not be interrupted nor >>>>>> require user's interaction. >>>>>> >>>>>> Assume that you don't have Morphic loaded in your image, then what you >>>>>> expect to happen if you do >>>>>> 1 inspect >>>>>> ? >>>>> >>>>> I understand now that the test is wrong. I just wanted to offer an >>>>> example of spawning a ui, but I think I found the problem like this :). >>>>> >>>>> Now, the thing is that my test tests that triggering the entries from a >>>>> menu does not result in an error. And inspect or browse happen to be >>>>> among the menu entries. Is there a way to still have this test working on >>>>> the server? >>>>> >>>>> Should I put a guard condition in the method triggering the inspector? >>>>> That sounds bad. Any other ideas? >>>>> >>>> >>>> Yes, you could swallow all ErrorNonInteractive. >>>> So if you will know that something will lead to UI interaction, you >>>> can catch ErrorNonInteractive. >>>> Since there is no UI you won't proceed further, but still will know >>>> that during running the test some UI is involved. >>>> >>>> So, actually a following should pass: >>>> >>>> UIManager default isInteractive ifFalse: [ >>>> self should: [1 inspect] raise: ErrorNonInteractive >>>> ] >>>> >>>> The problem is that there is some missing protocol in >>>> NonInteractiveUIManager (because at the time i was adding it , i >>>> covered all methods, >>>> but then some more stuff were added to morphic ui manager without >>>> parallel extension to other ui managers, >>>> so the test above can fail because you will get DNU error instead of >>>> ErrorNonInteractive ) >>> >>> I tried it: >>> >>> testStartup >>> self shouldnt: [[1 inspect] on: ErrorNonInteractive do: [:x | ]] >>> raise: Error >>> >>> But this still fails. You can try using the attached st file. >>> >>> Cheers, >>> Doru >>> >> >>> >>>>> Cheers, >>>>> Doru >>>>> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "The coherence of a trip is given by the clearness of the goal." >>> >>> >>> >>> >> >> -- >> www.tudorgirba.com >> >> "What is more important: To be happy, or to make happy?" >> >> >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch >
