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

[Pharo-project] How do I install seaside in Pharo 1.0?

by Torsten Bergmann

When you use the script you will always load the "latestVersion" which is now (since time went on) a higher number for Seaside then at the times of Pharo 1.0 and is now surely intended for the newer Pharo 1.1. You can try one of the older versions by loading a specific version instead of the latest: ((Smalltalk at: #ConfigurationOfSeaside ) project version: '...') load You can also use one of the prebuilt images from: http://seaside.st/download/pharo Bye T. -- GRATIS fÃ¼r alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01

May 31, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

On May 31, 2010, at 12:29 PM, Nicolas Cellier wrote: > Oh, and I see one more advantage: Only quick tests are run > interactively by default from your TestRunner. > We could automate the separation between long tests and quick tests > based on timeout if the information is discoverable (either in method > annotations or class side query, I don't care). but do we have to tag that with a timeout. jorge already sorted tests as unit = fast and integration = slow. In interactive mode we could only run the fast one. I think that we have already a lot and we do not use it enough. So we will learn and see. Stef

May 31, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

>> >> > > In other words, the timeout has the advantage to turn a rather > implicit requirement into an explicit requirement. > And it's then up to test producers to fine tune their tests wrt this > requirement or use the available hooks in case of long tests, rather > than letting the integrator guess. yes now for that we can probably use "We already have #should:notTakeMoreThan: and friends in TestCase. The complete TestCase can be protected by overriding #runCase, the individual test by wrapping the code of the test method. "

May 31, 2010

Re: [Pharo-project] SUnit Time out

by StÃ©phane Ducasse

ok tx Now may be the test runner should be adapted. We will see. Now I just remove the items from the urgent list and if the need emerges we know that this is there. Stef On May 31, 2010, at 12:10 PM, Nicolas Cellier wrote: > 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On May 30, 2010, at 8:52 PM, Chris Muller wrote: >> >>> (Copying squeak-dev too). >>> >>> I'm not sold on the whole test timeout thing. When I run tests, I >>> want to know the answer to the question, "is the software working?" >>> >>> Putting a timeout on tests trades a slower, but definitive, "yes" or >>> "no" for a supposedly-faster "maybe". But is getting a "maybe" back >>> really faster? I've just incurred the cost of running a test suite, >>> but left without my answer. I get a "maybe", what am I supposed to do >>> next? Find a faster machine? Hack into the code to fiddle with a >>> timeout pragma? That's not faster.. >> >> Thanks this is a really good point. >> >>> But, the reason given for the change was not for running tests >>> interactively (the 99% case), rather, all tests form the beginning of >>> time are now saddled with a timeout for the 1% case: >>> >>> "The purpose of the timeout is to catch issues like infinite loops, >>> unexpected user input etc. in automated test environments." >>> >>> If tests are supposed to be quick (and deterministic) anyway, wouldn't >>> an infinite loop or user-input be caught the first time the test was >>> run (interactively)? Seriously, when you make software changes, we >>> run the tests interactively first, and then the purpose of night-time >>> automated test environment is to catch regressions on the merged >>> code.. >> >> Yes this is what I was also implying in my previous mail. >> If we have a test server this does not really help to have a time out >> and I wonder the case of infinite loop because this may be really rare. >> > > My opinion differs here. Every test should run in a short time frame > but a few exceptions. So it seems reasonnable to just have to specify > a default timeout on your architecture and some specific timeouts for > a few specific tests (or test classes). > > Your main argument is that manual tuning will always be better than > automated default behaviour, and we can only agree on that one. > > But there are two pragmatic cases you don't take into account: > - the case when community supplied test cases do not comply with these > rather implicit requirements, and image integrator does not have time > to dig into each case and do the fine tuning for the rest of > community. > - the case when automated tests are used for exploratory package testing. > > In the first case, integrator just put a threshold that will reject > some tests, up to rest of community to inject more time in solving the > problem. > > Maybe Andreas was also addressing case of network-in-the-loop tests. > Thus it can be seen as a quick hack for by-passing the low level > timeout and number of retries (which are not always accessible that > easily in some APIs...). > > Concerning infinite loops occurence, some are produced by uncompatible > packages. So when you automate compatible package exploration, it > might help because I doubt you will have explored each case > interactively. Of course, you can always put a timeout at upper level > in your bash or something, but it would not be particularly fine > grained, would it ? > > One typical case I often bump into is those classes defining printOn: > by sending storeOn: et vice et versa, same for printString and > printOn:. If core happens to change between two releases, and you have > a subclass defined in your package, probability to run into one of > these infinite loops increases. > > Nicolas > >>> In that case, the high-level test-controller which spits out the >>> results could and should be responsible for handling "unexpected user >>> input" and/or putting in a timeout, not each and every last test >>> method.. >>> >>> IMO, we want short tests, so let's just write them to be short. If >>> they're too long, then the encouragement to shorten them comes from >>> our own impatience of running them interactively. Running them in >>> batch at night requires no patience, because we're sleeping, and >>> besides, the batch processor should take responsibility for handling >>> those rare scenarios at a higher-level.. >> >> I agree. >> Thanks for sharing your thoughts. >> So the issue is done. :) >> >> >>> >>> Regards, >>> Chris >>> >>> >>> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> Hi guys >>>> >>>> in Squeak andreas introduced the idea of test time out >>>> Do you think that this is interesting? >>>> >>>> Stef >>>> >>>> SUnit >>>> ----- >>>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>>> _______________________________________________ >>>> 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

May 31, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

Oh, and I see one more advantage: Only quick tests are run interactively by default from your TestRunner. We could automate the separation between long tests and quick tests based on timeout if the information is discoverable (either in method annotations or class side query, I don't care). Of course, as a user I would be interested to distinguish failures errors and timeouts, so I would want the user interface to change. Nicolas 2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: >> 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On May 30, 2010, at 8:52 PM, Chris Muller wrote: >>> >>>> (Copying squeak-dev too). >>>> >>>> I'm not sold on the whole test timeout thing. Â When I run tests, I >>>> want to know the answer to the question, "is the software working?" >>>> >>>> Putting a timeout on tests trades a slower, but definitive, "yes" or >>>> "no" for a supposedly-faster "maybe". Â But is getting a "maybe" back >>>> really faster? Â I've just incurred the cost of running a test suite, >>>> but left without my answer. Â I get a "maybe", what am I supposed to do >>>> next? Â Find a faster machine? Â Hack into the code to fiddle with a >>>> timeout pragma? Â That's not faster.. >>> >>> Thanks this is a really good point. >>> >>>> But, the reason given for the change was not for running tests >>>> interactively (the 99% case), rather, all tests form the beginning of >>>> time are now saddled with a timeout for the 1% case: >>>> >>>> Â "The purpose of the timeout is to catch issues like infinite loops, >>>> unexpected user input etc. in automated test environments." >>>> >>>> If tests are supposed to be quick (and deterministic) anyway, wouldn't >>>> an infinite loop or user-input be caught the first time the test was >>>> run (interactively)? Â Seriously, when you make software changes, we >>>> run the tests interactively first, and then the purpose of night-time >>>> automated test environment is to catch regressions on the merged >>>> code.. >>> >>> Yes this is what I was also implying in my previous mail. >>> If we have a test server this does not really help to have a time out >>> and I wonder the case of infinite loop because this may be really rare. >>> >> >> My opinion differs here. Every test should run in a short time frame >> but a few exceptions. So it seems reasonnable to just have to specify >> a default timeout on your architecture and some specific timeouts for >> a few specific tests (or test classes). >> >> Your main argument is that manual tuning will always be better than >> automated default behaviour, and we can only agree on that one. >> >> But there are two pragmatic cases you don't take into account: >> - the case when community supplied test cases do not comply with these >> rather implicit requirements, and image integrator does not have time >> to dig into each case and do the fine tuning for the rest of >> community. >> - the case when automated tests are used for exploratory package testing. >> >> In the first case, integrator just put a threshold that will reject >> some tests, up to rest of community to inject more time in solving the >> problem. >> > > In other words, the timeout has the advantage to turn a rather > implicit requirement into an explicit requirement. > And it's then up to test producers to fine tune their tests wrt this > requirement or use the available hooks in case of long tests, rather > than letting the integrator guess. > > Nicolas > >> Maybe Andreas was also addressing case of network-in-the-loop tests. >> Thus it can be seen as a quick hack for by-passing the low level >> timeout and number of retries (which are not always accessible that >> easily in some APIs...). >> >> Concerning infinite loops occurence, some are produced by uncompatible >> packages. So when you automate compatible package exploration, it >> might help because I doubt you will have explored each case >> interactively. Of course, you can always put a timeout at upper level >> in your bash or something, but it would not be particularly fine >> grained, would it ? >> >> One typical case I often bump into is those classes defining printOn: >> by sending storeOn: et vice et versa, same for printString and >> printOn:. If core happens to change between two releases, and you have >> a subclass defined in your package, probability to run into one of >> these infinite loops increases. >> >> Nicolas >> >>>> In that case, the high-level test-controller which spits out the >>>> results could and should be responsible for handling "unexpected user >>>> input" and/or putting in a timeout, not each and every last test >>>> method.. >>>> >>>> IMO, we want short tests, so let's just write them to be short. Â If >>>> they're too long, then the encouragement to shorten them comes from >>>> our own impatience of running them interactively. Â Running them in >>>> batch at night requires no patience, because we're sleeping, and >>>> besides, the batch processor should take responsibility for handling >>>> those rare scenarios at a higher-level.. >>> >>> I agree. >>> Thanks for sharing your thoughts. >>> So the issue is done. :) >>> >>> >>>> >>>> Regards, >>>> Â Chris >>>> >>>> >>>> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >>>> <stephane.ducasse(a)free.fr> wrote: >>>>> Hi guys >>>>> >>>>> in Squeak andreas introduced the idea of test time out >>>>> Do you think that this is interesting? >>>>> >>>>> Stef >>>>> >>>>> SUnit >>>>> ----- >>>>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>>>> _______________________________________________ >>>>> 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 >>> >> >

May 31, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

2010/5/31 Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com>: > 2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >> On May 30, 2010, at 8:52 PM, Chris Muller wrote: >> >>> (Copying squeak-dev too). >>> >>> I'm not sold on the whole test timeout thing. Â When I run tests, I >>> want to know the answer to the question, "is the software working?" >>> >>> Putting a timeout on tests trades a slower, but definitive, "yes" or >>> "no" for a supposedly-faster "maybe". Â But is getting a "maybe" back >>> really faster? Â I've just incurred the cost of running a test suite, >>> but left without my answer. Â I get a "maybe", what am I supposed to do >>> next? Â Find a faster machine? Â Hack into the code to fiddle with a >>> timeout pragma? Â That's not faster.. >> >> Thanks this is a really good point. >> >>> But, the reason given for the change was not for running tests >>> interactively (the 99% case), rather, all tests form the beginning of >>> time are now saddled with a timeout for the 1% case: >>> >>> Â "The purpose of the timeout is to catch issues like infinite loops, >>> unexpected user input etc. in automated test environments." >>> >>> If tests are supposed to be quick (and deterministic) anyway, wouldn't >>> an infinite loop or user-input be caught the first time the test was >>> run (interactively)? Â Seriously, when you make software changes, we >>> run the tests interactively first, and then the purpose of night-time >>> automated test environment is to catch regressions on the merged >>> code.. >> >> Yes this is what I was also implying in my previous mail. >> If we have a test server this does not really help to have a time out >> and I wonder the case of infinite loop because this may be really rare. >> > > My opinion differs here. Every test should run in a short time frame > but a few exceptions. So it seems reasonnable to just have to specify > a default timeout on your architecture and some specific timeouts for > a few specific tests (or test classes). > > Your main argument is that manual tuning will always be better than > automated default behaviour, and we can only agree on that one. > > But there are two pragmatic cases you don't take into account: > - the case when community supplied test cases do not comply with these > rather implicit requirements, and image integrator does not have time > to dig into each case and do the fine tuning for the rest of > community. > - the case when automated tests are used for exploratory package testing. > > In the first case, integrator just put a threshold that will reject > some tests, up to rest of community to inject more time in solving the > problem. > In other words, the timeout has the advantage to turn a rather implicit requirement into an explicit requirement. And it's then up to test producers to fine tune their tests wrt this requirement or use the available hooks in case of long tests, rather than letting the integrator guess. Nicolas > Maybe Andreas was also addressing case of network-in-the-loop tests. > Thus it can be seen as a quick hack for by-passing the low level > timeout and number of retries (which are not always accessible that > easily in some APIs...). > > Concerning infinite loops occurence, some are produced by uncompatible > packages. So when you automate compatible package exploration, it > might help because I doubt you will have explored each case > interactively. Of course, you can always put a timeout at upper level > in your bash or something, but it would not be particularly fine > grained, would it ? > > One typical case I often bump into is those classes defining printOn: > by sending storeOn: et vice et versa, same for printString and > printOn:. If core happens to change between two releases, and you have > a subclass defined in your package, probability to run into one of > these infinite loops increases. > > Nicolas > >>> In that case, the high-level test-controller which spits out the >>> results could and should be responsible for handling "unexpected user >>> input" and/or putting in a timeout, not each and every last test >>> method.. >>> >>> IMO, we want short tests, so let's just write them to be short. Â If >>> they're too long, then the encouragement to shorten them comes from >>> our own impatience of running them interactively. Â Running them in >>> batch at night requires no patience, because we're sleeping, and >>> besides, the batch processor should take responsibility for handling >>> those rare scenarios at a higher-level.. >> >> I agree. >> Thanks for sharing your thoughts. >> So the issue is done. :) >> >> >>> >>> Regards, >>> Â Chris >>> >>> >>> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >>> <stephane.ducasse(a)free.fr> wrote: >>>> Hi guys >>>> >>>> in Squeak andreas introduced the idea of test time out >>>> Do you think that this is interesting? >>>> >>>> Stef >>>> >>>> SUnit >>>> ----- >>>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>>> _______________________________________________ >>>> 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 >> >

May 31, 2010

Re: [Pharo-project] SUnit Time out

by Nicolas Cellier

2010/5/30 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > > On May 30, 2010, at 8:52 PM, Chris Muller wrote: > >> (Copying squeak-dev too). >> >> I'm not sold on the whole test timeout thing. Â When I run tests, I >> want to know the answer to the question, "is the software working?" >> >> Putting a timeout on tests trades a slower, but definitive, "yes" or >> "no" for a supposedly-faster "maybe". Â But is getting a "maybe" back >> really faster? Â I've just incurred the cost of running a test suite, >> but left without my answer. Â I get a "maybe", what am I supposed to do >> next? Â Find a faster machine? Â Hack into the code to fiddle with a >> timeout pragma? Â That's not faster.. > > Thanks this is a really good point. > >> But, the reason given for the change was not for running tests >> interactively (the 99% case), rather, all tests form the beginning of >> time are now saddled with a timeout for the 1% case: >> >> Â "The purpose of the timeout is to catch issues like infinite loops, >> unexpected user input etc. in automated test environments." >> >> If tests are supposed to be quick (and deterministic) anyway, wouldn't >> an infinite loop or user-input be caught the first time the test was >> run (interactively)? Â Seriously, when you make software changes, we >> run the tests interactively first, and then the purpose of night-time >> automated test environment is to catch regressions on the merged >> code.. > > Yes this is what I was also implying in my previous mail. > If we have a test server this does not really help to have a time out > and I wonder the case of infinite loop because this may be really rare. > My opinion differs here. Every test should run in a short time frame but a few exceptions. So it seems reasonnable to just have to specify a default timeout on your architecture and some specific timeouts for a few specific tests (or test classes). Your main argument is that manual tuning will always be better than automated default behaviour, and we can only agree on that one. But there are two pragmatic cases you don't take into account: - the case when community supplied test cases do not comply with these rather implicit requirements, and image integrator does not have time to dig into each case and do the fine tuning for the rest of community. - the case when automated tests are used for exploratory package testing. In the first case, integrator just put a threshold that will reject some tests, up to rest of community to inject more time in solving the problem. Maybe Andreas was also addressing case of network-in-the-loop tests. Thus it can be seen as a quick hack for by-passing the low level timeout and number of retries (which are not always accessible that easily in some APIs...). Concerning infinite loops occurence, some are produced by uncompatible packages. So when you automate compatible package exploration, it might help because I doubt you will have explored each case interactively. Of course, you can always put a timeout at upper level in your bash or something, but it would not be particularly fine grained, would it ? One typical case I often bump into is those classes defining printOn: by sending storeOn: et vice et versa, same for printString and printOn:. If core happens to change between two releases, and you have a subclass defined in your package, probability to run into one of these infinite loops increases. Nicolas >> In that case, the high-level test-controller which spits out the >> results could and should be responsible for handling "unexpected user >> input" and/or putting in a timeout, not each and every last test >> method.. >> >> IMO, we want short tests, so let's just write them to be short. Â If >> they're too long, then the encouragement to shorten them comes from >> our own impatience of running them interactively. Â Running them in >> batch at night requires no patience, because we're sleeping, and >> besides, the batch processor should take responsibility for handling >> those rare scenarios at a higher-level.. > > I agree. > Thanks for sharing your thoughts. > So the issue is done. :) > > >> >> Regards, >> Â Chris >> >> >> On Sat, May 29, 2010 at 2:53 AM, stephane ducasse >> <stephane.ducasse(a)free.fr> wrote: >>> Hi guys >>> >>> in Squeak andreas introduced the idea of test time out >>> Do you think that this is interesting? >>> >>> Stef >>> >>> SUnit >>> ----- >>> All test cases now have an associated timeout after which the test is considered failed. The purpose of the timeout is to catch issues like infinite loops, unexpected user input etc. in automated test environments. Timeouts can be set on an individual test basis using the <timeout: seconds> tag or for an entire test case by implementing the #defaultTimeout method. >>> _______________________________________________ >>> 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 >

May 31, 2010

[Pharo-project] [update 1.1] #11381

by StÃ©phane Ducasse

11381 ----- - Issue 2491: Rewrite Author prompt text similar to PharoCore 1.0. Thanks Miguel. - Issue 2492: choose default browser should be a setting. Thanks Alain - Issue 2475: StringTest#testUnCategorizedMethods fails. Thanks laurent Stef

May 31, 2010

Re: [Pharo-project] Recompile all in ImageForDevelopers ?

by StÃ©phane Ducasse

I think that what would be good is indeed that we check that systematically so that we finally identify the changes problem. Now did you check if the changes are modified? Apparently not. Stef On May 31, 2010, at 10:47 AM, Mariano Martinez Peck wrote: > Hi folks. The official Pharo 1.0 has a little bug that you can see here: > > http://code.google.com/p/pharo/issues/detail?id=2341 > > In order to avoid such problems, I though about evaluating "Compiler recompileAll" during the ImageForDeveloper >> install method > With this, when I or you are using ConfigurationOfPharo to build a Dev image, you will automatically realize there is a problem. > > What do you think? > > Cheers > > Mariano > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 31, 2010

Re: [Pharo-project] Trip to Pharo land

by Adrian Lienhard

Thanks for the suggestions, GÃ¶ran. I've updated the frontpage of the website. Adrian On May 31, 2010, at 00:02 , GÃ¶ran Krampe wrote: > Hi! > > On 05/30/2010 11:17 PM, StÃ©phane Ducasse wrote: >>> Hi! >>> >>> So much discussion about that little post... :) >>> >>> On 05/30/2010 10:10 PM, StÃ©phane Ducasse wrote: >>>> Yes but in that case >>>> try 1.0 >>>> try 1.1 alpha >>> >>> Hmmm, Stephane still likes to top post I notice :) >> >> I do not know what you are implying. > > Eh, "top posting". See this: > > http://en.wikipedia.org/wiki/Posting_style > > So it was not an implication of anything, I just joked a little. > > ...but I see in this post that you are interleaving instead :) > >> But I think that we are trying to building a process for pharo >> so this discussion is only about that: what are the expectations of people and what can we deliver >> and if all these stuff make sense. >> Conclusion >> - we can only retrofit showstoppers fixes >> - even good documentation of changes may not make people not failed but we can try something simple. >> - short release cycles is a must and we are doing it now. > > Yeah, I am all with you. > > Just wondering if... well, I chose 1.0 since it is clearly what the website "wants me to do" so to speak. And 1.1 is mentioned as "bleeding edge" etc. > > But if you think I will have a smoother ride in 1.1, then perhaps the site should somehow indicate that. But again, I really don't know if that is a good idea. > >>> Anyway, Igor nailed it pretty good with his post actually - I was merely documenting "what I was trying to do and ended up doing". >>> >>> And one thing to note is that I should have tried 1.1. But... why didn't I? >>> > >> I really (stupid I know, but hey...) didn't think it was to be considered "outdated" already :) >> >> Yes it really is. >> Get the feel with 1.1. It is ***really*** better. > > Then perhaps you *should* write that on the website somehow. Like: > > "Even though 1.1 is still in alpha development we feel it is even in its current state a much better environment than 1.0 for development. But it is of course not yet a stable baseline." > > Also, if you only backport showstoppers (and not "bugs") then 1.0 is as of today not even preferrable from a stability standpoint, or? > > regards, GÃ¶ran > > PS. I am really trying to be constructive here, these problems are generic in nature and Squeak.org suffer from the exact same issues of course - devel vs stable etc. Just curious how Pharo should "talk to newcomers" about it. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 31, 2010