Common Ygor Problems & Known Bugs

Common Ygor Problems & Known Bugs

Make Related Errors

Make error ".depend file not found" Makefiles always attempt to include a file named .depend. When this error is encountered, try running touch .depend, and run make again.
Make error "unexpected end of file at..." This error is very cryptic. Usually this occurrs when the make program in /usr/ccs/bin is used instead of gnu make. Make sure that gnu make is used.

Compiler/Environment Setup

YGOR_TELESCOPE not set exiting... The environment variable YGOR_TELESCOPE must be set to the installation directory (e.g. /home/gbt or /home/sim)

Data Description Problems

Error message "No dd for id 0.0.0.x" This is usually caused by one of two problems:
- The first is due to not adding the manager's DDL to the Panel. This can be done directly by creating a DDL for your manager and calling PanelData::addDDL(). The other way is to use panelAccess() to dynamically load the DDL. (panelAccess make the PanelData::addDDL() call internally.) Yet another [easier] method is to use the DeviceAccessContainer class.
- The other common cause of this problem, is due to not passing the Manager's baseId to the Manager base constructor properly. (This used to be a problem when using mngrgen.)
Some data structures cannot be easily represented using DataDescriptions. DataDescriptors can only describe data types which are a contiguous block of memory. (So things like linked lists, string pointers, STL containers, etc. cannot be used.)

Manager core dumps for an unknown reason. Well of course this could be anything. But for some unfortunate reason, I seem to have run into this problem too many times. Often this is due to a rearangement of the Managers parameter enumerations. Adding an enumeration without adding the code to the manager constructor is the cause. I usually add the following code to the end of my Manager constructor:

for (int i = ManagerId::ParameterCount; i < MyManagerId::ParameterCount; ++i)
{
    if (p[i] == 0)
    {
        print a warning !
    }
}

'C' code

Rule #1: Only if you must, and with great care.

I ran across this one recently: In file foo1.c:

void foo(float a, float b, int c)
{
}

and referenced by a function in another file:

void bar()
{
    foo( (float)1.0, (float)2.0, (int) 3);
}

No worries right? But in foo none of the values of a,b or c are correct. Why? Well because without a prototype, the call to foo() places the floating point values onto the stack as doubles! The simple fix here is to place a prototype somewhere in an include file, so that the values are properly placed on the stack. (Of course it helps to add the -ansi and -Wall flags to gcc, but a call without a prototype is only a warning.) I should point out that this 'automatic float to double' conversion is both a feature, and a bug. This 'feature' is what allows %f to be used in printf() for both float and double types.

Alternatively, never use 'float' in argument lists, rather use double. It is my opinion that the float type will eventually become antiquated for PC-level applications. (How many of us still use the 'short' type?)

Win32 Errors

Under Win32 unusedRPCNumber() fails. This often occurrs when the Win32 portmapper has zero programs registered. If you execute rpcinfo -p host and it replies "No programs registered", than this is the problem. (This is because unusedRPCNumber() can't tell the difference between no programs registered and a communications error.) Temporary fix is to create a RPCserver, prior to calling unusedRPCNumber(). DataDescList and Transporter::addDescriptorList() It should be noted that Transporter::addDescriptorList() deletes the container list passed into this method. The DataDescriptors themselves are not deleted.

-- JoeBrandt - 24 May 2008

WebForm
TopicClassification:	NoDisclosure
OperatingSystem:
OsVersion:

Topic YgorProblemsAndKnownBugs . { Edit | Attach | Ref-By | Printable | Diffs | r1.3 | > | r1.2 | > | r1.1 | More }

Revision r1.3 - 28 May 2008 - 21:06 GMT - JoeBrandt Parents: MnCKnowledge	Content copyright © 1999-2007 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.