November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] GUI Testing Library

by Sean P. DeNigris

Alexandre Bergel-7 wrote > > I opened an issue: http://code.google.com/p/pharo/issues/detail?id=5010 > Fix (although I guess there are more widgets to fix?) in 1.4 inbox SLICE-Issue-5010-Testing-GUI-widgets-SeanDeNigris.1 Alexandre Bergel-7 wrote > > This is very valuable. Currently it is really hard to test GUI in Pharo. > I think it could be very easy with a little work Alexandre Bergel-7 wrote > > One problem I faced several times is that GUI are not uniformly managed: > some GUI widgets use of exceptions (which is cool), some other are > blocking the currently thread (which is not cool). > The hook points are in MorphicUIManager's "ui requests" protocol. For each type of interaction (e.g. confirm), in the method that takes the most arguments (e.g. #confirm:label:, not #confirm:), ProvideAnswerNotification is signaled. Alexandre Bergel-7 wrote > > For example, I can write... > Thanks for the examples. I wrote them into Morphic tests (incl. in fix above) Alexandre Bergel-7 wrote > > self should: ['/tmp' = ([UIManager default chooseDirectory] > valueSupplyingAnswer: #('/tmp'))] > This works now, but the syntax is ...valueSupplyingAnswer: { 'Choose Directory'. FileDirectory on: '/tmp' }. HTH, Sean -- View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4100236.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

Re: [Pharo-project] Building 32-bit Cairo library on Macs

by Stefan Marr

Hi: On 23 Nov 2011, at 16:50, Igor Stasenko wrote: > build_arch to "i386" There used to be the +universal flag that made sure that all universal_archs where build, and then universal_archs was "x86_64 i386". Not sure what the easiest way is to get macports to rebuild all the dependencies, but when I update with the force option, I think it is doing that. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Nov. 23, 2011

[Pharo-project] Building 32-bit Cairo library on Macs

by Igor Stasenko

