Hi Dave,
This seems to work just fine. As you say, it's a massive XML schema, so I
can't easily verify that it's correctly generated but I will let you know
of any potential issues.
Many thanks!
//Olof
On Wed, Mar 14, 2018 at 12:53 AM, Dave Kuhlman <dkuhl...@davekuhlman.org>
wrote:
> 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: "unsignedPositiveLongintExpress
> ion">
> > > <XschemaElement name: "range" type: "range">
> > > <XschemaElement name: "range" type: "unsignedPositiveLongintExpress
> ion">
> > > <XschemaElement name: "range" type: "unsignedPositiveLongintExpress
> ion">
> > > <XschemaElement name: "range" type: "range">
> > > <XschemaElement name: "range" type: "unsignedPositiveLongintExpress
> ion">
> > > <XschemaElement name: "range" type: "unsignedPositiveLongintExpress
> ion">
> > >
> > > 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
>
------------------------------------------------------------------------------
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
