Zinc again

I switched my current projects back to the use of metacello as deployment helper. Using it I introduced some problems that aren't easy to solve. The zinc port to gemstone has some flaws. The last stable version was 1.1. And nobody found time to make the port somewhat complete. The version 1.2 of zinc does not really work on gemstone but is referenced in ConfigurationOfSeaside30.
This way I learned there is no way in metacello to pin a version deliberately to a certain package file name. Now I'm asking what was the outcome of the last discussion about zinc? Was there a strategy already how to proceed? The current setup with overrides fails as soon as a new version of zinc is able to creep in.
Even if this question is repetitive I like to ask it again. It would be good to decide how we like to proceed (overrides, fork...). Then it would be best to have the socket handling done by someone that knows gemstone very well. For the rest me for sure and others can chime in fixing the rest.

Any ideas?

Norbert

Hi Norbert,

Not an immediate answer to your question, but... we are using Zinc 1.1 on Gemstone and I'm definitely interested to also work on creating a new port.

About the metacello load process: I'm referencing the Zinc version directly from our application metacello config (which also references the Seaside30 config). This (apparently) ensured that version 1.1. got loaded.
Although I must admit that I'm also controlling which repositories metacello can use (using repositoryOverrides:) during the load. This makes sure that I'm never loading any packages that I did not explicitly replicate to my local development repository. However, if metacello is determined on loading another version, I would get a 'not found' error anyway.

Johan

On 03 Feb 2012, at 11:00, Norbert Hartl wrote:

> I switched my current projects back to the use of metacello as deployment helper. Using it I introduced some problems that aren't easy to solve. The zinc port to gemstone has some flaws. The last stable version was 1.1. And nobody found time to make the port somewhat complete. The version 1.2 of zinc does not really work on gemstone but is referenced in ConfigurationOfSeaside30.
> This way I learned there is no way in metacello to pin a version deliberately to a certain package file name. Now I'm asking what was the outcome of the last discussion about zinc? Was there a strategy already how to proceed? The current setup with overrides fails as soon as a new version of zinc is able to creep in.
> Even if this question is repetitive I like to ask it again. It would be good to decide how we like to proceed (overrides, fork...). Then it would be best to have the socket handling done by someone that knows gemstone very well. For the rest me for sure and others can chime in fixing the rest.
>
> Any ideas?
>
> Norbert

Norbert,

So you bring up several things here:

  1. Zinc 1.2 is spec'ed in the Seaside30 configuration
  2. version 1.2 doesn't work in GemStone
  3. "no way in metacello to pin a version deliberately
      to a certain package file name"
  4. the fact that the Zinc port still needs work...

