FET as command-line program without Qt?

[Bob Hairgrove]

I've seen this mentioned in the documentation, but has anyone actually done this -- i.e., strip out all of Qt and implement FET using just ANSI-C++ and STL, for example? Because then it would be relatively easy to set up FET as a CGI script which could be called from a web-based application (typical LAMP or WAMP architecture). For generating complete school schedules, of course, it would not work because of the Apache/PHP timeout problem. But for our music teachers, I see this as a real possibility. FET was able to generate my little schedule of individual instrumental music lessons in a few milliseconds!

But even the presently existing command-line mode of FET is highly dependent on Qt for many things. The most difficult things changing over from Qt to STL, IMHO, are the little things ... such as the index for reading and writing elements of QString, QList etc. taking a signed int, whereas STL containers take unsigned size_t. I think it would not be easy. Besides, in the C++ classes used in FET, almost all have all members public (and hardly anything is const, which might be more of a problem with STL because objects cannot be passed around by value as easily as with Qt objects which are usually reference-counted pointers).

[Volker Dirr]

A few guys tried/started to convert. But i don't know if they ever finished their work. See for example here:
http://lalescu.ro/liviu/fet/forum/index.php?topic=1266.0
http://lalescu.ro/liviu/fet/forum/index.php?topic=675.0
http://lalescu.ro/liviu/fet/forum/index.php?topic=434.0
http://lalescu.ro/liviu/fet/forum/index.php?topic=430.0

You always need to think about this:
If you converted FET - Who will code the GUI?
Why should a school set up a webserver?
If the school doesn't setup the webserver - Who will set it up and who will pay it?
What about data privacy? For example schools in my county are not allowed by law to upload that data into the Internet.

[Bob Hairgrove]

A few guys tried/started to convert. But i don't know if they ever finished their work. See for example here:
http://lalescu.ro/liviu/fet/forum/index.php?topic=1266.0
http://lalescu.ro/liviu/fet/forum/index.php?topic=675.0
http://lalescu.ro/liviu/fet/forum/index.php?topic=434.0
http://lalescu.ro/liviu/fet/forum/index.php?topic=430.0

Thank you, Volker, for these links and ideas/questions!

You always need to think about this:
If you converted FET - Who will code the GUI?

Actually, I do this myself. At the school where I teach, music teachers have an extra week holidays because they do not participate in special school endeavors, but we are paid the same as other teachers. So we have to compensate this somehow. I have applied my programming skills to help the school with various projects. I will send you a private e-mail where you can see what i have done.

Why should a school set up a webserver?

Our school actually has its own website and many department websites (see the link in your e-mail which I will send shortly). I have set up the one for the music department.

What about data privacy? For example schools in my county are not allowed by law to upload that data into the Internet.

This has been discussed by our school directors, and they haven't had any issues with simple schedule information (which is actually already on the internet for anyone to see). It is a sensitive matter, and I have done my best to ensure that our applications are conforming to the laws in the country where I teach. However, I am not a lawyer, so if I find out that there is something wrong with this, I would be the first to try to comply.

[Volker Dirr]

ok. i got your message.

if a school already have it's own server and know how to do and protect it, then there is no problem with data privacy. But i can't see an advantage then. It is easier to use stand alone software. But it looks like you are more talking about using final tables, not about making tables. In my opinion that are 2 different kind oft software tools.

[Liviu Lalescu]

I've seen this mentioned in the documentation, but has anyone actually done this -- i.e., strip out all of Qt and implement FET using just ANSI-C++ and STL, for example? Because then it would be relatively easy to set up FET as a CGI script which could be called from a web-based application (typical LAMP or WAMP architecture). For generating complete school schedules, of course, it would not work because of the Apache/PHP timeout problem. But for our music teachers, I see this as a real possibility. FET was able to generate my little schedule of individual instrumental music lessons in a few milliseconds!

But even the presently existing command-line mode of FET is highly dependent on Qt for many things. The most difficult things changing over from Qt to STL, IMHO, are the little things ... such as the index for reading and writing elements of QString, QList etc. taking a signed int, whereas STL containers take unsigned size_t. I think it would not be easy. Besides, in the C++ classes used in FET, almost all have all members public (and hardly anything is const, which might be more of a problem with STL because objects cannot be passed around by value as easily as with Qt objects which are usually reference-counted pointers).

I do not know many of the words mentioned above. But about things I understand: I think the difference signed/unsigned is negligible. Also I think that having most of members public in FET classes is also not a problem.

There are not many Qt classes used in FET command-line. A problem would be the "foreach" keyword. The rest would not be so difficult. But maybe a good solution would be just to take small portions of Qt code (as small as possible) and include them in the package. QList, QSet, QHash (I am not sure about this one), foreach keyword, QString, and I think that would be nearly everything. I took care in the code that any implementation of QSet (any order of the elements) gives the same behavior of the generation, so you can start with the same random seed and check the official FET and the customized FET to have the same final random seed.

Indeed, I think if it were not for the "foreach" keyword, one could replace QList by list, QSet by set, QHash by hash, and QString by string. But "foreach" is tricky - I think I tried this some time ago.

