[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Liberty-eiffel] I dont agree with that error
From: |
Raphael Mack |
Subject: |
Re: [Liberty-eiffel] I dont agree with that error |
Date: |
Mon, 06 Jan 2014 10:23:18 +0100 |
Hi,
I'd like to investigate into this, but I don't yet understand the
intention of the original commit which introduces the problem. Could you
elaborate here? - Just reverting these changes would probably help to
fix Josés compile issue, but Frederic (he is zen, right?) didn't add
this check just for fun...
Cheers,
Rapha
Am Freitag, den 13.12.2013, 23:01 +0100 schrieb José Bollo:
> Le Thu, 12 Dec 2013 14:01:24 +0100,
> Cyril ADRIAN <address@hidden> a écrit :
>
> > Hi José,
> >
> > 2013/12/11 José Bollo <address@hidden>
> >
> > > It works very well with SmartEiffel but adler doesn't want to
> > > compile it. It argues that at least one conforming path must exist.
> > > Why? I can't agree. From ECMA page 94, the validity rule VMRC also
> > > disagree.
> > >
> > > So Why? What is the good reason that I don't know?
> > >
> >
> > You are right, that is strange. It comes from the never-released
> > SmartEiffel 2.4 codebase
> > (r8513<https://gforge.inria.fr/scm/viewvc.php/trunk/tools/kernel/feature_accumulator.e?root=smarteiffel&view=diff&r1=8512&r2=8513>),
> > the log is "Checking for situations that can lead to ambiguous feature
> > calls".
>
> That's good it means that I will have satisfaction. When?
>
> > The problem is a technical one and the solution is not good because it
> > forbids valid use cases and does not fix actual problem (see
> > TEST_INHERIT2).
>
> Yes I see...
>
> Thanks.
> Regard
>
> >
> > Cheers
> >
>
- Re: [Liberty-eiffel] I dont agree with that error,
Raphael Mack <=