"v0.99: Fixed MI bug with interface vtbl dispatch."

Whatever you fixed doesn't resolve the broken MI-Interface vTable afflicting certain areas of Mango ... the wrong methods are still invoked when calling through an interface.


"Walter" <newshound@digitalmars.com> wrote in message news:cg5lqs$n6p$1@digitaldaemon.com...
> Ok, I'll check them out.
>
> "antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> > "Walter" wrote...
> > > What exactly is mango waiting on?
> >
> > - The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99
say
> > this is resolved, though I haven't tried it yet. Certain areas of Mango
> have
> > been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'd
go
> > in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but move
> it
> > to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.
> >
> > - The version() operational discrepancy between Windows and linux was
> still
> > causing grief recently.
> >
> > - Static constructors not invoked for inner/nested classes.
> >
> > - The static-constructor ordering noted in May, June, and July. I've
held
> > off on a few things until that is resolved.
> >
> > - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than a
> bug,
> > but it places a burden on Mango clients that is totally unnecessary and, frankly, untenable. You don't really run into this until you start using Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO),
yet
> > there are likely several ways to avoid said hole completely while still providing the required functionality.
> >
> > - Corrupt stack when assigning 'out' arguments within a nested/inner function.
> >
> >
> > Each of these has stalled, delayed, or halted Mango development in one
way
> > or another. Sure, one just finds something else to work on; but it's
hard
> to
> > maintain focus when ongoing issues are not resolved for months on end.
> >
> >
> >
> >
>
>

more info:

Turns out this is aggravated by what I'd term a "compound" Interface. If you do the following:

interface ICompound : ISomeInterface, IOtherInterface, IYetAnotherInterface {}

and then

interface IDerived : ICompound
{
   // some method signatures ...
}

IDerived.method ();

the vTable gets borked. Note that the ICompound interface is /empty/. There's no additional signatures, as it's just a convenience for combining/gathering common interfaces together. If I declare the Interfaces explicitly (rather than using ICompound) then v0.100 does the right thing.

The "empty" Interface may be a factor?



"antiAlias" <fu@bar.com> wrote in message news:cgaob0$10as$1@digitaldaemon.com...
> "v0.99: Fixed MI bug with interface vtbl dispatch."
>
> Whatever you fixed doesn't resolve the broken MI-Interface vTable
afflicting
> certain areas of Mango ... the wrong methods are still invoked when
calling
> through an interface.
>
>
> "Walter" <newshound@digitalmars.com> wrote in message news:cg5lqs$n6p$1@digitaldaemon.com...
> > Ok, I'll check them out.
> >
> > "antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> > > "Walter" wrote...
> > > > What exactly is mango waiting on?
> > >
> > > - The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99
> say
> > > this is resolved, though I haven't tried it yet. Certain areas of
Mango
> > have
> > > been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage,
I'd
> go
> > > in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but
move
> > it
> > > to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.
> > >
> > > - The version() operational discrepancy between Windows and linux was
> > still
> > > causing grief recently.
> > >
> > > - Static constructors not invoked for inner/nested classes.
> > >
> > > - The static-constructor ordering noted in May, June, and July. I've
> held
> > > off on a few things until that is resolved.
> > >
> > > - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than
a
> > bug,
> > > but it places a burden on Mango clients that is totally unnecessary
and,
> > > frankly, untenable. You don't really run into this until you start
using
> > > Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO),
> yet
> > > there are likely several ways to avoid said hole completely while
still
> > > providing the required functionality.
> > >
> > > - Corrupt stack when assigning 'out' arguments within a nested/inner function.
> > >
> > >
> > > Each of these has stalled, delayed, or halted Mango development in one
> way
> > > or another. Sure, one just finds something else to work on; but it's
> hard
> > to
> > > maintain focus when ongoing issues are not resolved for months on end.
> > >
> > >
> > >
> > >
> >
> >
>
>

Can you post a complete example, please?

I would, but Mango is a bit too big <g>

Can you work with the original source, if I guide you on it?


"Walter" <newshound@digitalmars.com> wrote in message news:cgb2ai$18df$1@digitaldaemon.com...
>
> Can you post a complete example, please?
>
>

Appreciated. Please let me know if you need further input.

"Walter"  wrote
> Ok, I'll check them out.




