Multiple extens issue with ned files

[Peter Staab]

Hi,

I am having trouble with the ned files again.
My module hierarchy is as follows:

moduleinterface UDPApp
{
gates:
input udpIn;
output udpOut;
}

simple UDPApp1 like UDPApp
{
parameters:
@class(UDPApp1);
...
gates:
input udpIn;
output udpOut;
}

simple UDPApp2 extends UDPApp1 like UDPApp
{
parameters:
@class(UDPApp2);
...
}

UDPApp1 works fine, but when I try to run a simulation with UDPApp2, I
get this error (in the command promp):
"<!> Error: module type has no gate `udpIn', required by interface
`UDPApp', at UDPApp2.ned:26."

When I extend UDPApp2 with gates then I get this error (and the IDE ned
editor also yields an error indicated by a red cross):
"<!> Error: redeclaration of gate `udpIn', at UDPApp2.ned:32."

Where is the error?

Regards,

[Rudolf Hornig]

Have you tried this way? (just declare the gates but do not define)

simple UDPApp2 extends UDPApp1 like UDPApp

{

   parameters:

       @class(UDPApp2);

   gates:

       udpIn;

       udpOut;

[Peter Staab]

No that does not work neither.



Rudolf Hornig schrieb:

[Peter Staab]

Sorry, there is an error in my description.
The mentioned problem occurs when I try to run UDPApp3, so the error occurs after the second inheritance:

simple UDPApp3 extends UDPApp2 like UDPApp
{
   parameters:
       @class(UDPApp2);
...
}

UDPApp1 and UDPApp2 do work. UDPApp3 produces the failure.

You can easily reproduce the error by creating a new project in the IDE and adding three ned files ("UDPApp*.ned).




Rudolf Hornig schrieb:

[Rudolf Hornig]

I've just created the lines below in the IDE (no errors so far).

Do you have the problem in the IDE or during runtime ?

Rudolf

moduleinterface UDPApp

{

   gates:

       input udpIn;

       output udpOut;

}

simple UDPApp1 like UDPApp

{

   parameters:

       @class(UDPApp1);

   gates:

       input udpIn;

       output udpOut;

}

simple UDPApp2 extends UDPApp1 like UDPApp

{

   parameters:

       @class(UDPApp2);

   gates:

       udpIn;

       udpOut;

}

simple UDPApp3 extends UDPApp2 like UDPApp

{

   parameters:

       @class(UDPApp3);

   gates:

       udpIn;

       udpOut;

[Peter Staab]

Yes, the error occurs when I try to start OMNet (it crashes with the failure mentioned before). It is not necessary to make a simulation that uses the UDPApp* modules - it suffices that the UDPApp* modules are loaded.

Btw: I am (trying to) starting OMNet from the IDE.


Rudolf Hornig schrieb:

[Rudolf Hornig]

Ahh ok, I see:

Just leave out the "like UDPApp" when you extending the UDPApp1 module. You will inherit the interface implicitly from UDPApp1

This is working for me (setting "type" to UDPApp1 or  UDPApp2 works, while UDPApp3 fails of course)

Rudolf

(ps: But I agree that specifying the like UDPApp clause should not generate an error, so this is an issue in omnet)

example:

moduleinterface UDPApp

{

    gates:

        input udpIn;

        output udpOut;

}

module UDPApp1 like UDPApp

{

    gates:

        input udpIn;

        output udpOut;

    connections allowunconnected:

}

module UDPApp2 extends UDPApp1      // do not include "like UDPApp" it inherits the interface automatically

{

}

module UDPApp3 {   // no inheritance or interface => cannot be used as udpApp below

    gates:

        input udpIn;

        output udpOut;

}

network Network

{

    // string type = "UDPApp1";  // ok

    string type = "UDPApp2";  // ok

    // string type = "UDPApp3"; // error (of course)

    submodules:

        udpApp: <type> like UDPApp {

        }

        connections allowunconnected:

}

[Henry]

On Oct 21, 2:14 pm, Rudolf Hornig <rudolf.hor...@gmail.com> wrote:
> This is working for me (setting "type" to UDPApp1 or  UDPApp2 works, while
> UDPApp3 fails of course)

Why do you write "of course"?
The whole Idea is to use UDPApp3 inheriting everything from UDPApp2,
not UDPApp2 itself.
This problem occured to me as well and I filed a bug for this:
http://dev.omnetpp.org/bugs/view.php?id=88 with a test case attached.
No solution so far.

The problem is actually not that the gate is lost on the second
inheritance, because the gate is there if you leave the interface
aside. But on the second inheritance the inferface compliance check
fails for no comprehensible reason. I could even find the point where
it fails by debugging the NED-parsing process, but the reason stayed a
mystery for me.

Regards,
Henry

Before you ask, why such a complex inheritance situation is used, I
can give you a rather simple example:
You define an interface and an "abstract" module (UDPApp1)
implementing this interface where you define everything common to all
modules of this kind.
Now you have a special module (UDPApp2) for a given task that extends
the abstract one.
And now you want to write a test case for the special module. In the
test case you want to check for multiple errors of course. This means
you need another module (UDPApp3) around the specialised on to catch
the errors and present some output to check agains. Otherwise you
would have to write one test case for every situation leading to an
error. UDPApp3 needs to behave in every way like UDPApp2 which is
tested so you extend UDPApp2 and voila you meet the bug for the first
time...

> Rudolf
>
> (ps: But I agree that specifying the like UDPApp clause should not generate
> an error, so this is an issue in omnet)
>
> example:
>
> moduleinterface UDPApp
> {
>     gates:
>         input udpIn;
>         output udpOut;
>
> }
>
> module UDPApp1 like UDPApp
> {
>     gates:
>         input udpIn;
>         output udpOut;
>     connections allowunconnected:
>
> }
>

> module UDPApp2 extends UDPApp1      *// do not include "like UDPApp" it
> inherits the interface automatically*
> {
>
> }
>
> module UDPApp3 {   *// no inheritance or interface => cannot be used as
> udpApp below*

[Rudolf Hornig]

On Wed, Oct 21, 2009 at 3:10 PM, Henry <henry....@gmail.com> wrote:

On Oct 21, 2:14 pm, Rudolf Hornig <rudolf.hor...@gmail.com> wrote:
> This is working for me (setting "type" to UDPApp1 or  UDPApp2 works, while
> UDPApp3 fails of course)

Why do you write "of course"?

Ahh, ok. I was writing "of course" because in that file I was just creating a negative test case (i.e. just a module with the same gates, but without interface or inheritance. of course this has to fail...I was testing only the first level :( sorry ) 

Further investigating, I can confirm that on the second level of inheritance the chain is broken. You are right. This is an issue, and it should work correctly. I have raised the priority for this and we will fix it for the next release.

Thanks for reporting it.

Rudolf

[Peter Staab]

The problem is, that until UDPApp2 it does work with and without "like UDPApp". But when I want to extend "UDPApp2" then OMNet crashes (with and w/o "like UDPApp").

moduleinterface UDPApp

{

    gates:

        input udpIn;

        output udpOut;

}

module UDPApp1 like UDPApp

{

    gates:

        input udpIn;

        output udpOut;

    connections allowunconnected:

}

module UDPApp2 extends UDPApp1 like UDPApp

{

}

module UDPApp3 extends UDPApp2 {

    gates:

        input udpIn;

        output udpOut;

}

Rudolf Hornig schrieb:

[Peter Staab]

Ok, thanks. Then you can ignore my last email.

Regards,


Rudolf Hornig schrieb: