[vwnc] Cincom's Store roadmap. Re: What is Linkuistics?

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

[vwnc] Cincom's Store roadmap. Re: What is Linkuistics?

Mathieu van Echtelt-2
Hi list,

We're are also curious about Cincom's Store roadmap. e.g. they
mentioned introducing "Configuration" support a long time ago but as
far as I know, there isn't much progress in the area.

Since playing with vw7.7 many store-extensions we are using do not
work anymore. I suppose this is because Store/VW interaction is now
Glorp based. This will hopefully kick-start some  long planned
improvements.  Before we start migrating all our store extensions to
be glorp aware, I would like to know more about Cincoms' store roadmap
and what has changed since 7.6. This will help us make the right
decisions.

about "Store lineup extensions":

We're especially heavy users of  "Store lineup extensions" ( a package
of Cees de Groot in the open cincom repositorty). This package
introduces so called Configurations and Lineups and abandons the use
of "Bundles" totally. Even though, with this package much store
behaviour is made dependent from a package's name (e.g. "* Config"),
it still is a big improvement for Store is our experience. I'm really
curious how other teams (with say at least 5 programmers working on 1
product) can work efficiently with Store without this package.

Besides "configurations", "overrides" are also not well supported in
Store. We try not to use them as much as possible. The problem is;
when you load an individual package, which has an overriden method in
the image, it will override it again.

greetings,

Mathieu van Echtelt



On Mon, Oct 5, 2009 at 9:52 AM, Dennis Schetinin <[hidden email]> wrote:

> The name is very interesting, and I remember it mentioned on blogs... But no
> comments for the bundles in Open Repository and many unrevealed dependecies
> preventing it to be loaded in 7.6 makes it a secret weapon...
>
> BTW, the lack of comments in Open Repository and usually sophisticated
> process of loading (a bunch of prerequisites each having a lot of versions)
> still (it's for years now) prevent beginners (students for example) from
> using it (Open Repository) and sequentially VisualWorks. What about putting
> some order there?
>
> --
> Dennis Schetinin
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>



--
AG5
Timorplein 37
1094 CC
Amsterdam

T  020  4630942
F  020  4630946
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Cincom's Store roadmap. Re: What is Linkuistics?

Ulli Wenk
ON YOUR "...I'm really curious how other teams (with say at least 5 programmers working on 1 product) can work efficiently with Store without this package."

Since 7 years, we have the strategy:

0) We ensured (by simple modifications of setting blessings and pre-checking publishing) that there is for every pundle a unique integration-ready version.

1) There is one central bundle containing all subpundles of our application in ANY version (at first it was the (most recent) integration-ready version).

2) We've written a load-method, doing the following:

Load the (most recent) integration-ready (= i-r) version of all subpundles of the central bundle, i.e. trace thru (contained items (=CIs) of) the central bundle and:

a) if a CI is a bundle that has a more recent i-r version, than unload all no more needed subpundles and continue the process with the contained items of the more recent i-r version

b) if a CI is a package load the most recent i-r version.

3) If a developer wants to publish a package s/he merges all from the i-r version and publishs as i-r (our default)

4) If s/he has to add a new bundle B into a superbundle A, he has to edit the specification of A and to publish A as i-r.

Thus every developer can load the most recent sources of the whole team and can publish at every time he wants. Cause we are checking (in the moment of publishing in DB) that your package version is child of the last i-r, the problems of two parallel publisher does not occur. The last of these two publisher gets a message that there is a more recent i-r version of the parent package where from he started before merging.


Mathieu van Echtelt-2 wrote
Hi list,

We're are also curious about Cincom's Store roadmap. e.g. they
mentioned introducing "Configuration" support a long time ago but as
far as I know, there isn't much progress in the area.

Since playing with vw7.7 many store-extensions we are using do not
work anymore. I suppose this is because Store/VW interaction is now
Glorp based. This will hopefully kick-start some  long planned
improvements.  Before we start migrating all our store extensions to
be glorp aware, I would like to know more about Cincoms' store roadmap
and what has changed since 7.6. This will help us make the right
decisions.

about "Store lineup extensions":

We're especially heavy users of  "Store lineup extensions" ( a package
of Cees de Groot in the open cincom repositorty). This package
introduces so called Configurations and Lineups and abandons the use
of "Bundles" totally. Even though, with this package much store
behaviour is made dependent from a package's name (e.g. "* Config"),
it still is a big improvement for Store is our experience. I'm really
curious how other teams (with say at least 5 programmers working on 1
product) can work efficiently with Store without this package.

Besides "configurations", "overrides" are also not well supported in
Store. We try not to use them as much as possible. The problem is;
when you load an individual package, which has an overriden method in
the image, it will override it again.

greetings,

Mathieu van Echtelt



