Noeud « Next »: , Noeud « Previous »: Tiger 2002, Noeud « Up »: History



1.4.3 Tiger 2003

During this year, I was helped by:

Comaintainers
Alexandre Duret-Lutz, Thierry Géraud.

Delivery date were:

T1 Monday, December 18th 2000 at noon
T2 Friday, February 23th 2001 at noon
T3 Friday, March 30th 2001 at noon
T4 Tuesday, June 12th 2001 at noon
T5 Monday, September 17th 2001 at noon

Some groups have reached T6.

Criticisms include:

The C++ compiler is broken
I had to install an updated version of the C++ compiler since the system team did not want non standard software. Unfortunately, NetBSD turned out to be seriously incompatible with this version of the C++ compiler (its crt1.o dumped core on the standard stream constructors, way before calling main). We had to revert to using the bad native C++ compiler.

It is to be noted that some funny guy once replaced the g++ executable from my account into rm -rf ~. Some students and myself have been bitten. The funny thing is that this is when the system administration realized the teacher accounts were not backed up.

Fortunately, since that time, we have decent compilers made available by students, and the Tiger Compiler is now written in strictly standard C++.

The ast is rigid
Because the members of the ast objects were references, it was impossible to implement any change on it: simplifications, optimization etc. This is fixed in Tiger 2004 where all the members are now pointers, but the interface to these classes still uses references.
Akim is even more tired during the student defenses
Just as the previous year, see Tiger 2002, but with more groups and more stages. But now there are enough competent students to create a group of assistants, the Yakas, to help the students, and to share the load of defenses.
Upgrading is not easy
Only tarballs were delivered, making upgrades delicate, error prone, and time consuming. The systematic use of patches between tarballs since the 2004 edition solves this issue.
Upgraded tarballs don't compile
Students would like at least to be able to compile a tarball with its holes. To this end, much of the removed code is now inside functions, leaving just what it needed to satisfy the prototype. Unfortunately this is not very easy to do, and conflicts with the next complaint:
Filling holes is not interesting
In order to scale down the amount of code students have to write, in order to have them focus on instructional material, more parts are delivered almost complete except for a few interesting places. Unfortunately, some students decided to answer the question completely mechanically (copy, paste, tweak until it compiles), instead of focusing of completing their own education. There is not much I can do about this. Some parts will therefore grow; typically some files will be left empty instead of having most of the skeleton ready (prototypes and so forth). This means more work, but more interesting I guess. But it conflicts with the previous item...