December 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] External projects

by StÃ©phane Ducasse

> Stef, > > An easy one is to try: > > ScriptLoader > loadLatestPackage:'OSProcess' fromSqueaksource:'OSProcess'; > loadLatestPackage:'Tests-OSProcess' fromSqueaksource:'OSProcess'; > loadLatestPackage:'CommandShell' fromSqueaksource:'CommandShell'. in which version are you loading them? dev-rc1? I suggest you to publish a metacello configuration and also contact david lewis. May be the lastest version is not the one to be loaded. What I do in my code is that I never load the latest versions this way I control other changes when I'm ready to migrate. > For the full effect, leave deprecation warnings activated; even with these warnings disabled, you should be stopped after just enough time to really whack up an automated load. > > > Citezen turns out to be more interesting. The Wiki says to evaluate > > Installer ss project: 'Citezen'; install: 'Citezen-Loader'. > > 12.2 is missing Installer, which is no doubt in the name of progress. A quick look at Gofer lead me to try > > Gofer new > squeaksource:'Citezen'; > package:'Citezen-Loader'; > load. I should fix the citezen loader.... > > This installs Installer :) Now have a look at #newForWin32; note that it answers RioLocalDosExecutive, not RioLocalDosExecutive new. The last time I tried such an image, I could not get it to load on Windows until I loaded it on another platform, added the #new, and then reloaded it. The poor folks stuck with Windows have enough to worry about ;) > > I realize this is not Pharo's fault, but it is Pharo's problem, and hence **our** problem (aka Error 33). > > Bill > > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] > Sent: Monday, December 28, 2009 9:57 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] External projects > > I think that we should have a group of people controling integration. > > Stef > > >> Hello all, >> >> I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode. >> >> When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows. > > apparently this is not pharo's fault. > >> OS Process did not load cleanly. > > Bill what we are trying to with metacello is to have configuration of working packages. > >> Do we have a plan to fix such things? There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work. > > Yes > > Now can you report your problem is a way that we can reproduce them? > >> At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo. PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki?? In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users. >> >> Bill >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Lukas Renggli

>> There are more related to the packages we are including? > > No. Only the core bits of OB are tested. There aren't any tests for the refactoring code or Shout. The refactoring code is quite well tested with the tests of the refactoring engine. The thing that is not tested is the RB integration in OB: hounders of new commands and a couple of extra browsers. I am sorry, I was too lazy to write these tests. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Colin Putney

On 2009-12-28, at 10:09 AM, Mariano Martinez Peck wrote: > Hi Colin! I saw you were committing in the OmniBrowser tests. I am interested in loading these tests in Pharo (optionally). But I am not sure which packages to include and their state. > > Right now, in our Pharo images we are loading the following packages from http://source.wiresong.ca/ob > > package: 'OmniBrowser'; > package: 'OB-Morphic'; > package: 'OB-Standard'; > package: 'OB-Refactory'; > package: 'OB-Regex'; > package: 'OB-SUnitIntegration'; > package: 'OB-Shout'; Looks good. > I saw the following tests packages: > > OB-Tests-Core > OB-Tests-Morphic > OB-Tests-Standard Also good. > There are more related to the packages we are including? No. Only the core bits of OB are tested. There aren't any tests for the refactoring code or Shout. > should these test be all green? Yes. There might be platform issues, especially around Morphic, but aside from that, there should be no failures. Colin

Dec. 28, 2009

Re: [Pharo-project] Tests of OmniBrowser

by Lukas Renggli

2009/12/28 Mariano Martinez Peck <marianopeck(a)gmail.com>: > Hi Colin!Â I saw you were committing in the OmniBrowser tests. I am > interested in loading these tests in Pharo (optionally). But I am not sure > which packages to include and their state. I spent quite some time to fix all Pharo related bugs in OB. Also I fixed all the tests that were broken in Pharo (only if O2 is not loaded): 546 run, 546 passes, 0 failures, 0 errors > Right now, in our Pharo images we are loading the following packages from > http://source.wiresong.ca/ob AFAIK, the updated code from http://source.lukas-renggli.ch/omnibrowser hasn't been merged into the repository of Colin yet. I assume that will happen sometime soon. > There are more related to the packages we are including? See OB-Umbrella, this loads all code in the right order. > should these test be all green? Definitely. OB has an excellent test suite. The only problem in the past was that nobody that changed things run and updated these tests. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Dec. 28, 2009

