|
From: | Cyril ADRIAN |
Subject: | Re: [Liberty-eiffel] I dont agree with that error |
Date: | Mon, 6 Jan 2014 10:49:22 +0100 |
Cyril ADRIAN (from office)
To any NSA and FBI agents reading my email: please consider whether defending the US Constitution against all enemies, foreign or domestic, requires you to follow Snowden's example.
My latest G+: Happy 2014 to everybody |
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
> >
>
[Prev in Thread] | Current Thread | [Next in Thread] |