[Pharo-project] 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?"
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."
Wonder what the default TooSet is in headless mode... (since inspect goes via the tool set) Regards, Gary ----- Original Message ----- From: "Tudor Girba" <tudor@tudorgirba.com> To: "Pharo-project@lists.gforge.inria.fr open-source Smalltalk" <pharo-project@lists.gforge.inria.fr> 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:10, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Wonder what the default TooSet is in headless mode... (since inspect goes via the tool set)
There is no ToolSet (it will be removed) All references to ToolSet will be replaced by Smalltalk tools blah blah idiom. (btw we need to integrate that)
Regards, Gary
----- Original Message ----- From: "Tudor Girba" <tudor@tudorgirba.com> To: "Pharo-project@lists.gforge.inria.fr open-source Smalltalk" <pharo-project@lists.gforge.inria.fr> 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."
-- Best regards, Igor Stasenko AKA sig.
Ok, didn't dig deep enough ;-) Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Thursday, May 26, 2011 4:42 PM Subject: Re: [Pharo-project] testing ui errors in headless mode On 26 May 2011 17:10, Gary Chambers <gazzaguru2@btinternet.com> wrote:
Wonder what the default TooSet is in headless mode... (since inspect goes via the tool set)
There is no ToolSet (it will be removed) All references to ToolSet will be replaced by Smalltalk tools blah blah idiom. (btw we need to integrate that)
Regards, Gary
----- Original Message ----- From: "Tudor Girba" <tudor@tudorgirba.com> To: "Pharo-project@lists.gforge.inria.fr open-source Smalltalk" <pharo-project@lists.gforge.inria.fr> 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."
-- Best regards, Igor Stasenko AKA sig.
On 26 May 2011 17:03, Tudor Girba <tudor@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 ?
- 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 <tudor@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? Cheers, Doru
- 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.
-- www.tudorgirba.com "It's not how it is, it is how we see it."
On 31 May 2011 23:15, Tudor Girba <tudor@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 <tudor@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 ).
Cheers, Doru
-- Best regards, Igor Stasenko AKA sig.
Hi, On 31 May 2011, at 22:32, Igor Stasenko wrote:
On 31 May 2011 23:15, Tudor Girba <tudor@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 <tudor@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."
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 <tudor@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 <tudor@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 <tudor@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?"
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 <tudor@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 <tudor@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 <tudor@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 <tudor@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
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 <tudor@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 <tudor@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 <tudor@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 <tudor@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
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-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse [stephane.ducasse@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 <tudor@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 <tudor@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 <tudor@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 <tudor@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
To simulate running test in headless mode, use following: | old | old := UIManager default. UIManager default: old nonInteractiveManager. [ 1 inspect. ] ensure: [ UIManager default: old ] and so, if you don't handle the error.. image will quit and error logged to PharoDebug.log : THERE_BE_DRAGONS_HERE MessageNotUnderstood: NonInteractiveUIManager>>openInspector:asMorphOn:withLabel: 26 May 2011 7:31:32 pm VM: Mac OS - intel - 1066 - Croquet Closure Cog VM [CoInterpreter VMMaker-oscog-MarianoMartinezPeck.66] NBCog VM 4.0.0 Image: Pharo1.3a [Latest update: #13204] NonInteractiveUIManager(Object)>>doesNotUnderstand: #openInspector:asMorphOn:withLabel: Receiver: a NonInteractiveUIManager Arguments and temporary variables: aMessage: openInspector: Inspector asMorphOn: 1 withLabel: 'SmallInteger: 1' exception: MessageNotUnderstood: NonInteractiveUIManager>>openInspector:asMorph...etc... resumeValue: nil Receiver's instance variables: uiManager: a MorphicUIManager doNotQuitOnRestart: false You can also turn on #snapshotErrorImage setting, then on unhandled error, before quit an image will be saved (with different version) and if you open that image you will see that error in debugger. On 25 May 2011 21:21, Tudor Girba <tudor@tudorgirba.com> 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?"
-- Best regards, Igor Stasenko AKA sig.
participants (6)
-
Gary Chambers -
Igor Stasenko -
Lukas Renggli -
Schwab,Wilhelm K -
Stéphane Ducasse -
Tudor Girba