Class names and VisualWorks namespaces

On Nov 2, 2020, at 12:51 PM, Richard Sargent <[hidden email]> wrote:

On Tue, Oct 27, 2020 at 7:48 PM David Shaffer via GemStone-Smalltalk <[hidden email]> wrote:

Am I misunderstanding or does GemBuilder for VisualWorks ignore VisualWorks namespaces when automatically generating server classes and automatically creating connectors? 

From the GBS for VisualWorks documentation:

GemBuilder deposits automatically generated GemStone server classes in the
GemStone symbol dictionary UserClasses, which it creates if necessary.
Automatically generated client Smalltalk classes are deposited in the current
package.

With respect to the "ignore VisualWorks namespaces" part of your question, I think the best way to answer it is "pretty much".

As noted in the documentation, this automatic class generation is intended as a developer convenience. It is still best to deploy code to each environment in advance of running the application and to predefine the class connectors that could have a conflict or otherwise be unreachable by name lookup.

Best,

David

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

On Nov 2, 2020, at 1:55 PM, Richard Sargent <[hidden email]> wrote:

A quick glance has me thinking it looks good. It seems quite simple, which is always good - if it does the job. :-)

Topological sort may be overkill. Your requirement is to have the superclasses before the subclasses. So the following example might be entirely adequate.

| classes sortedClasses |
classes := Collection withAllSubclasses asSortedCollection: [:a :b | a name > b name].
sortedClasses := classes asSortedCollection: [:a :b | a allSuperclasses size < b allSuperclasses size].

On Mon, Nov 2, 2020 at 10:03 AM David Shaffer via GemStone-Smalltalk <[hidden email]> wrote:

Thanks Richard, I guess I was just looking for confirmation that I had to write this code myself.  At the moment I’m mapping VW namespaces to GS symbol dictionaries (replacing “.” with __ and ignoring containment of one namespace inside another).  This keeps classes unambiguous on the server.  Code attached “kind of” works and comments are welcomed but not expected ;)  Now I have to sort out all of the magic in GbsSession>>createGemStoneClassFor:copyOldVersion: and GbsSession>>doesClientClass:matchServerClass: since those methods handle lots of special cases (class already exists with same/different structure etc) but are, unfortunately, interactive.

(Sorry about the crappy Topological sort…it will need to be revisited if you’re publishing a large number of classes).

Best,

David

On Nov 2, 2020, at 12:51 PM, Richard Sargent <[hidden email]> wrote:

On Tue, Oct 27, 2020 at 7:48 PM David Shaffer via GemStone-Smalltalk <[hidden email]> wrote:

Am I misunderstanding or does GemBuilder for VisualWorks ignore VisualWorks namespaces when automatically generating server classes and automatically creating connectors? 

From the GBS for VisualWorks documentation:

GemBuilder deposits automatically generated GemStone server classes in the
GemStone symbol dictionary UserClasses, which it creates if necessary.
Automatically generated client Smalltalk classes are deposited in the current
package.

With respect to the "ignore VisualWorks namespaces" part of your question, I think the best way to answer it is "pretty much".

As noted in the documentation, this automatic class generation is intended as a developer convenience. It is still best to deploy code to each environment in advance of running the application and to predefine the class connectors that could have a conflict or otherwise be unreachable by name lookup.

Best,

David

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

On Nov 23, 2020, at 6:34 PM, Martin McClure <[hidden email]> wrote:

Hi David,

A bit of additional information that might be useful. As Richard says, GBS currently has no way to control which namespace automatically-generated classes are placed in. However, you can connect an existing class in any VW namespace by specifying an environment to the class connector.

Regards,
-Martin

On 11/2/20 10:03 AM, David Shaffer via GemStone-Smalltalk wrote:

Thanks Richard, I guess I was just looking for confirmation that I had to write this code myself.  At the moment I’m mapping VW namespaces to GS symbol dictionaries (replacing “.” with __ and ignoring containment of one namespace inside another).  This keeps classes unambiguous on the server.  Code attached “kind of” works and comments are welcomed but not expected ;)  Now I have to sort out all of the magic in GbsSession>>createGemStoneClassFor:copyOldVersion: and GbsSession>>doesClientClass:matchServerClass: since those methods handle lots of special cases (class already exists with same/different structure etc) but are, unfortunately, interactive.

(Sorry about the crappy Topological sort…it will need to be revisited if you’re publishing a large number of classes).

Best,

David

On Nov 2, 2020, at 12:51 PM, Richard Sargent <[hidden email]> wrote:

On Tue, Oct 27, 2020 at 7:48 PM David Shaffer via GemStone-Smalltalk <[hidden email]> wrote:

Am I misunderstanding or does GemBuilder for VisualWorks ignore VisualWorks namespaces when automatically generating server classes and automatically creating connectors? 

From the GBS for VisualWorks documentation:

GemBuilder deposits automatically generated GemStone server classes in the
GemStone symbol dictionary UserClasses, which it creates if necessary.
Automatically generated client Smalltalk classes are deposited in the current
package.

With respect to the "ignore VisualWorks namespaces" part of your question, I think the best way to answer it is "pretty much".

As noted in the documentation, this automatic class generation is intended as a developer convenience. It is still best to deploy code to each environment in advance of running the application and to predefine the class connectors that could have a conflict or otherwise be unreachable by name lookup.

Best,

David

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

On Nov 24, 2020, at 4:26 AM, Annick Fron <[hidden email]> wrote:

Hi David,

2 years ago I tried hard during one year to use Gemstone for seamless image distribution, but I ran on severe problems regarding GBS for VW.