> "antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> > "Walter" wrote...
> > > What exactly is mango waiting on?
> >
> > - The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99
say
> > this is resolved, though I haven't tried it yet. Certain areas of Mango
> have
> > been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage, I'd
go
> > in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but move
> it
> > to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.
> >
> > - The version() operational discrepancy between Windows and linux was
> still
> > causing grief recently.
> >
> > - Static constructors not invoked for inner/nested classes.
> >
> > - The static-constructor ordering noted in May, June, and July. I've
held
> > off on a few things until that is resolved.
> >
> > - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than a
> bug,
> > but it places a burden on Mango clients that is totally unnecessary and, frankly, untenable. You don't really run into this until you start using Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO),
yet
> > there are likely several ways to avoid said hole completely while still providing the required functionality.
> >
> > - Corrupt stack when assigning 'out' arguments within a nested/inner function.
> >
> >
> > Each of these has stalled, delayed, or halted Mango development in one
way
> > or another. Sure, one just finds something else to work on; but it's
hard
> to
> > maintain focus when ongoing issues are not resolved for months on end.
> >
> >
> >
> >
>
>

If it's too big for you, what hope have I, who is totally unfamiliar with it, to even identify what's going wrong?

"antiAlias" <fu@bar.com> wrote in message news:cgb37c$190f$1@digitaldaemon.com...
> I would, but Mango is a bit too big <g>
>
> Can you work with the original source, if I guide you on it?
>
>
> "Walter" <newshound@digitalmars.com> wrote in message news:cgb2ai$18df$1@digitaldaemon.com...
> >
> > Can you post a complete example, please?
> >
> >
>
>

I offered to guide you; doesn't that help? There is a small example program that exhibits the bug, but it uses a reasonable portion of Mango. Therefore, it's way too big to post.

I suppose I was hoping you might take a look at the Interface inheritance layout, inspect the generated vTables, and deduce a few ideas to try out in the compiler in terms of resolving the issue. Change the compiler; compile the example again; see if it got fixed; if so, make your own small test-case for regression purposes (once you understood exactly how the problem arose).

You noted recently in a post to Matthew that if a bug could not be whittled down to the requisite "10 line" size, then what one had would be good enough. That's the situation here, and I'd like to try and help you resolve this bug. I can tell you exactly how to change the source to make said bug appear and disappear; is that not helpful? I'll add a version() block if it would make it easier?

What do you wish to do?


"Walter" <newshound@digitalmars.com> wrote in message news:cgeu4l$l4d$1@digitaldaemon.com...
> If it's too big for you, what hope have I, who is totally unfamiliar with it, to even identify what's going wrong?
>
> "antiAlias" <fu@bar.com> wrote in message news:cgb37c$190f$1@digitaldaemon.com...
> > I would, but Mango is a bit too big <g>
> >
> > Can you work with the original source, if I guide you on it?
> >
> >
> > "Walter" <newshound@digitalmars.com> wrote in message news:cgb2ai$18df$1@digitaldaemon.com...
> > >
> > > Can you post a complete example, please?
> > >
> > >
> >
> >
>
>

"antiAlias" <fu@bar.com> wrote in message news:cgf0en$ma1$1@digitaldaemon.com...
> I offered to guide you; doesn't that help? There is a small example
program
> that exhibits the bug, but it uses a reasonable portion of Mango.
Therefore,
> it's way too big to post.
>
> I suppose I was hoping you might take a look at the Interface inheritance layout, inspect the generated vTables, and deduce a few ideas to try out
in
> the compiler in terms of resolving the issue. Change the compiler; compile the example again; see if it got fixed; if so, make your own small
test-case
> for regression purposes (once you understood exactly how the problem
arose).
>
> You noted recently in a post to Matthew that if a bug could not be
whittled
> down to the requisite "10 line" size, then what one had would be good enough. That's the situation here, and I'd like to try and help you
resolve
> this bug. I can tell you exactly how to change the source to make said bug appear and disappear; is that not helpful? I'll add a version() block if
it
> would make it easier?

My intent was to show how to do a shrink. All of them did shrink to 10 or 15 lines.

> What do you wish to do?

Copy mango to another directory, and delete everything that is not absolutely necessary for reproducing the problem. I ask you to believe me that that is far more productive at finding the problem then it is trying to disassemble the object files and poke through thousands of lines of irrelevant instructions.

Message numbers of the specific ones would also be most helpful.

