Re: [tablix-list] 0.2.0 configuration format

From: Tomaz Solc <>
Date: Sat Jan 08 2005 - 11:58:43 CET

Hash: SHA1


| 1. More consideration needs to be given to being able to prove that
| the input file is a valid description of the requirement. At the
| moment, we lack the ability to confirm by any programmatic method
| that we have scheduled the right number of lessons of each subject to
| each class and not overloaded individual teachers. If your input file
| doesn't converge, you don't know if it is because you have a mistake
| in the input or that the algorithm has failed.

This has been discussed before. As far as I know, proving that a Tablix
timetabling problem has a solution is equal to finding a solution. It is
impossible to take into account the effects of interactions of all used
modules. I would be happy if somebody could show me I'm wrong, but until
that happens, this feature won't be available in Tablix.

| As this mailing list has (silently) observed, my timetable can be
| divided into three bits and each bit will converge successfully with
| the correct number of lessons. Running it as a whole results in
| missing lessons and so the algorithm has to be slightly buggy.
| Relying on the output as a guide to the correctness of the input is
| therefore invalid.

If you think something is buggy, please provide a short and simple
example how to replicate that bug. So far all missing lessons I've seen
in the examples you've sent are simply because of wrong interpretations
of the resulting HTML timetable.

| 2. The parser needs to be improved hugely. At the moment, it accepts
| what it recognises and silently throws away about 80% of what it
| doesn't. This leads to a false conclusion that the input ins being
| executed as intended. It is very frustrating when you find that it
| has been completely ignored.

There is already a DTD file that you can use to validate a config file.
XML validation will in most cases find tags and properties that are not
recognized by Tablix. Future versions of Tablix could automatically
validate the config file before parsing it, but most of the XML parsers
I know simply ignore unknown parts of the XML files.

| 3. Point 2 can be addressed by the implementation of a complete user
| interface to generate the input file - but gtablix is broken for me
| (it has been for about six weeks) and wasn't complete the last time I
| was able to use it. A critical component that is independent and so
| outwith the control of the core project doesn't seem the best design
| philosophy.

My design philosophy is to separate the interface from the engine. This
is the case with most unix software and I intend to stick to it.

| 5. The code needs an overhaul to improve readability and commenting -
| and the documentation is sparse. I have only ever supervised work on
| GAs rather than programming myself, but the difference is I was able
| to understand the resulting code. Given the virtually non-existent
| response to mailing list queries, having readable code and fullsome
| documentation are the only viable alternatives for busy people.

If you think something is missing from the documentation, feel free to
add something. At 50 pages of documentation and man pages for all
executables, Tablix isn't exactly the least documented project I've seen.

Code readability is a problem, but if you would check the 0.2.0 branch,
you would see this is improving.

Best regards
Tomaz Solc
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird -

Received on Sat Jan 08 12:16:37 2005

This archive was generated by hypermail 2.1.8 : Tue Aug 16 2005 - 20:42:50 CEST