-
Fixed in xmlparse.c rev. 1.164.
Please report back if there are still issues.
2009-09-29 02:51:49 UTC in Expat XML Parser
-
kwaclaw committed patchset 1138 of module expat to the Expat XML Parser CVS repository, changing 1 files.
2009-09-29 02:49:16 UTC in Expat XML Parser
-
How complete are your modifications?
Could they be used to make a proper BDB for .NET release for version 4.7.25?
If yes, would you be willing to contribute?
Regards,
Karl.
2009-06-30 23:37:12 UTC in Berkeley DB for .NET
-
No, I don't think anyone has written a wrapper for 4.7.
It is not simple, as the binary layout of the structs has to match with the C library, and they change it around every time, so you have to re-check them field by field.
I plan on updating for version 4.8 (once released), but not sure how quick I can get it done.
Karl.
2009-06-30 04:08:19 UTC in Berkeley DB for .NET
-
I admit, reading the docs is not my strong side...
2009-06-09 22:52:12 UTC in Bouml
-
I wanted to rename a project, so i changed the folder name and project file name (they have to be in sync).
It worked initially, but subsequently the project file would always be saved with the original name, and I was not able to rename the project file from within the application. I finally used a text editor to update the project file with the new name, but that is not ideal.
Karl.
2009-06-09 15:26:16 UTC in Bouml
-
I just had someone with access to a 64 bit machine debug the library, and it looks as if we got it going for 64bit platforms. The main point was to translate all occurrences of time_t and size_t types in the C library to IntPtr instances in the .NET wrapper.
So, if you update to current CVS, the library should work on both, 32bit and 64bit Windows platforms, from the bit of testing that was...
2009-05-19 00:41:44 UTC in Berkeley DB for .NET
-
kwaclaw committed patchset 459 of module libdb-dotnet to the Berkeley DB for .NET CVS repository, changing 11 files.
2009-05-18 19:06:46 UTC in Berkeley DB for .NET
-
I looked at your C code.
The XmlNodeRef class gave it away, you are not actually using Expat directly, but apparently some DOM wrapper around it. This will build an in-memory representation of the XML file and consequently consume several times as much memory as the file size.
If you check the Expat reference document you will see that Expat based code uses call-backs to inform the...
2009-04-02 12:07:56 UTC in Expat XML Parser
-
I think your engineers are mistaken.
Expat does not build an in-memory tree of the XML file at all, and its memory consumption is negligible, even for multi-gigabyte files. The only exceptions are entity declarations in the DTD which could use a lot of memory (google for "million laughs attack"). If you don't have a DTD (it looks like that from your example), then I cannot see how Expat would...
2009-03-31 19:22:36 UTC in Expat XML Parser
