Olof, I think your clue about the `range` type being modified or switched is a good one. So, `logicalPortType` is ending up with a `range` child that has the wrong type.
I did some debugging around that idea today. Tomorrow, I'll try to find out when and how `logicalPortType` is ending up with the wrong type of `range`. Thanks for help with and ideas on this. Dave On Fri, Mar 09, 2018 at 12:53:41PM +0100, Olof Kindgren 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 > > 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
