From dave at dilbertobs.com Thu Nov 11 19:44:42 2010 From: dave at dilbertobs.com (Dave Sandage) Date: Fri Nov 12 00:10:17 2010 Subject: [xsde-users] Using XSD/e with Android? Message-ID: Has anyone tried using XSD/e on Android? Any tips on building the xsde runtime library? Thanks, Dave From boris at codesynthesis.com Fri Nov 12 08:58:59 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Nov 12 08:51:23 2010 Subject: [xsde-users] Using XSD/e with Android? In-Reply-To: References: Message-ID: Hi Dave, Dave Sandage writes: > Has anyone tried using XSD/e on Android? Any tips on building the xsde > runtime library? I created a sample configuration file, build system integration, and instructions for XSD/e 3.2.0.b1 (will be included in the final 3.2.0 release). I tested with the latest SDK/NDK/Android 1.5 and everything works fine. You can get 3.2.0.b1 from: http://www.codesynthesis.com/products/xsde/download.xhtml And the Android add-on from: http://www.codesynthesis.com/~boris/tmp/xsde-3.2.0.b1-android.tar.gz See the README file in the etc/android/ directory in the second package. Let me know if you run into any problems. Boris From Terry.O'Laughlin at ipc.com Mon Nov 22 22:45:59 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Mon Nov 22 22:46:05 2010 Subject: [xsde-users] Processing variable length root elements as part of message parsing / serializing Message-ID: Hi, I'm just getting into using XSD/e, see that using variable length root elements discourage the use of the operator = and the copy constructor because of memory allocation. I'm adapting the 'multiroot' example as we are using XML as the basis for messaging in a communications protocol. Works great with fixed-length messages. What do I need to do to adapt it to using variable length root elements? So when I parse, having received a message from the receiver, we won't know the message type until its parsed during runtime. I was trying to define a simple 'getter' for a dynamic root element, unfortunately trying to use the 'operator ='. I know have read and understood why this function and the copy constructor are private. I see things about 'clones' and detached functions but don't really understand them, an example would be helpful. So I've now read more and will try more tomorrow.... Generate-clone and detach function Are these used to 'get' and 'set' the object model? I just need to use the iterator generated with the class. Can someone show me an example of how this is supposed to work. Cheers, Terry O' Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logo5079.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logo5079.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logo5079.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20101122/2ab75c98/green-logo5079.jpg From boris at codesynthesis.com Tue Nov 23 10:56:04 2010 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Nov 23 10:48:51 2010 Subject: [xsde-users] Re: Processing variable length root elements as part of message parsing / serializing In-Reply-To: References: Message-ID: Hi Terry, O'Laughlin, Terry writes: > I'm adapting the 'multiroot' example as we are using XML as the basis > for messaging in a communications protocol. Works great with fixed- > length messages. What do I need to do to adapt it to using variable > length root elements? If the root element type is variable-length, then you can store a pointer to the object model instead of the value. Here is how one can adapt the document_pimpl class from the 'multiroot' example (only changed parts are shown): class document_pimpl: ... { public: ~document_pimpl () { free (); } request_type result_type () const { return result_type_; } // Return the object model and release ownership. // protocol::balance* balance () const { protocol::balance r = balance_; balance_ = 0; return r; } protocol::withdraw* withdraw () const { protocol::withdraw r = withdraw_; withdraw_ = 0; return r; } virtual void reset () { free (); xml_schema::document_pimpl::reset (); balance_p_.reset (); withdraw_p_.reset (); } private: void free () { switch (result_type_) { case balance_type: { delete balance_; break; } case withdraw_type: { delete withdraw_; break; } unknown_type: { break; } } result_type_ = unknown_type; } private: request_type result_type_; protocol::balance* balance_; protocol::withdraw* withdraw_; }; Then, in main(), the relevant changes are as follows: // Print what we've got. // switch (doc_p.result_type ()) { case balance_type: { balance* b = doc_p.balance (); cerr << "balance request for acc# " << b->account () << endl; delete b; break; } case withdraw_type: { withdraw* w = doc_p.withdraw (); cerr << "withdrawal request for acc# " << w->account () << ", " << "amount: " << w->amount () << endl; delete w; break; } case unknown_type: { cerr << "unknown request" << endl; break; } } Boris From Terry.O'Laughlin at ipc.com Tue Nov 23 13:24:31 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Tue Nov 23 13:24:57 2010 Subject: [xsde-users] RE: Processing variable length root elements as part of message parsing / serializing In-Reply-To: References: Message-ID: Hi Boris, Thanks for the prototype. I'd just stumbled upon this type of thing earlier today, your example makes it more robust. How about adding examples of 'variable-length' elements to the distribution? Down the road, why not add this type of extra code to the code generation compiler? OR Treat every element as if it were 'variable-length'. Return a pointer to the object model, which you do now, parserAggr.post(). Then for each element, you have a '_copy()' method. Is this a deep copy? I would rather not: 1) Have to treat elements differently just because they are variable-length. 2) 'look' under the cover of all the code that's generated to learn this stuff. I'm taking your suggestion, I'm figuring that the only thing I need to work with is the object model code, plus the modified 'document_pimpl' in the 'multi-root' example, and even that, can't you guys generate the code for me? I've got more to learn with XSD/e. I think the tool is good. It does a TON of stuff, so I can see that it would be hard to please all the people all the time. Cheers, Terry O' ----------------------------------------------------- Please consider the environment before printing this email. -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: Tuesday, November 23, 2010 10:56 AM To: O'Laughlin, Terry Cc: xsde-users@codesynthesis.com Subject: Re: Processing variable length root elements as part of message parsing / serializing Hi Terry, O'Laughlin, Terry writes: > I'm adapting the 'multiroot' example as we are using XML as the basis > for messaging in a communications protocol. Works great with fixed- > length messages. What do I need to do to adapt it to using variable > length root elements? If the root element type is variable-length, then you can store a pointer to the object model instead of the value. Here is how one can adapt the document_pimpl class from the 'multiroot' example (only changed parts are shown): class document_pimpl: ... { public: ~document_pimpl () { free (); } request_type result_type () const { return result_type_; } // Return the object model and release ownership. // protocol::balance* balance () const { protocol::balance r = balance_; balance_ = 0; return r; } protocol::withdraw* withdraw () const { protocol::withdraw r = withdraw_; withdraw_ = 0; return r; } virtual void reset () { free (); xml_schema::document_pimpl::reset (); balance_p_.reset (); withdraw_p_.reset (); } private: void free () { switch (result_type_) { case balance_type: { delete balance_; break; } case withdraw_type: { delete withdraw_; break; } unknown_type: { break; } } result_type_ = unknown_type; } private: request_type result_type_; protocol::balance* balance_; protocol::withdraw* withdraw_; }; Then, in main(), the relevant changes are as follows: // Print what we've got. // switch (doc_p.result_type ()) { case balance_type: { balance* b = doc_p.balance (); cerr << "balance request for acc# " << b->account () << endl; delete b; break; } case withdraw_type: { withdraw* w = doc_p.withdraw (); cerr << "withdrawal request for acc# " << w->account () << ", " << "amount: " << w->amount () << endl; delete w; break; } case unknown_type: { cerr << "unknown request" << endl; break; } } Boris DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. From Terry.O'Laughlin at ipc.com Tue Nov 30 16:07:26 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Tue Nov 30 16:07:31 2010 Subject: [xsde-users] Serializing questions: Illegal namespace error & 'g1' namespace/prefix Message-ID: New user questions ... 1. Why do I get this error, illegal namespace, when I try to serialize an element from my schema? I see where someone else had this problem and found a line of code in the genx.c file. I make the changed as described in the link below. The error goes away. Is this a bug in Genx? Is there something that I'm doing wrong? Is this a valid 'fix'? I did not see a response to this message. http://codesynthesis.com/pipermail/xsd-users/2010-August/002970.html I see that there is another message in this thread. I will say that I don't have the XML background at this time to understand the question and the answer. http://codesynthesis.com/pipermail/xsd-users/2010-August/002973.html I do have some complex types in my schema, which I think is part of the crux of this message exchange. The message (root element) I was trying to serialize is a complex element type. 2. Why do I get the prefix/namespace 'g1:' added as an attribute to my root element? (Here is my serialized output, with "crs" added for readability)
ConnectRequest 099 2 2 0 0
3 0 0 Why doesn't the 'hello' serialize example have this same 'g1' prefix/namespace? (Screen shot of 'hello' serializer example C:\xsde_v3.2_win32_vc9>cd examples\cxx\serializer\hello C:\xsde_v3.2_win32_vc9\examples\cxx\serializer\hello>driver Hello sun moon world C:\xsde_v3.2_win32_vc9\examples\cxx\serializer\hello> Inquiring minds are inquiring. Thanks for the help, Cheers, Terry O' Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logo1ff1.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logo1ff1.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logo1ff1.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20101130/2237c2ac/green-logo1ff1.jpg From Terry.O'Laughlin at ipc.com Tue Nov 30 23:18:32 2010 From: Terry.O'Laughlin at ipc.com (O'Laughlin, Terry) Date: Tue Nov 30 23:18:36 2010 Subject: [xsde-users] Build fails with socket references not resolved in XSDe v3.2.b1 but builds fine in V3.2 Message-ID: Boris, I'm perplexed. I get the following link errors when building with the beta version of 3.2b (whatever the latest version I've been using). But I move the build directory to build under V3.2, no problem, builds fine. This is prototype code which runs on Windows, using VS2008 command line (CL) compiler. I'm scratching my head on this one. This is a sample parser modified from the multi root example, which parses our messages xml vocabulary. Works just fine parsing everything. I was just adding a function to read input data via a udp socket. Thoughts? Appreciate the help, Cheers, Terry O' C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers> C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers> C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers> C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers>nmake -f nmakefile Microsoft (R) Program Maintenance Utility Version 9.00.30729.01 Copyright (C) Microsoft Corporation. All rights reserved. cl.exe -D_CRT_SECURE_NO_DEPRECATE /I..\..\..\..\libxsde /nologo /W3 /EHs /c /TP driver.cxx /Fodriver.obj driver.cxx link.exe /nologo /OUT:driver.exe driver.obj messages.obj messages-pskel.obj messages-pimpl.obj ..\..\..\..\libxsde\xsde\xsde.lib driver.obj : error LNK2019: unresolved external symbol __imp__htons@4 referenced in function "int __cdecl receieve_from_socket(char *)" (?receieve_fro m_socket@@YAHPAD@Z) driver.obj : error LNK2019: unresolved external symbol __imp__gethostbyname@4 referenced in function "int __cdecl receieve_from_socket(char *)" (?rece ieve_from_socket@@YAHPAD@Z) driver.obj : error LNK2019: unresolved external symbol __imp__WSACleanup@0 referenced in function "int __cdecl receieve_from_socket(char *)" (?receiev e_from_socket@@YAHPAD@Z) driver.obj : error LNK2019: unresolved external symbol __imp__WSAGetLastError@0 referenced in function "int __cdecl receieve_from_socket(char *)" (?re ceieve_from_socket@@YAHPAD@Z) driver.obj : error LNK2019: unresolved external symbol __imp__socket@12 referenced in function "int __cdecl receieve_from_socket(char *)" (?receieve_f rom_socket@@YAHPAD@Z) driver.obj : error LNK2019: unresolved external symbol __imp__WSAStartup@8 referenced in function "int __cdecl receieve_from_socket(char *)" (?receiev e_from_socket@@YAHPAD@Z) driver.obj : error LNK2019: unresolved external symbol __imp__sendto@24 referenced in function "int __cdecl write_to_socket(class std::basic_ostringst ream,class std::allocator > &)" (?write_to_socket@@YAHAAV?$basic_ostringstream@DU?$char_traits@D@std@@V?$allo cator@D@2@@std@@@Z) driver.exe : fatal error LNK1120: 7 unresolved externals NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 9.0\VC\BIN\link.exe"' : return code '0x460' Stop. C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers> C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers> C:\xsde-3.2.0.b1_win32_vc9\examples\cxx\hybrid\MessageParsers> Terry O'Laughlin Sr. Software Engineer IPC TS Engineering Alliance Sustaining Dept. 777 Commerce Drive Fairfield, CT 06825 phone: 203-339-7987 fax: 203-339-7809 www.ipc.com Terry.O'Laughlin@ipc.com ________________________________ DISCLAIMER: This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unintended recipients are prohibited from taking action on the basis of information in this e-mail.E-mail messages may contain computer viruses or other defects, may not be accurately replicated on other systems, or may be intercepted, deleted or interfered with without the knowledge of the sender or the intended recipient. If you are not comfortable with the risks associated with e-mail messages, you may decide not to use e-mail to communicate with IPC. IPC reserves the right, to the extent and under circumstances permitted by applicable law, to retain, monitor and intercept e-mail messages to and from its systems. [cid:green-logo5d3d.jpg]Please consider the environment before printing this email. -------------- next part -------------- A non-text attachment was scrubbed... Name: green-logo5d3d.jpg Type: image/jpeg Size: 1268 bytes Desc: green-logo5d3d.jpg Url : http://codesynthesis.com/pipermail/xsde-users/attachments/20101130/43a5e0ee/green-logo5d3d.jpg