fetrunner – a tool to assist in "debugging" FET files

gradgrind · October 30, 2025, 02:39:32 PM

I have been working on a tool to help in finding problems with FET-files, basically by automatically running multiple instances of fet-cl on source files which have been derived from the input file by systematically disabling/enabling various subsets of its constraints.

By starting with no constraints and gradually adding single-type groups of constraints, it should be possible to determine which of the constraints in the source file are "difficult". The results are returned as a JSON file. A somewhat lengthier description of this tool is available at the github repo.

It is not yet "finished", and is at present "only" a command-line utility, but it already works quite well. If anyone is interested in trying it out, I would be very glad to receive feedback, bug reports, suggestions for improvements, etc.

Here are links to executable binaries of the first release:

For Linux – https://github.com/gradgrind/fetrunner/releases/download/v0.0.1/fetrunner

For Windows (untested) – https://github.com/gradgrind/fetrunner/releases/download/v0.0.1/fetrunner.exe

Liviu Lalescu · October 30, 2025, 03:50:09 PM

Thank you, gradgrind! I will have now a look at it (I will see the sources and try to compile on GNU/Linux and maybe run). Did you use C++ and Qt, or other programming language and platform?

Liviu Lalescu · October 30, 2025, 05:19:54 PM

I just ran it. I installed at first gcc-go, but I removed it and installed go1.24 and go1.24-race. It worked.

It is interesting!

gradgrind · October 30, 2025, 07:10:22 PM

Glad you got the compiler working, Liviu! I suppose I should have written a little more about that, but I was rather expecting anyone who wanted to test it to use the executable I uploaded.

Although it is possible to use Go packages from your Linux distro, I use the downloads from go.dev – they are quick to install and always the newest.

I like Go for projects like this because of the relative simplicity of the language, the good libraries and the fast compilation to a single binary with no dependencies. The handling of multiprocessing is also very convenient. And cross-compilation is so easy!

Volker Dirr · October 30, 2025, 07:56:29 PM

Interesting. I didn't tried it yet. I only read the manual and saw https://github.com/gradgrind/fetrunner/blob/main/fet/constraint_order.go

I think you can even improve it a bit more by this:

do it in 3 larger tasks:
1. check room constraints only.
2. check time constraints only.
3. check room and time constraints at the same time.

Liviu Lalescu · October 30, 2025, 08:32:01 PM

Dear Michael / gradgrind,

Please let me know if you would like:

1) A link in the Tools/Links page of FET, about your tool. Let me know your desired words (see the other tools).

and

2) A board on the FET forum about your tool, and you'll be a moderator.

gradgrind · November 01, 2025, 10:33:59 AM

Dear Liviu,

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

Something like this for the text?

QuoteA 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.

Liviu Lalescu · November 01, 2025, 11:10:18 AM

Thank you, gradgrind! I added your project in Tools/Links, please check it. I am opened to add it higher up in the list - now I just added it chronologically, the last one.

I am not sure I would like to integrate such an idea in FET, but I will think about it. Please let me know if you want your idea in the TODO list.

The problem with FET further development is unfortunately the lack of user feed-back and the lack of financial support.

Volker Dirr · November 01, 2025, 01:57:56 PM

Quote from: gradgrind on November 01, 2025, 10:33:59 AMI 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.

Well, in that 3 blocks you should still use your "smaller blocks" of course.
Or in other words: You do only the last step right now. I recommend to do your approach 3 times.
1st time with room constraints only, step by step like you do it now.
2nd time with time constraints only, step by step like you do it now.
3rd time like you do it now.

- bugs in room and time constraints are independent in many cases (of course not in all)
- you are faster if you don't care the other constraints. they will only slow down. so why adding time constraints if there is a room bug? That will only slow down. And visa versa.
- i do similar approaches if i manually hunt for bugs and in many (but not all) cases I can catch the bugs manually in a few minutes by approaches like that. even I don't know the data set of the other guys and even I can't read/speak their language.

gradgrind · November 02, 2025, 07:34:46 PM

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.

Volker Dirr · November 02, 2025, 10:35:56 PM

Well, I saw a lot of files from other guys that asked for help. And room problems are not rare.

Of course it is depending on the the bug in the data set. But i am sure: If you have a difficult data set with an "easy" bug (so bugs that I myself solve quick manually) will be must faster if you separate it as I wrote. Yes, if it is a difficult data set with a "difficult" bug, then your variant will be faster to get to the point where it is impossible, but in that case it will be still difficult to understand why it is like that. (imagine it is the last constraint with max gaps for all teachers. it will take long to get to that point and it will still not help much, since it still can't say what exactly is the problem. Don't forget that in fact there is nearly never a single constraint the "bad guy". In normal case it is a conflict of 2 constraints that are conflicting or 1 constraint and a (set of) activities. So in normal case there are at least TWO possible solutions to fix a bug.

Liviu Lalescu · November 03, 2025, 06:24:03 AM

gradgrind, I have many more files for testing, but the majority are private, from the users.

But you can create some impossible files. I mainly use Volker's German sample to derive impossible fet files.

corra · January 05, 2026, 05:50:06 PM

Hi,

I tried to install the tool in Debian, but after git-clone when I run the compiler I get:

Code Select

/home/corrado/Lavoro/fetrunner/go.mod:3: invalid go version '1.25.0': must match format 1.23
Maybe it is a go version problem?

Thank you and best regards,

Corrado

Volker Dirr · January 05, 2026, 11:25:14 PM

I am not a go coder. But if you watch line 3 of file "go.mod", then there is a pretty strict "go 1.25.0".
So i guess you have 2 options:
a) install a newer go version.
or
b) modify line 3 into "go 1.23". If you have luck, then the author was only a bit too strict and in fact don't use features of the newer go version.

gradgrind · January 08, 2026, 05:57:56 AM

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.