Still unable to run PARPG, now with "too many opened files" error

[Knitter]

Hi,

I've been struggling to get PARPG to run, yes I know that others have had success in this little endeavor but I'm failing miserably . I had, and still have, several exceptions about missing files though I've confirmed that they are indeed in the correct folder, what's worse, some files are found others aren't. I've got around that problem by testing a few combinations and after knowing what files give the exception I ignored the problematic files.

Yes, this is not a way to solve the problem, I just wanted to see if I could debug it further. I added a few IF statements that just jump over the "non existing" files.

Now I get a nice exception that tells me that I have too many opened files.

Code:

Traceback (most recent call last):
  File "parpg.py", line 49, in <module>
  File "../parpg/main.py", line 76, in main
  File "../parpg/application.py", line 130, in __init__
  File "../parpg/gamemodel.py", line 875, in getDialogues
  File "../parpg/common/utils.py", line 47, in locateFiles
  File "/Users/sergio/Working/FIFE/engine/python/fife/fife.py", line 12190, in listFiles
RuntimeError: _[Exception]_ , Generic FIFE exception :: boost::filesystem::directory_iterator::construct: Too many open files: "/Users/sergio/Working/PARPG/parpg-data/dialogue"

I haven't looked at the utils.py file and will do it next, but I was hoping someone had some light to shed on why this is being so complicated.

All the libs are here, I'm running the parpg.py script from inside the bin folder with the proper parameters (-m .. and -p with FIFE path) and I have changed the settings file with the proper data folder path. I know the files are there, I know some files in the data folder are being picked up while other aren't, I have no idea why this is happening.

I'm trying to run PARPG on OS X Lion, standard HFS filesystem (case insensitive), with python 2.7 and FIFE rev. 3891

[Beliar]

I really wish I could help you, but I have no idea what the problem could be.

Can you run the fife demos?

[Knitter]

Yes, if I navigate into the demos folder, I can run all the demos including the pychan ones without errors with my compiled FIFE module.

[Zimble]

Could you check your system setting on how many concurrent open files are allowed?

Code:

launchctl limits

(in a console)

I checked this on a mac osx of a coworker and it said only 256 files are allowed.
maybe that's the problem.

[Knitter]

It seems that each time an exception is thrown the files are not properly closed, if I run parpg.py several times trying to see what is happening I reach the opened file limit. I don't know if it happens only due to PARPG/FIFE or due to the debugger I'm using (puDB).

So, back to the original problem, some XML files are reported as not found yet they are in the correct place. The only thing I can seem to find is that while in gamemodel.py (getAgentImportFiles) loading several XML definition files, some are not found while others load correctly. When a file is not found the load throws an exception.

If I put a few if/continue to ignore the files that are reported as missing, the game continues to load but will fail when trying to load the font file, failing with something along the lines of "oldtypewriter module not found".

[Knitter]

And it runs!

It was really related to the opened files limit, it seems that 256 is not enough. When I ignored some files I was just moving the error to another load somewhere deeper in the code.

I first tried to set the maximum number but since I forgot to restart the console, the old setting was still in effect. After restarting the console/terminal I can run PARPG without a problem.

[Beliar]

I thought about that problem today and I realized by what it might be caused.

While the files should be closed when the file variables are deleted this may not happen instantaneous as python is using a garbage collector. So if a lot of files are opened in short order they might break such limits as it may take some time until they are closed.

This is only a guess, though.