Zinc packaging

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Zinc packaging

NorbertHartl
Dale, Paul,

I'm trying now to integrate zinc at my site in order to exchange to fastcgi adaptor in favour of the zinc adaptor. Looking at the packages it is not really clear to me how it should be at the moment:

- Zinc-HTTP is in both repositories (squeaksource and gemsource). Looking at the Configuration it seems the Zinc-HTTP should be the same for gemstone and others, right? The version 140 is different in both repositories. 
- Zinc-Gemstone-Preliminary is a preparation package to load Zinc-HTTP? Therein are only mock classes/methods that enable to loading of the Zinc-HTTP package?
- What is the Zinc-Gemstone package for? Did you move the method extensions from Zinc-HTTP to Zinc-Gemstone? I can see the Zinc-HTTP 140 in gemsource has the same method extensions as Zinc-Gemstone but Zinc-HTTP 140 on squeaksource does not have the method extensions

I think there is a problem with metacello. I did 

Gofer new
        squeaksource: 'ZincHTTPComponents';
        package: 'ConfigurationOfZincHTTPComponents';
        load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load: 'Seaside'.
In the baseline Zinc-HTTP is from squeaksource. But it is loaded from gemsource and this version has the same method extensions as Zinc-Gemstone thus rendering the problem visible. Dale, could it be that Zinc-HTTP in the baseline attached to squeaksource will moved to gemsource with the following taken from the gemstone section? Just a guess but the package loaded is the wrong one. 

spec for: #gemstone do:[
spec repository: 'http://seaside.gemstone.com/ss/ZincHTTPComponents'.  
spec
...
package:'Zinc-HTTP' with:[spec requires: #('Zinc-Gemstone-Preliminary')  ];
...

Norbert
Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

NorbertHartl
Another attempt to gues how it goes :)

