[Smtk-developers] SMTK code review, more Remus debugging

[David Thompson]

> Overall the branch looks good to me. I might have missed it but when a
> bridge starts a server how do you capture and advertise what the
> endpoint back to that server is?

It's easy to miss and only minimally functional, but when RemusBridgeConnection::connectToServer is followed by a call to bridgeNames(), the BridgeRegistrar is told of new bridges; the smtk::function that the BridgeRegistrar is given to create a bridge will create a RemuteRemoteBridge configured to that endpoint. (I use smtk::function there so that I can pass in a functor that knows the proper endpoint and worker info to use.)

The problems I'm having now are

1. The unit test works from a command line but not from ctest (unitRemusBridgeConnection starts a process-local server -- which finds a remus-worker file, starts the worker specified by the test, and runs a "read" operation on a test file via the worker). CTest fails to import things properly and I haven't figured out what's different about the environment variables that's causing the issue

2. The following Python script now runs on the branch but hangs because the worker turns into a zombie process immediately.

  import smtk
  rbc = smtk.bridge.remote.RemusBridgeConnection.create()
  rbc.addSearchDir('/usr/local/var/smtk/workers')
  rbc.connectToServer('local', 50505)
  print smtk.model.Manager.bridgeNames()
  sess = mgr.createSession('smtk::model[cgm{OpenCascade}]')

I haven't had a chance to debug in detail and think the SC demo is more important at the moment.


> In smtk/common/Paths.cxx Have you thought about simplifying the OS
> includes, maybe to something like: ...

I like that it's simpler but prefer to keep the headers ordered with highest sanity at the top and no repetition. :-)

	Thanks,
	David