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: [hidden email] [[hidden email]]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

> 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/artifact/seaside3/*zip*/seaside3.zip

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Lukas Renggli [[hidden email]]
Sent: Saturday, June 12, 2010 11:18 AM
To: [hidden email]
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/artifact/seaside3/*zip*/seaside3.zip

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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: [hidden email] [[hidden email]] On Behalf Of Lukas Renggli [[hidden email]]
Sent: Saturday, June 12, 2010 11:18 AM
To: [hidden email]
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/artifact/seaside3/*zip*/seaside3.zip

Lukas

--
Lukas Renggli
www.lukas-renggli.ch

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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:


_______________________________________________
Pharo-project mailing list
[hidden email]
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

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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: [hidden email] [[hidden email]] On Behalf Of Lukas Renggli [[hidden email]]
Sent: Saturday, June 12, 2010 4:09 PM
To: [hidden email]
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
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

_______________________________________________
Pharo-project mailing list
[hidden email]
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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

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
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project