- Zinc-Gemstone-preliminary is the preparation still
- Zinc-HTTP should be loaded from squeaksource (it doesn't in my case. see last mail)
- Zinc-Gemstone does not only have method extensions. There are also some method overwrites that package the package to fit into gemstone. 

I think the loading should be fixed and the method overwrites should be avoided were possible.

Norbert

Am 23.05.2011 um 12:08 schrieb Norbert Hartl:

Dale, Paul,

I'm trying now to integrate zinc at my site in order to exchange to fastcgi adaptor in favour of the zinc adaptor. Looking at the packages it is not really clear to me how it should be at the moment:

- Zinc-HTTP is in both repositories (squeaksource and gemsource). Looking at the Configuration it seems the Zinc-HTTP should be the same for gemstone and others, right? The version 140 is different in both repositories. 
- Zinc-Gemstone-Preliminary is a preparation package to load Zinc-HTTP? Therein are only mock classes/methods that enable to loading of the Zinc-HTTP package?
- What is the Zinc-Gemstone package for? Did you move the method extensions from Zinc-HTTP to Zinc-Gemstone? I can see the Zinc-HTTP 140 in gemsource has the same method extensions as Zinc-Gemstone but Zinc-HTTP 140 on squeaksource does not have the method extensions

I think there is a problem with metacello. I did 

Gofer new
        squeaksource: 'ZincHTTPComponents';
        package: 'ConfigurationOfZincHTTPComponents';
        load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load: 'Seaside'.
In the baseline Zinc-HTTP is from squeaksource. But it is loaded from gemsource and this version has the same method extensions as Zinc-Gemstone thus rendering the problem visible. Dale, could it be that Zinc-HTTP in the baseline attached to squeaksource will moved to gemsource with the following taken from the gemstone section? Just a guess but the package loaded is the wrong one. 

spec for: #gemstone do:[
spec repository: 'http://seaside.gemstone.com/ss/ZincHTTPComponents'.  
spec
...
package:'Zinc-HTTP' with:[spec requires: #('Zinc-Gemstone-Preliminary')  ];
...

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

Paul DeBruicker
Hi Norbert

I am away for the next few days and haven't looked at Zinc since I last uploaded some changes but it is my recollection that using the metacello configuration from squeaksource it would load into a clean extent. I have not updated Zinc in gemstone to Sven's most recent bugfixes.  

Good luck and I'll take a look next week.

Paul.





On May 23, 2011, at 6:24 AM, Norbert Hartl <[hidden email]> wrote:

> Another attempt to gues how it goes :)
>
> - Zinc-Gemstone-preliminary is the preparation still
> - Zinc-HTTP should be loaded from squeaksource (it doesn't in my case. see last mail)
> - Zinc-Gemstone does not only have method extensions. There are also some method overwrites that package the package to fit into gemstone.
>
> I think the loading should be fixed and the method overwrites should be avoided were possible.
>
> Norbert
>
> Am 23.05.2011 um 12:08 schrieb Norbert Hartl:
>
>> Dale, Paul,
>>
>> I'm trying now to integrate zinc at my site in order to exchange to fastcgi adaptor in favour of the zinc adaptor. Looking at the packages it is not really clear to me how it should be at the moment:
>>
>> - Zinc-HTTP is in both repositories (squeaksource and gemsource). Looking at the Configuration it seems the Zinc-HTTP should be the same for gemstone and others, right? The version 140 is different in both repositories.
>> - Zinc-Gemstone-Preliminary is a preparation package to load Zinc-HTTP? Therein are only mock classes/methods that enable to loading of the Zinc-HTTP package?
>> - What is the Zinc-Gemstone package for? Did you move the method extensions from Zinc-HTTP to Zinc-Gemstone? I can see the Zinc-HTTP 140 in gemsource has the same method extensions as Zinc-Gemstone but Zinc-HTTP 140 on squeaksource does not have the method extensions
>>
>> I think there is a problem with metacello. I did
>>
>> Gofer new
>>         squeaksource: 'ZincHTTPComponents';
>>         package: 'ConfigurationOfZincHTTPComponents';
>>         load.
>> ((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load.
>> ((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load: 'Seaside'.
>> In the baseline Zinc-HTTP is from squeaksource. But it is loaded from gemsource and this version has the same method extensions as Zinc-Gemstone thus rendering the problem visible. Dale, could it be that Zinc-HTTP in the baseline attached to squeaksource will moved to gemsource with the following taken from the gemstone section? Just a guess but the package loaded is the wrong one.
>>
>> spec for: #gemstone do:[
>> spec repository: 'http://seaside.gemstone.com/ss/ZincHTTPComponents'.  
>> spec
>> ...
>> package:'Zinc-HTTP' with:[spec requires: #('Zinc-Gemstone-Preliminary')  ];
>> ...
>>
>> Norbert
>
Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

Dale Henrichs
In reply to this post by NorbertHartl
Norbert,

The way the repositories are defined in the project, the packages may be loaded from: 

  http://www.squeaksource.com/ZincHTTPComponents
OR
  http://seaside.gemstone.com/ss/ZincHTTPComponents

The package Zinc-HTTP-PaulDeBruicker.140 exists in both repositories, but the UUID is different for each one ...

GemSource:

 Name: Zinc-HTTP-PaulDeBruicker.140
Author: PaulDeBruicker
Time: 04/10/2011, 09:53:39
UUID: d3f596f3-2eae-4255-ae7c-d1952a2b35fe
Ancestors: Zinc-HTTP-PaulDeBruicker.139

SqueakSource:

Name: Zinc-HTTP-PaulDeBruicker.140
Author: PaulDeBruicker
Time: 04/10/2011, 12:03:38
UUID: 9ac457ad-7824-4c0c-8d5d-e7ebe36f0280
Ancestors: Zinc-HTTP-SvenVanCaekenberghe.139

The one that got loaded into my image was the one from SqueakSource, which is presumably the wrong one ... The config entry for Zinc-HTTP in the baseline could be changed to this, to ensure that the correct repository is used:

  package: 'Zinc-HTTP' with: [
    spec 
      repository: 'http://seaside.gemstone.com/ss/ZincHTTPComponents';
      requires: #('Zinc-Gemstone-Preliminary')  ]

The other dirty packages appear to be related to overrides for bugfixes that have been incorporated into GLASS ...

Dale


From: "Norbert Hartl" <[hidden email]>
To: "GemStone Seaside beta discussion" <[hidden email]>
Sent: Monday, May 23, 2011 3:24:24 AM
Subject: Re: [GS/SS Beta] Zinc packaging

Another attempt to gues how it goes :)

- Zinc-Gemstone-preliminary is the preparation still
- Zinc-HTTP should be loaded from squeaksource (it doesn't in my case. see last mail)
- Zinc-Gemstone does not only have method extensions. There are also some method overwrites that package the package to fit into gemstone. 

I think the loading should be fixed and the method overwrites should be avoided were possible.

Norbert

Am 23.05.2011 um 12:08 schrieb Norbert Hartl:

Dale, Paul,

I'm trying now to integrate zinc at my site in order to exchange to fastcgi adaptor in favour of the zinc adaptor. Looking at the packages it is not really clear to me how it should be at the moment:

- Zinc-HTTP is in both repositories (squeaksource and gemsource). Looking at the Configuration it seems the Zinc-HTTP should be the same for gemstone and others, right? The version 140 is different in both repositories. 
- Zinc-Gemstone-Preliminary is a preparation package to load Zinc-HTTP? Therein are only mock classes/methods that enable to loading of the Zinc-HTTP package?
- What is the Zinc-Gemstone package for? Did you move the method extensions from Zinc-HTTP to Zinc-Gemstone? I can see the Zinc-HTTP 140 in gemsource has the same method extensions as Zinc-Gemstone but Zinc-HTTP 140 on squeaksource does not have the method extensions

I think there is a problem with metacello. I did 

Gofer new
        squeaksource: 'ZincHTTPComponents';
        package: 'ConfigurationOfZincHTTPComponents';
        load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load: 'Seaside'.
In the baseline Zinc-HTTP is from squeaksource. But it is loaded from gemsource and this version has the same method extensions as Zinc-Gemstone thus rendering the problem visible. Dale, could it be that Zinc-HTTP in the baseline attached to squeaksource will moved to gemsource with the following taken from the gemstone section? Just a guess but the package loaded is the wrong one. 

spec for: #gemstone do:[
spec repository: 'http://seaside.gemstone.com/ss/ZincHTTPComponents'.  
spec
...
package:'Zinc-HTTP' with:[spec requires: #('Zinc-Gemstone-Preliminary')  ];
...

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

NorbertHartl


Am 23.05.2011 um 20:35 schrieb Dale Henrichs <[hidden email]>:

Norbert,

The way the repositories are defined in the project, the packages may be loaded from: 

OR

The package Zinc-HTTP-PaulDeBruicker.140 exists in both repositories, but the UUID is different for each one ...

GemSource:

 Name: Zinc-HTTP-PaulDeBruicker.140
Author: PaulDeBruicker
Time: 04/10/2011, 09:53:39
UUID: d3f596f3-2eae-4255-ae7c-d1952a2b35fe
Ancestors: Zinc-HTTP-PaulDeBruicker.139

SqueakSource:

Name: Zinc-HTTP-PaulDeBruicker.140
Author: PaulDeBruicker
Time: 04/10/2011, 12:03:38
UUID: 9ac457ad-7824-4c0c-8d5d-e7ebe36f0280
Ancestors: Zinc-HTTP-SvenVanCaekenberghe.139

The one that got loaded into my image was the one from SqueakSource, which is presumably the wrong one ... The config entry for Zinc-HTTP in the baseline could be changed to this, to ensure that the correct repository is used:

that is strange. I think the squeaksource one is the right one. In my case it loaded the gemsource one

  package: 'Zinc-HTTP' with: [
    spec 
      requires: #('Zinc-Gemstone-Preliminary')  ]

The other dirty packages appear to be related to overrides for bugfixes that have been incorporated into GLASS ...

So it would be best to check the incorporated fixes and remove the overrides from the package?

Norbert

Dale


From: "Norbert Hartl" <[hidden email]>
To: "GemStone Seaside beta discussion" <[hidden email]>
Sent: Monday, May 23, 2011 3:24:24 AM
Subject: Re: [GS/SS Beta] Zinc packaging

Another attempt to gues how it goes :)

- Zinc-Gemstone-preliminary is the preparation still
- Zinc-HTTP should be loaded from squeaksource (it doesn't in my case. see last mail)
- Zinc-Gemstone does not only have method extensions. There are also some method overwrites that package the package to fit into gemstone. 

I think the loading should be fixed and the method overwrites should be avoided were possible.

Norbert

Am 23.05.2011 um 12:08 schrieb Norbert Hartl:

Dale, Paul,

I'm trying now to integrate zinc at my site in order to exchange to fastcgi adaptor in favour of the zinc adaptor. Looking at the packages it is not really clear to me how it should be at the moment:

- Zinc-HTTP is in both repositories (squeaksource and gemsource). Looking at the Configuration it seems the Zinc-HTTP should be the same for gemstone and others, right? The version 140 is different in both repositories. 
- Zinc-Gemstone-Preliminary is a preparation package to load Zinc-HTTP? Therein are only mock classes/methods that enable to loading of the Zinc-HTTP package?
- What is the Zinc-Gemstone package for? Did you move the method extensions from Zinc-HTTP to Zinc-Gemstone? I can see the Zinc-HTTP 140 in gemsource has the same method extensions as Zinc-Gemstone but Zinc-HTTP 140 on squeaksource does not have the method extensions

I think there is a problem with metacello. I did 

Gofer new
        squeaksource: 'ZincHTTPComponents';
        package: 'ConfigurationOfZincHTTPComponents';
        load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load.
((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load: 'Seaside'.
In the baseline Zinc-HTTP is from squeaksource. But it is loaded from gemsource and this version has the same method extensions as Zinc-Gemstone thus rendering the problem visible. Dale, could it be that Zinc-HTTP in the baseline attached to squeaksource will moved to gemsource with the following taken from the gemstone section? Just a guess but the package loaded is the wrong one. 

spec for: #gemstone do:[
spec
...
package:'Zinc-HTTP' with:[spec requires: #('Zinc-Gemstone-Preliminary')  ];
...

Norbert


Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

Paul DeBruicker
Dale & Norbert-

The Zinc-Gemstone package has some changes that are probably best suited
in the GSPharo or GSSqueakCommon.  Do you want me to extract them into a
separate package and put them in the Pharo Compatability repo?

Also my general porting strategy for this has been to change the
SqueakSource version of the Zinc packages as little as possible and
create Gemsource packages that just contain overrides and extensions to
the SqueakSource packages.  Is there a better strategy I should use?




On 05/23/2011 03:37 PM, Norbert Hartl wrote:
>
>

>> The one that got loaded into my image was the one from SqueakSource,
>> which is presumably the wrong one ... The config entry for Zinc-HTTP
>> in the baseline could be changed to this, to ensure that the correct
>> repository is used:
>>
> that is strange. I think the squeaksource one is the right one. In my
> case it loaded the gemsource one
>

The squeaksource package is the one that should load using the Metacello
config.  Sorry for creating the bug then not seeing it and the resulting
confusion.  I've removed the Zinc-HTTP package on Gemsource.  The
Zinc-Gemstone package has Gemstone specfic overrides for the Zinc-HTTP
package on squeaksource and extensions for Pharo compatability.

The Zinc-Tests package on Gemsource should be used to test the Gemstone
implementation.  I'm going to create a Zinc-Gemstone-Tests package that
will just contain overrides to the latest Zinc-Tests package on
SqueakSource. Once that is working I will remove the Gemsource
Zinc-Tests package and update the metacello configs.

I'm going to add a version 1.1 to the metacello config that will reflect
the bugfixes Sven and others have created in the past month and a half
and correct my faulty packaging.


>> The other dirty packages appear to be related to overrides for
>> bugfixes that have been incorporated into GLASS ...
>>
> So it would be best to check the incorporated fixes and remove the
> overrides from the package?
>


Is there a way to see what has changed in GLASS since mid April and
whether or not the Pharo compatability things for Zinc have been
incorporated?


Thanks for your patience and suggestions

Paul
Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

Paul DeBruicker
Dale, Norbert & Sven,

I've updated the Gemstone port to Sven's latest Zinc-HTTP version on
SqueakSource.  I revised the Pharo portion of the metacello config to
include the Zodiac package.  I cleaned up the repository on Gemsource.
The Zinc-Gemstone packages has 28 method overwrites in 18 classes from
the Zinc-HTTP package and 26 methods in 11 classes that should probably
go into GsPharo or GsSqueakCommon.

Everything should load properly into a clean 1.0-beta.6 extent.  If you
want to load the Seaside packages into a clean extent you need to wrap
it in a

MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
    ((Smalltalk at: #ConfigurationOfZincHTTPComponents) project
latestVersion) load: 'Seaside'.
   ].

block.

146 of 151 tests pass and those that don't pass rely on Stream classes I
don't intend to port until Gemstone 3.0 is released.  For this update I
have not done extensive testing of either the Zinc port or its Seaside
adaptor.

Paul
Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

NorbertHartl
Paul,

this is really great. I will find some time next week to start over the next testing phase. I'm still eager to get rid of fastcgi and replace my complete environment to zinc.

thank you for the effort,

Norbert

Am 02.06.2011 um 16:14 schrieb Paul DeBruicker:

> Dale, Norbert & Sven,
>
> I've updated the Gemstone port to Sven's latest Zinc-HTTP version on SqueakSource.  I revised the Pharo portion of the metacello config to include the Zodiac package.  I cleaned up the repository on Gemsource. The Zinc-Gemstone packages has 28 method overwrites in 18 classes from the Zinc-HTTP package and 26 methods in 11 classes that should probably go into GsPharo or GsSqueakCommon.
>
> Everything should load properly into a clean 1.0-beta.6 extent.  If you want to load the Seaside packages into a clean extent you need to wrap it in a
>
> MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
>   ((Smalltalk at: #ConfigurationOfZincHTTPComponents) project latestVersion) load: 'Seaside'.
>  ].
>
> block.
>
> 146 of 151 tests pass and those that don't pass rely on Stream classes I don't intend to port until Gemstone 3.0 is released.  For this update I have not done extensive testing of either the Zinc port or its Seaside adaptor.
>
> Paul

Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

Philippe Marschall
2011/6/2 Norbert Hartl <[hidden email]>:
> Paul,
>
> this is really great. I will find some time next week to start over the next testing phase. I'm still eager to get rid of fastcgi and replace my complete environment to zinc.

As a bystander, what are the issues with fastcgi?

Cheers
Philippe
Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

NorbertHartl

Am 02.06.2011 um 17:50 schrieb Philippe Marschall:

> 2011/6/2 Norbert Hartl <[hidden email]>:
>> Paul,
>>
>> this is really great. I will find some time next week to start over the next testing phase. I'm still eager to get rid of fastcgi and replace my complete environment to zinc.
>
> As a bystander, what are the issues with fastcgi?
>
There are no real issues. I just don't really like it. It is hard to debug, hard to monitor and HTTP wise I don't get smarter results than from Kom or swazoo. In the near future I like to have a server that does proper mime handling, that understands all of the HTTP verbs. I'm using seaside-REST daily and I would like to have that interface and getting mime messages from it so I can upload images along with my xml content without having to think too much (and have it reliable).

Just that,

Norbert

Reply | Threaded
Open this post in threaded view
|

Re: Zinc packaging

Dale Henrichs
In reply to this post by Paul DeBruicker
Paul,

I too plan to start moving to Zinc for tODE (previously known as Naviode). I want to run a separate gem to serve tODE so that one can do things in development that consume a whole vm for a period of time without impacting the set of production gems and doing a single standalone gem using Zinc seems to make sense ... I am also planning on doing some RESTful services with tODE and will need to be able to HTTP client functionality...

At that time I will look at the things that have/can be packaged in GsSqueakCommon and friends and help clean that up ...

Dale


----- Original Message -----
| From: "Paul DeBruicker" <[hidden email]>
| To: [hidden email], "Sven Van Caekenberghe" <[hidden email]>
| Sent: Thursday, June 2, 2011 7:14:57 AM
| Subject: Re: [GS/SS Beta] Zinc packaging
|
| Dale, Norbert & Sven,
|
| I've updated the Gemstone port to Sven's latest Zinc-HTTP version on
| SqueakSource.  I revised the Pharo portion of the metacello config to
| include the Zodiac package.  I cleaned up the repository on
| Gemsource.
| The Zinc-Gemstone packages has 28 method overwrites in 18 classes
| from
| the Zinc-HTTP package and 26 methods in 11 classes that should
| probably
| go into GsPharo or GsSqueakCommon.
|
| Everything should load properly into a clean 1.0-beta.6 extent.  If
| you
| want to load the Seaside packages into a clean extent you need to
| wrap
| it in a
|
| MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [
|     ((Smalltalk at: #ConfigurationOfZincHTTPComponents) project
| latestVersion) load: 'Seaside'.
|    ].
|
| block.
|
| 146 of 151 tests pass and those that don't pass rely on Stream
| classes I
| don't intend to port until Gemstone 3.0 is released.  For this update
| I
| have not done extensive testing of either the Zinc port or its
| Seaside
| adaptor.
|
| Paul
|