Hi,
I have been working very hard on my BasexCpp client project for the last few months. The most effort has been to convert the code that worked flawlessly in Eclipse to a library that meets all the requirements (see also https://medium.com/@pananton/modern-cmake-tutorial-for-c-library-developers-..., Modern CMake tutorial for C++ library developers). During that work, there turned out to be imperfections anyway. Fixing a memory-leak took the most effort. I now have 2 versions of the code. The first version is based on CMake and builds a shared library that has to be installed. The second version does not use CMake. This version has to be compiled manually. Both versions use the same code for the library. As soon as I fix the last,following problem, I will publish both new versions.
The last problem is in the test program. That program contains the following line: Session.Add(“Add_XML_2”, “/home/bengbers/Git/Private/Raw/libBasexCpp/src/extdata/Articles.xml”); This line calls the "Add command" from the server protocol. The above line is executed without errors. However, the problem is that when I change the path to "./Raw/libBasexCpp/src/extdata/Articles.xml" I get the following error message: "Content is not allowed in prolog.". And since the same testprogram is used to test the different versions, the path has to be relative.
My question is how I can use a relative path in the Add-command.
Hi Ben,
Relative paths are supported, but they are resolved against the working directory of your server instance (not the client instance, as you might expect).
Hope this helps, Christian
Ben Engbers Ben.Engbers@be-logical.nl schrieb am Fr., 6. Dez. 2024, 16:03:
Hi,
I have been working very hard on my BasexCpp client project for the last few months. The most effort has been to convert the code that worked flawlessly in Eclipse to a library that meets all the requirements (see also
https://medium.com/@pananton/modern-cmake-tutorial-for-c-library-developers-...,
Modern CMake tutorial for C++ library developers). During that work, there turned out to be imperfections anyway. Fixing a memory-leak took the most effort. I now have 2 versions of the code. The first version is based on CMake and builds a shared library that has to be installed. The second version does not use CMake. This version has to be compiled manually. Both versions use the same code for the library. As soon as I fix the last,following problem, I will publish both new versions.
The last problem is in the test program. That program contains the following line: Session.Add(“Add_XML_2”, “/home/bengbers/Git/Private/Raw/libBasexCpp/src/extdata/Articles.xml”); This line calls the "Add command" from the server protocol. The above line is executed without errors. However, the problem is that when I change the path to "./Raw/libBasexCpp/src/extdata/Articles.xml" I get the following error message: "Content is not allowed in prolog.". And since the same testprogram is used to test the different versions, the path has to be relative.
My question is how I can use a relative path in the Add-command.
-- Ben Engbers Grietjeshof 77 6721 VH Bennekom +31 6 23634840
On Sat, 2024-12-07 at 00:16 +0100, Christian Grün wrote:
Hi Ben,
Relative paths are supported, but they are resolved against the working directory of your server instance (not the client instance, as you might expect).
Note also, the Content not allowed in prolog message is produced by the default Java XML parser (and maybe others) if it encounters whitespace or anything other than <?xml or <!DOCTYPE or < followed by a name character at the start of the document. This can include an empty file, so th message can mean the file wasn't found. In some configurations, error messages can get sent to the parser by mistake, instead of to standard error or raising an exception, and of course those error messages are then parsed as XML and the parser gives this error.
This was one of the hardest things about using (at least early versions of) Calabash, the XProc processor.
On Linux you can also use strace to trace the BaseX server - attach to the running process and trace the "openat" and "stat" system calls - and this will show where it’s looking. Use dtrace on the Mac (or on Solaris), i think.
liam
basex-talk@mailman.uni-konstanz.de
-
Ben Engbers -
Christian Grün -
Liam R. E. Quin