Replicating DLLCC stuff

Dear all,

I use the GemStone GemBuilder for Smaltalk (GB/S) library and I keep
the code in my Store repository.  This has worked fine, until now.

I have just set up a new Store instance on a PostgreSQL server
instance running on my MacBook.  I have replicated (using the Glorp
replicator) the contents of my current working repository to the new
one.  Everything works fine except for GB/S.  If I load GB/S from one
of my established repositories all is well and I can use GB/S to talk
to my GemStone servers.  If I load GB/S from the new replica
repository it fails to connect to any GemStone database and it looks
like it is having DLLCC problems.

Has anyone else seen any problems with:

o replicating code that used DLLCC between Store repositories?
o repositories using PostgreSQL running on OS/X?

Thanks,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

Dear Bruce,

could this be another instance of the problem that typedefs are
sometimes compiled in the wrong order when loading ExternalInterfaces
from parcels or from Store? If so, it could help to send
#recompileMethods to all subclasses of ExternalInterface after loading
the packages.

HTH,
Joachim

Bruce Badger schrieb am 20.04.2007 21:03:

On 20/04/07, Joachim Geidel <[hidden email]> wrote:
> could this be another instance of the problem that typedefs are
> sometimes compiled in the wrong order when loading ExternalInterfaces
> from parcels or from Store? If so, it could help to send
> #recompileMethods to all subclasses of ExternalInterface after loading
> the packages.

Your suggestion fixed the problem.  I have added a post load action to
use >>recompileMethods as you suggest and everything works nicely now.

Many thanks.

Very best regards,
    Bruce
--
Make the most of your skills - with OpenSkills
http://www.openskills.org/

At 04:38 PM 4/20/2007, Bruce Badger wrote:

On 20/04/07, Joachim Geidel <[hidden email]> wrote:

could this be another instance of the problem that typedefs are
sometimes compiled in the wrong order when loading ExternalInterfaces
from parcels or from Store? If so, it could help to send
#recompileMethods to all subclasses of ExternalInterface after loading
the packages.

Your suggestion fixed the problem.  I have added a post load action to
use >>recompileMethods as you suggest and everything works nicely now.

Hmm, it's possible this might be due to the replication modifying the order of methods if it works in the original but not in the replicated version. It tries to preserve the order, but something might have gone wrong with. At least that's the most likely reason I can think of.