Re: [Pharo-project] External projects

by Schwab,Wilhelm K

Stef, An easy one is to try: ScriptLoader loadLatestPackage:'OSProcess' fromSqueaksource:'OSProcess'; loadLatestPackage:'Tests-OSProcess' fromSqueaksource:'OSProcess'; loadLatestPackage:'CommandShell' fromSqueaksource:'CommandShell'. For the full effect, leave deprecation warnings activated; even with these warnings disabled, you should be stopped after just enough time to really whack up an automated load. Citezen turns out to be more interesting. The Wiki says to evaluate Installer ss project: 'Citezen'; install: 'Citezen-Loader'. 12.2 is missing Installer, which is no doubt in the name of progress. A quick look at Gofer lead me to try Gofer new squeaksource:'Citezen'; package:'Citezen-Loader'; load. This installs Installer :) Now have a look at #newForWin32; note that it answers RioLocalDosExecutive, not RioLocalDosExecutive new. The last time I tried such an image, I could not get it to load on Windows until I loaded it on another platform, added the #new, and then reloaded it. The poor folks stuck with Windows have enough to worry about ;) I realize this is not Pharo's fault, but it is Pharo's problem, and hence **our** problem (aka Error 33). Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr] Sent: Monday, December 28, 2009 9:57 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] External projects I think that we should have a group of people controling integration. Stef > Hello all, > > I just noticed that the December web image (12.2) cannot open context menus for want of #isMethodNode and #isClassNode. > > When I last built an image, Citezen's installation was pointing to what I am told is an old copy of RIO which is broken on Windows. apparently this is not pharo's fault. > OS Process did not load cleanly. Bill what we are trying to with metacello is to have configuration of working packages. > Do we have a plan to fix such things? There is an obvious tradeoff between using the external code in its ideally up-to-date state and having something that is known to work. Yes Now can you report your problem is a way that we can reproduce them? > At a minimum, we might have a section on the Wiki dedicated to workarounds for loading packages with problems on Pharo. PackagesTestedInPharo is close; the Notes column might link to package-specific notes elsewhere on th wiki?? In some cases (e.g. the context menus), we should probably have needed methods added to each image as it is built to avoid giving a broken image to new users. > > Bill > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 7:29 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Mariano Martinez Peck <marianopeck@...> writes: > > > So, what I would do is to "fix" it but (I don't know) put is as > deprecated so > > that all the tests of the people are still green and give them time to > change > > it to expectedErrors or similar. After a second release you can remove > this > > fix :) What do you think? > > Yes, that is how I planned it ... and then you came with your dynamically > generated expectations. Which the new system does not support. > > It's an awesome idea, so I am thinking about a way to support dynamic > expectations in the new system. I have one solution in mind: given your > #expectedFailures, would the following work for you? > > testBlob > self assume: SqueakDatabaseAccessor DefaultDriver ~~ > SqueakDBXDriver. > ... > > which runs the test if and only if the default driver is not > SqueakDBXDriver. > This would have the same effect as your #expectedFailures implementation, > where you expected an error for that case. Like this your expectation is > put > closer to the code. > > Yes, this will work and will give me a benefit and a drawback :) Benefit: I can declare a expected failure only for a single test and not for all the tests of the class. Right now, I have situations like this and I a doing exactly that (more ugly actually), an if to see something and then a ^ self is it shouldn't be run. Drawback: Most of the times (in my case) the condition (SqueakDatabaseAccessor DefaultDriver ~~ SqueakDBXDrive) is always the same, so that's why it was easier as I did it. Here I should declare it in every test. However, this is VERYYYYYY little detail that I really don't care (I am not eve sure if this solution is better). I am bothering too much hahaha. Of course, I don't know what other people think about this but in my point of view, this is ok :) Cheers Mariano > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Mariano Martinez Peck