Hello, i'd like to know, if there's anyone who can help with making 32-bit version of cairo library on macs? Because if i just do: port install cairo everything is ok, except that VM cannot use that library because it is 64bit.. And if i set build_arch to "i386" in /opt/local/etc/macports/macports.conf and run it, it also doesn't going well (see the end of mail), because of having too much dependecies from libraries which already installed and 64-bit :( Is there a way to tell port to just build stuff in a separate place.. or is there a way to build cairo library without port? sudo port install cairo Warning: port definitions are more than two weeks old, consider using selfupdate ---> Fetching pkgconfig ---> Attempting to fetch pkg-config-0.25.tar.gz from http://lil.fr.distfiles.macports.org/pkgconfig ---> Verifying checksum(s) for pkgconfig ---> Extracting pkgconfig ---> Applying patches to pkgconfig ---> Configuring pkgconfig ---> Building pkgconfig ---> Staging pkgconfig into destroot ---> Installing pkgconfig @0.25_1 ---> Deactivating pkgconfig @0.23_1 ---> Activating pkgconfig @0.25_1 ---> Cleaning pkgconfig ---> Fetching libpixman ---> Attempting to fetch pixman-0.20.0.tar.bz2 from http://lil.fr.distfiles.macports.org/libpixman ---> Verifying checksum(s) for libpixman ---> Extracting libpixman ---> Configuring libpixman ---> Building libpixman ---> Staging libpixman into destroot ---> Installing libpixman @0.20.0_0 ---> Deactivating libpixman @0.16.4_0 ---> Activating libpixman @0.20.0_0 ---> Cleaning libpixman ---> Fetching xorg-util-macros ---> Attempting to fetch util-macros-1.11.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-util-macros ---> Verifying checksum(s) for xorg-util-macros ---> Extracting xorg-util-macros ---> Configuring xorg-util-macros ---> Building xorg-util-macros ---> Staging xorg-util-macros into destroot ---> Installing xorg-util-macros @1.11.0_0 ---> Deactivating xorg-util-macros @1.5.0_0 ---> Activating xorg-util-macros @1.11.0_0 ---> Cleaning xorg-util-macros ---> Fetching xorg-xtrans ---> Attempting to fetch xtrans-1.2.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xtrans ---> Verifying checksum(s) for xorg-xtrans ---> Extracting xorg-xtrans ---> Configuring xorg-xtrans ---> Building xorg-xtrans ---> Staging xorg-xtrans into destroot ---> Installing xorg-xtrans @1.2.6_0 ---> Deactivating xorg-xtrans @1.2.5_0 ---> Activating xorg-xtrans @1.2.6_0 ---> Cleaning xorg-xtrans ---> Fetching xorg-bigreqsproto ---> Attempting to fetch bigreqsproto-1.1.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-bigreqsproto ---> Verifying checksum(s) for xorg-bigreqsproto ---> Extracting xorg-bigreqsproto ---> Configuring xorg-bigreqsproto ---> Building xorg-bigreqsproto ---> Staging xorg-bigreqsproto into destroot ---> Installing xorg-bigreqsproto @1.1.1_0 ---> Deactivating xorg-bigreqsproto @1.1.0_0 ---> Activating xorg-bigreqsproto @1.1.1_0 ---> Cleaning xorg-bigreqsproto ---> Fetching xorg-xcmiscproto ---> Attempting to fetch xcmiscproto-1.2.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xcmiscproto ---> Verifying checksum(s) for xorg-xcmiscproto ---> Extracting xorg-xcmiscproto ---> Configuring xorg-xcmiscproto ---> Building xorg-xcmiscproto ---> Staging xorg-xcmiscproto into destroot ---> Installing xorg-xcmiscproto @1.2.1_0 ---> Deactivating xorg-xcmiscproto @1.2.0_0 ---> Activating xorg-xcmiscproto @1.2.1_0 ---> Cleaning xorg-xcmiscproto ---> Fetching xorg-xextproto ---> Attempting to fetch xextproto-7.1.2.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xextproto ---> Verifying checksum(s) for xorg-xextproto ---> Extracting xorg-xextproto ---> Configuring xorg-xextproto ---> Building xorg-xextproto ---> Staging xorg-xextproto into destroot ---> Installing xorg-xextproto @7.1.2_0 ---> Deactivating xorg-xextproto @7.1.1_0 ---> Activating xorg-xextproto @7.1.2_0 ---> Cleaning xorg-xextproto ---> Fetching xorg-inputproto ---> Attempting to fetch inputproto-2.0.1.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-inputproto ---> Verifying checksum(s) for xorg-inputproto ---> Extracting xorg-inputproto ---> Configuring xorg-inputproto ---> Building xorg-inputproto ---> Staging xorg-inputproto into destroot ---> Installing xorg-inputproto @2.0.1_0 ---> Deactivating xorg-inputproto @2.0_0 ---> Activating xorg-inputproto @2.0.1_0 ---> Cleaning xorg-inputproto ---> Fetching xorg-xproto ---> Attempting to fetch xproto-7.0.20.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-xproto ---> Verifying checksum(s) for xorg-xproto ---> Extracting xorg-xproto ---> Configuring xorg-xproto ---> Building xorg-xproto ---> Staging xorg-xproto into destroot ---> Installing xorg-xproto @7.0.20_0 ---> Deactivating xorg-xproto @7.0.16_0 ---> Activating xorg-xproto @7.0.20_0 ---> Cleaning xorg-xproto ---> Computing dependencies for xorg-libXdmcp ---> Fetching xorg-libXdmcp ---> Attempting to fetch libXdmcp-1.1.0.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXdmcp ---> Verifying checksum(s) for xorg-libXdmcp ---> Extracting xorg-libXdmcp ---> Configuring xorg-libXdmcp ---> Building xorg-libXdmcp ---> Staging xorg-libXdmcp into destroot ---> Computing dependencies for xorg-libXdmcp ---> Installing xorg-libXdmcp @1.1.0_0 ---> Deactivating xorg-libXdmcp @1.0.3_0 ---> Activating xorg-libXdmcp @1.1.0_0 ---> Cleaning xorg-libXdmcp ---> Computing dependencies for xorg-libXau ---> Fetching xorg-libXau ---> Attempting to fetch libXau-1.0.6.tar.bz2 from http://lil.fr.distfiles.macports.org/xorg-libXau ---> Verifying checksum(s) for xorg-libXau ---> Extracting xorg-libXau ---> Configuring xorg-libXau ---> Building xorg-libXau ---> Staging xorg-libXau into destroot ---> Computing dependencies for xorg-libXau ---> Installing xorg-libXau @1.0.6_0 ---> Deactivating xorg-libXau @1.0.5_0 ---> Activating xorg-libXau @1.0.6_0 ---> Cleaning xorg-libXau ---> Computing dependencies for libxml2 ---> Dependencies to be installed: libiconv zlib ---> Fetching libxml2 ---> Attempting to fetch libxml2-2.7.8.tar.gz from http://lil.fr.distfiles.macports.org/libxml2 ---> Verifying checksum(s) for libxml2 ---> Extracting libxml2 ---> Configuring libxml2 Error: You cannot install libxml2 for the architecture(s) i386 because Error: its dependency libiconv only contains the architecture(s) x86_64. Error: Error: Did you upgrade to a new version of Mac OS X? If so, please see Error: Error: http://trac.macports.org/wiki/Migration Error: Error: Target org.macports.configure returned: incompatible architectures in dependencies Log for libxml2 is at: /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_ports_textproc_libxml2/main.log Error: Unable to upgrade port: 1 Error: Unable to execute port: upgrade xrender failed To report a bug, see <http://guide.macports.org/#project.tickets> -- Best regards, Igor Stasenko.

