From laasunde at hotmail.com Thu Mar 3 07:23:09 2016 From: laasunde at hotmail.com (Lars) Date: Thu Mar 3 07:23:18 2016 Subject: [xsd-users] unexpected_enumerator Message-ID: Hello, We have used codesynthesis 4.0 to generated C++ code for a long time. Recently we needed to add an enumerator to that schema. However the generated C++ code now throws an unexpected_enumerator exception when loading an xml. We have use oxygen to validate the xml file against the updated schema and it is valid. So for some reason the C++ code does not like the updated schema. Here is the schema addition; Debugging the exception I found the below generated C++ code: Type::value Type:: _xsd_Type_convert () const { ::xsd::cxx::tree::enum_comparator< char > c (_xsd_Type_literals_); const value* i (::std::lower_bound ( _xsd_Type_indexes_, _xsd_Type_ + 3, *this, c)); //****************************************************** // Debugging code //****************************************************** xsd::cxx::tree::_type lhs(_xsd_Type_literals_[*i]); // empty xsd::cxx::tree::_type rhs(*this); // contains value "bbb" bool comp = (lhs != rhs); // equals true //****************************************************** if (i == _xsd_Type_indexes_ + 3 || _xsd_Type_literals_[*i] != *this) { throw ::xsd::cxx::tree::unexpected_enumerator < char > (*this); } return *i; } const char* const Type:: _xsd_Type_literals_[3] = { "aaa", "bbb", "ccc" }; const Type::value Type:: _xsd_Type_indexes_[3] = { ::Domain::App_1::Type::ccc, ::Domain::App_1::Type::aaa, ::Domain::App_1::Type::bbb }; The second part of the if statement is evalated to true which causes the exception. However viewing the _xsd_Type_literals_[*i] and *this part with the debugger they both appear to contain the same value. Stepping into the expression it looks like _xsd_Type_literals_[*i] is converted into a xsd::cxx:tree::_type using the template _type(const C* s); constructor. This constructor ignores the string and creates an empty instance. That means the left-hand-side of the expression loses it value in the type convertion. Any comparisson after that will be faulty. What can cause this behaviour? Have we configured codesynthesis incorrectly ? Appreciate any input on the matter. kind regards, Lars From boris at codesynthesis.com Thu Mar 3 08:58:07 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 3 08:58:10 2016 Subject: [xsd-users] unexpected_enumerator In-Reply-To: References: Message-ID: Hi Lars, Lars writes: > xsd::cxx::tree::_type lhs(_xsd_Type_literals_[*i]); // empty > xsd::cxx::tree::_type rhs(*this); // contains value "bbb" > bool comp = (lhs != rhs); // equals true This code is incorrect. Are you using it to try to reproduce the problem or is this the actual code in your application? If it is the actual code, then you will need to change it (use the actual enumartion type instead of _type). If this is just for reproduction, then I would rather ask you to do two things: 1. Try to recompile your application from scratch (recompile all the schemas, then all C++ code). 2. If that doesn't help, then I would need to a small but complete test case that reproduces the problem (i.e., the schema file, the xml file, and the test driver with main()). Boris From jweinkam at enbala.com Mon Mar 7 10:38:17 2016 From: jweinkam at enbala.com (James Weinkam) Date: Mon Mar 7 10:38:26 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema Message-ID: I have been using CodeSynthesis XSD version 3.3.0. CodeSynthesis XSD XML Schema to C++ compiler 3.3.0 Copyright (C) 2005-2010 Code Synthesis Tools CC and recently upgraded to 4.0.0 CodeSynthesis XSD XML Schema to C++ compiler 4.0.0 Copyright (c) 2005-2014 Code Synthesis Tools CC The following command line worked with the old version, but now results in a segmentation fault. xsd cxx-tree --generate-polymorphic --polymorphic-type-all --generate-ostream --generate-wildcard --generate-serialization --generate-forward --namespace-map http://openadr.org/oadr-2.0b/2012/07=oadr --namespace-map http://docs.oasis-open.org/ns/energyinterop/201110=ei --namespace-map http://docs.oasis-open.org/ns/emix/2011/06=emix --namespace-map http://www.opengis.net/gml/3.2=gml --namespace-map "http://www.w3.org/2009/xmldsig11#=dsig11" --namespace-map http://www.w3.org/2000/09/xmldsig#=ds --namespace-map http://openadr.org/oadr-2.0b/2012/07/xmldsig-properties=dsp --hxx-suffix .h --cxx-suffix .cpp oadr_20b.xsd The xsd schema files are from the openADR alliance, and can be downloaded from http://www.openadr.org/specification. I am unable to get CoseSynthesis 4.0.0 to generate the .h and .cpp files for the openADR 2.0b profile schema and would appreciate any help that can be provided. Thanks, James From boris at codesynthesis.com Tue Mar 8 08:58:40 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 8 08:58:40 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: Hi James, James Weinkam writes: > The following command line worked with the old version, but now results > in a segmentation fault. Could you try the latest pre-release and see if it makes any difference? http://codesynthesis.com/~boris/tmp/xsd/ Thanks, Boris From jweinkam at enbala.com Tue Mar 8 09:53:53 2016 From: jweinkam at enbala.com (James Weinkam) Date: Tue Mar 8 09:54:02 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: Yes, I still get the segmentation fault. CodeSynthesis XSD XML Schema to C++ compiler 4.1.0.a7 Copyright (c) 2005-2014 Code Synthesis Tools CC This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Here is the stack trace from the core file. #0 0x000000000063d034 in XSDFrontend::SemanticGraph::Instance::type() const () #1 0x000000000069f939 in XSDFrontend::(anonymous namespace)::Resolver::resolve_element(XSDFrontend::SemanticGraph::Element&) () #2 0x0000000000428a15 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Node&) () #3 0x0000000000429325 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Edge&) () #4 0x000000000041b690 in XSDFrontend::Traversal::ScopeTemplate::names(XSDFrontend::SemanticGraph::Namespace&) () #5 0x000000000041b1a3 in XSDFrontend::Traversal::Namespace::traverse(XSDFrontend::SemanticGraph::Namespace&) () #6 0x0000000000428a15 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Node&) () #7 0x0000000000429325 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Edge&) () #8 0x000000000041b520 in XSDFrontend::Traversal::ScopeTemplate::names(XSDFrontend::SemanticGraph::Schema&) () #9 0x000000000041b7a6 in XSDFrontend::Traversal::Schema::traverse(XSDFrontend::SemanticGraph::Schema&) () #10 0x0000000000428a15 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Node&) () #11 0x0000000000660d32 in XSDFrontend::Parser::Impl::parse(cutl::fs::basic_path const&)::Uses::traverse(XSDFrontend::SemanticGraph::Uses&) () #12 0x0000000000429325 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Edge&) () #13 0x000000000041b793 in XSDFrontend::Traversal::Schema::traverse(XSDFrontend::SemanticGraph::Schema&) () #14 0x0000000000428a15 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Node&) () #15 0x0000000000660d32 in XSDFrontend::Parser::Impl::parse(cutl::fs::basic_path const&)::Uses::traverse(XSDFrontend::SemanticGraph::Uses&) () #16 0x0000000000429325 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Edge&) () #17 0x000000000041b793 in XSDFrontend::Traversal::Schema::traverse(XSDFrontend::SemanticGraph::Schema&) () #18 0x0000000000428a15 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Node&) () #19 0x0000000000660d32 in XSDFrontend::Parser::Impl::parse(cutl::fs::basic_path const&)::Uses::traverse(XSDFrontend::SemanticGraph::Uses&) () #20 0x0000000000429325 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Edge&) () #21 0x000000000041b793 in XSDFrontend::Traversal::Schema::traverse(XSDFrontend::SemanticGraph::Schema&) () #22 0x0000000000428a15 in cutl::compiler::dispatcher::dispatch(XSDFrontend::SemanticGraph::Node&) () #23 0x00000000006836a4 in XSDFrontend::Parser::Impl::parse(cutl::fs::basic_path const&) () #24 0x0000000000684343 in XSDFrontend::Parser::parse(cutl::fs::basic_path const&) () #25 0x000000000040939d in main () Thanks, James -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: March 08, 2016 5:59 AM To: James Weinkam Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema Hi James, James Weinkam writes: > The following command line worked with the old version, but now > results in a segmentation fault. Could you try the latest pre-release and see if it makes any difference? http://codesynthesis.com/~boris/tmp/xsd/ Thanks, Boris From boris at codesynthesis.com Wed Mar 9 09:53:21 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 9 09:53:19 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: Hi James, James Weinkam writes: > Yes, I still get the segmentation fault. Ok, thanks for testing it. Would it possible for you to send me (off-list) the archive of the schemas that you use? I don't really want to "agree to receive emails from OpenADR Alliance" ;-). Thanks, Boris From jweinkam at enbala.com Tue Mar 15 11:05:22 2016 From: jweinkam at enbala.com (James Weinkam) Date: Tue Mar 15 11:05:32 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: I had sent a zip file with the OpenADR 2.0b xsd files on March 9 to your email. Were you able to receive it and have you any insite into why it causes a segmentation fault? Thanks, James -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: March 09, 2016 6:53 AM To: James Weinkam Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema Hi James, James Weinkam writes: > Yes, I still get the segmentation fault. Ok, thanks for testing it. Would it possible for you to send me (off-list) the archive of the schemas that you use? I don't really want to "agree to receive emails from OpenADR Alliance" ;-). Thanks, Boris From boris at codesynthesis.com Tue Mar 15 11:46:26 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Mar 15 11:45:55 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: Hi James, James Weinkam writes: > I had sent a zip file with the OpenADR 2.0b xsd files on March 9 to > your email. Were you able to receive it and have you any insite into > why it causes a segmentation fault? Yes, I got the schemas, thank you. I am looking into this, sorry for the delay. Will let you know as soon as I have something. Boris From d at op.st Tue Mar 15 12:12:59 2016 From: d at op.st (Derrick Babb) Date: Tue Mar 15 12:13:07 2016 Subject: [xsd-users] Set Node Text via Iterator Message-ID: Hello, I am having difficulty setting the text of a node whose type extends public ::xml_schema::string via an iterator. Here are the details: class myType: public ::xml_schema::string { ... } for (my_iterator itor = root.examples().begin(); itor != root.examples().end(); itor++) *itor = "Some Text"; Compiler error: no match for ?operator=? (operand types are ?xsd::cxx::tree::iterator_adapter<__gnu_cxx::__normal_iterator >, myType>::value_type {aka myType}? and ?const char [10]?) Other node attributes should be preserved. Only the node text should be replaced. Thank you! Sincerely, d From boris at codesynthesis.com Wed Mar 16 11:43:37 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 16 11:43:12 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: Hi James, Ok, I've fixed this bug and build a pre-release binary for you to try: http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a8-x86_64-linux-gnu.tar.bz2 It compiles all the openADR schemas, however, I wasn't able to compile the generated C++. It looks like the schema uses recursive self-inclusion and will need the file-per-type mode. Were you able to make it work with XSD 3.3 in the file-per-schema mode? Boris From boris at codesynthesis.com Wed Mar 16 11:56:56 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Mar 16 11:56:25 2016 Subject: [xsd-users] Set Node Text via Iterator In-Reply-To: References: Message-ID: Hi Derrick, Derrick Babb writes: > class myType: public ::xml_schema::string > { > ... > } > > for (my_iterator itor = root.examples().begin(); itor != > root.examples().end(); itor++) > *itor = "Some Text"; XSD-generated classes don't define any assignment operators so the compiler- generated ones must be hiding the ones from the string. You can do: static_cast (*itor) = "Some Text"; Ok, knowing that xml_schema::string derives from std::string and that std::string has assign(), you can do: itor->assign ("Some Text"); Boris From jweinkam at enbala.com Wed Mar 16 11:59:45 2016 From: jweinkam at enbala.com (James Weinkam) Date: Wed Mar 16 11:59:54 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: In 3.3, I had used --cxx-prologue '#include "oadr_ei_20b.h"' for a few of the xsd files, and this then enabled compiling by forcing this one header to get included before others so that all the necessary types were defined before being referenced. Eventually, I will need the FreeBSD port, but for now I can test out with the linux version. I will let you know if I have any more problems. Thanks, James -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: March 16, 2016 8:44 AM To: James Weinkam Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema Hi James, Ok, I've fixed this bug and build a pre-release binary for you to try: http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a8-x86_64-linux-gnu.tar.bz2 It compiles all the openADR schemas, however, I wasn't able to compile the generated C++. It looks like the schema uses recursive self-inclusion and will need the file-per-type mode. Were you able to make it work with XSD 3.3 in the file-per-schema mode? Boris From jweinkam at enbala.com Wed Mar 16 13:46:27 2016 From: jweinkam at enbala.com (James Weinkam) Date: Wed Mar 16 13:46:36 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: I have now successfully compiled, linked, and run our small test program that load and parses some sample OpenADR xml files, as well as create some XML files. Thanks, James -----Original Message----- From: xsd-users-bounces@codesynthesis.com [mailto:xsd-users-bounces@codesynthesis.com] On Behalf Of James Weinkam Sent: March 16, 2016 9:00 AM To: xsd-users@codesynthesis.com Subject: RE: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In 3.3, I had used --cxx-prologue '#include "oadr_ei_20b.h"' for a few of the xsd files, and this then enabled compiling by forcing this one header to get included before others so that all the necessary types were defined before being referenced. Eventually, I will need the FreeBSD port, but for now I can test out with the linux version. I will let you know if I have any more problems. Thanks, James -----Original Message----- From: Boris Kolpackov [mailto:boris@codesynthesis.com] Sent: March 16, 2016 8:44 AM To: James Weinkam Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema Hi James, Ok, I've fixed this bug and build a pre-release binary for you to try: http://codesynthesis.com/~boris/tmp/xsd/xsd-4.1.0.a8-x86_64-linux-gnu.tar.bz2 It compiles all the openADR schemas, however, I wasn't able to compile the generated C++. It looks like the schema uses recursive self-inclusion and will need the file-per-type mode. Were you able to make it work with XSD 3.3 in the file-per-schema mode? Boris From bhargav06513 at gmail.com Thu Mar 17 05:59:25 2016 From: bhargav06513 at gmail.com (Bhargav ManneMuddu) Date: Thu Mar 17 11:22:40 2016 Subject: [xsd-users] xsd parser Message-ID: Hi, How to parse xsd file if element type is not matched how to jump to other node in xsd parser can explain with example Regards, Bhargav.M From boris at codesynthesis.com Thu Mar 17 11:42:04 2016 From: boris at codesynthesis.com (Boris Kolpackov) Date: Thu Mar 17 11:42:11 2016 Subject: [xsd-users] Segmentation fault running xsd with openADR 2.0b profile schema In-Reply-To: References: Message-ID: Hi James, James Weinkam writes: > I have now successfully compiled, linked, and run our small test program > that load and parses some sample OpenADR xml files, as well as create some > XML files. Great, thanks for letting us know! Boris