On Mon, Oct 5, 2009 at 9:52 AM, Dennis Schetinin <chaetal@gmail.com> wrote:
> The name is very interesting, and I remember it mentioned on blogs... But no
> comments for the bundles in Open Repository and many unrevealed dependecies
> preventing it to be loaded in 7.6 makes it a secret weapon...
>
> BTW, the lack of comments in Open Repository and usually sophisticated
> process of loading (a bunch of prerequisites each having a lot of versions)
> still (it's for years now) prevent beginners (students for example) from
> using it (Open Repository) and sequentially VisualWorks. What about putting
> some order there?
>
> --
> Dennis Schetinin
>
> _______________________________________________
> vwnc mailing list
> vwnc@cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>



--
AG5
Timorplein 37
1094 CC
Amsterdam

T  020  4630942
F  020  4630946
_______________________________________________
vwnc mailing list
vwnc@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Cincom's Store roadmap. Re: What is Linkuistics?

Mathieu van Echtelt-2
Thanks for your detailed explanation.

I do not understand all the details of your approach, but what I do
understand is that your approach is also dependent from extensions you
made yourself.  Which is fine but is something I would like to avoid.
Especially for source code management systems, which are about sharing
code between versions, projects and people. Having
extension made ourselves is now one of the problems we encounter
during migration to VW7.7.

About the podcast James mentioned:

Good to hear Cincom takes Store's progress serious and have 2
dedicated experts working on it.

In the interview is also the remark:
VW/Store will "for sure not" have import/export functionality with
file based scm systems like subversion, cvs.

The projects I worked on for the last 10 years always had other than
Smalltalk technologies involved, and these are mostly managed with
these file based scm systems. More cooperation would be good for
Smalltalk is my opinion.

I'm still curious how e.g. Cincom is able to manage all their source
code, they are with many developers working on at least 3 complex
products (VW, OS, WV) and (hopefully) also share code between these
Smalltalk products. But it is probabely better to wait till I meet a
Cincom developer, sitting behind a computer helps so much to
understand/explain such a difficult thing as scm, which is partly
about tools, partly about work processes (and so far, also partly
about self made extensions:).

greetings,
Mathieu

On Tue, Oct 6, 2009 at 11:21 AM, Ulli Wenk <[hidden email]> wrote:

>
> ON YOUR "...I'm really curious how other teams (with say at least 5
> programmers working on 1 product) can work efficiently with Store without
> this package."
>
> Since 7 years, we have the strategy:
>
> 0) We ensured (by simple modifications of setting blessings and pre-checking
> publishing) that there is for every pundle a unique integration-ready
> version.
>
> 1) There is one central bundle containing all subpundles of our application
> in ANY version (at first it was the (most recent) integration-ready
> version).
>
> 2) We've written a load-method, doing the following:
>
> Load the (most recent) integration-ready (= i-r) version of all subpundles
> of the central bundle, i.e. trace thru (contained items (=CIs) of) the
> central bundle and:
>
> a) if a CI is a bundle that has a more recent i-r version, than unload all
> no more needed subpundles and continue the process with the contained items
> of the more recent i-r version
>
> b) if a CI is a package load the most recent i-r version.
>
> 3) If a developer wants to publish a package s/he merges all from the i-r
> version and publishs as i-r (our default)
>
> 4) If s/he has to add a new bundle B into a superbundle A, he has to edit
> the specification of A and to publish A as i-r.
>
> Thus every developer can load the most recent sources of the whole team and
> can publish at every time he wants. Cause we are checking (in the moment of
> publishing in DB) that your package version is child of the last i-r, the
> problems of two parallel publisher does not occur. The last of these two
> publisher gets a message that there is a more recent i-r version of the
> parent package where from he started before merging.
>
>
>
> Mathieu van Echtelt-2 wrote:
>>
>> Hi list,
>>
>> We're are also curious about Cincom's Store roadmap. e.g. they
>> mentioned introducing "Configuration" support a long time ago but as
>> far as I know, there isn't much progress in the area.
>>
>> Since playing with vw7.7 many store-extensions we are using do not
>> work anymore. I suppose this is because Store/VW interaction is now
>> Glorp based. This will hopefully kick-start some  long planned
>> improvements.  Before we start migrating all our store extensions to
>> be glorp aware, I would like to know more about Cincoms' store roadmap
>> and what has changed since 7.6. This will help us make the right
>> decisions.
>>
>> about "Store lineup extensions":
>>
>> We're especially heavy users of  "Store lineup extensions" ( a package
>> of Cees de Groot in the open cincom repositorty). This package
>> introduces so called Configurations and Lineups and abandons the use
>> of "Bundles" totally. Even though, with this package much store
>> behaviour is made dependent from a package's name (e.g. "* Config"),
>> it still is a big improvement for Store is our experience. I'm really
>> curious how other teams (with say at least 5 programmers working on 1
>> product) can work efficiently with Store without this package.
>>
>> Besides "configurations", "overrides" are also not well supported in
>> Store. We try not to use them as much as possible. The problem is;
>> when you load an individual package, which has an overriden method in
>> the image, it will override it again.
>>
>> greetings,
>>
>> Mathieu van Echtelt
>>
>>
>>
>> On Mon, Oct 5, 2009 at 9:52 AM, Dennis Schetinin <[hidden email]>
>> wrote:
>>> The name is very interesting, and I remember it mentioned on blogs... But
>>> no
>>> comments for the bundles in Open Repository and many unrevealed
>>> dependecies
>>> preventing it to be loaded in 7.6 makes it a secret weapon...
>>>
>>> BTW, the lack of comments in Open Repository and usually sophisticated
>>> process of loading (a bunch of prerequisites each having a lot of
>>> versions)
>>> still (it's for years now) prevent beginners (students for example) from
>>> using it (Open Repository) and sequentially VisualWorks. What about
>>> putting
>>> some order there?
>>>
>>> --
>>> Dennis Schetinin
>>>
>>> _______________________________________________
>>> vwnc mailing list
>>> [hidden email]
>>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>>
>>>
>>
>>
>>
>> --
>> AG5
>> Timorplein 37
>> 1094 CC
>> Amsterdam
>>
>> T  020  4630942
>> F  020  4630946
>> _______________________________________________
>> vwnc mailing list
>> [hidden email]
>> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>>
>>
>
> --
> View this message in context: http://www.nabble.com/-vwnc--Cincom%27s-Store-roadmap.-Re%3A--What-is-Linkuistics--tp25748114p25765375.html
> Sent from the VisualWorks mailing list archive at Nabble.com.
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>



--
AG5
Timorplein 37
1094 CC
Amsterdam

T  020  4630942
F  020  4630946

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
Reply | Threaded
Open this post in threaded view
|

Re: [vwnc] Cincom's Store roadmap. Re: What is Linkuistics?

Alan Knight-2
In reply to this post by Mathieu van Echtelt-2
We have internal designs for supporting larger-scale organizational units, which we have internally been calling Projects, but you are correct in that that has not moved forward recently. It's something that I think you want to think pretty carefully about before putting out an implementation.

There's quite a lot of work on Store in this release. In addition to the internals of most parts of it now using the StoreGlorp back-end, it also uses shadow (or atomic) loading by default. Both of these are things that have the potential to break extensions which rely on the old mechanisms. But we think that they provide quite significant benefits. With a stronger model in the back-end, it should also be fairly easy to update old extensions. The next major thing on the agenda is work on the merge and comparison tools. These are not yet Glorp-based, and there are a few other issues with the existing tools that users have mentioned over the years.

In terms of more details of what has changed I'll refer you to the 7.7 release notes (once 7.7 is released, I don't think most of that information is there yet) and to the fixed_ars.txt list for an exhaustive list of ARs.