On Mon, Dec 28, 2009 at 7:01 PM, Adrian Kuhn <akuhn(a)iam.unibe.ch> wrote: > Alexandre Bergel <alexandre@...> writes: > > > > The stored history is compiled into a method on the class side. So you > get > > > the exact benefit of #expectedFailures/#expectedError. It is persistent > > > across source control and will mark your failures/errors as expected. > So > > > you dont need #expectedError at all. > > > > Yep, I know this, I pair programmed the history mechanism with Simon > > But I still do not understand how do you distinguish a method that > > always fails from an expectedFailure (i.e., a method that I know will > > fail, but I do not want it to make my unit test red)? > > If we need expectedFailure, we will probably need expectedError no? > > This is an aspect that I changed. An outcome is unexpected if and only if > it > does not match what is in the stored history. (For compatibility only > #expectedFailures are added to the stored history.) So the preferred way > to > mark an outcome as unexpected is to store the history. > > Try it > > - remove #expectedFailures > - run all your tests (you'll get failures and errors, -> not green) > - store the history > - run all your tests again (all your defects are expected, -> green) > > And just for demonstration > > - introduce a new defect > - run all your tests again (one unexpected defect, -> not green) > > Does this match your workflow? > The problem is if you have several others failing/error tests but that they are not expected :( Ok...I can run only the expected ones and store them, or don't run the error/failures ones and run them later > > --AA > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Mariano Martinez Peck <marianopeck@...> writes: > So, what I would do is to "fix" it but (I don't know) put is as deprecated so > that all the tests of the people are still green and give them time to change > it to expectedErrors or similar. After a second release you can remove this > fix :) What do you think? Yes, that is how I planned it ... and then you came with your dynamically generated expectations. Which the new system does not support. It's an awesome idea, so I am thinking about a way to support dynamic expectations in the new system. I have one solution in mind: given your #expectedFailures, would the following work for you? testBlob self assume: SqueakDatabaseAccessor DefaultDriver ~~ SqueakDBXDriver. ... which runs the test if and only if the default driver is not SqueakDBXDriver. This would have the same effect as your #expectedFailures implementation, where you expected an error for that case. Like this your expectation is put closer to the code. --AA

Dec. 28, 2009

[Pharo-project] Tests of OmniBrowser

by Mariano Martinez Peck

Hi Colin! I saw you were committing in the OmniBrowser tests. I am interested in loading these tests in Pharo (optionally). But I am not sure which packages to include and their state. Right now, in our Pharo images we are loading the following packages from http://source.wiresong.ca/ob package: 'OmniBrowser'; package: 'OB-Morphic'; package: 'OB-Standard'; package: 'OB-Refactory'; package: 'OB-Regex'; package: 'OB-SUnitIntegration'; package: 'OB-Shout'; I saw the following tests packages: OB-Tests-Core OB-Tests-Morphic OB-Tests-Standard There are more related to the packages we are including? should these test be all green? Thank you very much. Mariano

Dec. 28, 2009

Re: [Pharo-project] akuhn/SUnit, christmas edition :)

by Adrian Kuhn

Alexandre Bergel <alexandre@...> writes: > > The stored history is compiled into a method on the class side. So you get > > the exact benefit of #expectedFailures/#expectedError. It is persistent > > across source control and will mark your failures/errors as expected. So > > you dont need #expectedError at all. > > Yep, I know this, I pair programmed the history mechanism with Simon > But I still do not understand how do you distinguish a method that > always fails from an expectedFailure (i.e., a method that I know will > fail, but I do not want it to make my unit test red)? > If we need expectedFailure, we will probably need expectedError no? This is an aspect that I changed. An outcome is unexpected if and only if it does not match what is in the stored history. (For compatibility only #expectedFailures are added to the stored history.) So the preferred way to mark an outcome as unexpected is to store the history. Try it - remove #expectedFailures - run all your tests (you'll get failures and errors, -> not green) - store the history - run all your tests again (all your defects are expected, -> green) And just for demonstration - introduce a new defect - run all your tests again (one unexpected defect, -> not green) Does this match your workflow? --AA

Dec. 28, 2009