Nov. 23, 2011

Re: [Pharo-project] GUI Testing Library

by Tudor Girba

Wow, this looks brilliant! I will definitely give it a try in the following days. Doru On Wed, Nov 23, 2011 at 4:10 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Tudor Girba-2 wrote >> >> Could you provide more information? Or maybe an example? >> > Sure. Thanks for the push to write tests :) > > I just uploaded a new version with some simple tests. Here is a snippet: > testSimulateCmdKeystroke > > Â Â Â Â | ws | > Â Â Â Â ws := Workspace open. > Â Â Â Â self simulateKeyStrokes: 'var := 3.'. > > Â Â Â Â self simulateKeyStroke: $s command. > > Â Â Â Â self assert: ws hasUnacceptedEdits = false. > > I'll be adding functionality as I go because I'm using it to test my own > GUIs, but let me know if there's anything specific that you'd really love to > see here... > > Sean > > p.s. only in a live, open, dynamic system like Smalltalk could I do this so > easily. I've read books devoted to this topic, but I coded this up in a few > minutes. > > -- > View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4099975.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

Nov. 23, 2011

Re: [Pharo-project] GUI Testing Library

by Sean P. DeNigris

Tudor Girba-2 wrote > > Could you provide more information? Or maybe an example? > Sure. Thanks for the push to write tests :) I just uploaded a new version with some simple tests. Here is a snippet: testSimulateCmdKeystroke | ws | ws := Workspace open. self simulateKeyStrokes: 'var := 3.'. self simulateKeyStroke: $s command. self assert: ws hasUnacceptedEdits = false. I'll be adding functionality as I go because I'm using it to test my own GUIs, but let me know if there's anything specific that you'd really love to see here... Sean p.s. only in a live, open, dynamic system like Smalltalk could I do this so easily. I've read books devoted to this topic, but I coded this up in a few minutes. -- View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4099975.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 23, 2011

Re: [Pharo-project] GUI Testing Library

by Guillermo Polito

On Tue, Nov 22, 2011 at 10:09 PM, Sean P. DeNigris <sean(a)clipperadams.com>wrote: > > This is fun! I integrated with Keymapping, so now you can write: > self simulateKeyStrokes: 'Object'. > self simulateKeyStroke: $s command. > Haha! great :) I'll freeze an stable version soon.

Nov. 23, 2011

Re: [Pharo-project] [Zinc] ZnTooManyRedirects exception

by StÃ©phane Ducasse

I really like such kind of exchange. Constructive and positive energy: this is what makes a powerful community and give us energy to out pass ourselves. Stef On Nov 23, 2011, at 2:12 PM, Sven Van Caekenberghe wrote: > Hi Jan, > > Nice to hear from you again. > > On 23 Nov 2011, at 13:45, Jan van de Sandt wrote: > >> Hello, >> >> I'm busy updating CloudforkSSO to use the latest version of the Zinc http client (ZnClient). Most of the required changes are pretty simple. But I have a problem with redirects. >> >> I cannot let ZnClient handle the redirects because I need to update the Authorization header. So I use the dontFollowRedirects option and proces the redirect myself. But now ZnClient signals a ZnTooManyRedirects exception when a redirect response is received. >> >> It seems more logical to me to just answer the response. Especially when the numberOfRetries option is greater than zero. It's no use retrying a request that answers a redirect. >> >> Is it possible to change ZnClient so that it doesn't signal a ZnTooManyRedirects when the maxNumberOfRedirects is zero? >> >> Jan. > > As one of the more advanced users of Zn you are right of course: if you want to handle redirects yourself, setting dontFollowRedirects will give you a ZnTooManyRedirects exception when one occurs, which is stupid. > > And indeed, retrying instead of following redirects does also not make much sense ;-) > > Let me think a bit about this, and I will come back to you. > > I'll have to write some tests too. > >> PS: For the rest I really like the simple but powerful interface of ZnClient! > > Thank you! > > Sven > >

