Rainbow problem copying module from Journal to dta directory

[walter]

In TurtleArtPortfolio, I copy a Python module from the Journal to the Rainbow-supplied data directory. I then try loading the module. Works with Rainbow turned off; fails with Rainbow turned on.

In both cases, despite messages in the log file to the contrary, the correct file is copied into the data directory. In both cases, the permissions on the file are rw-r-r.

In both cases, the sys.path seems correct (see log files)

This is on an OLPC-XO-1 running Build 767.

[mstone]

 Line 37 of the "rainbow-on" log is very suspicious: it indicates that  Line 459 of TAPortfolioActivity.py is failing, which means that the python module isn't being copied from the datastore into TAP's writable space. We need to find out why this line is failing, e.g. with targeted logging or by using subprocess.check_call instead of os.system so that we receive an exception when the copy command fails.

[walter]

It is nice to know about subprocess.call_check... I'll replace my os calls with it throughout. Alas, I am not making much progress. The copy is failing, but twice there was no error in the log and then finally, there was an error code of 1. I have a feeling that it is a matter of the file I am copying rather than the place I am copying to, but it is hard to unravel all the layers here. The log refers to a datastore object in a uid_to_instance subdirectory, but it doesn't seem to be geting there from the datastore for copying.

[garycmartin]

Walter, your "uid_to_instance" just reminded me of a problem I had with Moon last week. It started failing to stop without causing a Journal error alert, changes will be lost. Had some real unexpected and inconsistent error messages. After a lot of digging it turned out that the file in the uid_to_instance had the wrong user id, so I was not getting access. I deleted the file (I just use it for persistent preferences), and the problem stopped.

I think it happened in my dev environment (on XO) due to perhaps using a symbolic link in ~/Activities to my working source tree (via ./setup dev). I was re-testing Moon-9.xo install process was all still good and wanted to clean up. If you right click in home and erase a sym linked activity, it doesn't correctly remove the link (it deletes your source folder contents (ouch!) but leaves the folder and home icon). This may be confusing Rainbow, perhaps erase is silently failing some cleanup, so a subsequent Moon install gets new user id but it's persistent storage is left with an old user id it can no longer access?

[mstone]

Still stuck?

[walter]

I did an end run around the copy problem by opening the Journal object, reading the data, then writing a file into the data directory. The file is created properly, but the module still does not seem to load.

[walter]

I've done an end-run around the problem, having tried, unsuccessfully, xreload and other ways of getting the module (confirmed to be properly copied from the Journal) to reload. Now I open the file from the Journal, read its contents and execute the Python code directly, never saving it as a module. This resolve my problem, but we should look into this further, perhaps in the 0.86 time frame.