[m-dev.] .NET back-end test results

Tyson Dowd trd at cs.mu.OZ.AU
Wed Oct 23 14:23:01 AEST 2002


On 23-Oct-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> On 23-Oct-2002, Tyson Dowd <trd at cs.mu.OZ.AU> wrote:
> > On 22-Oct-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > On 20-Oct-2002, Fergus Henderson <fjh at cs.mu.OZ.AU> wrote:
> > > > - lots of tests fail due to the use of C foreign clauses (FAILED.NO_CLAUSES)
> > > 
> > > What do you think is the best way to fix these:
> > > 
> > > 	- disable these test cases for IL grades
> > > 	- add C# clauses
> > > 	- add MC++ clauses
> > > 	- add Mercury clauses
> > > 	- support the C interface in IL grades
> > > 	- something else?
> > 
> > One of these options on a case by case basis.
> 
> :-(
> 
> (I wanted an easy answer! ;-)
> 
> > If the feature is non-portable, disable test cases.
> 
> What exactly do you mean by non-portable?
> 
> The feature of using C foreign clauses is never portable,
> since it is not going to work for the Java back-end.
> Should I therefore disable all these test cases?
> 
> Or did you mean if the particular feature of C being used
> can't (easily?) be reimplemented in another language?

Yes.

> > Same if it is non-essential.
> 
> What do you mean by non-essential?  Not essential to what?
> Are you talking about the essentialness of the feature to the
> test case?  Or are you talking about the essentialness of the
> test case?  How should either kind of essentialness be determined?

I'm talking about essentialness of the feature being tested by the test
case.

The essentialness is of course how essential it is to an implementation
of Mercury.  

e.g: 
	Unification is essential.
	copy/2 is less essential.
	io__set_environment_variable not very essential at all.

> > If the feature can be implemented easily and/or efficiently in Mercury, do it.
> > That way we get it implemented in Java too.
> 
> OK.  The drawback of this is that maybe some of these test cases
> were intended to test things which only show up if there are C clauses
> but no Mercury clauses.  But I can live with that.

Yep, if you are sure that is true it would be fine to just disable the
test case.  But I think it would be rare.

> > C# clauses are preferrable to MC++ clauses - they are more readable and
> > are verifiable. 
> 
> Agreed.
> 
> > C interface in IL grades is not trivial...
> 
> Not trivial, sure -- no new foreign language interface is entirely trivial.
> But is there any reason why it should be any more difficult than the
> MC++ interface?
> 
> I guess there are some marshalling issues for "char" and "string".
> Anything else?

Anything involving memory management would probably be ugly.

> > and I doubt very much that the C code we use could be re-used unchanged.
> 
> Not all of it, sure.  But quite a bit of it could, I think.

You are welcome to try it out... 

Tyson.
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------



More information about the developers mailing list