January 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by Adrian Lienhard

On Jan 9, 2010, at 22:32 , Mariano Martinez Peck wrote: > Thanks Benoit for the report and taking the time to run all the > tests. I > already knew that there are a lot failing tests. Unfortunately, > there is not > too much I can do: > > 1) Maintainers of packages with failures can tell me if they are > failing for > "my fault". I mean, because I don't load a dependency or something > like > that. And if this is the case, I can fix that. > > 2) I can remove all the packages that have failing tests -> I think > we will > load very few packages. > > 3) We should ask maintainers to fix them. Of course, there are > packages that > even don't have maintainers. > > thoughts about this ? Some time ago I individually talked with each maintainer and eventually we managed to get all tests pass. That was with the previous build of the Pharo image that Damien did. Now, I don't know which additional tests you have loaded (?) but either these need to be fixed or we should not load them. We want all tests to be green for the release. Cheers, Adrian

Jan. 10, 2010

Re: [Pharo-project] rss code.google problem

by Lukas Renggli

It is a known bug in Google Code: <http://code.google.com/p/support/issues/detail?id=3475> I have the same issue with all my issue feeds. The links on the Seaside website are broken too. Lukas 2010/1/9 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Hi > > I was used to read the updates of the issue using the rss stream of code.google..... > Now when I click on the Read more link about the Â issue in my rss reader I get > http://code.google.com/None/None/issues/detail?id=1765 > which means that I cannot go there... > > do you have the same behavior? > > Stef > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 10, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by StÃ©phane Ducasse

did one of you had a look at the enh proposed by adrian K because they looks interesting. I got no time to go the next step (removing the loading error). Stef On Jan 10, 2010, at 9:49 AM, Lukas Renggli wrote: >>> Ok, grab it with: >>> >>> git clone git://github.com/renggli/builder.git >> >> I've updated the project description for the Hudson Build project on >> squeaksource.com to point at this git repository, for the scripts. Also, >> I've added you as a developer. Anyone else wanting to be added, please >> ask. The code base is really tiny. The feature I like to see added is to >> report the time taken to run each test, but that requires support from >> SUnit. > > Hi Yanni > > Thank you for adding me to the repository. I will commit my changes to > the HudsonBuildTools there, if this is ok with you? > > I've made some significant changes: > > - added methods to run all tests of a package > - make the distinction between error and failure > - measure the time it took to run a test > - display the exception and stack trace of a failing test > - encode all XML values properly (I had some problems with the stacks) > > You can see some failing tests here: > > http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testRepor… > > I couldn't really find any documentation on this JUnit XML thing, I > just filled the empty parts in your code. > > Lukas > > > > > I couldn't commit my changes to the HudsonBuildTools, because I had no > write rights. I've uploaded the changed runner now. > > > >> >> -- >> Yanni >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] TestRunner author while running tests

by StÃ©phane Ducasse

ok http://code.google.com/p/pharo/issues/list?thanks=1769 On Jan 10, 2010, at 9:40 AM, Lukas Renggli wrote: > Looks like the code of Adrian Lienhard ;-) > > I guess that it tries to fix tests so that they do not pup-up a dialog > when they compile code. > > Initially the code in SUnit was like this: > > TestCase>>runCase > [self setUp. > self performTest] > ensure: [ > self tearDown. > self cleanUpInstanceVariables ] ] > > Then it was change to this (this is where I discovered the issue): > > TestCase>>runCase > Author > useAuthor: 'TestRunner' > during: [ > [self setUp. > self performTest] > ensure: [ > self tearDown. > self cleanUpInstanceVariables ] ] > > In the latest version it was changed again: > > TestCase>>runCase > Author > ifUnknownAuthorUse: 'TestRunner' > during: [ > [self setUp. > self performTest] > ensure: [ > self tearDown. > self cleanUpInstanceVariables ] ] > > In any case the author name is 'TestRunner' if you edit source code > anywhere in the system when a debugger on a test is open. Also I am > not sure what happens if you have multiple debuggers on tests open, > that might give very strange situations. > > I suggest that we revert to the earliest presented version of the > method in question, and fix the particular tests that compile code. > > Lukas > > -- > Lukas Renggli > http://www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] [ANN] Hudson continuous integration server support

by Lukas Renggli

>> Ok, grab it with: >> >> Â Â git clone git://github.com/renggli/builder.git > > I've updated the project description for the Hudson Build project on > squeaksource.com to point at this git repository, for the scripts. Also, > I've added you as a developer. Anyone else wanting to be added, please > ask. The code base is really tiny. The feature I like to see added is to > report the time taken to run each test, but that requires support from > SUnit. Hi Yanni Thank you for adding me to the repository. I will commit my changes to the HudsonBuildTools there, if this is ok with you? I've made some significant changes: - added methods to run all tests of a package - make the distinction between error and failure - measure the time it took to run a test - display the exception and stack trace of a failing test - encode all XML values properly (I had some problems with the stacks) You can see some failing tests here: http://hudson.lukas-renggli.ch/job/Development/lastCompletedBuild/testRepor… I couldn't really find any documentation on this JUnit XML thing, I just filled the empty parts in your code. Lukas I couldn't commit my changes to the HudsonBuildTools, because I had no write rights. I've uploaded the changed runner now. > > -- > Yanni > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 10, 2010

