Olof,
I believe I've found a fix. After this patch, gDS correctly
generates the `buildChildren` method in class `logicalPortType` so
that the `range` child is built as an instance of class `range` and
not as an `unsignedPositiveLongintExpression`.
It does cause other differences in the generated module. I tried to
track down several of them, and I believe that these differences are
corrections analogous to the `logicalPortType` and `range`, and are
not errors. But, I could be confused about that. The XML schema
(ipxact) is pretty complex.
This patched version of `generateDS.py` still passes the unit tests,
which gives us some reason to believe that this change has not
introduced errors.
I've attached a fixed version in a separate email. There is also a
patch attached to this email, but I don't know whether that can be
applied to your version of generateDS.py.
I'm rushing this to you, because I don't want you to spend more time
on this, *if* we do have the correct patch. I'll do some more
checking, tomorrow.
If you try it, please let me know about your results.
Dave
On Sun, Mar 11, 2018 at 09:29:59PM +0100, Olof Kindgren wrote:
> On Fri, Mar 9, 2018 at 12:53 PM, Olof Kindgren <olof.kindg...@gmail.com>
> wrote:
>
> >
> >
> > On Thu, Mar 8, 2018 at 11:32 PM, Dave Kuhlman <dkuhl...@davekuhlman.org>
> > wrote:
> >
> >> Olof,
> >>
> >> I saw in another email from you that you solved your namespace issue
> >> with the --no-namespace-defs command line option.
> >>
> >> Great.
> >>
> >
> > I realize later that I had not solved it completely, but I'll leave that
> > for now. Still have some things to check here
> >
> >>
> >> Concerning the problem you describe below related to the differences
> >> between classes logicalPort and partSelect -- Thank you for
> >> providing that sample code and the XML schemas (in the github repo).
> >> I was able to generate a module using your shell script. And, yes I
> >> do not understand why the logicalPort class is building a
> >> unsignedPositiveLongintExpression object while the partSelect is
> >> building a range_ object. Possibly because "range" is a Python
> >> keyword? Or, maybe because one range is defined inside an
> >> xs:sequence and the other is inside an xs:choice.
> >>
> >> I'll look at this problem again tomorrow.
> >>
> >> But, if you've already solved this or have ideas on it, let me know.
> >>
> >>
> > I tested with adding a xs:choice outside of the sequence, but to no big
> > suprise that only changed the 'choice' element of the class.
> >
> > Another theory I had was that it was instead dependent on order of
> > evaulation, so that range might have been redefined between parsing
> > logicalPort and partSelect. I haven't really mapped out the generateDS
> > code, but as a test I looked at the contents of DelayedElements during the
> > generation of the two classes.
> >
> > When partSelect is generated, DelayedElements contain one instance of
> > range looking like this <XschemaElement name: "range" type: "range">
> >
> > When logicalPort is generated, DelayedElements instead contain the
> > following elements with the name 'range'
> > <XschemaElement name: "range" type: "range">
> > <XschemaElement name: "range" type: "unsignedPositiveLongintExpression">
> > <XschemaElement name: "range" type: "range">
> > <XschemaElement name: "range" type: "unsignedPositiveLongintExpression">
> > <XschemaElement name: "range" type: "unsignedPositiveLongintExpression">
> > <XschemaElement name: "range" type: "range">
> > <XschemaElement name: "range" type: "unsignedPositiveLongintExpression">
> > <XschemaElement name: "range" type: "unsignedPositiveLongintExpression">
> >
> > AlreadyGenerated contains http://www.accellera.org/
> > XMLSchema/IPXACT/1685-2014:range in both cases
> >
> > I'm fully aware that I might be looking at the wrong thing here, but I
> > though I'd mention my observations as I was a bit surprised about the
> > DelayedElements contents
> >
> > Cheers,
> > Olof
> >
>
> Ok, so I spent far more time on this than I intended to. Just couldn't let
> it go :)
>
> Anyway, this is what I have discovered so far.
>
> It has nothing to do with the element being called range. I renamed all
> occurances of range to deranged and still end up with a
> unsignedPositiveLongintExpression in the logicalPortType class.
>
> I did however noticed that the name 'range' appears in several places in
> the XML files, and some of the were defined as
> unsignedPositiveLongintExpression. Hmm... a clue here. I kept the
> definition of the one I wanted and renamed the other ones to range1,
> range2, range3 and range4. This made the problem go away.
> So.. my guess is that first when partSelect is evaluated in
> annotate_find_type, it will evaulate range to the definition I want. After
> that, the other range elements are evaluated, which overwrites the original
> defintion of range. After that, logicalPortType is evaluated and get the
> wrong range definition. (this theory is also supported by some trace print
> debugging I added to the generateDS code) And I presume the evaluation
> order is dependent in the include order.
>
> As my XML skills are a bit so-so I can't really discern if this is a bug in
> generateDS, or if the multiple range definitions are ambiguous and gives
> generateDS no choice but to guess.
>
> Will report back if I get time to do more debugging, but as I'm unsure
> about where to put the blame at this point, I will probably want for some
> input
>
> Cheers,
> Olof
>
>
> > More later.
> >>
> >> Dave
> >>
> >> On Wed, Mar 07, 2018 at 12:09:48PM +0100, Olof Kindgren wrote:
> >> > Not sure how to best describe the problem, but I found an issue where it
> >> > seems like I get the subelement of a node instead of the node itself.
> >> >
> >> > The following input XML
> >> > <ipxact:portMap>
> >> > <ipxact:logicalPort>
> >> > <ipxact:name>adr_o</ipxact:name>
> >> > <ipxact:range>
> >> > <ipxact:left>2</ipxact:left>
> >> > <ipxact:right>0</ipxact:right>
> >> > </ipxact:range>
> >> > </ipxact:logicalPort>
> >> > <ipxact:physicalPort>
> >> > <ipxact:name>wb_adr_i</ipxact:name>
> >> > <ipxact:partSelect>
> >> > <ipxact:range>
> >> > <ipxact:left>2</ipxact:left>
> >> > <ipxact:right>0</ipxact:right>
> >> > </ipxact:range>
> >> > </ipxact:partSelect>
> >> > </ipxact:physicalPort>
> >> > </ipxact:portMap>
> >> >
> >> > will generate
> >> >
> >> > <ipxact:portMap xmlns:ipxact="
> >> > http://www.accellera.org/XMLSchema/IPXACT/1685-2014";>
> >> > <ipxact:logicalPort xmlns:ipxact="
> >> > http://www.accellera.org/XMLSchema/IPXACT/1685-2014";>
> >> > <ipxact:name>adr_o</ipxact:name>
> >> > <ipxact:range>
> >> >
> >> >
> >> > </ipxact:range>
> >> > </ipxact:logicalPort>
> >> > <ipxact:physicalPort xmlns:ipxact="
> >> > http://www.accellera.org/XMLSchema/IPXACT/1685-2014";>
> >> > <ipxact:name>wb_adr_i</ipxact:name>
> >> > <ipxact:partSelect xmlns:ipxact="
> >> > http://www.accellera.org/XMLSchema/IPXACT/1685-2014";>
> >> > <ipxact:range xmlns:ipxact="
> >> > http://www.accellera.org/XMLSchema/IPXACT/1685-2014";>
> >> > <ipxact:left>2</ipxact:left>
> >> > <ipxact:right>0</ipxact:right>
> >> > </ipxact:range>
> >> > </ipxact:partSelect>
> >> > </ipxact:physicalPort>
> >> > </ipxact:portMap>
> >> >
> >> > when it is exported.
> >> >
> >> > Looking through the python object tree I see that the range object is
> >> > determined to be a ipxact.unsignedPositiveLongintExpression in the case
> >> > where it is missing in the output file, while it is a ipxact.rangeType
> >> in
> >> > the case where it works. I see that there are also differences in the
> >> > Python code generated by generateDS between the partSelect and
> >> logicalPort
> >> > classes
> >> >
> >> > I have prepared a test case here
> >> > https://github.com/olofk/ipxact_gen/tree/gendsbugs
> >> >
> >> > regen.sh will run generateDS
> >> > test_range.sh will print out the differences in types as mentioned above
> >> >
> >> > Finding this painfully hard to describe, so please let me know if I can
> >> add
> >> > any more information
> >> >
> >> > Cheers,
> >> > Olof
> >>
> >> > ------------------------------------------------------------
> >> ------------------
> >> > Check out the vibrant tech community on one of the world's most
> >> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >>
> >> > _______________________________________________
> >> > generateds-users mailing list
> >> > generateds-users@lists.sourceforge.net
> >> > https://lists.sourceforge.net/lists/listinfo/generateds-users
> >>
> >>
> >> --
> >>
> >> Dave Kuhlman
> >> http://www.davekuhlman.org
> >>
> >
> >
--
Dave Kuhlman
http://www.davekuhlman.org
diff -r 561c89c0595e generateDS.py
--- a/generateDS.py Mon Mar 05 10:33:29 2018 -0800
+++ b/generateDS.py Tue Mar 13 16:41:08 2018 -0700
@@ -1623,7 +1623,7 @@
self.inNonanonymousComplexType = 1
element = XschemaElement(attrs, Targetnamespace)
fqn = element.getFullyQualifiedName()
- if fqn:
+ if fqn and name == ComplexTypeType:
fqnToElementDict[fqn] = element
if element.prefix in prefixToNamespaceMap:
element.namespace = prefixToNamespaceMap[element.prefix]
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
generateds-users mailing list
generateds-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/generateds-users
