DCFile broken in 1.1.0??

I have been having tremendous troubles in trying to get the high level networkin API to work in panda3d 1.1.0

I installed 1.0.5 by itself and tried out the networking tutorial (the chatroom example). When I tried to use it in 1.1.0 it appears that the DCFile class cannot correctly read in the sample.dc file pointed to. I tried pointing to the sample.dc file both in the config.prc file and hard-coding in “sample.dc” in the tutorial’s code. The error that I get is withing readDCFile inside ServerRepository.py and the output is “Could not read dc file: s”
Looks to me like DCFile is not reading in the entire string that I fed it.
What do you ppl think?
-RC

Sometimes there is a more useful error message printed out before the Python code raises the exception that causes the final error message to be printed. Scroll back up in your output, and see if there is some syntax error message printed before the traceback begins.

You can also use the program dcparse to validate the syntax of your dc file, e.g.:


dcparse file.dc

I don’t know why the error message is not printing the name of your dc file. That’s kind of weird. What call are you using to invoke it?

David

Thanks for the reply drwr!

All that I have done is taken the directory called Feature-Tutorials–Netoworking from the 1.0.5 sample code and placed it in my 1.1.0 samples directory, changed the paths of the shortcuts to follow the 1.1.0 directory, as well as adding the line “dc-file sample.dc” to the config.prc file in 1.1.0 since it was missing.

Here is part of the traceback from when I run the program:

File "C:\Panda3D-1.1.0\samples\Feature-Tutorials--Netowrking\chatcore.py", line 231, in initiateConnection
    self.serverrepository = ServerRepository(tcpPort=19233, udpPort=19233)
File "C:\Panda3D-1.1.0\direct\src\distributed\ServerRepository.py", line 44, in __init__
   self.readDCFile(dcFileNames)
File "C:\Panda3D-1.1.0\direct\src\distributed\ServerRepository.py", line 95, in readDCFile
    self.notify.error("Could not read dc file.")
...

Then I went into chatcore.py and called the ServerRepository with explicitly defined dcFileNames:


File "C:\Panda3D-1.1.0\samples\Feature-Tutorials--Netowrking\chatcore.py", line 231, in initiateConnection
    self.serverrepository = ServerRepository(tcpPort=19233, udpPort=19233, dcFileNames="sample.dc")
File "C:\Panda3D-1.1.0\direct\src\distributed\ServerRepository.py", line 44, in __init__
   self.readDCFile(dcFileNames)
File "C:\Panda3D-1.1.0\direct\src\distributed\ServerRepository.py", line 100, in readDCFile
    self.notify.error("Could not read dc file: %s" % (dcFileName))
File "C:\Panda3D-1.1.0\direct\src\directnotify\Notifier.py", line 121, in error
    raise exception(errorString)
StandardError: Could not read dc file: s

the output of dcparse is:

Error in sample.dc at line 10, column 52:
   setPigLatinFlag(int16 flag) required broadcast p2p;
                                                    ^

parse error

So, in looking at sample.dc in the doc directory in either 1.1.0 or 1.0.5 (same in each) I noticed that they had db in place of p2p so I tried that instead and it seemed to help it accept sample.dc. However, I then began running into the fact that there are many changes in ClientRepository since 1.0.5 such as the lack of the method ‘sendSetZoneMsg’.

What should I do? I’d really love to get this high level API working in 1.1.0!

Thanks again
RC

There is a bug in ServerRepository (lines 96-100). There is an iteration over a variable dcFileNames, which means if a string is passed in, it iterates over the characters in the string. It couldn’t read the dc file ‘s’, giving the error message.

The quick fix would be to wrap the name of the dc file in a list.

Ah, so it is. ServerRepository.readDCFile() expects the parameter called dcFileNames to be a list of strings, not a single string. Whether this is a bug or a misunderstanding of the interface is open to some debate, but I agree that ServerRepository could be written to check whether it was given a single string. :slight_smile:

There appear to be a number of methods that have inadertently been removed from ClientRepository by Panda3d 1.1.0. I am not sure why this was done, or if it was done intentionally; I will investigate.

David

I didn’t mean to sound so accusative. And you are right, the interface might require a list. I was thinking if it did, it should probably have an assert statement (or other check) to make sure it is a list type. If the user passed in something else an informative error could then be thrown.
Or it could account for string types also.
Even so, I would guess there should be a check on whatever type is passed in to make sure readDCFile can handle it.

So besides the passing a list versus a file name problem, is the clientrepository and serverrepository code functional and able to be used in panda 1.1.0 ? (nevermind if it’s documented or not)

Thanks,
Tim

No, it looks like some changes were accidentally checked in that prevent this from working in Panda3D 1.1.0. I have checked in a corrected version to the CVS version of Panda; this will be released with a future version.

Sorry about that.

David

Thank you very much drwr!!!

I just downloaded the files you modified from the cvs and plugged them into my 1.1.0 directories, and after making 1 change in the demo code I got it to work! (sort of)

The only thing that still gave me a problem was that the DCfile class still wont read in the sample.dc file if it has p2p as an argument to a function such as:


setPigLatinFlag(int16 flag) required broadcast p2p;

I simply changed any instance of “p2p” with “db” because I saw the sample.dc file in the doc’s included with the source for 1.1.0 used “db”.

(Does anyone know what db stands for here? I realize p2p is peer to peer)

As a result, the chat clients work (at least on the same host, haven’t tried separate computers yet), with the exception that any given instance of a host does not see the messages that it sends.

Try putting the following line in the beginning of your dc file:

keyword p2p;

The ‘p2p’ keyword is no longer built-in to the DC syntax. In fact, we are phasing out all of these built-in keywords.

David