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

Re: [Pharo-dev] test failures in downloaded image 30733

by Goubier Thierry

Le 04/02/2014 09:48, Usman Bhatti a Ã©crit : > > > > On Tue, Feb 4, 2014 at 9:29 AM, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > > > > Le 04/02/2014 09:23, Usman Bhatti a Ã©crit : > > > > > Yes, I use that already with Glamour and Roassal, and other morph > widgets that I have. > The harder part for me so far is responding to dialog boxes e.g. > answer > the user questions automatically and once I have that, I'd be > able to > completely test my current set of UIs automatically. > > > What about writing a Shim over the dialog creator with a catalog of > predefined answers that could be picked by each dialog creation? > When calling a dialog, we're usually going through a factory > interface usually. > > > I do not know what is a Shim. From Wikipedia: In computer programming, a shim (from shim) or shiv is a small library that transparently intercepts an API and changes the parameters passed, handles the operation itself, or redirects the operation elsewhere. > Sometimes, we would like to provide our own answers to the dialogue to > see if the tests pass in different configurations (e.g. when we have two > or more checkboxes, to see if we get different results selecting > different boxes). > > Or may be we can start with a simpler solution and then evolve towards a > completely customizable one. My simple approach would be : in normal code, instead of calling UIManager directly as in: UIManager default chooseFrom: aCollection title: aString withCRs. use a shim (self class myUIManager ....). In the test case, setup so that: `self class myUIManager` returns a shim over UIManager capturing the chooseFrom:title: and containing a dictionary with 'title' -> value to choose. You preload the shim with the right answers and the keys for the shim to find to which dialog this refers (it could be ordered: answer for first dialog, answer for second dialog, etc...). The shim, instead of creating the dialog, returns the value it already has (or an error if it hasn't, which will help you fill the needed values !). For stuff not related to dialogs you are using the shim for, you can just do a passthrough (i.e. UIManager default perform: ) which can even be handled automagically via doesNotUnderstand:. As you can see, there isn't much to it. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 4, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by Usman Bhatti

On Tue, Feb 4, 2014 at 9:29 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > > > Le 04/02/2014 09:23, Usman Bhatti a Ã©crit : > > >> >> >> Yes, I use that already with Glamour and Roassal, and other morph >> widgets that I have. >> The harder part for me so far is responding to dialog boxes e.g. answer >> the user questions automatically and once I have that, I'd be able to >> completely test my current set of UIs automatically. >> > > What about writing a Shim over the dialog creator with a catalog of > predefined answers that could be picked by each dialog creation? When > calling a dialog, we're usually going through a factory interface usually. I do not know what is a Shim. Sometimes, we would like to provide our own answers to the dialogue to see if the tests pass in different configurations (e.g. when we have two or more checkboxes, to see if we get different results selecting different boxes). Or may be we can start with a simpler solution and then evolve towards a completely customizable one. > > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

Feb. 4, 2014

Re: [Pharo-dev] PharoProjectCatalog for Pharo 3?

by Damien Cassou

On Tue, Feb 4, 2014 at 12:42 AM, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: > If you want to integrate, I have attached changes to CatalogBuilder methods > for redirecting to MetaRepoForPharo3. > I don't know the proper way to test it yet I just gave Torsten and you write access. > CatalogBuilder new generateAll ?? that should work. But this will take quite some time. Another solution is to write something like (untested): CatalogBuilder new generateCardFor: ConfigurationOfPillar > but gives me a MessageNotUnderstood: GoferResolvedReference>>load :-( -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Feb. 4, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by Goubier Thierry

Le 04/02/2014 09:23, Usman Bhatti a Ã©crit : > > > > Yes, I use that already with Glamour and Roassal, and other morph > widgets that I have. > The harder part for me so far is responding to dialog boxes e.g. answer > the user questions automatically and once I have that, I'd be able to > completely test my current set of UIs automatically. What about writing a Shim over the dialog creator with a catalog of predefined answers that could be picked by each dialog creation? When calling a dialog, we're usually going through a factory interface usually. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 4, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by Usman Bhatti

On Tue, Feb 4, 2014 at 9:08 AM, Goubier Thierry <thierry.goubier(a)cea.fr>wrote: > > > Le 03/02/2014 21:41, Usman Bhatti a Ã©crit : > >> >> >> >> On Sun, Feb 2, 2014 at 2:43 PM, Marcus Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> >> On 02 Feb 2014, at 14:31, btc(a)openinworld.com >> <mailto:btc@openinworld.com> wrote: >> >> > For diligence and curiosity leading up to the Pharo3 release, I >> downloaded build image 30733 (with PharoLauncher) >> >> Getting an image green is a lot of little, trivial, hard work... and >> green always means "Green in this context". Just headless vs. >> non-headless >> changes a lot, for example. >> >> Another wonderful thing is that tests are fine when run >> individually, but fail when running all tests. >> >> We need to think about automatic UI testing... >> >> >> It will be awesome to have automatic UI tests. >> > > Well, it can be done as it is now. > > It's fairly easy in Pharo to write tests that open a GUI, test a few > things in it, and close it. There, you can already test automatically that > your gui updates correctly when the model change. > Yes, I use that already with Glamour and Roassal, and other morph widgets that I have. The harder part for me so far is responding to dialog boxes e.g. answer the user questions automatically and once I have that, I'd be able to completely test my current set of UIs automatically. > > It may be a bit harder to trigger events on specific positions, but not > that much difficult. A way to write a test method out of Sean event > recorder would be nice there. > > > Currently, I can go as far as invoking the UI but then to complete the >> fields in another process/thread, I haven't really spent enough time. I >> think that's already discussed on the mailing list but some time I >> should have a look. Automated tests before a release/roll-out will be a >> dream coming true ;-). >> > > Yes. Especially on all the gui parts: drag and drop for example. > > But, technically, we're not very far. It's just that nobody writes tests > that way. > > Thierry > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > >

