CoCoA » CoCoA-5

For cocoa5 it's easy: if there is no prompt, then it is busy.
That was not the case for cocoa-4, which had no prompt.

I know, this is a non-answer, but I think it is not so important.

A problem with watching for the prompt is that a user program might print out a copy of the prompt inside some string.
Also I think it is necessary to signal both: "waiting for input" (i.e. the prompt), and "starting to execute command" (currently no explicit sign is given).

I'm not sure what happens if someone runs a program which uses StandardInput.
I'm not even sure what should happen in such a case.

I looked through the CoCoA-4 code (which used a Qt interface).
The situation is different from Klaus's problem because the interpreter itself was modified to work with the Qt GUI.
The hope with CoCoA-5 was to build a GUI which did not require intrusive changes to the CoCoA-5 interpreter (or only minimal changes).

The is also the old Qt4 interface for CoCoA-5 which Ulrich has tried to resuscitate, apparently with some success (to be confirmed when I am in Genoa). Again this GUI has "intrusive" code in the interpreter (and I am not sure if there was an indication that CoCoA is busy).

Perhaps the relevant function is Interpreter::readAndExecute, not sure though... (too busy with other stuff currently)

I have just spoken to Kreuzer, and he showed me that the old ApCoCoA GUI would indicate either "Calculation in progress" or the CPU time of the last computation. This makes me strongly suspect that the old GUI also required modification to the C4 UI code (otherwise how/why would it indicate amount of CPU time consumed?

I think it is ambitious (i.e. risky) to hope to write the new UI part in C++ for CoCoA-5 in time for the COCOA School.
We could be lucky: perhaps copying the existing Qt-based code, and modifying that will suffice... but it is a gamble.

I have just modified Interpreter.C so that it prints out [WAITING FOR INPUT] and [RUNNING].
A few quick tests suggest that it is working reasonably.

Not checked into CVS!

NOTE the changes are inside Interpreter::run. The clue was to mimic what was implemented for the Qt interface (code which is inside CPP blocks visible only when C5IDE is set). Inserted clog<<"[WAITING]" around line 2866; inserted clog<<"[RUNNING]" around line 2900.

Here is what I get currently:

clog:[RUNNING]
clog:[WAITING FOR INPUT] 
>>> n := factorial(10000000);
clog:[RUNNING]
clog:[TIME TAKEN: 2.5]
clog:[WAITING FOR INPUT] 
>>> 

Not checked into CVS!!

Perhaps see also issue #1236 to see how I implemented sockets...

I have given Klaus a (minimal) executable to use for developing on his computer.
A full executable gave a linker error related to libgmpxx; I suppose my version used dynamic linking for the system installed version...

My proposed solution does not work quite as I would like.

With the input if n = factorial(10^7) then println "equal"; endif the log produces R and then W2.5.
BUT the same input with a final semicolon produces a different log, namely R then W2.5 and then R and W0.

1. after a compound command, if the next symbol is just "semicolon" then silently consume it
2. do not print R and W lines in the log if the command is void

Approach 2 seems easier to me; and would also handle the case of accidentally putting too many semicolons after a command.

I have changed the main eval loop so that EmptyStatements are skipped over without being executed (since they do nothing anyway).
At the moment Skip is still executed, but I can easily change that.

It seems to work as desired: i.e. it does not issue R and W0 log output.