CoCoA » CoCoA-5

JAA thinks that this could be hard to do portably.

A potentially simpler solution would be to have some way of marking "end-of-block-of-input" (some sort of invisible character that has the same semantics as newline).

This appears to be impossible in C++ (version 2003), at least in a fully portable way.

I have found a post which explains how to do it if you compile with g++: see http://www.cplusplus.com/forum/general/74355/

The solution proposed there does work for me (I compiled with Apple's g++ version 4.2.1), but we cannot accept it as it depends on compiling with g++ -- I could add a CPP #ifdef but then the expected output of the CoCoA-5 tests would depend on which compiler was used to compile CoCoA-5.

Attempts to use the in_avail member function failed because it always returns 0; this is allowed by the definition. Even trying to use the readsome member function produced the same overall effect (since readsome is allowed to return without reading anything).

Altogether a frustrating two hour waste of time. Maybe more recent versions of C++ cater for testing the availability of input?

Note: another solution idea I read was to view stdin as a socket, and then to use select and poll to test whether there is pending data. If I recall well, the person suggesting this suggested that it may not work as desired on every platform.

I have checked in the code for automatic prompt suppression (in Main.C:153 and LineProviders.C:85; but the code is commented out because I doubt it works portably).

• do not print any prompt (initially)
• call getline with short timeout (say 0.1s)
• if no input, then print the prompt, and call getline again (but with no timeout)
• otherwise if there is a new input line, do not print the prompt, just process the new line

This will produce a slightly odd effect with normal interactive use: the prompt will appear with a very slight delay (and someone who types very fast may be able to type some chars before the prompt appears -- that's anyway possible if the previous command was slow).

Is it worth trying this? (assuming getline with timeout exists)

There is a potentially useful code outline on StackOverflow (https://stackoverflow.com/questions/15524122/how-to-implement-timeout-for-getline):
[WARNING: BUGGY CODE -- has dangling ref]

#include <thread>
#include <atomic>
#include <iostream>
#include <string>

int main()
{
    std::atomic<bool> flag = false;
    std::thread([&]
    {
        std::this_thread::sleep_for(std::chrono::seconds(5));

        if (!flag)
            std::terminate();
    }).detach();

    std::string s;
    std::getline(std::cin, s);
    flag = true;
    std::cout << s << '\n';

I have just tried a minor variant of the code excerpt given in the previous comment (11).
It did not work (as expected).

The very first prompt did not appear at all.
After sending several lines (via cut-and-paste), a prompt was printed at the end of the (3) lines... good!
BUT after typing in just 1 more line, suddenly 4 = 3+1 prompts were printed out... bad :-(

I wonder if the flag should be global (via a shared_ptr)?

The current may have a weak spot: if very many simple lines are given as input, presumably the process could create very many concurrent threads since the first thread will vanish only after 0.25s (by which time there may be another 1000 threads... if the input lines are very simple).

I have tried a test with input like the following:

t0 := CpuTime();
A := 1;
A := 1;
...
A := 1;
TimeFrom(t0);

So far the current impl of my linux computer works well enough with 1000 copies of A := 1;

1. reduce the wait time from 0.25s (how long a line can be read in 0.25s?)
2. change the sleep call into a 25-iter loop which sleeps for 0.01s and then checks the flag

I suppose approach 1 is more KISS...

UPDATE my computer can read a line about 800k long in 0.25s (the line was just many repeats of A := 1;)
How short a time can a thread "sleep" for?

I have tried to cause problems by giving inputs with many simple lines, but observed no indication of trouble (surely there must have been several thousand threads...?)

One useful change was to avoid creating a thread if --no-prompt was set to true: suddenly the test ran about 10 times faster (wow!)

Mu experience suggests that 0.25s wait time is a bit too long... it feels odd that the prompt "hesitates" before appearing.
I'll try 0.1s.

I finally managed to make the orig impl fail (with system exception Resource temporarily unavailable).
There were 100000 copies of A := 1; and the time delay was 0.25s. There was no problem with a delay of 0.1s.

Changing the wait into a loop fixed the problem:

  for (int slept = 0; slept < SNOOZE_TIME; slept += 10)
  {
    std::this_thread::sleep_for(std::chrono::milliseconds(10));
    if (*GetlineCompleted_ptr) return;
  }

Strictly the loop should use a steady clock to check the actual amount of time that has been slept...

The loop version from the previous comment worked OK, but incurred a noticeable run-time overhead.

For the time being I have gone back to a single sleep_for with a time of 200ms. That worked on my computer (even with 100000 lines of input).
This seems to be a reasonable compromise... but the "resource unavailable" exception could haunt us on a different platform?

I confirm that disappointingly large overhead mentioned in comment 15 above.

./cocoa5 --no-readline < TEST.cocoa5             # takes about 3.6s
./cocoa5 --no-readline --no-prompt < TEST.cocoa5 # takes about 0.2s

I am now considering changing the design so that just 2 threads are used: main thread, and a separate one which decides whether to print a prompt.
Communication would have to be via globals... hmmm, that's not a good sign.

There could be a subtle bug to deal with: what happens if the interpreter exits while the prompt thread is still running? Is the impl safe in this situation?