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
>>
>
>
------------------------------------------------------------------------------
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
