Menu
▾
▴
[convey-developers] wxWiindows and STL
|
From: Scott L. <sco...@ho...> - 2003-10-10 22:55:33
|
Hello Andy, Ed.
Hope things are good.
Well, I've been working on getting somthing that would compute XML diff's
for Convey-- this past week. So far, it works fairly well with expat,
although with some modifications to the expat source (icky, but necessary).
Furthermore, xmldiff (let's call it that, for the sake of convienence)
produces dfff information in concise DUL (delta update language) in addition
to an alternative output format (which is processing instructions embedded
in the XML tree/document). DUL will allow us to minimize the bytes sent
across the network.
Ideally, I would like to have xmldiff to be a library with an API such as
XDiff xdiff(input1, input2, delta);
where the arguments may be an XML file, a root element, or a document
object, as below:
XmlDiffDocHandle *input1 = new XmlDiffDocHandle("doc1.xml");
wxXmlElement *rootNode;
wxXmlDocument *deltaDoc;
XmlDiffDocHandle *input2 = new XmlDiffDocHandle(rootNode);
XmlDiffDocHandle *delta = new XmlDiffDocHandle(deltaDoc);
Furthermore, XDiffUpdate update(document, delta, output) updates "document"
with "delta" and saves the result in "output" if it is not NULL, otherwise
"document" would be modified. "delta" may be NULL to signify that
"document" has processing instructions.
As you would expect, since we are using wxWindows, libxmldiff.a needs to be
compatible with this framework. I was hoping to retain the use of STL
containers and algorithms by using some tricks listed in the wxWindows
documentation. Specifically, there are two things I am doing;
(1) include the directives below before including any STL headers.
#ifdef new
#undef new
#endif
(2) set the following definitions (or some variant of such):
#define wxUSE_GLOBAL_MEMORY_OPERATORS 0
#define wxUSE_IOSTREAMH 0
#define wxUSE_DEBUG_CONTEXT 0
#define wxUSE_MEMORY_TRACING 0
#define wxUSE_DEBUG_NEW_ALWAYS 0
#define wxUSE_STD_IOSTREAM 1
However, I have not yet had any success in building xmldiff so that it uses
wxWindows classes AND STL containers/algorithms. An example of compilation
errors follows:
XLut.o: In function `_Hashtable_node<pair<unsigned int const, unsigned long
long> > * * __copy_trivial<_Hashtable_node<pair<unsigned int const, unsigned
long long> > *>(_Hashtable_node<pair<unsigned int const, unsigned long long>
> * const *, _Hashtable_node<pair<unsigned int const, unsigned long long> >
* const *, _Hashtable_node<pair<unsigned int const, unsigned long long> > *
*)':
/usr/lib/gcc-lib/i386-slackware-linux/2.95.3/../../../../include/g++-3/stl_vector.h(.__malloc_alloc_template<0>::gnu.linkonce.t._S_oom_malloc(unsigned
int)+0x1a): undefined reference to `endl(ostream &)'
Perhaps there is another way to do this? I hope so because the alternatives
(below) are less appealing:
(1) Fork xmldiff as a child process which only operates on files. File I/O
and starting a new process may be expensive.
(2) Convert STL templates to wxWindows classes. This may be possible, but
tedious.
Surprisingly, there are not too many discussions about this problem on the
internet. Perhaps you or your colleagues have encountered/resolved this
problem before? Otherwise, I'll keep tweeking until I resign myself to one
of the two options above.
Thanks,
Scott
>From: "Scott Luan" <sco...@ho...>
>Reply-To: con...@li...
>To: con...@li...
>Subject: [convey-developers] makefiles and etc
>Date: Wed, 01 Oct 2003 22:05:58 -0700
>
>Hello Andy,
>
>Thanks for the clarification. I see what you mean about the top-level
>makefile. autoconf or some such would be a nice touch. A simple
>alternative would be to have the top-level makefile test for the existence
>of various directories, and build the binaries as appropriate. This way
>there is a method of building several components with one command at the
>top-level, rather than manually invoking make at each subdirectory. This
>method may be used for those who have checked-out only a portion of the
>source tree (i.e. wxxml, wxjab but not convey). The only requirement is
>that the source tree structure does not change. Note that each
>subdirectory contains a makefile that is self-sufficient -- that is, wxxml
>and wxjab my be checked-out and built independently.
>
>Just to get sync-ed up with you guys, here's a list of what I will be
>working on for the next few weeks (in between moving, an OS class, and
>etc).
>
>1. Adapt an existing xml diff program to use expat. The author's paper is
>quite helpful: "X-Diff: An Effective Change Detection Algorithm for XML
>Documents." If you like, we can discuss some limitations of his algorithm
>and how it would impact convey. If you have a better alternative, please
>let me know. You may find more information at:
>http://www.cs.wisc.edu/~yuanwang/xdiff.html
>
>2. Write client code for NTP time sync. We should also leave this open to
>discussion, as NTP may possibly be too hefty for our purposes. We may have
>to investigate ways to time sync via TCP.
>
>3. And of course, the makefiles.
>
>Hope the quarter is going well for you guys.
>
>Regards,
>Scott
>
>
>>From: "Andy Ames" <ag...@sb...>
>>Reply-To: con...@li...
>>To: <con...@li...>
>>Subject: RE: [convey-developers] convey 0.4?
>>Date: Sat, 27 Sep 2003 16:38:58 -0700
>>
>>Scott,
>>
>>-----Original Message-----
>>From: con...@li...
>>[mailto:con...@li...]On Behalf Of Scott
>>Luan
>>Sent: Saturday, September 27, 2003 12:56 PM
>>To: con...@li...
>>Subject: RE: [convey-developers] convey 0.4?
>>
>>
>>Hello Andy,
>>
>>Thanks for the info.
>>
>>(1) The error generated while making wxjab.o is listed below:
>>
>>In file included from wxjab.cpp:1:
>>../../wxjab/include/wxjab.h:112: parse error before `,'
>>../../wxjab/include/wxjab.h:112: stray '\' in program
>>../../wxjab/include/wxjab.h:113: stray '\' in program
>>../../wxjab/include/wxjab.h:114: stray '\' in program
>>../../wxjab/include/wxjab.h:115: stray '\' in program
>>
>>This is the macro definition in wxjab.h:
>>#define EVT_JABBER_MESSAGE(id, func) \
>>
>> DECLARE_EVENT_TABLE_ENTRY(wxEVT_JABBER_MESSAGE, id, -1, \
>>
>> (wxObjectEventFunction) \
>>
>> (wxEventFunction) \
>>
>> (wxJabberMessageEventFunction) & func, \
>>
>> (wxObject *) NULL ),<--- ends here.
>>
>>Note that this macro is not used anywhere.
>>
>><andy>Sweet.</andy>
>>
>>(2) The build error for wxjab, I discovered, is due to a mistaken identity
>>in the header files. Specifically testapp.h for both wxxml and wxjab.
>>
>><andy>Perhaps they should be renamed to testxml and testjab, or
>>something.</andy>
>>
>>(3) I am not sure if we decided to include the makefiles in the source
>>tree.
>> I think it is a good idea so that we can all use the same build
>>process.
>>But.. there may be incompatibilities with MS' nmake. Hmmm... Well,
>>perhaps
>>we just have to sync up manually and accept the amusing fact that we are
>>using 4 platforms among 3 people! :-) Well, if we have decided to
>>include
>>the makefiles, I don't believe I can create/checkin any files in any
>>directory other than wxjab. Perhaps for the sake of convienence, the
>>adminstrative demands may be relaxed for this informal group of fun-loving
>>developers. :-)
>>
>><andy>You can't checkin files? Hmmm. I'll look into it and give you
>>permissions for the whole source tree.
>>Makefiles are definately good. This will allow us to synch up Mac OS X,
>>Linux, Solaris, and the like. I definately think we should have them. I
>>also
>>would like to have MSVC and Project Builder projects for GUI debugging. Of
>>course, it is difficult to keep them synched with Makefiles. In practice,
>>the GUI project builds usually breakdown more frequently. That's okay,
>>though.
>>
>>Makefiles with Windows are almost never compatible with 'nixes for many
>>reasons, so I don't even care to try. That was a plus with Java. You could
>>better streamline the build systems between OSes. However, in practice, in
>>didn't always work.</andy>
>>
>>(4) >can we provide a way to indicate to the wxjab build system where it
>>can find the wxxml library.
>>yes, we can use the -L switch for the linker
>>
>><andy>What I mean is by using some kind of configure or autoconf
>>mechanism.
>>The reason is that I'd like wxxml and wxjab to be as separate as possible.
>>I
>>was thinking this because the wxxml module can be checked out and built
>>separate from the wxjab module. I'd like to keep it that way.
>>
>>(At UCSC, we're using the wxxml module to do...well, XML stuff. We don't
>>need wxjab.)
>>
>>This is also why I wasn't thinking we'd have a top-level Makefile.
>>
>>What are your thoughts on this? If someone were to check out only the
>>wxxml
>>module, then they wouldn't get the top-level Makefile anyway. Right? What
>>about if they only checked out the wxxml and wxjab modules, but not
>>convey?
>>
>>Hopefully this gives you an idea of my thinking. I guess I would like a
>>top-level Makefile as long as it can detect which modules have been
>>checked
>>out and only build those. Should it also build Convey Java?</andy>
>>
>>(5) >I'd prefer not to have to place a top-level convey Makefile in the
>>repository.
>>Having a makefile in the top-level directory will allow a recursive build
>>process which is convienent to automate the entire build.
>>
>>That's all for now. Enjoy your weekends.
>>
>>Andy
>>
>>
>>
>>-------------------------------------------------------
>>This sf.net email is sponsored by:ThinkGeek
>>Welcome to geek heaven.
>>http://thinkgeek.com/sf
>>_______________________________________________
>>convey-developers mailing list
>>con...@li...
>>https://lists.sourceforge.net/lists/listinfo/convey-developers
>
>_________________________________________________________________
>Share your photos without swamping your Inbox. Get Hotmail Extra Storage
>today! http://join.msn.com/?PAGE=features/es
>
>
>
>-------------------------------------------------------
>This sf.net email is sponsored by:ThinkGeek
>Welcome to geek heaven.
>http://thinkgeek.com/sf
>_______________________________________________
>convey-developers mailing list
>con...@li...
>https://lists.sourceforge.net/lists/listinfo/convey-developers
_________________________________________________________________
Share your photos without swamping your Inbox. Get Hotmail Extra Storage
today! http://join.msn.com/?PAGE=features/es
|