For instance, on top of the problems you mentioned, even in the gemstone parcel the namespaces are not properly handled (try a lint on it), and worse Gemstone never recognized any problem.

I also had problems using cairo and forgetting to omit the variables in the persistence process, problems with reconnecting to a broken connection, problems of netldi shutting down independently of the 2 other processes ….

I have completely given up using Gemstone.

Best regards

Annick

Le 24 nov. 2020 à 03:10, David Shaffer via GemStone-Smalltalk <[hidden email]> a écrit :

Thanks Martin,

As you noted, since I have many classes with the same base name I can’t use the automatic tools at all.  My philosophy is that I need “automatic” in the sense that my development cycle shouldn’t be significantly impacted by the fact that some classes have instances stored in Gemstone.  I should be able to continue to create, modify and rename persistent classes in client Smalltalk and generally not worry about Gemstone except migration-related issues.  In addition, the process of populating the class hierarchy in server Smalltalk should be easily reproducible (this was also the advice in the GBS User’s Guide).  My idea was to create a tool that you give a collection of classes and it:

1) makes an assessment of the following:

1a) which namespaces are missing on the server (I map VW namespace to Gemstone SymbolDictionary in the user’s symbol list)?

1b) which classes are missing on the server?

1c) which classes have structural difference between the Gemstone version and the client version?

1d) given session parameters, which connectors are missing or incorrect?

2) Given an assessment, correct as many problems as possible automatically

The reason for the two step process is that you might find that you need to manually fix some of the problems.  For example, in 1b a “missing server class” might actually be a case where you renamed a client Smalltalk class.

I have attached code but, frankly, it looks like amateur hour.  I apologize but I got lost in a maze of private methods that didn’t quite do what I needed.  I finally just gave in and used the private methods in hopes of not being burnt in the next Gemstone release.  There are problems remaining:

1) the method GbsSession>>createServerClassFor:inDictionaryNamed:usingName:generateConnector: uses GbsSession>>gemStoneClassFor: to find the superclass of the class you’re trying to create.  If the class you’re creating’s superclass has not been mapped, the latter method falls back on searching for a SymbolDictionary containing the appropriately named class which can result in the wrong superclass being found.

2) I some cases where I probably should, I don’t consult the session class cache so my code seems to be working on the assumption that their are no classes mapped in the session.  I think this /might/ be OK as I’d only use this tool on a fresh session and most of the (private) methods I use, consult the cache as needed.  Honestly I can’t tell how big a problem this is.

3) I’m calling the following private methods:

   GbsSession>>createServerClassFor:inDictionaryNamed:usingName:generateConnector: 

   Object>>gbxDelegate

   … maybe more that I can’t remember...

But, I was able to use the class side methods as such:

   assessment := GemstoneClassBuilder assessPundlesNamed: #(mybundle myotherbundle etc).

   “Inspect assessment to make sure you’re not going to do something stupid”

   GemstoneClassBuilder correctAsssessment: assessment.

...and it populated Gemstone with 1000+ classes….well, actually I had to run the same code a few times before it decided that all of the required Gemstone classes existed.  But, the result looks OK.  There are a few classes that have multiple versions (maybe in different SymbolDictionaries?) but I feel like I’m close.

I’m a bit embarrassed to share this code…I’m kind of hoping someone will simply tell me that I’ve missed an obvious ways to do this. Criticism, constructive or otherwise, is welcomed.

Best,

David

<GemstoneAssessment.st>

On Nov 23, 2020, at 6:34 PM, Martin McClure <[hidden email]> wrote:

Hi David,

A bit of additional information that might be useful. As Richard says, GBS currently has no way to control which namespace automatically-generated classes are placed in. However, you can connect an existing class in any VW namespace by specifying an environment to the class connector.

Regards,
-Martin

On 11/2/20 10:03 AM, David Shaffer via GemStone-Smalltalk wrote:

Thanks Richard, I guess I was just looking for confirmation that I had to write this code myself.  At the moment I’m mapping VW namespaces to GS symbol dictionaries (replacing “.” with __ and ignoring containment of one namespace inside another).  This keeps classes unambiguous on the server.  Code attached “kind of” works and comments are welcomed but not expected ;)  Now I have to sort out all of the magic in GbsSession>>createGemStoneClassFor:copyOldVersion: and GbsSession>>doesClientClass:matchServerClass: since those methods handle lots of special cases (class already exists with same/different structure etc) but are, unfortunately, interactive.

(Sorry about the crappy Topological sort…it will need to be revisited if you’re publishing a large number of classes).

Best,

David

On Nov 2, 2020, at 12:51 PM, Richard Sargent <[hidden email]> wrote:

On Tue, Oct 27, 2020 at 7:48 PM David Shaffer via GemStone-Smalltalk <[hidden email]> wrote:

Am I misunderstanding or does GemBuilder for VisualWorks ignore VisualWorks namespaces when automatically generating server classes and automatically creating connectors? 

From the GBS for VisualWorks documentation:

GemBuilder deposits automatically generated GemStone server classes in the
GemStone symbol dictionary UserClasses, which it creates if necessary.
Automatically generated client Smalltalk classes are deposited in the current
package.

With respect to the "ignore VisualWorks namespaces" part of your question, I think the best way to answer it is "pretty much".

As noted in the documentation, this automatic class generation is intended as a developer convenience. It is still best to deploy code to each environment in advance of running the application and to predefine the class connectors that could have a conflict or otherwise be unreachable by name lookup.

Best,

David

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk

_______________________________________________
GemStone-Smalltalk mailing list
[hidden email]
https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk