tests ui errors in headless mode

> 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
>
> - loads HudsonTools
>
> - runs the test and outputs the XML file report
>
> - although the test should pass, it raises the error:
> HeadlessStartupTest(TestCase)>>signalFailure:
> HeadlessStartupTest(TestCase)>>assert:
> HeadlessStartupTest(TestCase)>>shouldnt:raise:
> HeadlessStartupTest>>testStartup
> HeadlessStartupTest(TestCase)>>performTest
>
>
> Can anyone help?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "What is more important: To be happy, or to make happy?"
>
> <headlesstest.st>

> 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
>
> - loads HudsonTools
>
> - runs the test and outputs the XML file report
>
> - although the test should pass, it raises the error:
> HeadlessStartupTest(TestCase)>>signalFailure:
> HeadlessStartupTest(TestCase)>>assert:
> HeadlessStartupTest(TestCase)>>shouldnt:raise:
> HeadlessStartupTest>>testStartup
> HeadlessStartupTest(TestCase)>>performTest
>
>
> Can anyone help?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "What is more important: To be happy, or to make happy?"
>
> <headlesstest.st>

> 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
>
> - loads HudsonTools
>
> - runs the test and outputs the XML file report
>
> - although the test should pass, it raises the error:
> HeadlessStartupTest(TestCase)>>signalFailure:
> HeadlessStartupTest(TestCase)>>assert:
> HeadlessStartupTest(TestCase)>>shouldnt:raise:
> HeadlessStartupTest>>testStartup
> HeadlessStartupTest(TestCase)>>performTest
>
>
> Can anyone help?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "What is more important: To be happy, or to make happy?"
>
>

> Regards, Gary
>
> ----- Original Message ----- From: "Tudor Girba" <[hidden email]>
> To: "[hidden email] open-source Smalltalk"
> <[hidden email]>
> Sent: Thursday, May 26, 2011 4:03 PM
> Subject: Re: [Pharo-project] testing ui errors in headless mode
>
>
> 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
>>
>> - loads HudsonTools
>>
>> - runs the test and outputs the XML file report
>>
>> - although the test should pass, it raises the error:
>> HeadlessStartupTest(TestCase)>>signalFailure:
>> HeadlessStartupTest(TestCase)>>assert:
>> HeadlessStartupTest(TestCase)>>shouldnt:raise:
>> HeadlessStartupTest>>testStartup
>> HeadlessStartupTest(TestCase)>>performTest
>>
>>
>> Can anyone help?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>> <headlesstest.st>
>
> --
> www.tudorgirba.com
>
> "It's not what we do that matters most, it's how we do it."
>
>
>
>

> 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

>>
>> - loads HudsonTools
>>
>> - runs the test and outputs the XML file report
>>
>> - although the test should pass, it raises the error:
>> HeadlessStartupTest(TestCase)>>signalFailure:
>> HeadlessStartupTest(TestCase)>>assert:
>> HeadlessStartupTest(TestCase)>>shouldnt:raise:
>> HeadlessStartupTest>>testStartup
>> HeadlessStartupTest(TestCase)>>performTest
>>
>>
>> Can anyone help?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>> <headlesstest.st>
>
> --
> www.tudorgirba.com
>
> "It's not what we do that matters most, it's how we do it."
>
>
>

> Regards, Gary
>
> ----- Original Message ----- From: "Tudor Girba" <[hidden email]>
> To: "[hidden email] open-source Smalltalk"
> <[hidden email]>
> Sent: Thursday, May 26, 2011 4:03 PM
> Subject: Re: [Pharo-project] testing ui errors in headless mode
>
>
> 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
>>
>> - loads HudsonTools
>>
>> - runs the test and outputs the XML file report
>>
>> - although the test should pass, it raises the error:
>> HeadlessStartupTest(TestCase)>>signalFailure:
>> HeadlessStartupTest(TestCase)>>assert:
>> HeadlessStartupTest(TestCase)>>shouldnt:raise:
>> HeadlessStartupTest>>testStartup
>> HeadlessStartupTest(TestCase)>>performTest
>>
>>
>> Can anyone help?
>>
>> Cheers,
>> Doru
>>
>> --
>> www.tudorgirba.com
>>
>> "What is more important: To be happy, or to make happy?"
>>
>> <headlesstest.st>
>
> --
> www.tudorgirba.com
>
> "It's not what we do that matters most, it's how we do it."
>
>
>
>

> On 26 May 2011 17:03, Tudor Girba <[hidden email]> 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
> ?

>>>
>>> - loads HudsonTools
>>>
>>> - runs the test and outputs the XML file report
>>>
>>> - although the test should pass, it raises the error:
>>> HeadlessStartupTest(TestCase)>>signalFailure:
>>> HeadlessStartupTest(TestCase)>>assert:
>>> HeadlessStartupTest(TestCase)>>shouldnt:raise:
>>> HeadlessStartupTest>>testStartup
>>> HeadlessStartupTest(TestCase)>>performTest
>>>
>>>
>>> Can anyone help?
>>>
>>> Cheers,
>>> Doru
>>>
>>> --
>>> www.tudorgirba.com
>>>
>>> "What is more important: To be happy, or to make happy?"
>>>
>>> <headlesstest.st>
>>
>> --
>> www.tudorgirba.com
>>
>> "It's not what we do that matters most, it's how we do it."
>>
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.
>

> 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 <[hidden email]> 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?
>

>

> 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 <[hidden email]>
>> Date: 31 May 2011 23:08:03 CEST
>> To: [hidden email]
>> 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 <[hidden email]> 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 <[hidden email]> 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?"
>
>
>

> 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 <[hidden email]> 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 <[hidden email]>
>>> Date: 31 May 2011 23:08:03 CEST
>>> To: [hidden email]
>>> 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 <[hidden email]> 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 <[hidden email]> 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
>

> 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 <[hidden email]> 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 <[hidden email]>
>>> Date: 31 May 2011 23:08:03 CEST
>>> To: [hidden email]
>>> 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 <[hidden email]> 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 <[hidden email]> 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
>