From aazmp at yandex.ru Tue Dec 4 01:11:09 2018 From: aazmp at yandex.ru (=?utf-8?B?0J/QtdGB0L7RhtC60LjQuSDQnNCw0LrRgdC40Lw=?=) Date: Tue Dec 4 01:22:47 2018 Subject: [xsde-users] XSD/e compiler sources (release candidate) Message-ID: <6921131543903869@sas1-a3690af4eda2.qloud-c.yandex.net> Hi Is it possible to get XSD/e compiler's source, corresponding to latest libxsde RC http://codesynthesis.com/~boris/tmp/xsde/xsde-3.3.0.a8-x86_64-linux-gnu.tar.bz2 ? Thanks From yadykin_a at mail.ru Wed Dec 5 02:15:38 2018 From: yadykin_a at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFlhZHlraW4=?=) Date: Wed Dec 5 08:59:13 2018 Subject: [xsde-users] Source codes for XSD/e compiler Message-ID: <1543994138.868780086@f475.i.mail.ru> Dear Boris, It looks like that last available alpha version of XSD/e 3.3.0 (a10 from 2016-01-17) does not contain source codes for XSD/e compiler. Is?compiler sources still opened? Could you please be so kind as to share it?? Thanks in advance. Best regards, Alexander Yadykin From boris at codesynthesis.com Wed Dec 5 08:56:16 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 5 09:07:49 2018 Subject: [xsde-users] Source codes for XSD/e compiler In-Reply-To: <1543994138.868780086@f475.i.mail.ru> References: <1543994138.868780086@f475.i.mail.ru> Message-ID: Alexander Yadykin writes: > It looks like that last available alpha version of XSD/e 3.3.0 (a10 > from 2016-01-17) does not contain source codes for XSD/e compiler. It is available in the repository, just not as a package: https://scm.codesynthesis.com/cgit/xsde/xsde/ While recreating the exact source code the a10 binary was built from would be too time consuming, I can make a11 and package its source code, if that would be helpful. From yadykin_a at mail.ru Wed Dec 5 22:42:53 2018 From: yadykin_a at mail.ru (=?UTF-8?B?QWxleGFuZGVyIFlhZHlraW4=?=) Date: Thu Dec 6 02:09:04 2018 Subject: =?UTF-8?B?UmVbMl06IFt4c2RlLXVzZXJzXSBTb3VyY2UgY29kZXMgZm9yIFhTRC9lIGNv?= =?UTF-8?B?bXBpbGVy?= In-Reply-To: References: <1543994138.868780086@f475.i.mail.ru> Message-ID: <1544067773.161292796@f367.i.mail.ru> Dear Boris, Thanks a lot! Access to repository is a most convenient solution in my case. I hope that I can build project by my own forces. Thank you one more time. Best regards, Alexander Yadykin From aazmp at yandex.ru Tue Dec 11 06:50:40 2018 From: aazmp at yandex.ru (=?utf-8?B?0J/QtdGB0L7RhtC60LjQuSDQnNCw0LrRgdC40Lw=?=) Date: Tue Dec 11 07:02:42 2018 Subject: [xsde-users] using same TypeNames in different NameSpaces in inheritance chain Message-ID: <11559031544529040@iva5-d3020dc3459d.qloud-c.yandex.net> Hi Could someone please tell if i use incorrect xsd schema or incorrect xsde compiler parameters or if type serializer is incorrectly generated tested with 3.3.0-a8 version for linux and git version with XSDE_REUSE_STYLE_TIEIN flag in attachment archive there are xsd-schemas, (level1.xsd, level2.xsd) runCompiler.sh (with two calls to xsdeCompiler) main.cpp (creates aggregator for derived type element and calls its root_serializer ) i have two schemas (level1.xsd, level2.xsd), each in it's own namespace (level1, level2 respectiely) level2.xsd imports level1.xsd on level1 i declare a type level1:ElemType and element level1:Elem of this type on level2 - level2:ElemType derived from level1:ElemType and element level2:Elem, that substitutes level1:Elem on level1 my element have one field a1 (int) and on level2 field a2 (double) is added when i create top level aggregator level2::Elem_saggr and try to serialize with its root_serializer() program is stopped at this assertion (in file level2-sskel.cxx): int ElemType_sskel:: a1 () { assert (this->ElemType_impl_); // <---- here this->ElemType_impl_ == 0x0 return this->ElemType_impl_->a1 (); } it checks ElemType_impl_ of derived type, not base if this check is replaced with assert (level1::ElemType_sskel::ElemType_impl_); then it passes ok or if in level2.xsd schema derived type is named differently ElemType2 this function becomes int ElemType2_sskel:: a1 () { assert (this->ElemType_impl_); return this->ElemType_impl_->a1 (); } and checks base ElemType_impl_, which is not null is it correct to have same type names (in different namespaces) for derived types? or maybe its incorrect to use TIEIN reuse style in that case? Thanks -------------- next part -------------- A non-text attachment was scrubbed... Name: xsdeNameOverlap.tar.gz Type: application/x-gzip Size: 1583 bytes Desc: not available Url : https://codesynthesis.com/pipermail/xsde-users/attachments/20181211/f80f7076/xsdeNameOverlap.tar.bin From boris at codesynthesis.com Wed Dec 12 10:15:32 2018 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Dec 12 10:27:29 2018 Subject: [xsde-users] using same TypeNames in different NameSpaces in inheritance chain In-Reply-To: <11559031544529040@iva5-d3020dc3459d.qloud-c.yandex.net> References: <11559031544529040@iva5-d3020dc3459d.qloud-c.yandex.net> Message-ID: ???????? ?????? writes: > is it correct to have same type names (in different namespaces) for > derived types? or maybe its incorrect to use TIEIN reuse style in > that case? While it should be correct on the schema level, as you have probably realized by now, the mapping to C++ is fairly complex and there are many corner cases. Generally, we recommend limiting XSD/e usage to simple schemas. Things can get especially tricky with polymorphism. In this particular case it could be a bug in XSD/e or you could have wired something incorrectly. Unfortunately, I don't have the bandwidth to debug this to any extend. One thing you may want to try is switch to the mix-in reuse and see if that makes any difference. From aazmp at yandex.ru Mon Dec 17 13:27:38 2018 From: aazmp at yandex.ru (=?utf-8?B?0J/QtdGB0L7RhtC60LjQuSDQnNCw0LrRgdC40Lw=?=) Date: Mon Dec 17 13:39:59 2018 Subject: [xsde-users] using same TypeNames in different NameSpaces in inheritance chain In-Reply-To: References: <11559031544529040@iva5-d3020dc3459d.qloud-c.yandex.net> Message-ID: <5403521545071258@myt4-174696c9aa9d.qloud-c.yandex.net> Hi 12.12.2018, 18:15, "Boris Kolpackov" : > One thing you may want to > try is switch to the mix-in reuse and see if that makes any > difference. with MIXIN there is a similar error, derived element tries to call ::pre(), but calls its own (because its name has overriden base) and recursion begins if i understood correctly it is not a bug in compiler, just probably unfortunate "choice" of C++ constructions to call to sskel elements in case of TIEIN version this->{ElemType}_impl overrides base one with the same name to generate example from previous message int ElemType_sskel:: a1 () { assert (this->ElemType_impl_); // <---- here this->ElemType_impl_ == 0x0 return this->ElemType_impl_->a1 (); } code from cxx/serializer/serializer-source.cxx : starting around line 150 is used if (ret != L"void") { String const& name (ename (e)); os << ret << " " << scope_ << "::" << endl << name << " ()" << "{" << "assert (this->" << impl << ");" << "return this->" << impl << "->" << name << " ();" << "}"; } Probably replacing "assert (this->" << impl << ");" with something like "assert (" << SCOPE_UNROLL(e.scope()) << impl << ");" where SCOPE_UNROLLED is formed through series of calls String SCOPE_UNROLL(Node e) { if (e.scope().named_p()) { return SCOPE_UNROLL(e.scope()) + "::" + e.scope().name(); } else { return ""; } } will try to test this From aazmp at yandex.ru Mon Dec 24 06:47:05 2018 From: aazmp at yandex.ru (=?utf-8?B?0J/QtdGB0L7RhtC60LjQuSDQnNCw0LrRgdC40Lw=?=) Date: Mon Dec 24 06:59:48 2018 Subject: [xsde-users] using same TypeNames in different NameSpaces in inheritance chain In-Reply-To: <5403521545071258@myt4-174696c9aa9d.qloud-c.yandex.net> References: <11559031544529040@iva5-d3020dc3459d.qloud-c.yandex.net> <5403521545071258@myt4-174696c9aa9d.qloud-c.yandex.net> Message-ID: <8787061545652025@sas1-2b3c3045b736.qloud-c.yandex.net> this is what seems to work for me cxx/serializer/serializer-source.cxx to acquire c++ namespace of element +static SemanticGraph::Namespace* getNameSpace(SemanticGraph::Nameable& n) +{ + SemanticGraph::Namespace* ns = 0; + SemanticGraph::Nameable* n_ = &n.scope(); + while (!ns) + { + if (!n_->named_p()) + break; + ns = dynamic_cast(n_); + if (ns) + break; + n_ = &n_->scope(); + } + return ns; +} + using e.namespace_() didn't work (do not know if it should), sometimes it returned namespace of base type instead of actual then two parts of complete scope :: for each element/attribute/choice etc like this + String scopeTypeSskelName; + String scopeNamespace; + { + SemanticGraph::Scope& sc = scope (c); + const SemanticGraph::Type* scopeType = dynamic_cast(&sc); + scopeTypeSskelName = scopeType ? this->ename(*scopeType) + L"::" : L"E_R_R_O_R "; + SemanticGraph::Namespace* ns = getNameSpace(sc); // this is call to function above + if (ns) + scopeNamespace = this->ns_name(*ns) + L"::"; + } + and instead of construction like this - << "assert (this->" << impl << ");" - << "return this->" << impl << "->" << next << " ();" using + << "assert (" << scopeNamespace << scopeTypeSskelName << impl << ");" + << "return " << scopeNamespace << scopeTypeSskelName << impl << "->" << next << " ();" tried for SemanticGraph::Element SemanticGraph::Choice SemanticGraph::Attribute seems to be working