Hello,

We have trouble as well sometimes, and end up putting debug code in the
XmlIO.py to figure out what is going on.  Here, though, it's not as bad as
it looks.

The [42] that is mentioned is the key of the offending object, so this
means that DataLocation with serial=42 is missing.  And since DataSource
is the only thing that uses DataLocations (certainly in the Nmr package,
which is mentioned) it means that some DataSource is looking for a
DataLocation that no longer exists.  The DataLocation is part of the
memops Implementation package which means it lives in the top-level
project XML file.  This error to me would indicate that somehow the
top-level project file got re-used, or there is a bug somewhere, or some
crash happened during a save, or ...

If you look for the word "dataLocation" in Nmr.py you will soon enough
find which DataSource is using dataLocation 42 (there could be more than
one but that is not so likely).  Between the other information for that
DataSource you will hopefully figure out which spectrum this is and
perhaps recall where its data is on disk.  Then you can look at the
top-level project XML file to see if there is a DataLocation with this
path (you have to combine with the path of the Url of the DataLocation to
get the full path).  If it is there then you can change the 42 to the
correct serial (in Nmr.xml).  If it is not there then I'm not sure what
the best option is.  You could try adding a new DataLocation to the
project XML file.  (Not totally trivial.)  Or you could delete that
information from the DataSource record (but off the top of my head I'm not
sure what Analysis would do with a missing DataLocation, it might not cope
gracefully or it might).  If you need further help then I can try editing
the files.

However I would also say that if DataLocation pointer is wrong, you have
to wonder about the fidelity of the others.  So even if they point to a
serial which still exists, is it the correct serial.  So it might be worth
checking a couple of those (most easily done in the SaveAs dialog if you
manage to get Analysis to open it, or otherwise you will have to look at
the files as above).

We might be able to add more verbose output as an option (in the new API,
not the existing one), Rasmus would be able to better comment on that.

As for a "rigourous definition" of the XML, that goes completely against
what we are trying to do with the API.  That is, we want the API to be
stable, and that is what people should code against, not the XML.  So the
XML format can change without anyone knowing (not that this happens very
often, it is between the old and new APIs, though).  If anyone really
needs to see what is going on then the code that reads and writes the
format is in the SourceForge CVS repository in the directory
ccpn/python/memops/scripts_v2/xmlio (the scripts_v2 might get renamed at
some point to scripts, if and when we get rid of the old scripts
directory), and in the directory ccpn/python/memops/format/xml.  (Not
totally trivial reading, shall we say.)

Wayne

On Sun, 28 Oct 2007, Gary Thompson wrote:

> Dear All
>
> We have another old project which refuses to load (as an side we definitley
> regard opening old projects as 'a fraught execise'... we have a first time
> success rate of ~ 1/3 say) anyway here is the backtrace
>
> last xml element read:
> </dataLocation>
>
>
> parser state was:
> reading
>
> ERROR loading xml ccp.nmr.Nmr ccp/Nmr.xml
> Traceback (most recent call last):
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/ccpnmr1.0/python/ccpnmr/analysis/AnalysisGui.py",
> line 217, in ?
>     main(filename, max_size, glDirect)
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/ccpnmr1.0/python/ccpnmr/analysis/AnalysisGui.py",
> line 110, in main
>     top.initProject(project)
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/ccpnmr1.0/python/ccpnmr/analysis/AnalysisPopup.py",
> line 929, in initProject
>     Analysis.initProject(self, project)
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/ccpnmr1.0/python/ccpnmr/analysis/Analysis.py",
> line 405, in initProject
>     self.initTopObjects(project)
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/ccpnmr1.0/python/ccpnmr/analysis/Analysis.py",
> line 195, in initTopObjects
>     if not project.currentNmrProject:
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/temporaryReleaseDir/ccpnmr/ccpnmr1.0/python/memops/api/Implementation.py",
> line 18782, in getCurrentNmrProject
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/temporaryReleaseDir/ccpnmr/ccpnmr1.0/python/memops/api/Implementation.py",
> line 13173, in findFirstNmrProject
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/temporaryReleaseDir/ccpnmr/ccpnmr1.0/python/memops/api/Implementation.py",
> line 9066, in load
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/temporaryReleaseDir/ccpnmr/ccpnmr1.0/python/ccp/xml/nmr/Nmr.py",
> line 114, in load
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/temporaryReleaseDir/ccpnmr/ccpnmr1.0/python/memops/format/xml/XmlIO.py",
> line 425, in load
>   File
> "/home/garyt/programs/ccpnmr/1.0.12/temporaryReleaseDir/ccpnmr/ccpnmr1.0/python/memops/format/xml/XmlIO.py",
> line 741, in doLoad
> memops.general.Implementation.ApiError: Error loading fileNo DataLocation
> object found from key:
> [42]
>
> regards
> gary
>
> as an aside the information here is not the most helpful I have seen (I know
> its hard ;-) I have seen far worse and from commercial applications at
> that), specifically
>
> 1. there is no indication of the line number which caused the error, though
> the file is listed which is good
> 2. the last read xml element provides little context if there are lots of
> these elements (there are 34 dataLocation elements in my Nmr.xml)
> 3. the message Error loading fileNo DataLocation object found from key:
> [42]  is pretty cryptic and provides little information on what the parser
> was doing when it gaveup
> 4. would it be possible to provide a verbose mode that provided output on
> the console as elements are read?
> 5. will there at some point be a rigorous definition of what the ccpnmr xml
> format is? Say god forbid that ccpn didn't get renewed next time round what
> would other implimentors use to create back compatible implimentations?
>