Feb. 4, 2014

Re: [Pharo-dev] test failures in downloaded image 30733

by Goubier Thierry

Le 03/02/2014 21:41, Usman Bhatti a Ã©crit : > > > > On Sun, Feb 2, 2014 at 2:43 PM, Marcus Denker <marcus.denker(a)inria.fr > <mailto:marcus.denker@inria.fr>> wrote: > > > On 02 Feb 2014, at 14:31, btc(a)openinworld.com > <mailto:btc@openinworld.com> wrote: > > > For diligence and curiosity leading up to the Pharo3 release, I > downloaded build image 30733 (with PharoLauncher) > > Getting an image green is a lot of little, trivial, hard workâ¦ and > green always means âGreen in this contextâ. Just headless vs. > non-headless > changes a lot, for example. > > Another wonderful thing is that tests are fine when run > individually, but fail when running all tests. > > We need to think about automatic UI testingâ¦ > > > It will be awesome to have automatic UI tests. Well, it can be done as it is now. It's fairly easy in Pharo to write tests that open a GUI, test a few things in it, and close it. There, you can already test automatically that your gui updates correctly when the model change. It may be a bit harder to trigger events on specific positions, but not that much difficult. A way to write a test method out of Sean event recorder would be nice there. > Currently, I can go as far as invoking the UI but then to complete the > fields in another process/thread, I haven't really spent enough time. I > think that's already discussed on the mailing list but some time I > should have a look. Automated tests before a release/roll-out will be a > dream coming true ;-). Yes. Especially on all the gui parts: drag and drop for example. But, technically, we're not very far. It's just that nobody writes tests that way. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Feb. 4, 2014

Re: [Pharo-dev] Who invented Nautilus Groups (DynamicGroup/DynamicClassGroup)

by Nicolai Hess

2014-02-03 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com>: > On 03 Feb 2014, at 20:57, Nicolai Hess <nicolaihess(a)web.de> wrote: > > I don't get why a DynamicGroup manages a list of methods and not a list > of classes like DyanmicClassGroup. > > > Me for the title. > > And to answer shortly, to have groups with a finer grained definition. > > > If Nautilus tries to create the class list from a DyanicGroup group it > takes > awful long time if this Groups have more than 20-30 different classes > > > Then maybe the correct kind of group should be used. > Ben > > Ok, thanks. (I am not sure if this is easily fixable, I don't know where to make this distinction). Nicolai

Feb. 4, 2014

Re: [Pharo-dev] PharoProjectCatalog for Pharo 3?

by HernÃ¡n Morales Durand

Thank you Torsten! If you want to integrate, I have attached changes to CatalogBuilder methods for redirecting to MetaRepoForPharo3. I don't know the proper way to test it yet CatalogBuilder new generateAll ?? but gives me a MessageNotUnderstood: GoferResolvedReference>>load Cheers HernÃ¡n 2014-02-03 Torsten Bergmann <astares(a)gmx.de>: > HernÃ¡n wrote: > >I have noticed the following catalog url lists configurations for Pharo > 2.0 > > > https://ci.inria.fr/pharo-contribution/job/PharoProjectCatalog/HTML_Report/ > ? > > > >Is there a job/url for configurations for Pharo 3? > > > Not yet, AFAIK Catalog had to be adopted manualy for MetaRepoForPharo30. > > Code is on > http://smalltalkhub.com/mc/DamienCassou/Pier-Gutemberg/main > > if you like to adopt. > > Thanks > T. > > > > >

Feb. 3, 2014

Re: [Pharo-dev] Zodiac and IMAP

by Sven Van Caekenberghe

Hi Torsten, On 04 Feb 2014, at 00:18, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Sven, > > while there is support for SMTP and POP3 in Zodiac I wonder > about IMAP protocol support. > > Thx > T. I am not sure I understand the question. Yes, there are ZdcSecurePOP3Client and ZdcSecureSMTPClient as subclasses of existing implementations of POP3 and SMTP respectively. As far as I know, there is no IMAP client in the image, yet. Zodiac only adds the 'secure' part, not the implementation proper. It would be nice to have IMAP client/server support though ;-) Sven

Feb. 3, 2014

Zodiac and IMAP

by Torsten Bergmann

Hi Sven, while there is support for SMTP and POP3 in Zodiac I wonder about IMAP protocol support. Thx T.

Feb. 3, 2014