"antiAlias" <fu@bar.com> wrote in message news:cgesu7$k2r$1@digitaldaemon.com...
> Appreciated. Please let me know if you need further input.
>
> "Walter"  wrote
> > Ok, I'll check them out.
>
>
>
>
> > "antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> > > "Walter" wrote...
> > > > What exactly is mango waiting on?
> > >
> > > - The ongoing Interface issues (now described as Interface MI issues) originally noted in April, then again in June. Release notes for v0.99
> say
> > > this is resolved, though I haven't tried it yet. Certain areas of
Mango
> > have
> > > been terribly fragile for months due to this, and non-extensible. For example, whenever a gpf would occur in relation to Interface usage,
I'd
> go
> > > in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but
move
> > it
> > > to another. Adding additional Interfaces to class declarations simply aggravated the problem, so Mango development vis-a-vis Interfaces just stopped.
> > >
> > > - The version() operational discrepancy between Windows and linux was
> > still
> > > causing grief recently.
> > >
> > > - Static constructors not invoked for inner/nested classes.
> > >
> > > - The static-constructor ordering noted in May, June, and July. I've
> held
> > > off on a few things until that is resolved.
> > >
> > > - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather than
a
> > bug,
> > > but it places a burden on Mango clients that is totally unnecessary
and,
> > > frankly, untenable. You don't really run into this until you start
using
> > > Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature, IMO),
> yet
> > > there are likely several ways to avoid said hole completely while
still
> > > providing the required functionality.
> > >
> > > - Corrupt stack when assigning 'out' arguments within a nested/inner function.
> > >
> > >
> > > Each of these has stalled, delayed, or halted Mango development in one
> way
> > > or another. Sure, one just finds something else to work on; but it's
> hard
> > to
> > > maintain focus when ongoing issues are not resolved for months on end.
> > >
> > >
> > >
> > >
> >
> >
>
>

"Walter" <newshound@digitalmars.com> wrote
> Message numbers of the specific ones would also be most helpful.

No problem ... here's a few:

news:c74fis$gfi$1@digitaldaemon.com news:c9h3us$2qjl$1@digitaldaemon.com news:c9igfc$1r64$1@digitaldaemon.com news:c9j0lk$2i1a$1@digitaldaemon.com news:c9lc9k$2vc0$1@digitaldaemon.com news:cbla1e$1llq$1@digitaldaemon.com news:ccc8kc$306m$1@digitaldaemon.com news:cctgns$sst$1@digitaldaemon.com news:c4f7rj$2qgi$1@digitaldaemon.com news:c5phf1$1idh$1@digitaldaemon.com news:cgaqe6$11je$1@digitaldaemon.com

The "Satisfying Interface Contracts via Inheritance" issue is not written up as a bug, because it's a (crucial, IMO)missing feature. I sent email to you about this one on April 8th, 12:08pm PST, and it's been noted a few times since then.



> "antiAlias" <fu@bar.com> wrote in message news:cgesu7$k2r$1@digitaldaemon.com...
> > Appreciated. Please let me know if you need further input.
> >
> > "Walter"  wrote
> > > Ok, I'll check them out.
> >
> >
> >
> >
> > > "antiAlias" <fu@bar.com> wrote in message news:cg5gte$k4c$1@digitaldaemon.com...
> > > > "Walter" wrote...
> > > > > What exactly is mango waiting on?
> > > >
> > > > - The ongoing Interface issues (now described as Interface MI
issues)
> > > > originally noted in April, then again in June. Release notes for
v0.99
> > say
> > > > this is resolved, though I haven't tried it yet. Certain areas of
> Mango
> > > have
> > > > been terribly fragile for months due to this, and non-extensible.
For
> > > > example, whenever a gpf would occur in relation to Interface usage,
> I'd
> > go
> > > > in and switch the order in which Interfaces were declared in class declarations (lunacy!). It would eliminate the gpf for one area but
> move
> > > it
> > > > to another. Adding additional Interfaces to class declarations
simply
> > > > aggravated the problem, so Mango development vis-a-vis Interfaces
just
> > > > stopped.
> > > >
> > > > - The version() operational discrepancy between Windows and linux
was
> > > still
> > > > causing grief recently.
> > > >
> > > > - Static constructors not invoked for inner/nested classes.
> > > >
> > > > - The static-constructor ordering noted in May, June, and July. I've
> > held
> > > > off on a few things until that is resolved.
> > > >
> > > > - The inability of a class to satisfy an Interface contract via its inheritance tree (noted in April). This is a design issue rather
than
> a
> > > bug,
> > > > but it places a burden on Mango clients that is totally unnecessary
> and,
> > > > frankly, untenable. You don't really run into this until you start
> using
> > > > Interfaces a lot. Mango is an Interface-based design so, naturally, comes-a-cropper over this all the time. You note there's a potential type-hole involved (though the hole is of a questionable nature,
IMO),
> > yet
> > > > there are likely several ways to avoid said hole completely while
> still
> > > > providing the required functionality.
> > > >
> > > > - Corrupt stack when assigning 'out' arguments within a nested/inner function.
> > > >
> > > >
> > > > Each of these has stalled, delayed, or halted Mango development in
one
> > way
> > > > or another. Sure, one just finds something else to work on; but it's
> > hard
> > > to
> > > > maintain focus when ongoing issues are not resolved for months on
end.
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>