Re: [tablix-list] Tablix roadmap

From: Nicholas Robinson <nprREMOVE@THISbottlehall.freeserve.co.uk>
Date: Sat Dec 18 2004 - 02:27:44 CET

Suggestion for <module>

It may be that you have used restrictions for a module in your input file but
want to turn off that module. At the moment, if you comment out the module or
whatever, you then get errors about the unknown restrictions. Would it be a
good idea to have something like

<module name="more_teachers.so" weight="70" mandatory="yes" active="no"/>

So that tablix can parse the input file, recognise the restrictions and not
report errors, but then not execute the module?

Nick

On Monday 13 December 2004 19:13, TomaĹľ Ĺ olc wrote:
> Hi
>
> Following is a description of what is planned for Tablix in the next
> year. Suggestions and comments are welcome as always.
>
> Current Tablix kernel code is becoming increasingly hard to extend and
> maintain. Large parts of the code should be refactored to allow for
> greater modularity and readability. The Rottertablix project also
> helped me found a few spots where code could be more general, which
> would simplify modifications like this. Several important features are
> still implemented as rough hacks in the code (for example
> more_teachers.so module) and should be properly implemented with an
> extended module API.
>
> Experience with Tablix so far showed that the current genetic algorithm
> is not very efficient with very constrained problems. Specially
> timetables with a large number of "place capability" restrictions in
> combination with different time constraints seem problematic. These
> limitations could be solved with a slightly different genetic
> algorithm. Changing the algorithm will most likely mean that most
> modules will need to be rewritten.
>
> All above modifications are planned to be included in the 0.2.0 release
> of Tablix, which will probably be finished sometime before the end of
> 2005. A few weeks ago I tagged BRANCH_0_2_0 in the CVS, so anyone
> interested in the Tablix development can it check out of repository. Be
> warned though that code in this branch is currently a big mess and will
> probably not even compile.
>
> Branch 0.1.0 will still be maintained until the release of 0.2.0. I
> expect two or three more stable releases of this branch, mostly to
> include contributed modules and to fix any bugs that may be discovered,
> but no new features will be added.
>
> Best regards
> Tomaz Solc
Received on Sat Dec 18 02:38:21 2004

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