[m-dev.] for review: minutes from today's meeting

Tyson Dowd trd at cs.mu.OZ.AU
Sat Nov 18 04:33:15 AEDT 2000


FYI:

> 	- Foreign code mechanism
> 		Tyson has posted a diff, and this should be included for the
> 		release.

I am about to commit this change.

> 
> 	- .NET `tech preview'
> 		This relies on the foreign code mechanism to implement some
> 		parts of the library for the IL backend.
> 
> 		This can probably go in the release, but Tyson wasn't there
> 		to comment.

Of about 300 predicates implemented using pragma c_code, I have done
around 100, including most of the important ones.  I expect to get most
of the rest done on the plane.

> 	- Mmake rules for the IL backend
> 		These will be done for the release.
> 
> 		If possible, these rules will only be generated when the
> 		IL back end is actually being used. There was some discussion
> 		about whether it would be worth it, given that `mmake depend'
> 		would then need to examine grade options or other flags. Fergus
> 		pointed out that the hlc back end has special dependencies
> 		generated for it, so it shouldn't be too difficult.

I have a diff for most of this.  I am now building the library in
mercury/library.

I see Fergus has also posted and committed a diff to do about half of
my diff (I have .il->.dll and .cpp->.dll and other rules).

It will probably be easiest at the moment to have some grade-dependent
dependencies.  This is because the set of foreign language files that
need to be compiled depend on the grade (e.g. we output .cpp files for
MC++ pragma foreign_code).  

But ultimnately it might be possible to output the dependencies inside
ifeq .. else .. endif.

> 
> 	- Tabled I/O for debugging
> 		There has been quite a lot done on this, but it won't get
> 		worked on for at least another week (as Zoltan will be busy
> 		marking exams until then). This should make it into the
> 		release.
> 
> 		Practical experience is needed with the feature before we can
> 		decide whether or not it is advisable to turn it on by
> 		default.

I thought this would be most likely marked "very experimental" in the
release.

> 	The release (codename: Rudolph) is to be made before Christmas.

Excellent codename.

> 4.  Testing on extras and samples:
> 
> 	Zoltan suggested that we need a standard way of testing the
> 	extras and samples. Fergus suggested that we enforce a rule that
> 	each Mmakefile contain a `check' target. It was pointed out that
> 	it can be quite difficult to test some of the things in extras
> 	such as the Tcl/Tk interface. Zoltan suggested that we just test them
> 	by compiling to C code.

I have already added test cases for the samples.  Check out the "tests"
subdir.

> 
> 5.  Summer students:
> 	
> 	The summer students are starting on November 27th, and we intend to
> 	give them a couple of days of talks about Mercury and the compiler
> 	(and our SE processes). Zoltan will not be available on Monday the 27th
> 	or Tuesday the 28th, so someone else will need to give the talks.
> 	Fergus should be around, as will Tyson (we expect). This needs to be
> 	sorted out in the next week.

Yes I will.

Thanks for the minutes, until you are away from the action you have no
idea how useful they are.

-- 
       Tyson Dowd           # 
                            #  Surreal humour isn't everyone's cup of fur.
     trd at cs.mu.oz.au        # 
http://www.cs.mu.oz.au/~trd #
--------------------------------------------------------------------------
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