Support

What this page is

If you maintain a workflow that depends on Ubigraph-era tooling, or you have been asked to bring an old graph visualisation example back to life, this page is for you. It is written as a small set of notes from the same point of view as the rest of the site: careful, direct, and honest about what is uncertain.

There is no ticket queue here. There is no formal SLA. The contact page is the way to reach the maintainer when a question genuinely needs a person rather than a page.

Where to start when something will not run

A general routine that works for almost any old example:

1. Get a clean Python environment with the version you intend to use.
2. Confirm the XML-RPC client side works at all by talking to a stub server that just logs calls.
3. Bring up the viewer separately and confirm it is listening on the port you expect.
4. Point your client at the viewer and try the smallest possible call - one vertex, one edge.
5. Only after that succeeds, run the actual example you care about.

Skipping any of those steps usually means debugging two unrelated problems at once.

Common environment problems

A short list of issues that come up repeatedly:

• Python 2 idioms in the example code. Print statements, urllib paths, xmlrpclib instead of xmlrpc.client. None of these are hard to fix. Together they account for most of the time you will spend porting an example.
• Network port already in use. A previous viewer process is still listening. Restart cleanly.
• Graphics drivers. Older 3D applications sometimes rely on features that current drivers no longer expose in the same way. Running inside a virtual machine with an older driver stack can isolate the problem.
• Encoding mismatches. Strings going to or from the server need consistent handling on both sides. Python 3 is stricter here than older code expects.
• Calls that no longer exist in your wrapper. If you are using a third-party wrapper, the calls available to you may not match what the example was written against.

None of these are unique to Ubigraph. They are the usual hazards of running older software on a current system.

Common client problems

If the network and the environment are fine but calls still fail:

• Wrong server URL. XML-RPC requires the exact path, including the trailing endpoint segment.
• Wrong namespacing on the call. Some wrappers expose the calls under a namespace, some do not. Read the wrapper you are using.
• Server expects different argument types. A vertex identifier is usually an integer. Passing a string can fail silently.
• No call batching. XML-RPC is not designed for high call rates. If you are sending tens of thousands of calls per second, you are pushing the protocol harder than it was meant to be pushed.
• No retries. If a call fails, you have to decide how to retry. The protocol does not do it for you.

The docs index is the right reference for the call surface.

Common viewer problems

If your client looks healthy but nothing appears in the viewer:

• The viewer is running but is not visible. Window placement on multi-monitor systems can hide a viewer entirely. Check window listings.
• The viewer received no calls. Confirm by sending a single call from a separate process. If that call appears, your real client is the problem. If it does not, the viewer connection is the problem.
• The layout has not yet settled. A viewer with a slow layout pass may take a few seconds to show the first useful picture.
• Visual attributes are wrong, not missing. A node with the same colour as the background is invisible. Set an obvious colour first.

When to give up on the original tooling

There is no shame in this. If your goal is the workflow rather than the specific binary, switching to a modern graph drawing library is often the more sensible move. The graph visualisation alternatives lab note covers the categories worth knowing about.

A reasonable rule of thumb: if you have spent more than a few hours fighting the viewer and have not made measurable progress, write down what you needed the viewer to do, and look at whether a current library does it in less time.

Backing up what you have

If you are running an old workflow that still works, do not assume tomorrow will be the same as today.

• Keep a snapshot of the working virtual machine or container image.
• Keep copies of the example code you depend on, somewhere outside the running environment.
• Document the exact versions of any wrappers you rely on.
• Write down the smallest reproducer for each behaviour you care about.

A small amount of preservation effort goes a long way when the underlying environment shifts.

Questions that are out of scope

There are a few things this site does not try to do:

• Confirm or distribute Ubigraph-era binaries.
• Answer general C++ template metaprogramming questions outside the papers section.
• Provide a graph theory tutorial. The Ubigraph pillar covers what is needed for context.
• Provide consulting hours. The contact page is for substantive questions, not for project work.

If the question you have lives outside that boundary, the honest answer is usually that you will be better served by a current general resource than by this site.

Useful next pages

• Ubigraph pillar
• Demo index
• Docs index
• Downloads notes
• FAQ
• Contact
• Lab notes index

The short version

If something will not run, take it one layer at a time. Confirm the client. Confirm the viewer. Confirm the network. Confirm the call shape. Then look at the actual example. If the layers all check out and the example still will not behave, you are probably hitting the edge of how well the old toolchain interacts with current systems, and that is the point at which a modern substitute starts to look attractive.