Re: [Pharo-project] TestRunner author while running tests

by Lukas Renggli

Looks like the code of Adrian Lienhard ;-) I guess that it tries to fix tests so that they do not pup-up a dialog when they compile code. Initially the code in SUnit was like this: TestCase>>runCase [self setUp. self performTest] ensure: [ self tearDown. self cleanUpInstanceVariables ] ] Then it was change to this (this is where I discovered the issue): TestCase>>runCase Author useAuthor: 'TestRunner' during: [ [self setUp. self performTest] ensure: [ self tearDown. self cleanUpInstanceVariables ] ] In the latest version it was changed again: TestCase>>runCase Author ifUnknownAuthorUse: 'TestRunner' during: [ [self setUp. self performTest] ensure: [ self tearDown. self cleanUpInstanceVariables ] ] In any case the author name is 'TestRunner' if you edit source code anywhere in the system when a debugger on a test is open. Also I am not sure what happens if you have multiple debuggers on tests open, that might give very strange situations. I suggest that we revert to the earliest presented version of the method in question, and fix the particular tests that compile code. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by StÃ©phane Ducasse

+1 > Whatever you guys want, so long as it indeed works. With the explicit version, ConfigurationOfSeaside28 seems to do the trick. I suggest adding a link to the downloads page with code for FFI and Seaside for starters. > > Another idea would be to add class methods to Gofer that use Metacello. The existing #seaside28 should be rewritten or removed. > > Bill >

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by StÃ©phane Ducasse

this raises the interesting question of headless build testing in presence of popup. So we should have a way to control them from metacello ? On Jan 10, 2010, at 1:52 AM, Mariano Martinez Peck wrote: > > > 2010/1/10 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > That does work. > > You see ? It was a matter of the version, no more than that. Now you have your PharoWeb image :) > > > As with the Loader solution, it prompts for the user name and password; other solutions available trap those and provide reasonable defaults, which is nice for automated builds. > > Yes true. However, maybe other people rather to put a real username and password. I think this is more flexible. > It would be cool to hear opinions. > > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck > Sent: Saturday, January 09, 2010 7:34 PM > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 > > > > 2010/1/10 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> > Mariano, > > Whether it makes sense or not, try it yourself. Either Loader is more than you think it is, or it does something that is critical to allowing Metacello to succeed. > > > Can you try this and tell me if it works: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfSeaside28'; > load. > > ((Smalltalk at: #ConfigurationOfSeaside28) project version: '2.8.4.2') load > > > Bill > > > > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Mariano Martinez Peck > Sent: Saturday, January 09, 2010 6:37 PM > > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1 > > > > 2010/1/10 Miguel Enrique CobÃ¡ Martinez <miguel.coba(a)gmail.com> > El dom, 10-01-2010 a las 00:08 +0100, Matthias Berth escribiÃ³: > > Hi Bill, > > > > this one works for me with the current pharo core 1.0 rc1, update upto 10505 > > > > "execute this:" > > Gofer new > > squeaksource: 'Loader'; > > package: 'Loader'; > > load. > > "then this" > > Loader new load: 'Pharo' version: '1.0-rc2.10505'. > > "then this" > > Loader new > > load: 'Seaside28' version: '2.8.4.2' > > > > The "Loader new load: 'Pharo' version: '1.0-rc2.10505'." loads a lot > > of additional pharo packages. I guess you won't need that just to get > > seaside working. > > > > But isn't the loader alpha yet? > > Maybe even before. Hoever, it does not make sense. Loader is just a simplifier API to metacello. If Loader works with Seaside2.8, ConfigurationOfSeaside28 MUST work too. > > > I mean, I am really expecting for Esteban to release it because is more > concise to write commands, but the issue here is the testing of the 1.0 > release of pharo with the current available/stable tools, that is, > monticello, gofer and metacello. > > > Yes, please. Let's try to use this tools first. When we are stable enough we start with another ones. > > Cheers > > Mariano > > Cheers > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by StÃ©phane Ducasse

>> > > As I understand it, ScriptLoader will be deprecated and removed from > images with the advent of Gofer/Metacello. Yes may be not tomorrow because we have a lot of nice=ugly behavior but yes this is the idea. > Loader is a way to access Gofer/Metacello in a less verbose way. As > stated before, isn't even beta, so don't use it for real apps, unless > you're helping Esteban with feedback. > > So, for pharo the way to go is Gofer and Metacello at least for release > 1.0. Yes Especially since I would like to see if conceptually Loader is not just a special subclass of Gofer GoferConfigLoader to shirnk the vocabulary

Jan. 10, 2010

Re: [Pharo-project] [BetaTesting] [ANN] Pharo1.0-10505-rc1dev10.01.1

by StÃ©phane Ducasse

> > > Respect to this list, and maybe this should be a ticket. Shouldn't be > better to have an established message to cleanup the image on release. > Something like the cleanUpForImageRelease but generalized and then, the > classes that need to do something like this, they implement that > message. > > So on release a new image version you only call something like > > Smalltalk cleanUpForImageRelease. > > > It is already in ScriptLoader >> cleanUpForRelease miguel proposes modular cleanUpForRelease solution. Keith in kernel extensions propose that and we should have a look at what he did I remember reading his code and making a report on the wiki.

Jan. 10, 2010