[m-dev.] for review: add events and reports to web page.
Tyson Dowd
trd at cs.mu.OZ.AU
Wed Oct 4 17:57:35 AEDT 2000
Hi,
comp.lang.functional asked for a report on Mercury's entry into ICFP2000.
Pete said the minutes would be good.
I was waiting for some compile jobs.
===================================================================
Estimated hours taken: 2
Update the web page with 2 new sections.
Events describe one-off events, such as the ICFP 2000 programming
competition.
Reports are more sundry items, such as the Mercury meeting minutes.
This structure should be pretty easy to add new meeting minutes to.
Sending the review diff for the minutes web page is as good as sending
the minutes to mercury-developers.
include/functions.inc:
include/menubar.inc:
information/Makefile:
Add reports and events to the menubar and build process.
information/events.php3:
information/events/icfp2000.html:
information/events/images/mtest7.gml:
information/events/images/mtest7.jpg:
Add the events section, along with our first event, the ICFP
2000 competition. Thanks to Peter Ross for most of the text of
this page.
information/reports.php3:
information/reports/minutes_29_09_00.html:
news/reportsdb.inc:
Add the reports section along with fjh's minutes for the
meeting.
news/newsdb.inc:
Mention the new sections.
Index: include/functions.inc
===================================================================
RCS file: /home/mercury1/repository/w3/include/functions.inc,v
retrieving revision 1.3
diff -u -r1.3 functions.inc
--- include/functions.inc 2000/08/09 15:41:04 1.3
+++ include/functions.inc 2000/10/04 05:07:25
@@ -16,4 +16,21 @@
echo $news;
echo "</td></tr>";
}
+
+function reportitem($date, $item) {
+ global $root;
+
+ list($filename, $descr) = $item;
+ echo "<tr>";
+ list($day, $month, $year) = split(" ",$date);
+
+ echo "<td valign=top><tt>[";
+ printf("%02d $month $year", $day);
+ echo "]</tt></td>";
+
+ echo "<td><strong><a href=\"$root/information/reports/";
+ echo $filename;
+ echo "\">$descr</a></strong><br>\n";
+ echo "</td></tr>";
+}
?>
Index: include/menubar.inc
===================================================================
RCS file: /home/mercury1/repository/w3/include/menubar.inc,v
retrieving revision 1.8
diff -u -r1.8 menubar.inc
--- include/menubar.inc 2000/08/31 15:35:57 1.8
+++ include/menubar.inc 2000/10/04 06:42:02
@@ -19,6 +19,10 @@
<BR>
 <a href="<?echo $root?>/information/developer.html">Developers</a>
