best and current timetable for cli

[Davide G. M. Salvetti]

Hi,

first of all, many, many thanks to Liviu for the latest version release.

I have a suggestion which I deem very useful for the command line interface of fet: as I understand, there is at this moment no way to tell fet to save the current or best timetable if started from cli, just like one can do with the gui.

In a Unix environment, I would suggest to let fet save to disk the current timetable on receiving SIGUSR1 and the best timetable on receiving SIGUSR2, or something like that.  I don't know enough about Windows to suggest something for that.

Thanks.

[Liviu Lalescu]

Good suggestion, I'll add it in the TODO and I might even consider it for the next version. But:

1) I would like a unified treatment of any environment (GNU/Linux, Windows, Mac OS X);

2) How can I treat signals? (I have no experience.).

Should I take care of other things? Like writing the impossible activity and so on?

[Davide G. M. Salvetti]

1) I would like a unified treatment of any environment (GNU/Linux, Windows, Mac OS X);

You can use signals on every POSIX compliant OS, which includes GNU/Linux and Mac OS X.  Unfortunately, I believe Windows has no concept of signals (I might be mistaken here, though, I don't grok Windows); maybe we can use a file system polling approach instead, see below.

2) How can I treat signals? (I have no experience.).

The basic concept is to define a handler (function / method) for a particular signal and let the OS know about it: whenever that signal arrives the OS will pass control to the handler, which runs by default without context switching.  A minimal C example should clarify:

#include <stdio.h>
#include <signal.h>

/* Define the handler */
void
sigusr1_handler (int signum)    /* the signum parameter allows to let a
                                                    single function handle more than one
                                                    signal; we don't need it here */
{
  printf ("Hi there, we've just got a USR1 signal.\n"); /* whatever */
  return;
}

int
main (void)
{
  signal (SIGUSR1, sigusr1_handler); /* register the handler with the OS
                                                             for the USR1 signal  */
  for ( ;; ) {}                   /* wait for ever */
}

In a POSIX compliant system you should compile, run and `kill -USR1 $pid' to see it in action.  There are many signals, not all of them can be handled with a custom handler, but I think USR1 and USR2 are what we want here.

Should I take care of other things? Like writing the impossible activity and so on?

Yes, I think you can handle this sort of things by writing to the `result.txt' file.

What can you do on Windows?  Well, I don't really know, but I think on every OS with a file system you can use file system polling: once in a while you look for the existance of a special named file in a special place, let's say $outputdir/write_current_timetable; if it exists, you handle the request and delete it afterwards.  This way the user could touch the file to notify fet of the request.  Of course signalling is technically superior to file system polling, but if nobody comes forth with a better suggestion which includes Windows, I believe file system polling will work everywhere.  That said, I think it would be good to have fet both handle signals on POSIX system _and_ do file system polling everywhere.

[Liviu Lalescu]

OK, I read that <csignal> is ANSI, so even under Windows it should compile.

Please see: http://cplusplus.com/reference/clibrary/csignal/ and http://cplusplus.com/reference/clibrary/csignal/signal/

SIGTERM for writing highest stage and stop, and SIGINT for writing current stage and stop? Do you have a better suggestion, but having ANSI signals?

The only problem in SIGTERM+SIGINT is that user cannot abandon generation without writing any timetable.

Edited to add: would it be better to write current timetable and best timetable on SIGTERM?

[Davide G. M. Salvetti]

OK, I read that <csignal> is ANSI, so even under Windows it should compile.

I see.  I have no idea of how a Windows user can send signals to the application, however; I imagine that C-c from CLI could be SIGINT, but what about SIGTERM?  Maybe by killing the window?

In any case, with only two possibility, I would vote to have one of them dumping both the current timetable and the best timetable while continuing to compute new timetables, while the other could dump both current and best timetable and stop.

The only problem in SIGTERM+SIGINT is that user cannot abandon generation without writing any timetable.

This is a minor problem, IMO, because the user can always easily delete unwanted timetables by hand.

Edited to add: would it be better to write current timetable and best timetable on SIGTERM?

To me it's important to have the choice between dumping and continue and dumping and stop, so I see use for at least two signals.

[Liviu Lalescu]

To me it's important to have the choice between dumping and continue and dumping and stop, so I see use for at least two signals.

Sorry, but there are not enough ANSI signals. Did you see that page? The only "decent" signal for me to handle would be SIGTERM. SIGINT must be left untouched by me.

I think to write current+best timetable and continue generation would not be useful. But I would add it, if I had other "decent" ANSI signals.

I am working on it right now :-)

[Davide G. M. Salvetti]

To me it's important to have the choice between dumping and continue and dumping and stop, so I see use for at least two signals.

Sorry, but there are not enough ANSI signals. Did you see that page? The only "decent" signal for me to handle would be SIGTERM. SIGINT must be left untouched by me.

Yes, I saw both pages, but I did not understand you thought you should catch only SIGTERM, leaving SIGINT untouched: I thought you considered using both of them.

I think to write current+best timetable and continue generation would not be useful. But I would add it, if I had other "decent" ANSI signals.

I will try to express my motivation about why I consider allowing fet to continue after timetables dumping far more important than stopping it:

• if fet nearly reached completion (say 998 activities placed out of 1000 total activities) and seems to have gotten stuck, the user might consider dumping the best timetable and working manually on it to try to place the few unplaced activities by hand while letting fet continue to run, hoping it will eventually reach completion, in case the user discovers to be actually unable to place the missing activies by hand, or just because fet could find a better solution, after all;
• if I want fet to stop after timetables dumping, I can always stop it by hand; if I want fet to continue after it has stopped, I cannot.

I am working on it right now :-)

Thanks :-)

[Liviu Lalescu]

I implemented this, please see Snapshots section, http://lalescu.ro/liviu/fet/forum/index.php?topic=1040.msg6029

For the moment, only SIGTERM -> will stop generation and write highest stage and current stage timetables.

I'll think about other options, but anyway this is an improvement.

[Davide G. M. Salvetti]

I'm testing the 2011-11-12 snapshot (Debian GNU/Linux here):

• sending SIGTERM works as declared;
• constraint comments and sorting thereon work as expected (i.e., lexicographically on comments)
• the constraint activate/deactivate flag works as epxected;
• activity comments work as expected; would it be possible to sort on comments the activity list as well?

Thanks! :-)

I have a question/suggestion more: I wonder if it's sensible to write a .fet file with all placed activities time and space constraints spelled out (i.e., just like the usual _data_and_timetable.fet, where each activity is (non permanently) blocked in time and space) even when fet gets interrupted, rather than only if it completes succesfully.  I think it could be useful, because that file could then be reused as a start, maybe manually deleting or adding some constraint.  What do you think?

[Liviu Lalescu]

activity comments work as expected; would it be possible to sort on comments the activity list as well?

I think FET is relying on activities being ordered by id. But I'll add in the TODO.

I have a question/suggestion more: I wonder if it's sensible to write a .fet file with all placed activities time and space constraints spelled out (i.e., just like the usual _data_and_timetable.fet, where each activity is (non permanently) blocked in time and space) even when fet gets interrupted, rather than only if it completes succesfully.  I think it could be useful, because that file could then be reused as a start, maybe manually deleting or adding some constraint.  What do you think?

I'll add in the TODO.