[Bob Hairgrove]

I do not know many of the words mentioned above. But about things I understand: I think the difference signed/unsigned is negligible.

It becomes a big problem when, every time you try to access a member of one of the STL containers, you have to cast the index, which is a parameter of very many functions ... which means either you have to change the function declaration, or else do an ugly cast inside the body of the function.

Also I think that having most of members public in FET classes is also not a problem.

It's not a problem until someone else besides yourself starts using the classes and maybe tries to change a value that shouldn't be changed. I'm not trying to criticize at all, you've really done a great job! But why not use the keyword "struct" instead of "class"? Then you wouldn't need to explicitly write "public"...

There are not many Qt classes used in FET command-line.

What about QCoreApplication? All of the translation things? Command-line argument parsing? QString is used all the time, and it is very different from std::string. I actually like to work with QString because it has many additional interfaces that std::string does not. Especially when FET is translated into so many different languages. But using just the functionality of the engine as a CGI script, that wouldn't be an issue.

A problem would be the "foreach" keyword. The rest would not be so difficult. But maybe a good solution would be just to take small portions of Qt code (as small as possible) and include them in the package. QList, QSet, QHash (I am not sure about this one), foreach keyword, QString, and I think that would be nearly everything. I took care in the code that any implementation of QSet (any order of the elements) gives the same behavior of the generation, so you can start with the same random seed and check the official FET and the customized FET to have the same final random seed.

Indeed, I think if it were not for the "foreach" keyword, one could replace QList by list, QSet by set, QHash by hash, and QString by string. But "foreach" is tricky - I think I tried this some time ago.

With C++11 support it is much easier: http://www.codeproject.com/Articles/570638/Ten-Cplusplus-Features-Every-Cplusplus-Developer#foreach

[Liviu Lalescu]

I do not know many of the words mentioned above. But about things I understand: I think the difference signed/unsigned is negligible.

It becomes a big problem when, every time you try to access a member of one of the STL containers, you have to cast the index, which is a parameter of very many functions ... which means either you have to change the function declaration, or else do an ugly cast inside the body of the function.

Yes, indeed; maybe a solution would be to compile and fix each compiler warning by replacing int with size_t.

Also I think that having most of members public in FET classes is also not a problem.

It's not a problem until someone else besides yourself starts using the classes and maybe tries to change a value that shouldn't be changed. I'm not trying to criticize at all, you've really done a great job! But why not use the keyword "struct" instead of "class"? Then you wouldn't need to explicitly write "public"...

You are right. But it is too late now. You can criticize me :-) you are right.

There are not many Qt classes used in FET command-line.

What about QCoreApplication? All of the translation things? Command-line argument parsing? QString is used all the time, and it is very different from std::string. I actually like to work with QString because it has many additional interfaces that std::string does not. Especially when FET is translated into so many different languages. But using just the functionality of the engine as a CGI script, that wouldn't be an issue.

QCoreApplication should not be a great problem. Just ignore/easily convert it. Translation things: #define tr(x) as string(x) or something. It is not difficult (but maybe tedious and a bit long work).

A problem would be the "foreach" keyword. The rest would not be so difficult. But maybe a good solution would be just to take small portions of Qt code (as small as possible) and include them in the package. QList, QSet, QHash (I am not sure about this one), foreach keyword, QString, and I think that would be nearly everything. I took care in the code that any implementation of QSet (any order of the elements) gives the same behavior of the generation, so you can start with the same random seed and check the official FET and the customized FET to have the same final random seed.

Indeed, I think if it were not for the "foreach" keyword, one could replace QList by list, QSet by set, QHash by hash, and QString by string. But "foreach" is tricky - I think I tried this some time ago.

With C++11 support it is much easier: http://www.codeproject.com/Articles/570638/Ten-Cplusplus-Features-Every-Cplusplus-Developer#foreach

Nice! So one can #define foreach(x,y) as for(x: y) or similar, and foreach will be converted by this #define.

[Bob Hairgrove]

With C++11 support it is much easier: http://www.codeproject.com/Articles/570638/Ten-Cplusplus-Features-Every-Cplusplus-Developer#foreach

Nice! So one can #define foreach(x,y) as for(x: y) or similar, and foreach will be converted by this #define.

I never tried it, but it sounds like a good idea.

[Liviu Lalescu]

With C++11 support it is much easier: http://www.codeproject.com/Articles/570638/Ten-Cplusplus-Features-Every-Cplusplus-Developer#foreach

Nice! So one can #define foreach(x,y) as for(x: y) or similar, and foreach will be converted by this #define.

I never tried it, but it sounds like a good idea.

Hmm, I am not sure. Because a foreach looks like:

foreach(int i, list)

So there is also the type for 'i'. But I think one may convert the code using regular expression replacements, so we obtain

for(const int& i: list)

It is tricky.

But the best I think would be to extract the Qt code for QList, QSet, QHash, QString and foreach. Should not be too large or dependent on other large code (I hope).