Nov. 23, 2011

Re: [Pharo-project] [Zinc] ZnTooManyRedirects exception

by Sven Van Caekenberghe

Hi Jan, Nice to hear from you again. On 23 Nov 2011, at 13:45, Jan van de Sandt wrote: > Hello, > > I'm busy updating CloudforkSSO to use the latest version of the Zinc http client (ZnClient). Most of the required changes are pretty simple. But I have a problem with redirects. > > I cannot let ZnClient handle the redirects because I need to update the Authorization header. So I use the dontFollowRedirects option and proces the redirect myself. But now ZnClient signals a ZnTooManyRedirects exception when a redirect response is received. > > It seems more logical to me to just answer the response. Especially when the numberOfRetries option is greater than zero. It's no use retrying a request that answers a redirect. > > Is it possible to change ZnClient so that it doesn't signal a ZnTooManyRedirects when the maxNumberOfRedirects is zero? > > Jan. As one of the more advanced users of Zn you are right of course: if you want to handle redirects yourself, setting dontFollowRedirects will give you a ZnTooManyRedirects exception when one occurs, which is stupid. And indeed, retrying instead of following redirects does also not make much sense ;-) Let me think a bit about this, and I will come back to you. I'll have to write some tests too. > PS: For the rest I really like the simple but powerful interface of ZnClient! Thank you! Sven

Nov. 23, 2011

[Pharo-project] [Zinc] ZnTooManyRedirects exception

by Jan van de Sandt

Hello, I'm busy updating CloudforkSSO to use the latest version of the Zinc http client (ZnClient). Most of the required changes are pretty simple. But I have a problem with redirects. I cannot let ZnClient handle the redirects because I need to update the Authorization header. So I use the dontFollowRedirects option and proces the redirect myself. But now ZnClient signals a ZnTooManyRedirects exception when a redirect response is received. It seems more logical to me to just answer the response. Especially when the numberOfRetries option is greater than zero. It's no use retrying a request that answers a redirect. Is it possible to change ZnClient so that it doesn't signal a ZnTooManyRedirects when the maxNumberOfRedirects is zero? Jan. PS: For the rest I really like the simple but powerful interface of ZnClient!

Nov. 23, 2011

Re: [Pharo-project] GUI Testing Library

by Alexandre Bergel

Hi Sean, This is very valuable. Currently it is really hard to test GUI in Pharo. One problem I faced several times is that GUI are not uniformly managed: some GUI widgets use of exceptions (which is cool), some other are blocking the currently thread (which is not cool). For example, I can write: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= | t | [self inform: 'blah'] on: Exception do: [:ex | t := ex ]. self assert: t messageText = 'blah' -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Other cool tests: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= testSupplyAnswerOfFillInTheBlank self should: ['blue' = ([UIManager default request: 'Your favorite color?'] valueSupplyingAnswer: #('Your favorite color?' 'blue'))] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= However, not all widgets can be tested that way, which is quite problematic. For example, the following code opens a window, which is not one would expect: -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= self should: ['/tmp' = ([UIManager default chooseDirectory] valueSupplyingAnswer: #('/tmp'))] -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I am not sure how easy is to solve this problem, but this is something we need to work on. This is important. I opened an issue: http://code.google.com/p/pharo/issues/detail?id=5010 Cheers, Alexandre On 22 Nov 2011, at 20:27, Sean P. DeNigris wrote: > I'm starting to put together some helpers for UI testing. What's out there > already? > > I started simulating keyboard events. It seems like the place to hook is > ActiveHand>>handleEvent:. This way, it will take into account the keyboard > focus and route the event the way it would for a real event. Does that sound > right? > > So far the API adds TestCase>>simulateKeyStrokes: which forwards to > ActiveHand>>handleEvent:, so you can put in a test: > testMyMorph > MyMorph new openInWorld. "MyMorph takes the keyboard focus in > #initialize" > self simulateKeyStrokes: 'abcd'. "keystrokes go to MyMorph instance" > > Obviously, there are things missing (like modifier keys), but what are your > thoughts on the general approach? > > Sean > > -- > View this message in context: http://forum.world.st/GUI-Testing-Library-tp4097866p4097866.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Nov. 23, 2011