I will mention that there was also a lot of work done on fixing issues with overrides, although the particular one that you mention is not yet addressed.

At 05:59 AM 2009-10-05, Mathieu van Echtelt wrote:
Hi list,

We're are also curious about Cincom's Store roadmap. e.g. they
mentioned introducing "Configuration" support a long time ago but as
far as I know, there isn't much progress in the area.

Since playing with vw7.7 many store-extensions we are using do not
work anymore. I suppose this is because Store/VW interaction is now
Glorp based. This will hopefully kick-start some  long planned
improvements.  Before we start migrating all our store extensions to
be glorp aware, I would like to know more about Cincoms' store roadmap
and what has changed since 7.6. This will help us make the right
decisions.

about "Store lineup extensions":

We're especially heavy users of  "Store lineup extensions" ( a package
of Cees de Groot in the open cincom repositorty). This package
introduces so called Configurations and Lineups and abandons the use
of "Bundles" totally. Even though, with this package much store
behaviour is made dependent from a package's name (e.g. "* Config"),
it still is a big improvement for Store is our experience. I'm really
curious how other teams (with say at least 5 programmers working on 1
product) can work efficiently with Store without this package.

Besides "configurations", "overrides" are also not well supported in
Store. We try not to use them as much as possible. The problem is;
when you load an individual package, which has an overriden method in
the image, it will override it again.

greetings,

Mathieu van Echtelt



On Mon, Oct 5, 2009 at 9:52 AM, Dennis Schetinin <[hidden email]> wrote:
> The name is very interesting, and I remember it mentioned on blogs... But no
> comments for the bundles in Open Repository and many unrevealed dependecies
> preventing it to be loaded in 7.6 makes it a secret weapon...
>
> BTW, the lack of comments in Open Repository and usually sophisticated
> process of loading (a bunch of prerequisites each having a lot of versions)
> still (it's for years now) prevent beginners (students for example) from
> using it (Open Repository) and sequentially VisualWorks. What about putting
> some order there?
>
> --
> Dennis Schetinin
>
> _______________________________________________
> vwnc mailing list
> [hidden email]
> http://lists.cs.uiuc.edu/mailman/listinfo/vwnc
>
>



--
AG5
Timorplein 37
1094 CC
Amsterdam

T  020  4630942
F  020  4630946
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

--
Alan Knight [|], Engineering Manager, Cincom Smalltalk

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc