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

Re: [Pharo-project] Silly Tweet

by Igor Stasenko

On 30 June 2011 03:30, Yanni Chiu <yanni(a)rogers.com> wrote: > On 29/06/11 6:24 PM, Schwab,Wilhelm K wrote: >> >> +1 to Sig's answer. Â Old builds are great, and we should (and do) >> keep them around, but they do not need to be on the CI server. Â As >> Sig said, the old versions don't change, so CI gets pretty boring. > > There is the option to disable the build job, so that no further builds take > place (until there are maintenance releases to build). > > There is also the option to use the CI server as the build archive as well. > You can mark some build numbers as "never remove". Normally, only the last N > builds are kept, and the oldest is deleted after the new build completes > (unless that oldest build is the last successful build, then it's kept until > the next successful build). Whichever builds are marked "never remove" would > form the archive. That would eliminate the apparent confusion caused by > having the archive at https://gforge.inria.fr/frs/?group_id=1299 > > The other factor is that a transition to Jenkins from Hudson is happening, > which is driving the desire to drop the Hudson based 1.2 builds. > Another aspect of it, that build servers has a limited space (Marcus has to cut the number of builds , since they taking too much space). While on gforge we can afford to keep much more. Of course keeping latest 'frozen' build doesn't takes too much , except of a little nuisiance after a couple of years every time you open a jenkins, you will see a very long list of jobs, where only few of them actually needed. That's why i thinking that moving things to archive is preferable. In any way, i think everyone understands that nobody wants to hide existing versions from public eyes. Its only a question of finding appropriate place for them, after development is done. -- Best regards, Igor Stasenko AKA sig.

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Yanni Chiu

On 29/06/11 6:24 PM, Schwab,Wilhelm K wrote: > +1 to Sig's answer. Old builds are great, and we should (and do) > keep them around, but they do not need to be on the CI server. As > Sig said, the old versions don't change, so CI gets pretty boring. There is the option to disable the build job, so that no further builds take place (until there are maintenance releases to build). There is also the option to use the CI server as the build archive as well. You can mark some build numbers as "never remove". Normally, only the last N builds are kept, and the oldest is deleted after the new build completes (unless that oldest build is the last successful build, then it's kept until the next successful build). Whichever builds are marked "never remove" would form the archive. That would eliminate the apparent confusion caused by having the archive at https://gforge.inria.fr/frs/?group_id=1299 The other factor is that a transition to Jenkins from Hudson is happening, which is driving the desire to drop the Hudson based 1.2 builds.

June 30, 2011

Re: [Pharo-project] Pharo One Click 1.3 update: #13279 with Glorp

by Yanni Chiu

On 29/06/11 5:56 PM, Igor Stasenko wrote: > On 30 June 2011 00:05, Mariano Martinez Peck<marianopeck(a)gmail.com> wrote: >> >> Hi. The problem is that the Transcipt has changed in Pharo 1.3 and after >> installing GlorpDBX we popup some transcripts explaining the next steps >> necessary to be able to run tests. > > Frankly, but such kind of messages belong to documentation, not to transcript :) > But yes.. i am missing old good transcript too. Opening a workspace would be better than a Transcript. I automatically rebuild my image with pre-made Transcript and SystemBrowsers, and it was disturbing to see two Transcript windows (before closing the Glorp one, since the Transcript I created was sized and placed where I wanted it). But even better would be to not open either. Eventually I'd like to load Glorp into a PharoKernel image, and the open workspace/transcript would be a nuisance in that case.

June 30, 2011

Re: [Pharo-project] Silly Tweet

by Schwab,Wilhelm K

There are 1.1.1 and 1.2.1 releases. What I do not know is how, for example, 1.2.1 compares with the 1.2 on the CI server?? Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of H. Hirzel [hannes.hirzel(a)gmail.com] Sent: Wednesday, June 29, 2011 6:23 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Silly Tweet Does this imply that older versions are not maintained (e.g. with 1.2.n or 1.3.n releases) which include important bug fixes. It seems so and from a practical point of view there is probably no way around it.... --Hannes On 6/29/11, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 June 2011 00:12, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Igor wrote: >>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: >>>> Having an archive seems sufficient - those who need old versions for use >>>> or research can get them; they don't have to be clogging up the build >>>> server. Sounds great. >>> >>>Indeed. If people would like to use older releases, they should look >>>for another place, not for build server. >>>Since build server are there to build & test bleeding-edge (under >>>development) versions, but not ones which already released and years >>>old. >> >> Ok, so you simply do not want the builds to be used by others. > > Its not about that we don't want users to download older versions > (they are available for download at pharo official site). > > No. Builds purpose is to follow a development process: new update -> new > build. > Now since we're done with 1.2 (and even almost done with 1.3) there > will be no new versions for these lines, > since all development is now in 1.4. > So, there is no reason to keep jobs for 1.2 and then 1.3 on build > server, because there will be no activity around it. > > > >> That's fine. >> >> Stephan Eggermont > > > -- > Best regards, > Igor Stasenko AKA sig. > >

June 29, 2011

Re: [Pharo-project] Silly Tweet

by Schwab,Wilhelm K

+1 to Sig's answer. Old builds are great, and we should (and do) keep them around, but they do not need to be on the CI server. As Sig said, the old versions don't change, so CI gets pretty boring. The old versions are available from an archive (https://gforge.inria.fr/frs/?group_id=1299) See the "file server" link on the downloads page. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, June 29, 2011 6:16 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Silly Tweet On 30 June 2011 00:12, Stephan Eggermont <stephan(a)stack.nl> wrote: > Igor wrote: >>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: >>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server. Sounds great. >> >>Indeed. If people would like to use older releases, they should look >>for another place, not for build server. >>Since build server are there to build & test bleeding-edge (under >>development) versions, but not ones which already released and years >>old. > > Ok, so you simply do not want the builds to be used by others. Its not about that we don't want users to download older versions (they are available for download at pharo official site). No. Builds purpose is to follow a development process: new update -> new build. Now since we're done with 1.2 (and even almost done with 1.3) there will be no new versions for these lines, since all development is now in 1.4. So, there is no reason to keep jobs for 1.2 and then 1.3 on build server, because there will be no activity around it. > That's fine. > > Stephan Eggermont -- Best regards, Igor Stasenko AKA sig.

June 29, 2011

Re: [Pharo-project] Silly Tweet

by H. Hirzel

Does this imply that older versions are not maintained (e.g. with 1.2.n or 1.3.n releases) which include important bug fixes. It seems so and from a practical point of view there is probably no way around it.... --Hannes On 6/29/11, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 30 June 2011 00:12, Stephan Eggermont <stephan(a)stack.nl> wrote: >> Igor wrote: >>>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: >>>> Having an archive seems sufficient - those who need old versions for use >>>> or research can get them; they don't have to be clogging up the build >>>> server. Â Sounds great. >>> >>>Indeed. If people would like to use older releases, they should look >>>for another place, not for build server. >>>Since build server are there to build & test bleeding-edge (under >>>development) versions, but not ones which already released and years >>>old. >> >> Ok, so you simply do not want the builds to be used by others. > > Its not about that we don't want users to download older versions > (they are available for download at pharo official site). > > No. Builds purpose is to follow a development process: new update -> new > build. > Now since we're done with 1.2 (and even almost done with 1.3) there > will be no new versions for these lines, > since all development is now in 1.4. > So, there is no reason to keep jobs for 1.2 and then 1.3 on build > server, because there will be no activity around it. > > > >> That's fine. >> >> Stephan Eggermont > > > -- > Best regards, > Igor Stasenko AKA sig. > >

June 29, 2011

Re: [Pharo-project] Silly Tweet

by Igor Stasenko

On 30 June 2011 00:12, Stephan Eggermont <stephan(a)stack.nl> wrote: > Igor wrote: >>On 29 June 2011 15:56, Schwab,Wilhelm K <bschwab at anest.ufl.edu wrote: >>> Having an archive seems sufficient - those who need old versions for use or research can get them; they don't have to be clogging up the build server. Â Sounds great. >> >>Indeed. If people would like to use older releases, they should look >>for another place, not for build server. >>Since build server are there to build & test bleeding-edge (under >>development) versions, but not ones which already released and years >>old. > > Ok, so you simply do not want the builds to be used by others. Its not about that we don't want users to download older versions (they are available for download at pharo official site). No. Builds purpose is to follow a development process: new update -> new build. Now since we're done with 1.2 (and even almost done with 1.3) there will be no new versions for these lines, since all development is now in 1.4. So, there is no reason to keep jobs for 1.2 and then 1.3 on build server, because there will be no activity around it. > That's fine. > > Stephan Eggermont -- Best regards, Igor Stasenko AKA sig.

June 29, 2011

Re: [Pharo-project] About HTTP proxies, settings and MacOS

by Chris Cunningham

On Wed, Jun 29, 2011 at 12:17 PM, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 29 Jun 2011, at 20:25, Chris Cunningham wrote: > >> Am I reading this right? Â If I was on, say, Windows behind a proxy, >> this would disable proxy use on startup? Â So, every time I started an >> image, I would have to manually re-enable proxy use? > > Uhh, no, on Windows nothing at all would happen, this is Mariano's code, as I formatted it: > Good. I did read it wrong.

June 29, 2011

Re: [Pharo-project] Pharo One Click 1.3 update: #13279 with Glorp

by Igor Stasenko

On 30 June 2011 00:05, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Wed, Jun 29, 2011 at 10:53 PM, Laszlo Zsolt Kiss <lzskiss(a)dublin.ie> > wrote: >> >> aloha phaoers:) >> I have a problem with a Pharo 1.3 One ClickÂ update: #13279 with Glorp. >> I downloaded a clean Pharo 1.3 One Click today. >> Next I probed this: >> >> Gofer new >> squeaksource: 'MetacelloRepository'; >> >> package: 'ConfigurationOfGlorpDBX'; >> load. >> >> ((Smalltalk at: #ConfigurationOfGlorpDBX) project version: '1.1') load >> >> I attached the error page. > > Hi. The problem is that the Transcipt has changed in Pharo 1.3 and after > installing GlorpDBX we popup some transcripts explaining the next steps > necessary to be able to run tests. > We couldn't update yet the code, but it is nothing important. You can just > comment the code in: > > ConfigurationOfGlorpDBX >> postLoadGlorpDriverSqueakDBX > Â Â Â SqueakDatabaseAccessor DefaultDriver: SqueakDBXDriver. > > Transcript open. > Â Â Â Transcript show: 'IMPORTANT FOR GLORP AND SqueakDBX DRIVER'; cr; > Â Â Â show: 'In order to run sucessfully Glorp tests you should need to change > the database connection settings used by them. To do this, change the > following methods: > Â Â Â -GlorpDatabaseLoginResource>>defaultPostgreSQLInternetLogin > Â Â Â -GlorpDatabaseLoginResource>>defaultPostgreSQLLocalLogin > Â Â Â -GlorpDatabaseLoginResource>>defaultPostgreSQLLoginForGlorpStore > > Â Â Â After doing this all Glorps tests must be green.' > Frankly, but such kind of messages belong to documentation, not to transcript :) But yes.. i am missing old good transcript too. > > > > The problem is Transcript open'. You can change it to 'Smalltalk tools > openTranscript' > > >> >> Please, help me. >> >> Thx >> >> Laszlo Zsolt > > > -- > Mariano > http://marianopeck.wordpress.com > > -- Best regards, Igor Stasenko AKA sig.

June 29, 2011

Re: [Pharo-project] Pharo One Click 1.3 update: #13279 with Glorp

by Yanni Chiu

On 29/06/11 5:03 PM, Guillermo Polito wrote: > Hmm, That's not great deal... In pharo 1.3 the Transcript interface > changed, so when the transcript is opened -as a post load- it fails. I file-in the attached method, before loading Glorp. I didn't want to modify the Glorp packages, so I did it this way.

June 29, 2011