<BR>
+  <a href="<?echo $root?>/information/events.html">Events</a>
+ <BR>
+  <a href="<?echo $root?>/information/reports.html">Reports</a>
+ <BR>
</SMALL>
<P>
Index: information/Makefile
===================================================================
RCS file: /home/mercury1/repository/w3/information/Makefile,v
retrieving revision 1.10
diff -u -r1.10 Makefile
--- information/Makefile 2000/07/26 06:27:33 1.10
+++ information/Makefile 2000/10/04 01:45:09
@@ -4,9 +4,11 @@
HTML= benchmarks.html \
developer.html \
documentation.html \
+ events.html \
features.html \
motivation.html \
papers.html \
+ reports.html \
related.html
all: local
Index: information/events.php3
===================================================================
RCS file: events.php3
diff -N events.php3
--- /dev/null Tue May 16 14:50:59 2000
+++ events.php3 Wed Oct 4 16:04:39 2000
@@ -0,0 +1,9 @@
+<HTML>
+<?
+ $title="Event Information";
+ $dir="information";
+ $root="..";
+ $include="events.inc";
+ include "$root/include/template.inc"
+?>
+</HTML>
Index: information/reports.php3
===================================================================
RCS file: reports.php3
diff -N reports.php3
--- /dev/null Tue May 16 14:50:59 2000
+++ reports.php3 Wed Oct 4 16:04:39 2000
@@ -0,0 +1,9 @@
+<HTML>
+<?
+ $title="Mercury Reports";
+ $dir="information";
+ $root="..";
+ $include="reports.inc";
+ include "$root/include/template.inc"
+?>
+</HTML>
Index: information/events/icfp2000.html
===================================================================
RCS file: icfp2000.html
diff -N icfp2000.html
--- /dev/null Tue May 16 14:50:59 2000
+++ icfp2000.html Wed Oct 4 17:39:16 2000
@@ -0,0 +1,226 @@
+<html>
+<body>
+<h2>
+ICFP 2000: The Merry Mercurians
+</h2>
+
+This page describes the
+<a href="http://www.cs.mu.oz.au/research/mercury/">Mercury</a>
+entry into the
+<a href="http://www.cs.cornell.edu/icfp/">ICFP 2000 programming
+contest</a>, and our experience with the contest.
+<p>
+
+A sample image (<a href="images/mtest7.gml">mtest7.gml</a>).<br><br>
+<img src="images/mtest7.jpg">
+
+
+<H3>The Contest</H3>
+
+The ICFP 2000 programming contest was to implement a ray tracer.
+<p>
+The input to the ray tracer was a scene description written in a simple
+functional language, called GML. Execution of a GML program produces
+zero, or more, image files, which are in PPM format. The feature set of
+GML was organized into three tiers, all of which were implemented by the
+Mercury entry.
+<p>
+GML has primitives for defining simple geometric objects (e.g., planes,
+spheres, and cubes) and lighting sources. The surface properties of the
+geometric objects used to render the objects are specified as functions
+in GML itself. GML also defined operators for combining the simple
+geometric objects to create more complex objects. In addition to
+supporting scene description, GML also has a render operator that
+renders a scene to an image file. For each pixel in the output image,
+the render command must compute a colour. Conceptually, this colour is
+computed by tracing the path of the light backwards from the eye of the
+viewer, to where it bounced off an object, and ultimately back to the
+light sources.
+<p>
+
+The contest rules stated that a team had 72 hours to implement a ray
+tracer. The ray tracer could be implemented in any language, and the
+team could consist of any size. The short time frame of the contest
+meant that programming languages that help programmers to build complex
+systems quickly, should be more advantageous to use then more efficient
+but less software engineering friendly languages (see the report on the
+1999 programming contest at
+http://www.eecs.harvard.edu/~nr/icfp/results.html
+for more information).
+
+<H3>The Team</H3>
+
+<pre>
+ Ralph Becket <rbeck at microsoft.com>
+ Tyson Dowd <trd at cs.mu.OZ.AU>
+ Fergus Henderson <fjh at cs.mu.OZ.AU>
+ Simon Taylor <stayl at cs.mu.OZ.AU>
+ Peter Ross <peter.ross at miscrit.be>
+ David Glen Jeffery <dgj at cs.mu.OZ.AU>
+ Tennessee Leeuwenburg <tjleeuw at students.cs.mu.OZ.AU>
+ Thomas Conway <conway at cs.mu.OZ.AU>
+ Rob Jeschofnik <rejj at students.cs.mu.OZ.AU>
+ Mark Brown <dougl at cs.mu.OZ.AU>
+ Mike Liddell <mjl at cs.mu.OZ.AU>
+ David Overton <dmo at cs.mu.OZ.AU>
+ Peter Eckersley <pde at cs.mu.OZ.AU>
+</pre>
+
+The Mercury entry was produced by a team of 13 members (at least 10 of
+which contributed code to the ray tracer). The team was also distributed
+over three countries (Australia (11 members), England (1 member) and
+Belgium (1 member)). Both the members of the team in England and
+Belgium contributed significant amounts of code. Nearly all the
+communication between distrubuted team members took place via email (the
+England and Belgium team members spoke occasionally by phone).
+<p>
+It should be remembered that Western Europe and Melbourne, Australia are
+nearly 12 hours apart in time-zones, so for nearly the entire 72 hours
+of the contest there was someone, somewhere in the world working on our
+entry. However, given the preferred working habits of some of the
+Mercury team members, this might have happened regardless of geography.
+<p>
+
+<H3>The entry and results</H3>
+
+Out of a field of 38 entries, we came 4th. For the first ever entry in
+Mercury, this is a fine accomplishment. We were also the largest team
+entry (13 members), nearly double the next largest team (7 members).
+<p>
+The rankings were largely determined by correctness (only 4 teams
+produced approximately the right results for all the images). After
+that we were ranked on speed, and that's where our entry didn't fare so
+well. The full contest results are available
+<a href="http://www.cs.cornell.edu/icfp/contest_results.htm">here</a>.
+<p>
+Unfortunately, we had to turn off one of our key optimizations (bounding
+spheres) because we found it caused a few pixels of error in one of the
+images when we submitted. On the small sample images this gave us a
+speedup of 50%, however on more complex images it may have been even
+higher.
+<p>
+This was unlikely to have even moved us up a place, however, because the
+Mercury implementation of floating point is fairly slow on the x86
+processor. At this point in the contest, our competition consisted of
+compilers with very good floating point support. This is a weakness in
+the Mercury implementation that we'd love to fix.
+<p>
+Between these two efficiency problems, we quickly fell off the pace when
+the contest images became large and complex.
+<p>
+One of the frustrating parts of the competition was that we encountered
+quite a few bugs in the specification and the sample images. Many hours
+were spent trying to figure out why our correct ray tracer refused to
+produce the wrong image. This isn't meant to be a criticism of the
+organizers -- they have a tough job, but keeping 13 people around the
+world up to date with task descriptions, image updates, food and caffeine
+was a tough job.
+<p>
+Of our own bugs, two of the most common were
+incorrect signs, and using non-unit vectors when unit-vectors were
+expected. We recommend using the type system to prevent the unit vector
+error if anyone wants to write a ray-tracer in Mercury in the future.
+
+<H3>Using Mercury</H3>
+
+The distrubuted nature of the entry and the lack of problems encountered
+due to the distribution of team members is a feather in the cap of the
+Mercury language. The strong type and mode system ensured that if an
+interface between distinct parts of the ray tracer changed, the spots
+which were impacted by the change were reported by the Mercury compiler,
+and could quickly be corrected. It also meant that different team
+members could work on different solutions to the same problem, as long
+as both solutions agreed on a common interface, and the best one could
+be chosen.
+
+The statistics for all the source files (including source files which
+were used to debug individual components of the ray tracer) are as
+follows:
+
+<pre>
+Number of types: 64
+Number of insts: 2
+Number of predicates: 162
+Number of functions: 133
+
+Number of predmodes: 102
+Number of funcmodes: 0
+Number of separate modes: 66
+Number of implicit function modes: ?
+Total number of modes: >= 168
+ =< 301
+ - det: 122 ( 72.62%)
+ - semidet: 40 ( 23.81%)
+ - nondet: 0 ( 0.00%)
+ - multi: 0 ( 0.00%)
+ - cc_nondet: 0 ( 0.00%)
+ - cc_multi: 2 ( 1.19%)
+ - erroneous: 8 ( 4.76%)
+ - failure: 0 ( 0.00%)
+Average modes per predicate: >= 1.037
+ =< 1.037
+
+Blank lines: 1263 ( 20.57%)
+Comment lines: 537 ( 8.74%)
+Total whitespace/comment lines: 1800 ( 29.31%)
+
+Function declaration lines: 147 ( 2.39%)
+Predicate declaration lines: 260 ( 4.23%)
+Mode declaration lines: 67 ( 1.09%)
+Type declaration lines: 308 ( 5.02%)
+Inst declaration lines: 13 ( 0.21%)
+Other declaration lines: 223 ( 3.63%)
+Total declaration lines: 1018 ( 16.58%)
+
+Code lines: 3323 ( 54.11%)
+
+Total number of lines: 6141 (100.00%)
+
+</pre>
+
+Mercury provides an interface to the C language. This interface was
+used once to do an efficient ray-box intersection test. The C code for
+this was located from the web, and rather then recoding the algorithm in
+Mercury we used the C code verbatim.
+<p>
+
+Functional programmers often ask whether any of Mercury's logic features
+were useful in this contest (as many of the other features of Mercury
+are very similar to functional languages).
+We didn't end up using any non-deterministic search in our final entry.
+However, we certainly used them during the early coding of the project.
+Our original implementation of finding the nearest intersection point of
+a ray simply found all the intersections using a call to `solutions' and
+a nondeterministic search through all the available objects. We
+eventually removed this code as we started using different algorithms to
+find the intersecting objects.
+
+<H3>Show me the code!</H3>
+
+The actual ray tracer source is available from the Mercury CVS archive
+in the module icfp2000. The CVSROOT environment variable should be set
+to :pserver:guest at hydra.cs.mu.oz.au:/home/mercury1/repository. The password
+is `guest'.
+<pre>
+cvs -d:pserver:guest at hydra.cs.mu.oz.au:/home/mercury1/repository login
+(password is guest)
+cvs -z6 -d:pserver:guest at hydra.cs.mu.oz.au:/home/mercury1/repository co icfp2000
+</pre>
+
+<p>
+You will need a recent daily release of the Mercury system to compile
+and build the code (The current 0.9.1 release lacks a few features that
+we have used in the ray tracer). You can download Mercury from the
+snapshots section of the
+<a href="http://www.cs.mu.oz.au/research/mercury/">Mercury homepage</a>.
+
+
+<p>
+
+The Mercury Team<br>
+<a href="http://www.cs.mu.oz.au/research/mercury/">
+http://www.cs.mu.oz.au/research/mercury/
+</a><br>
+<a href="mailto:mercury at cs.mu.oz.au">mercury at cs.mu.oz.au</a>
+</body>
+</html>
Index: information/events/images/mtest7.gml
===================================================================
RCS file: mtest7.gml
diff -N mtest7.gml
--- /dev/null Tue May 16 14:50:59 2000
+++ mtest7.gml Tue Aug 29 18:57:00 2000
@@ -0,0 +1,104 @@
+% mtest7.gml
+%
+%
+
+0.0 0.0 0.0 point /black
+1.0 1.0 1.0 point /white
+1.0 0.0 0.0 point /red
+0.0 1.0 0.0 point /green
+0.0 0.75 0.0 point /darkgreen
+0.0 0.0 1.0 point /blue
+1.0 0.0 1.0 point /magenta
+1.0 1.0 0.0 point /yellow
+0.0 1.0 1.0 point /cyan
+
+% ... <level> grey ==> <color>
+{ clampf /level level level level point } /grey
+
+% ... <color> matte ==> ... <surface>
+{ /color
+ { /v /u /face
+ color 1.0 0.0 1.0
+ }
+} /matte
+
+% ... <color> <kd> <ks> <n> ==> ... <surface>
+{ /n /ks /kd /color
+ { /v /u /face
+ color kd ks n
+ }
+} /const-surface
+
+% a directional light
+0.0 0.0 1.5 point % direction of light
+1.0 1.0 1.0 point pointlight /light1
+
+% a position light
+-2.0 0.0 1.0 point % direction of light
+1.0 1.0 1.0 point pointlight /light2
+
+% a mirror plane
+white 0.1 0.5 1.0 const-surface apply plane /mirror
+
+ % a sphere
+{ /v /u /face % bind arguments
+ blue % surface color
+ 0.4 0.7 8.0 % kd ks n
+} sphere /s1
+
+ % a sphere
+{ /v /u /face % bind arguments
+ red % surface color
+ 0.4 0.7 8.0 % kd ks n
+} sphere /s2
+ % a sphere
+{ /v /u /face % bind arguments
+ green % surface color
+ 0.4 0.7 8.0 % kd ks n
+} sphere /s3
+ % a sphere
+{ /v /u /face % bind arguments
+ white % surface color
+ 0.4 0.7 8.0 % kd ks n
+} sphere /s4
+
+{ /v /u /face % bind arguments
+ 0.8 v 0.2 point % surface color
+ 1.0 0.0 8.0 % kd ks n
+} sphere /s5
+
+blue 0.6 0.5 3.0 const-surface apply cube /box
+
+
+box 0.0 0.0 2.0 translate
+s1 -1.0 0.0 0.0 translate % behind and above viewer
+union
+s2 1.0 0.0 0.0 translate
+union
+s3 0.0 0.0 1.732 translate
+union
+s4 0.0 1.732 0.306 translate
+union
+
+%place the stack of spheres
+0.0 rotatex
+0.0 0.0 3.0 translate
+
+% add the mirrors
+mirror -90.0 rotatex 45.0 rotatey 0.0 0.0 6.0 translate
+union
+mirror -90.0 rotatex -45.0 rotatey 0.0 0.0 6.0 translate
+union
+mirror 0.0 -2.0 0.0 translate
+union
+
+/scene
+0.5 0.5 0.5 point % ambient
+[light1 ] % lights
+scene % object
+4 % depth
+90.0 % fov
+320 240 % wid ht
+"mtest7.ppm" % output file
+render
+
Index: information/events/images/mtest7.jpg
===================================================================
RCS file: mtest7.jpg
diff -N mtest7.jpg
Binary files /dev/null and mtest7.jpg differ
Index: information/reports/minutes_29_09_00.html
===================================================================
RCS file: minutes_29_09_00.html
diff -N minutes_29_09_00.html
--- /dev/null Tue May 16 14:50:59 2000
+++ minutes_29_09_00.html Wed Oct 4 16:07:53 2000
@@ -0,0 +1,222 @@
+<html>
+
+<pre>
+Hi,
+
+We had a meeting of the Mercury group on Fri Sep 29th, 3:15pm to 5:55pm.
+This is an extract from the minutes (I've omitted stuff like the
+discussion about hardware which is only of local interest).
+
+Attendees:
+ David Jeffery <dgj>
+ David Overton <dmo>
+ Mark Brown <dougl>
+ Zoltan Somogyi <zs>
+ Tyson Dowd <trd>
+ Fergus Henderson <fjh>
+ Peter Stuckey <pjs> (for part of the meeting)
+
+1. Progress reports.
+
+ We went around the table, with each person in turn discussing what
+ they had been working on recently and/or what they were planning
+ to work on.
+
+ David Jeffery <dgj>:
+ - Had been mostly working on HAL stuff.
+ - Is planning to merge the changes on the HAL branch
+ (`no_alias') of the cvs repository back into the
+ main branch. These changes were adding three new grade
+ components, which had the following effects:
+ (1) allocating a VAR tag (with value zero) on every
+ data type
+ (2) filling in a field in the type_ctor_info RTTI
+ structures with the address of the solver
+ equality procedure for that type
+ (3) likewise filling in another field with the solver
+ initialization procedure for that type
+ - Had been working on a paper on existential types (with fjh).
+
+ David Overton <dmo>:
+ - Had been finishing off the change to support polymorphic modes
+ (i.e. allowing inst variables which can be instantatied
+ to any ground inst in mode declarations).
+ The problem with this change was performance --
+ mode checking for a version of tree234 using polymorphic
+ modes was 1 minute 45 seconds, as compared to 17 seconds
+ for the non-polymorphically moded version.
+ This is getting much too slow.
+ However, since the changes didn't slow down mode checking
+ of existing code, we agreed that it was OK to commit this
+ change, particularly since this would help other people
+ experiment with it, work on it, and perhaps fix the
+ performance problem. David Overton speculated that
+ the performance problem might not be fixable in the
+ current mode system implementation.
+
+ - Is planning more work on the new mode system implementation
+ - stage 1 (determining producers and consumers)
+ is nearly complete -- dmo thinks he has
+ got higher-order support nearly finished
+ - stage 2 (reordering conjunctions appropriately)
+ not yet done. There was some discussion about
+ how to do this -- need to be careful to avoid
+ exponential complexity.
+
+ Mark Brown <dougl>:
+ Has mainly been working on extending the declarative debugger
+ to allow the user to mark a particular subterm as being
+ the "suspicious" subterm. The way this works is that
+ the term browser is extended with a new command that
+ marks the current term (or a term with a named path
+ from the current term) as suspicious and then quits
+ the browser. In particular, Mark has been figuring
+ out what algorithm the declarative debugger needs to
+ apply to support this.
+
+ Has also been working on reorganizing the parameters
+ used for the different browsers/pretty-printers.
+
+ Currently pretty printer doesn't support a line limit.
+ There was some discussion about limiting lines displayed
+ by the debugger -- this should be handled by a single
+ mechanism for all the different parts of the debugger,
+ including pretty printer, stack traces and printing
+ help messages.
+
+ Mark said he has also been testing the declarative debugger
+ by trying it out on bugs in the Mercury team's ICFP contest
+ entry. In particular, the variable naming bug in
+ `inside_sphere', and also the unsolved bug with an apparent
+ false shadow in a two-cylinder test case.
+ This bug remained in our final submitted solution, despite
+ a two or more hours search by lots of the team
+ members. By narrowing the field of focus to the area
+ which was incorrectly rendered, and changing the
+ resolution to 1 pixel by 1 pixel, he was able to come
+ up with a test case that he could use with the
+ declarative debugger, and had managed to find (and fix?)
+ the bug! (Applause.) It turned out to be a bug in the
+ cylinder intersection code.
+
+ Someone suggested that this would be a very good
+ example to write up for a paper on the declarative
+ debugger, and everyone agreed.
+
+ Zoltan Somogyi <zs>:
+ Had been working on extending mdb to allow attaching commands
+ to breakpoints. This would include attaching multiple
+ commands (by putting multi-command sequences in quotes
+ with commands separated by semicolons).
+ There was some discussion about what should happen if
+ you attach a movement command to a breakpoint.
+
+ Had been working on adding an option to selectively supress
+ given event types (except for call events, which can't
+ easily be supressed since some mdb commands depend on them,
+ and which it probably isn't useful to suppress anyway),
+ and also to suppress declarative debugger support (?)
+ and program representations.
+
+ An old change which involved changing retry to use the
+ "fail" command to skip to a
+ `fail' rather than just to an `exit' for nondet tabled
+ predicates (or something along those lines?)
+ was delayed because the reviewer (fjh) objected to it
+ since it didn't handle the situation where there was
+ a commit and thus no `fail' event.
+ Since (a) this problem only affected model_non tabled
+ predicates, which are documented as not working anyway,
+ and (b) the cause of the problem was arguably a problem
+ in the fail command, rather than this change (?),
+ we agreed that it would be OK to go ahead and commit
+ this change.
+
+
+
+ Tyson Dowd <trd>
+ Has been working on the IL back-end.
+ Most of the changes for that were now in the process
+ of being merged back into the main cvs repository,
+ and soon they would all be.
+
+ Planned to work on the IL runtime library support.
+ Since some routines will need to be implemented in
+ different languages, this required extending the foreign
+ language support in two ways: (1) allowing different
+ languages than C and (2) allowing more than one implementation
+ for each procedure, so long as each implementation is in
+ a different language, and then having some mapping from
+ target language to a list of implementation languages
+ in order of preference, so that for a given target language
+ the compiler can determine which implementation it uses
+ for each procedure.
+
+ Tyson said he now plans to implement the library in C# rather
+ than Managed C++, since C# would be a bit neater for this
+ kind of thing, the Managed C++ compiler was not considered
+ very reliable, and anyway Managed C++ is just as non-portable
+ as C#.
+
+ Tyson had also been working on MCORBA (and will
+ continue with this). Someone on the net has been
+ using it, and had reported some bugs which Tyson has
+ been working on.
+
+ Fergus Henderson <fjh>
+ Had been working on documenting the support for
+ parallelism/multithreading. Planned to rename the
+ `--parallel' option as `--thread-safe' or `--threads'
+ or `--multi-threaded' or something like that.
+ Concensus was that it should be called `--mt' /
+ `--multi-threaded' and `.mt' as the grade component.
+
+ Had been working on going through the bug list,
+ fixing bugs, and making the compiler pass its test
+ suite again.
+
+ Had been working on MLDS back-end. Planned to continue
+ this. Need to fix some bugs and generate better code
+ for switches.
+
+ Another thing we briefly discussed was using the new
+ high-level C code grade for the ICFP2000 contest and
+ seeing if there is any improvement in speed.
+ Tyson said he checked this out and remembered why we
+ didn't do it -- the contest code uses global.m, which
+ needs a working implementation of compare for univ (it
+ stores a map of string to univs). Currently that is
+ unimplemented in hlc.gc.
+
+ Planned to continue working on existential types paper
+ with dgj.
+
+2. Summer Studentship Projects
+ Suggestions included
+ - distributed Mmake: distribute work over multiple
+ machines on local area networks with NFS
+ (if time permits, same person could also work on
+ keeping object files in different directories for
+ different grades/architectures)
+ This is really a systems project involving Make and
+ shell scripts rather than a Mercury project.
+
+ - distributed Mercury: provide a Mercury library to
+ support distributed programming. This would
+ probably be a wrapper over one of the existing
+ libraries for this, e.g. MPI.
+
+ - support for SOAP/XML: provide a Mercury library
+ for supporting SOAP/XML.
+
+ - COM interface: modify existing MCORBA implementation
+ to support COM (if not already implemented by Mission
+ Critical)
+
+ - IIOP server: implement the CORBA IIOP protocol
+ in Mercury, so that MCORBA can use this rather
+ than wrapping the C++ CORBA implementation.
+
+Minutes taken by Fergus Henderson <fjh at cs.mu.oz.au>.
+</pre>
+</html>
Index: news/newsdb.inc
===================================================================
RCS file: /home/mercury1/repository/w3/news/newsdb.inc,v
retrieving revision 1.51
diff -u -r1.51 newsdb.inc
--- news/newsdb.inc 2000/09/25 15:10:44 1.51
+++ news/newsdb.inc 2000/10/04 06:51:14
@@ -11,15 +11,28 @@
** description
** ),
** Make sure you put a comma between each item, and an arrow
-** between the date and the news. You must test the entry before you
-** commit. Simply run `make' at the top level w3 directory, and use a
+** between the date and the news. Quotation marks must be escaped.
+** You must test the entry before you commit.
+** Simply run `make' at the top level w3 directory, and use a
** web browser (lynx is fine) to see that the news.html file formats
-** correctly.
+** correctly.
**
** ALSO the dates must be distinct.
*/
$newsdb = array(
+
+"04 Oct 2000" => array("Events and Reports",
+
+"Two new sections have been added to the web site. The events section
+will give information about events Mercury has been involved in -- we
+start this section with a <a href=\"information/events/icfp2000.html\">
+page on Mercury coming 4th</a> (of 38 teams) in
+the ICFP 2000 programming contest. The reports section contains regular
+reports from the developers, such as minutes from Mercury meetings.
+Both are available from the sidebar menu."
+),
+
"22 Sep 2000" => array("Tuple types",
Index: news/reportsdb.inc
===================================================================
RCS file: reportsdb.inc
diff -N reportsdb.inc
--- /dev/null Tue May 16 14:50:59 2000
+++ reportsdb.inc Wed Oct 4 17:42:59 2000
@@ -0,0 +1,21 @@
+<?
+
+/*
+** This is the reports news database.
+**
+** Add new items at the top in chronological order.
+**
+** Each item consists of
+** date => array(filename, description)
+** Make sure you put a comma between each item and an arrow between the
+** date and the filename.
+*/
+
+$reportsdb = array(
+ "29 Sep 2000" =>
+ array("minutes_29_09_00.html", "Mercury Meeting Minutes")
+);
+
+?>
+
+
--
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