Messages

It looks indeed like something is too highly constrained. BSB/Eng in 12C and 12D can't be placed because the only available slots (because of other constraints) are at times that are impossible for BSB (teaching in other classes). Hope this helps.

I'm sorry, but I can't test stuff on macOS. The best I can suggest at the moment is to try running fetrunner in Linux, in a virtual machine if you don't have a real one available (remember to allocate enough processors). However, note that although Go and Qt should work on ARM processors, fetrunner itself has not been tested in this environment.

As Volker wrote, some more details about how the attempt failed might be helpful – error messages, etc.

I don't know  anything about macOS, but a quick search suggested that you might need to set CMAKE_OSX_DEPLOYMENT_TARGET appropriately.

Thinking a bit further ...

If you were very ambitious you could use a QTextBrowser instead of a QTextEdit with an HTML table and use links in the cells, so that you could even edit the table:

 - use something like #2_3 (coordinates) for the links,

 - use images for the on/off cells,

 - connect a change-state function to the QTextBrowser::anchorClicked signal,

 - rewrite the HTML to reflect the change.

In this case images are perhaps better than text because the link would fill the whole cell, which might not be the case with text.

Hmmm ... I didn't think of that problem with the translations ... indeed, lupdate should only be done on the full build.

I'll need a bit of time to consider that one!

Hello Liviu,

I wanted to send this to your mail address, but it refused to accept it.

I have been trying to make the CMake files for FET produce results like your binary packages directly, picking up the version automatically from a VERSION file. Maybe this can simplify the build process?

I also wanted to make it easy to build just the command-line version, and of course (for fetrunner) to build the command-line binary without console window (fet-clw) on Windows.

There may be better ways of doing it, but I now have something that has been working well in my tests so far (I can't test MacOS). The modifications are attached.

There is (I think) just one change from your Windows package: I have put the Qt plugins in their own directory. It seemed neater to me.


I have been using the following build commands, always from a "build" directory in the FET root directory.


Linux, to configure, full build:

Code Select Expand

$HOME/Qt/Tools/CMake/bin/cmake .. -DCMAKE_PREFIX_PATH=$HOME/Qt/6.10.1/gcc_64 -DCMAKE_INSTALL_PREFIX=
The empty CMAKE_INSTALL_PREFIX causes the install directory to be named fet-x.y.z, where x.y.z is the version from the VERSION file.

Linux, to configure, cl-only:

Code Select Expand

$HOME/Qt/Tools/CMake/bin/cmake .. -DCMAKE_PREFIX_PATH=$HOME/Qt/6.10.1/gcc_64 -DCMAKE_INSTALL_PREFIX= -DCL_ONLY=on

Linux, to build and install:

Code Select Expand

$HOME/Qt/Tools/CMake/bin/cmake --build . --target install -j 4

Windows, to configure, full build:

Code Select Expand

C:\Qt\Tools\CMake_64\bin\cmake.exe .. -DCMAKE_PREFIX_PATH=C:\Qt\6.10.1\mingw_64 -DCMAKE_GENERATOR="MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=
Windows, to configure, cl-only:

Code Select Expand

C:\Qt\Tools\CMake_64\bin\cmake.exe .. -DCMAKE_PREFIX_PATH=C:\Qt\6.10.1\mingw_64 -DCMAKE_GENERATOR="MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install -DCL_ONLY=on
Windows, to configure for fet-clw:

Code Select Expand

C:\Qt\Tools\CMake_64\bin\cmake.exe .. -DCMAKE_PREFIX_PATH=C:\Qt\6.10.1\mingw_64 -DCMAKE_GENERATOR="MinGW Makefiles" -DCMAKE_INSTALL_PREFIX=install -DCL_ONLY=on -DNO_WIN_CONSOLE=on

Windows, to build and install:

Code Select Expand

C:\Qt\Tools\CMake_64\bin\cmake.exe --build . --target install -j 4

What do you think?

My fetrunner program tries to identify constraints which may be difficult or impossible to fulfil. It is, in general, not possible to say exactly which constraint is the "difficult" one, because the constraints interact with each other. There are perhaps several constraints which you could change to get a soluble timetable (in a reasonable time ...).

fetrunner runs FET many times, gradually enabling more and more of the constraints. Its result is a FET file with some of its constraints disabled so that the activities can all be placed. This may help you to find the area that is causing the difficulties. Like FET, it may produce different results on each run, but with some data files it can give a clear indication of where the problem lies.

Thank you, as per the previous message edit, this was clear now.
What would be desirable is an explanation of the "Run progress", "Run state" and "Log", which is a bit obscure to me.

As a small feedback, in my opinion "Soft constraints" which are unfulfilled should not necessarily be disabled: they can in any case direct the search without being an obstacle to the timetable creation.

It's not quite true that unfulfilled soft constraints are no obstacle to the timetable creation. They can make it much slower! The new version of fetrunner (0.10.0) even changes the weight of soft constraints to 100% by default, though they are still only introduced after handling the real hard constraints. Those with a greater weight are introduced first. I did this because the idea of soft constraints is rather in conflict with fetrunner, which tries to find unfulfillable constraints. Because of the way FET works, difficult soft constraints can extend the processing time greatly, and one of the aims of fetrunner is to get results in a limited time.

There is, however, still an option to let the soft constraints keep their original weight.

I have reworked the "Run state" page and written some more documentation about using the GUI.

That is an area of documentation that still needs some work, I guess!

If you open the "xxx_Result.fet" file (produced by fetrunner) in fet, you can see that some of the constraints have been deactivated (e.g. in the "Time" tab select "All"). These are the ones which fetrunner decided were "difficult" or impossible.

At the end of the log file, there should be a summary of the accepted constraints.

The "xxx_Result.json" file may contain some information about why a constraint was rejected, but it is rather intended for reading by other software. Nevertheless, a web browser (e.g. Firefox) can display this file quite neatly.

The fact that fetrunner has deactivated a constraint doesn't mean that the constraint is necessarily impossible, though it may do (in combination with other constraints). Another run, perhaps with a different timeout, might give a different result. The results rather list constraints which are making it difficult for fet to generate the timetable.

Looking at a timetable generated (in fet) from the "xxx_Result.fet" file (which is now known to be possible!) and at the disabled constraints will – I hope – help you to discover how you might need to modify your data (activities and constraints) in order to get an acceptable result.

Actually, there is a generated timetable (from "xxx_Result.fet") in "xxx_Result.json", but I haven't written the software to display this (yet).

In the GUI version you can get a "live" view of the progress of a fetrunner run.

fetrunner now has a GUI (Linux and Windows – sorry, I can't do macOS).

This will probably make it easier to use for many people.

I am unsure how I should release binary packages, but to help anyone who wants to test the software already, I have placed binaries for Linux and Windows in the Releases section:

https://github.com/gradgrind/fetrunner/releases/tag/v0.9.10

The GUI files are not standalone! The packages should be unpacked into the root directory of a current FET binary package, so that they can find the program libraries they need. They have been compiled with Qt-6.10.1 for FET-7.6.4, but should probably also work with later versions of FET. Note, however, that on Windows the special fet-clw will still be from FET-7.6.4 until it is recompiled to use the newer FET code.

If you are interested, please test it and send feedback. That will help me in writing documentation and adding new features.

Corrada: I'm afraid I can't remember whether I have used features from a more recent Go version. Did you try changing the go.mod file? Anyway, there is now a new precompiled binary for Linux on the Releases page.

Volker, you are of course right about the difficulties of a proper REST API. If that part of FET is not already thread-safe, it could be quite a lot of work. I can see from the Multiple-Generate feature that FET has some multithreading features already, but the threads are all using the same input file, which is perhaps less demanding.

It might be easier to take fet-cl as a basis and change the IO parts so that they don't write to files but send their output to stdout (or a socket). There could be a sort of query API using stdin (or a socket), so that only the desired outputs are returned. Then a lot of the command-line options would be unnecessary. A separate instance of this new version could be started (by the controlling software) for each input file. Progress could be monitored by sending polling queries.

Something like this can be done already using fet-cl (it is what I do in fetrunner), but the communication is via command line options and the output files, which are otherwise unnecessary and get deleted soon afterwards anyway. These are also more difficult to interface to (like repeatedly reading and parsing the logs/max_placed_activities.txt file to get the progress).

OK, while I'm making suggestions ...

I guess this one might be quite a bit more work (so I could understand you wanting sponsorship for something like this), but I think it might be a good idea for those cold, dark winter days ...

My suggestion is to make a library version of FET, rather like the command-line version, but interfacing via some communication mechanism (callbacks, messaging, whatever, ...). Or it could be an HTML server, using JSON messages for example ...

Anyway, this FET version would create no files, but pass all generated data and progress information back to the client, which could do with it whatever it wanted. Control of the processes, setting of options, etc., would be done by messages from the client.

Hello Liviu,

Having done some work on interfacing FET with other software, it seems to me that it might be useful in some cases to have Code and Comments fields on more elements.

The current state seems to be:

Day and Hour elements have neither Comments nor Code.

Activity elements have no Code.

Constraint elements have no Code – and also no unique identifier like Id or Name.

You probably had reasons for your choices, but if it is not too much work, perhaps it might be helpful to some people if these fields were also available on these elements (I may have missed something ...).

Best regards,
Michael

Liviu:

The entry in Tools/Links is fine, thanks.

I can understand your reluctance to undertake larger programming exercises without any promises of financing!

Running on Linux I can avoid the creation of many temporary files on SSD by making fet-cl output to tmpfs (/dev/shm). This seems a bit more difficult on other operating systems. I put this is in version 0.0.3.

Volker:

At first I was indeed handling the rooms separately, but on the files I was testing it was not helpful. So I decided to concentrate more on other things, like timeouts. It would be interesting to have a wider range of test files. I tried some of the examples distributed with FET, but only one or two were difficult enough to give any interesting results.

Dear Liviu,

A link in the Tools/Links page to the github repo might be good.

Something like this for the text?

A tool to help in finding problems with FET-files. Given a FET-file (.fet) it systematically disables and reenables the constraints, running each new file with the fet command-line program (fet-cl). Using timeouts and parallel processing it tries to identify the "difficult" constraints.

This is currently only available as a command-line utility, so it might not (yet) be of interest to everyone.

I'm not sure about a forum board. As fetrunner is at present command-line only, with results in a JSON document, it is perhaps only useful for a few people who are happy with this. What do you think?

It seems to me that it might be helpful to have fetrunner – or something like it – integrated into FET itself, as a further generate option. If it was part of FET it could probably skip much of the temporary file generation, doing everything in memory. But then it would need a GUI and quite a lot of work (presumably from you, I'm afraid ...) to integrate it. And I suppose you would like to have it in C++/Qt.

Volker:

I have thought about other divisions, and maybe there would be advantages to your suggestion. Do you have reasons for these three divisions? The tests I have done so far indicate that smaller blocks produce results more quickly, but I'm sure it depends on the data to be processed.