From owagh at tower-research.com Thu Aug 16 10:56:49 2012 From: owagh at tower-research.com (Omkar Wagh) Date: Thu Aug 16 10:56:52 2012 Subject: [xsd-users] Glibc on recompilation Message-ID: <502D0A31.8050907@tower-research.com> Hi I've noticed that if I change the schemas and then run make on my entire project without cleaning the current object files and installed libraries first, then I almost always end up with a an exec that crashes with a weird glibc error (corrupted double linked list). This stops crashing when I clean the object files/libraries and rebuild. The makefile seems to be running xsd and then the c++ compiler every time I make changes to the schema so that's definitely not an issue. Is there something common that I am missing out on here? Omkar From boris at codesynthesis.com Fri Aug 17 06:42:31 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Aug 17 06:27:56 2012 Subject: [xsd-users] Glibc on recompilation In-Reply-To: <502D0A31.8050907@tower-research.com> References: <502D0A31.8050907@tower-research.com> Message-ID: Hi Omkar, Omkar Wagh writes: > The makefile seems to be running xsd and then the c++ compiler every > time I make changes to the schema so that's definitely not an issue. While the makefile may re-compile the schema and then re-compile the generated C++ files, it also needs to re-compile all the C++ source files that use the generated C++ header files. Since you say that if you clean and then re-build the project everything starts working again, then the lack of this last step is most likely the cause of your broken incremental build. I suggest that you contact the author of the makefile and ask them to add missing dependencies on the generated header files. Boris From pvssvikas at gmail.com Thu Aug 23 10:27:00 2012 From: pvssvikas at gmail.com (vikas) Date: Thu Aug 23 10:27:08 2012 Subject: [xsd-users] how to access xs:ref="element" target element name Message-ID: Hello xsd-users, can you please help with the following scenario, I've tried checking at online forums, and user guides, all the given examples but could not find relevant information. *Can you please let me know how to access element name of the parsed xml, when reference elements are being used with xsd?* *Sample xsd:* *Sample xml:* Thanks, -Vikas. From boris at codesynthesis.com Fri Aug 24 09:07:35 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Fri Aug 24 08:51:47 2012 Subject: [xsd-users] how to access xs:ref="element" target element name In-Reply-To: References: Message-ID: Hi Vikas, vikas writes: > *Can you please let me know how to access element name of the parsed xml, > when reference elements are being used with xsd?* > > *Sample xsd:* > > > > maxOccurs="unbounded" /> > > > > *Sample xml:* > > > > > > > > > > I am not sure what you are trying to get. Is it "operation"? Or maybe "createglobaluser"? Or a value of createglobaluser? I suspect your schema is using substitution groups. Have you read Section 2.11, "Mapping for xsi:type and Substitution Groups" in the C++/Tree Mapping User Manual? http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11 Boris From pvssvikas at gmail.com Mon Aug 27 16:35:38 2012 From: pvssvikas at gmail.com (vikas) Date: Mon Aug 27 16:35:45 2012 Subject: [xsd-users] how to access xs:ref="element" target element name In-Reply-To: References: Message-ID: Hello Boris, Thank you very much for your time. Yes we are using substitution groups, I missed the mentioned part of documentation as I was looking for " xsd:ref " kind of example. Thanks for mentioning the relevant section. However, the technique used in that section will be more useful when we have limited number of derived types. In my case we have more number of derived types, so we are maintaining internal map of derived handler objects versus element names, so that xsd derived object can be interpreted by appropriate handler function. I was able to get the xml element node name when "keep_dom" flag is used. can you please help me with information, on when to use NodeName & when to use LocalName methods? In case of keep_dom usage do i need to take care of any special object destruction? or is it fine if I can rely on auto_ptr? auto_ptr s( testbed::config::scenario_ ( "UserCreationCheck.xml", xml_schema::flags::keep_dom ) ); wprintf(L"%s \n",s.get()->_node()->getLocalName()); testbed::config::OperationData &opD1 = *(s.get()->testcases().testcase().begin()->operation().begin()); wprintf(L"%s \n", opD1._node()->getNodeName() ); wprintf(L"%s \n", opD1._node()->getLocalName()); Thanks, -Vikas. On Fri, Aug 24, 2012 at 6:37 PM, Boris Kolpackov wrote: > Hi Vikas, > > vikas writes: > > > *Can you please let me know how to access element name of the parsed xml, > > when reference elements are being used with xsd?* > > > > *Sample xsd:* > > > > > > > > > maxOccurs="unbounded" /> > > > > > > > > *Sample xml:* > > > > > > > > > > > > > > > > > > > > > > I am not sure what you are trying to get. Is it "operation"? Or maybe > "createglobaluser"? Or a value of createglobaluser? > > I suspect your schema is using substitution groups. Have you read > Section 2.11, "Mapping for xsi:type and Substitution Groups" in the > C++/Tree Mapping User Manual? > > > http://www.codesynthesis.com/projects/xsd/documentation/cxx/tree/manual/#2.11 > > Boris > From oo.bryce.oo at gmail.com Tue Aug 28 05:32:56 2012 From: oo.bryce.oo at gmail.com (Brice) Date: Tue Aug 28 05:33:23 2012 Subject: [xsd-users] compilation issue with setg method in zc-istream class Message-ID: Dear developers, we tried to compile a simple source file (main.cpp in attached zip file), using a generated class (created by code synthesis 3.3.0). Compilation fails if we do not set -fpermissive compile option : g++ -I include -L . -lxerces-c-3.1 main.cpp test.cpp In file included from include/xsd/cxx/zc-istream.hxx:215:0, from include/xsd/cxx/tree/parsing/date-time.txx:7, from include/xsd/cxx/tree/parsing.hxx:10, from test.h:68, from test.cpp:41: include/xsd/cxx/zc-istream.txx: In instantiation of ?void xsd::cxx::zc_streambuf::init() [with C = char]?: include/xsd/cxx/zc-istream.txx:17:7: required from ?xsd::cxx::zc_streambuf::zc_streambuf(const xsd::cxx::ro_string&) [with C = char]? include/xsd/cxx/zc-istream.txx:64:20: required from ?xsd::cxx::zc_istream_base::zc_istream_base(const xsd::cxx::ro_string&) [with C = char]? include/xsd/cxx/zc-istream.txx:82:45: required from ?xsd::cxx::zc_istream::zc_istream(const xsd::cxx::ro_string&) [with C = char]? include/xsd/cxx/tree/parsing/long.hxx:69:30: required from ?static long long int xsd::cxx::tree::traits::create(const std::basic_string<_CharT>&, const xercesc_3_1::DOMElement*, xsd::cxx::tree::flags, xsd::cxx::tree::container*) [with C = char; xsd::cxx::tree::container = xsd::cxx::tree::_type]? include/xsd/cxx/tree/parsing/long.hxx:44:52: required from ?static long long int xsd::cxx::tree::traits::create(const xercesc_3_1::DOMElement&, xsd::cxx::tree::flags, xsd::cxx::tree::container*) [with C = char; xsd::cxx::tree::container = xsd::cxx::tree::_type]? test.cpp:123:69: required from here include/xsd/cxx/zc-istream.txx:35:7: error: ?setg? was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation [-fpermissive] include/xsd/cxx/zc-istream.txx:35:7: note: declarations in dependent base ?std::basic_streambuf? are not found by unqualified lookup include/xsd/cxx/zc-istream.txx:35:7: note: use ?this->setg? instead For information, the os used is a Linux CentOS : $ cat /proc/version Linux version 2.6.32-220.el6.x86_64 (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Tue Dec 6 19:48:22 GMT 2011 This does not happen with string types. We are here using integer types (integer, unsignedInteger...) Is there any solution ? Best regards, Brice -------------- next part -------------- A non-text attachment was scrubbed... Name: issue_code_synthesis.zip Type: application/zip Size: 6394 bytes Desc: not available Url : http://codesynthesis.com/pipermail/xsd-users/attachments/20120828/44008497/issue_code_synthesis.zip From jrm.martinet at gmail.com Tue Aug 28 02:31:19 2012 From: jrm.martinet at gmail.com (jerome martinet) Date: Tue Aug 28 08:01:21 2012 Subject: [xsd-users] multiple xsd Message-ID: HI, I'm trying to transform multiple xsd schemas I tryed to use the option --file-per-type but the generated code in incomplet (a type is not defined) What's the best solution to do this ? Sincerely, J?r?me From boris at codesynthesis.com Tue Aug 28 08:27:16 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 28 08:10:44 2012 Subject: [xsd-users] how to access xs:ref="element" target element name In-Reply-To: References: Message-ID: Hi Vikas, vikas writes: > In my case we have more number of derived types, so we are maintaining > internal map of derived handler objects versus element names, so that xsd > derived object can be interpreted by appropriate handler function. If you have one-to-one mapping between derived types and element names, then you could instead have a map of std::type_info to handler functions. This will be faster than comparing strings (element names) and you won't need to maintain the DOM association. > I was able to get the xml element node name when "keep_dom" flag is used. > can you please help me with information, on when to use NodeName & when to > use LocalName methods? See the Xerces-C++ documentation. > In case of keep_dom usage do i need to take care of any special object > destruction? or is it fine if I can rely on auto_ptr? Again, refer to the documentation. Specifically, Section 5.1, "DOM Association". Boris From boris at codesynthesis.com Tue Aug 28 08:34:33 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 28 08:18:02 2012 Subject: [xsd-users] multiple xsd In-Reply-To: References: Message-ID: Hi Jerome, jerome martinet writes: > I'm trying to transform multiple xsd schemas > I tryed to use the option --file-per-type but the generated code in > incomplet (a type is not defined) What's the best solution to do this? Normally you should just compile each of your schemas separately (i.e., the file-per-schema mode). The file-per-type mode is only need for certain schemas that have circular dependencies that involve inheritance. It is difficult to say what exactly is wrong in your case without seeing the schemas. If you can send them to me (you can send them off-list), then I can take a look. Boris From boris at codesynthesis.com Tue Aug 28 08:41:21 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 28 08:24:49 2012 Subject: [xsd-users] compilation issue with setg method in zc-istream class In-Reply-To: References: Message-ID: Hi Brice, Brice writes: > include/xsd/cxx/zc-istream.txx:35:7: error: ?setg? was not declared in this > scope, and no declarations were found by argument-dependent lookup at the > point of instantiation [-fpermissive] > include/xsd/cxx/zc-istream.txx:35:7: note: declarations in dependent base > ?std::basic_streambuf? are not found by unqualified lookup > include/xsd/cxx/zc-istream.txx:35:7: note: use ?this->setg? instead This is a known bug that we have fixed for the next release of XSD. In the meantime, you may want to try the pre-release: http://www.codesynthesis.com/~boris/tmp/xsd/xsd-4.0.0.a9-i686-linux-gnu.tar.bz2 http://www.codesynthesis.com/~boris/tmp/xsd/xsd-4.0.0.a9-x86_64-linux-gnu.tar.bz2 Boris From oo.bryce.oo at gmail.com Tue Aug 28 08:50:05 2012 From: oo.bryce.oo at gmail.com (Brice) Date: Tue Aug 28 08:50:31 2012 Subject: [xsd-users] compilation issue with setg method in zc-istream class In-Reply-To: References: Message-ID: Hi Boris, Many thanks for your prompt reply, I will have a look at this new version. Is there any official delivery date for the 4.0.0 version planned ? Once more, many thanks ! Cheers, Brice On Tue, Aug 28, 2012 at 2:41 PM, Boris Kolpackov wrote: > Hi Brice, > > Brice writes: > > > include/xsd/cxx/zc-istream.txx:35:7: error: ?setg? was not declared in > this > > scope, and no declarations were found by argument-dependent lookup at the > > point of instantiation [-fpermissive] > > include/xsd/cxx/zc-istream.txx:35:7: note: declarations in dependent base > > ?std::basic_streambuf? are not found by unqualified lookup > > include/xsd/cxx/zc-istream.txx:35:7: note: use ?this->setg? instead > > This is a known bug that we have fixed for the next release of XSD. > In the meantime, you may want to try the pre-release: > > > http://www.codesynthesis.com/~boris/tmp/xsd/xsd-4.0.0.a9-i686-linux-gnu.tar.bz2 > > http://www.codesynthesis.com/~boris/tmp/xsd/xsd-4.0.0.a9-x86_64-linux-gnu.tar.bz2 > > Boris > From boris at codesynthesis.com Tue Aug 28 09:12:33 2012 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 28 08:56:00 2012 Subject: [xsd-users] compilation issue with setg method in zc-istream class In-Reply-To: References: Message-ID: Hi Brice, Brice writes: > Is there any official delivery date for the 4.0.0 version planned? No firm date yet and it is still at least a few months out. The other thing that you may want to try is to use the RPM package for XSD (called xsdcxx) that comes with CentOS. It normally includes patches for issue like this. Boris