The Seaside30 configuration can (I've committed a new version of the configuration and patch 3.0.6.3 to use Zinc 1.1 for GemStone) be modified to reference Zinc 1.1 for GemStone ... which I think addresses points #1, and #3. Although I'm not completely sure what you mean by #3.

<aside>
As an aside, right now I'm working getting Monticello and Metacello to work with git and github ... so in the future (using git) this type of thing just won't happen. The GemStone branch of Zinc won't be slaved to the pharo branch as it is now ... You'll be able to "pin" a project, because you will be in control of which version of a project is cloned to your disk ...
</aside>

If I recall correctly a large number of the overrides are unnecessary in that the method being overridden is the correct implementation, but Paul had to create those methods because they didn't exist in GLASS at the time...

I don't recall the "socket issues", but I suppose that I am the best one to tackle those ... I'm pushing on the git project real hard right now, but I can work on specific socket issues for Zinc as they are identified ...

The best approach is to create '.gemstone' branches for each of the "common" packages that need to be modified for GemStone ... the configuration can be updated to correctly deal with these branches (it's what I have done for years with Seaside). After the fact requests can be made to the maintainers to restructure their code and packages to make it more portable (what the Seaside maintainers have done as well).

Dale

 
----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Friday, February 3, 2012 2:00:01 AM
| Subject: [GS/SS Beta] Zinc again
|
| I switched my current projects back to the use of metacello as
| deployment helper. Using it I introduced some problems that aren't
| easy to solve. The zinc port to gemstone has some flaws. The last
| stable version was 1.1. And nobody found time to make the port
| somewhat complete. The version 1.2 of zinc does not really work on
| gemstone but is referenced in ConfigurationOfSeaside30.
| This way I learned there is no way in metacello to pin a version
| deliberately to a certain package file name. Now I'm asking what was
| the outcome of the last discussion about zinc? Was there a strategy
| already how to proceed? The current setup with overrides fails as
| soon as a new version of zinc is able to creep in.
| Even if this question is repetitive I like to ask it again. It would
| be good to decide how we like to proceed (overrides, fork...). Then
| it would be best to have the socket handling done by someone that
| knows gemstone very well. For the rest me for sure and others can
| chime in fixing the rest.
|
| Any ideas?
|
| Norbert

I haven't looked at that code in a while. Would it be worthwhile for me to list why I did what I did or would it be better to start fresh?

Near the start of December I started porting the latest (at that time) Zinc but got distracted before fixing the bad parts of the earlier port.  At that time there wasn't much to do to get Zinc "working" at the same level it did for 1.1.

Also do you want to target Gemstone 2.4 or 3.x? 3.x has more compatible stream classes.



On Feb 3, 2012, at 10:09 AM, Dale Henrichs t <[hidden email]> wrote:

Dale,

Am 03.02.2012 um 19:09 schrieb Dale Henrichs:
yep

> <aside>
> As an aside, right now I'm working getting Monticello and Metacello to work with git and github ... so in the future (using git) this type of thing just won't happen. The GemStone branch of Zinc won't be slaved to the pharo branch as it is now ... You'll be able to "pin" a project, because you will be in control of which version of a project is cloned to your disk ...
> </aside>
>
Sounds good. But I need to come over the mixed feeling about externalizing some parts of the process and taking gain from utilizing existing tools.

> If I recall correctly a large number of the overrides are unnecessary in that the method being overridden is the correct implementation, but Paul had to create those methods because they didn't exist in GLASS at the time...
>
You are talking about 3.x gemstone? Or do they exist in 2.4.4.x as well?

> I don't recall the "socket issues", but I suppose that I am the best one to tackle those ... I'm pushing on the git project real hard right now, but I can work on specific socket issues for Zinc as they are identified ...
>
I tried to do a port before Paul. The combination of process and socket handling kept me from proceeding. Maybe I just made some stupid failures.

> The best approach is to create '.gemstone' branches for each of the "common" packages that need to be modified for GemStone ... the configuration can be updated to correctly deal with these branches (it's what I have done for years with Seaside). After the fact requests can be made to the maintainers to restructure their code and packages to make it more portable (what the Seaside maintainers have done as well).
Ok. What will be the best target for zinc? Is it much easier to do in 3.x gemstone? Or shouldn't the difference be that big.

Norbert

Am 03.02.2012 um 19:28 schrieb Paul DeBruicker:

> I haven't looked at that code in a while. Would it be worthwhile for me to list why I did what I did or would it be better to start fresh?
>
I think you are the best to decide. If you still think the port you've done makes sense then why spend the work again. It would be best to use your port.

> Near the start of December I started porting the latest (at that time) Zinc but got distracted before fixing the bad parts of the earlier port.  At that time there wasn't much to do to get Zinc "working" at the same level it did for 1.1.
>
Ok, so if you have little time we can make it up-to-date. I don't know how much time I'll find but it is just an important goal. Would be a shame not to have it in a proper state. I need also to update the xml parser to that latest version because there is not much development going on there.

> Also do you want to target Gemstone 2.4 or 3.x? 3.x has more compatible stream classes.
>
Don't know. Never used 3.x really.

Norbert

re: pinning ... I'll have some more to say today about pinning projects in an email on the Metacello list:)

I think the overridden methods I saw were in both 2.4 and 3.0 in the Squeak compatibility layer...

The socket support in 3.0 is potentially better, since a fair amount of work was done their to expand the socket api, but I would hope that it would be targetted for both 2.4 and 3.0...the differences will only show up in the socket layer ...

Dale
----- Original Message -----
| From: "Norbert Hartl" <[hidden email]>
| To: "GemStone Seaside beta discussion" <[hidden email]>
| Sent: Wednesday, February 8, 2012 5:26:00 AM
| Subject: Re: [GS/SS Beta] Zinc again
|
| Dale,
|
| Am 03.02.2012 um 19:09 schrieb Dale Henrichs:
|
| > Norbert,
| >
| > So you bring up several things here:
| >
| >  1. Zinc 1.2 is spec'ed in the Seaside30 configuration
| >  2. version 1.2 doesn't work in GemStone
| >  3. "no way in metacello to pin a version deliberately
| >      to a certain package file name"
| >  4. the fact that the Zinc port still needs work...
| >
| > The Seaside30 configuration can (I've committed a new version of
| > the configuration and patch 3.0.6.3 to use Zinc 1.1 for GemStone)
| > be modified to reference Zinc 1.1 for GemStone ... which I think
| > addresses points #1, and #3. Although I'm not completely sure what
| > you mean by #3.
| >
| yep
|
| > <aside>
| > As an aside, right now I'm working getting Monticello and Metacello
| > to work with git and github ... so in the future (using git) this
| > type of thing just won't happen. The GemStone branch of Zinc won't
| > be slaved to the pharo branch as it is now ... You'll be able to
| > "pin" a project, because you will be in control of which version
| > of a project is cloned to your disk ...
| > </aside>
| >
| Sounds good. But I need to come over the mixed feeling about
| externalizing some parts of the process and taking gain from
| utilizing existing tools.
|
| > If I recall correctly a large number of the overrides are
| > unnecessary in that the method being overridden is the correct
| > implementation, but Paul had to create those methods because they
| > didn't exist in GLASS at the time...
| >
| You are talking about 3.x gemstone? Or do they exist in 2.4.4.x as
| well?
|
| > I don't recall the "socket issues", but I suppose that I am the
| > best one to tackle those ... I'm pushing on the git project real
| > hard right now, but I can work on specific socket issues for Zinc
| > as they are identified ...
| >
| I tried to do a port before Paul. The combination of process and
| socket handling kept me from proceeding. Maybe I just made some
| stupid failures.
|
| > The best approach is to create '.gemstone' branches for each of the
| > "common" packages that need to be modified for GemStone ... the
| > configuration can be updated to correctly deal with these branches
| > (it's what I have done for years with Seaside). After the fact
| > requests can be made to the maintainers to restructure their code
| > and packages to make it more portable (what the Seaside
| > maintainers have done as well).
| Ok. What will be the best target for zinc? Is it much easier to do in
| 3.x gemstone? Or shouldn't the difference be that big.
|
| Norbert
| >
| >
| > ----- Original Message -----
| > | From: "Norbert Hartl" <[hidden email]>
| > | To: "GemStone Seaside beta discussion"
| > | <[hidden email]>
| > | Sent: Friday, February 3, 2012 2:00:01 AM
| > | Subject: [GS/SS Beta] Zinc again
| > |
| > | I switched my current projects back to the use of metacello as
| > | deployment helper. Using it I introduced some problems that
| > | aren't
| > | easy to solve. The zinc port to gemstone has some flaws. The last
| > | stable version was 1.1. And nobody found time to make the port
| > | somewhat complete. The version 1.2 of zinc does not really work
| > | on
| > | gemstone but is referenced in ConfigurationOfSeaside30.
| > | This way I learned there is no way in metacello to pin a version
| > | deliberately to a certain package file name. Now I'm asking what
| > | was
| > | the outcome of the last discussion about zinc? Was there a
| > | strategy
| > | already how to proceed? The current setup with overrides fails as
| > | soon as a new version of zinc is able to creep in.
| > | Even if this question is repetitive I like to ask it again. It
| > | would
| > | be good to decide how we like to proceed (overrides, fork...).
| > | Then
| > | it would be best to have the socket handling done by someone that
| > | knows gemstone very well. For the rest me for sure and others can
| > | chime in fixing the rest.
| > |
| > | Any ideas?
| > |
| > | Norbert
|
|