[GemStone-Smalltalk] Class names and VisualWorks namespaces

Tue Nov 24 10:23:55 PST 2020

Hey Annick,

My experience has been quite different.  With the exception of dealing with namespaces, and the retro-looking breakpoints in the debugger, GBS has been an absolute pleasure to use.  The GBS tools are outstanding...I’ve never seen anything that touches them in Smalltalk or otherwise.  On the server side, the database is feature-laden and much more performant than GOODS, for example.

I know exactly what you mean about dealing with references to transient objects.  All transparent persistence frameworks I’ve ever used need metadata in cases where you don’t want to persist certain I-vars.   For me, coming from GOODS, I already had this in place and just needed to convert it to GemStone.  I found that turning off automatic server class generation can help you track those down during development.

I haven’t had any NetLDI issues except having to remember to modify  /etc/services every time I switch machines :(  I’m running GemStone in docker, if that makes a difference (https://github.com/cdavidshaffer/gemstone-docker, https://github.com/jgfoster/DockerForGemStone <https://github.com/jgfoster/DockerForGemStone>).  

I feel like I’m on the cusp of resolving the namespace issue well enough for my purposes.  Unfortunately, the class resolution mechanism used in GemStone (symbol lists) doesn’t make a good proxy for VW namespaces.  Its the approach I’m using now and I’ll probably stick with it for this project.  Another option would have been to prefix the server /class names/ with the VW namespace.  Worth considering...

Best,

David

> On Nov 24, 2020, at 4:26 AM, Annick Fron <annick.fron at afceurope.com> 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 <gemstone-smalltalk at lists.gemtalksystems.com <mailto:gemstone-smalltalk at lists.gemtalksystems.com>> 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 <http://gemstoneassessment.st/>>
>> 
>>> On Nov 23, 2020, at 6:34 PM, Martin McClure <martin.mcclure at gemtalksystems.com <mailto:martin.mcclure at gemtalksystems.com>> 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 <richard.sargent at gemtalksystems.com <mailto:richard.sargent at gemtalksystems.com>> wrote:
>>>>> 
>>>>> On Tue, Oct 27, 2020 at 7:48 PM David Shaffer via GemStone-Smalltalk <gemstone-smalltalk at lists.gemtalksystems.com <mailto:gemstone-smalltalk at lists.gemtalksystems.com>> 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
>>>>> GemStone-Smalltalk at lists.gemtalksystems.com <mailto:GemStone-Smalltalk at lists.gemtalksystems.com>
>>>>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk <https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> GemStone-Smalltalk mailing list
>>>> GemStone-Smalltalk at lists.gemtalksystems.com <mailto:GemStone-Smalltalk at lists.gemtalksystems.com>
>>>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk <https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk>
>>> 
>> 
>> _______________________________________________
>> GemStone-Smalltalk mailing list
>> GemStone-Smalltalk at lists.gemtalksystems.com <mailto:GemStone-Smalltalk at lists.gemtalksystems.com>
>> https://lists.gemtalksystems.com/mailman/listinfo/gemstone-smalltalk
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gemtalksystems.com/mailman/private/gemstone-smalltalk/attachments/20201124/5d3e4b05/attachment-0001.htm>