[Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta
Marcus, I somewhat understand the logic of "if we didn't find it before this, it's not a problem now" but that attitude quickly leads to a trap. Part of why I did not find this sooner is that I have been struggling to adapt to metacello. I am not convinced that there is much information on how to use it, but there is certainly a lot of mis-information. The end result is a big hurdle to adopting new images. You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present. There is a growing tsunami of source code that I have to get into an image in order to be able to work. I built that process initially in terms of the web image; they are gone so I built it in terms of the dev image; now I can't even get that. Some stability (tenacity might be a better word) in the production of what is delivered to the user/developer would help me be a more aggressive tester. As it is, I am hacking the build process rather than applying it to reach a point that I can contribute to testing. In the extreme case, I could retreat to use Seaside's pre-made images and ignore the bleeding edge of Pharo, but that is not something I care to do. At a minimum, the unstable download section should contain a link to an "official" page that shows how to build the dev and web configurations. If we can't do that, work on 1.2 is premature. Back to 2476, it is quite possible that rydier's suggestion of removing the true return value will allow it to work. We are testing a new release, or should be. Does that not seem like a good time to introduce such a simple fix? Bill ________________________________________ From: pharo@googlecode.com [pharo@googlecode.com] Sent: Saturday, June 12, 2010 3:01 AM To: Schwab,Wilhelm K Subject: Re: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta Updates: Labels: -Milestone-1.1 Comment #6 on issue 2476 by marcus.denker: ConnectionQueue broken in 1.0 and 1.1 beta http://code.google.com/p/pharo/issues/detail?id=2476 In Pharo-dev 1.0 and 1.1 beta: not a show stopper for 1.1 -- You received this message because you are the owner of the issue. You may adjust your issue notification preferences at: https://code.google.com/hosting/settings
You are already producing 1.2. Â The core is at 1.1 RC - that's great! Â But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Â Then I need a Seaside-enabled image on top of that. Â There is very little of value I can do with a release until Seaside is present.
The daily Seaside builds are based on PharoCore1.1rc1. http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifac... Lukas -- Lukas Renggli www.lukas-renggli.ch
Ok, maybe I *do* want to "retreat" to the Seaside images :) I will give it a try. My current code is based on Seaside 2.8, but a quick scan of the migration document does not appear terrifying (most of my Seaside code is pretty simple, I think). I could ask a bunch of questions, but a quick look will provide the answers. Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Saturday, June 12, 2010 11:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta
You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present.
The daily Seaside builds are based on PharoCore1.1rc1. http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifac... Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Lukas, This is interesting. Is there any way to find the script that was run to build a particular image? What separates the successful and stable builds from the unstable ones? What (how bad) is a fail build? You load Shout (which is a must<g>). Otherwise, how similar is the image to Pharo-dev + Seaside? Is there a way to get the bleeding edge of Pharo and a stable version of Seaside? Is the reported "last duration" (41 min) the time it took to create the image? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Saturday, June 12, 2010 11:18 AM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta
You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present.
The daily Seaside builds are based on PharoCore1.1rc1. http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifac... Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is interesting. Â Is there any way to find the script that was run to build a particular image?
The scripts are here: http://github.com/renggli/builder/tree/master/scripts
What separates the successful and stable builds from the unstable ones?
Unstable builds are builds that have failing tests (or too many code critics errors).
What (how bad) is a fail build?
Filing builds are builds that could not be completed (missing package, compile error, ...).
You load Shout (which is a must<g>). Â Otherwise, how similar is the image to Pharo-dev + Seaside?
Probably quite different. I load packages and set settings according to my preference.
Is there a way to get the bleeding edge of Pharo and a stable version of Seaside?
Not from my server, but you could setup one that builds whatever you need. For me, I use ... - ... the latest release candidate or stable release of Pharo only. - ... the latest package versions for code I am working on (RB, OB, Seaside, Magritte, Pier, ...)
Is the reported "last duration" (41 min) the time it took to create the image?
Yes, this includes the time to run the tests (and code critics). Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas, Looking at your seaside3.st file, it does not look like it does everything; omnibrowser.st is probably also part of it. Is there a master script that I am missing, or do you specify that list elsewhere? Bill ________________________________________ From: pharo-project-bounces@lists.gforge.inria.fr [pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli [renggli@gmail.com] Sent: Saturday, June 12, 2010 4:09 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] FW: Issue 2476 in pharo: ConnectionQueue broken in 1.0 and 1.1 beta
This is interesting. Is there any way to find the script that was run to build a particular image?
The scripts are here: http://github.com/renggli/builder/tree/master/scripts
What separates the successful and stable builds from the unstable ones?
Unstable builds are builds that have failing tests (or too many code critics errors).
What (how bad) is a fail build?
Filing builds are builds that could not be completed (missing package, compile error, ...).
You load Shout (which is a must<g>). Otherwise, how similar is the image to Pharo-dev + Seaside?
Probably quite different. I load packages and set settings according to my preference.
Is there a way to get the bleeding edge of Pharo and a stable version of Seaside?
Not from my server, but you could setup one that builds whatever you need. For me, I use ... - ... the latest release candidate or stable release of Pharo only. - ... the latest package versions for code I am working on (RB, OB, Seaside, Magritte, Pier, ...)
Is the reported "last duration" (41 min) the time it took to create the image?
Yes, this includes the time to run the tests (and code critics). Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Schwab,Wilhelm K wrote:
Looking at your seaside3.st file, it does not look like it does everything; omnibrowser.st is probably also part of it. Is there a master script that I am missing, or do you specify that list elsewhere?
I think you want to follow the chain of "Upstream Projects" that is available in the Hudson server interface.
Lukas Renggli wrote:
Is there a way to get the bleeding edge of Pharo and a stable version of Seaside?
Not from my server, but you could setup one that builds whatever you need. For me, I use ...
- ... the latest release candidate or stable release of Pharo only. - ... the latest package versions for code I am working on (RB, OB, Seaside, Magritte, Pier, ...)
When I first set up my build server (hudson.jooshr.org), it was building the bleeding edge of Pharo and Seaside. I've since had to back off the bleeding edge of Pharo somewhat - I manually install new image .zip files now. I used to run the in-image update from whatever build image was installed, but the update often failed in headless mode, due to UI popups about deprecated methods, among other issues. I think there's a workaround, but I've not spent the time on it. The situation should improve now that there is a community build server for the core at: http://rmod.lille.inria.fr/hudson/. I then take the build image as the starting point to build my deliverable. I do this build on my local machine, using another Hudson server (they're easy to set up). In retrospect, I should have updated my initial build image much more frequently, then I would have detected the (minor) problems with Glorp and RFB, on PharoCore-1.1, much sooner. Note however that I had decided to start development using PharoCore-1.0 back in January, because it was more stable. So I had no real need to use 1.1 except to test for compatibility. My plan now is to build whatever community packages that I depend on (e.g. Glorp & RFB), continuously against the bleeding edge of Pharo. Then, whenever I decide to update my initial build image, there should not be problems loading community packages that I have to fix before I can run my own code. So if everyone were to build/test the community packages that they depend on, then we'd get test coverage on the most important ones.
On Jun 13, 2010, at 9:18 AM, Yanni Chiu wrote: > Lukas Renggli wrote: >>> Is there a way to get the bleeding edge of Pharo and a stable version of Seaside? >> Not from my server, but you could setup one that builds whatever you >> need. For me, I use ... >> - ... the latest release candidate or stable release of Pharo only. >> - ... the latest package versions for code I am working on (RB, OB, >> Seaside, Magritte, Pier, ...) > > When I first set up my build server (hudson.jooshr.org), it was building the bleeding edge of Pharo and Seaside. I've since had to back off the bleeding edge of Pharo somewhat - I manually install new image .zip files now. I used to run the in-image update from whatever build image was installed, but the update often failed in headless mode, due to UI popups about deprecated methods, among other issues. I think there's a workaround, but I've not spent the time on it. The situation should improve now that there is a community build server for the core at: http://rmod.lille.inria.fr/hudson/. Yes we will have to think about the UIPopUp and nuke them. We should be able to control the UIPop only when on interactive mode. So having a exception is the way to go. > I then take the build image as the starting point to build my deliverable. I do this build on my local machine, using another Hudson server (they're easy to set up). In retrospect, I should have updated my initial build image much more frequently, then I would have detected the (minor) problems with Glorp and RFB, on PharoCore-1.1, much sooner. Note however that I had decided to start development using PharoCore-1.0 back in January, because it was more stable. So I had no real need to use 1.1 except to test for compatibility. I think that this was wise :) > > My plan now is to build whatever community packages that I depend on (e.g. Glorp & RFB), continuously against the bleeding edge of Pharo. Then, whenever I decide to update my initial build image, there should not be problems loading community packages that I have to fix before I can run my own code. good. > So if everyone were to build/test the community packages that they depend on, then we'd get test coverage on the most important ones. yes. We plan to include in the integration server all the metacello configuration > > > _______________________________________________ > Pharo-project mailing list > Pharo-project@lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is cool lukas. Let us know if you have any problem. we started to put pharo1.2 in our hudson server and it worked but now we ahve to understand why this does not work anymore. In any case getting an integration server is great since it will force us to think in another way that interactively. Stef On Jun 12, 2010, at 5:18 PM, Lukas Renggli wrote:
You are already producing 1.2. The core is at 1.1 RC - that's great! But here in the trenches, there is nothing approximating a dev image beta, and I can't figure out how to build it. Then I need a Seaside-enabled image on top of that. There is very little of value I can do with a release until Seaside is present.
The daily Seaside builds are based on PharoCore1.1rc1.
http://hudson.lukas-renggli.ch/job/Seaside%203.0/lastSuccessfulBuild/artifac...
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (4)
-
Lukas Renggli -
Schwab,Wilhelm K -
Stéphane Ducasse -
Yanni Chiu