CoCoA » CoCoA-5

I had to change just one line in Main.C (and add some #include directives).

• (A) one possibility is to offer a command line arg to CoCoAInterpreter which tells it to use readline
• (B) or we could make use of readline the default, if it is present.

What should happen in (A) if the user requests readline and it has not been compiled in?
A quick test showed that the readline version works fine inside emacs, so hopefully there ought not to be any problem if we chose (B).

There is some problem with lines longer than 1023 chars. I think it is an Emacs/comint problem because cutting and pasting the same input (the value of factorial(1000)) in a plain terminal produced no problems. I recall that non-readline CoCoA-5 gives problems with not-so-very-long lines.

Compilation of CoCoAInterpreter with require the option -lreadline if the readline library is to be used.

The CoCoA-5 tests passed with readline active. So I have checked in (to reduce the risk of losing the code).

Still need to change configure, autoconf.mk and define a suitable flag to tell the linker to use readline library if necessary.

John Abbott wrote:

What to do?

• (A) one possibility is to offer a command line arg to CoCoAInterpreter which tells it to use readline
• (B) or we could make use of readline the default, if it is present.

I'll check out and run some test within emacs.
IF there are indeed some problems with emacs then it would be great to have a command line arg so that we can disable readline when calling from emacs, but having readline by default when calling from a terminal.

I have just updated configure. If a quick test passes, I'll check in.
Currently it is a bit of a hack: e.g. it assumes that libreadline.a is properly installed.

• treat readline like the other external libs.
• make configuration work even if readline is not properly installed.
• testing compatibility with emacs (should be OK unless you send weird chars, e.g. inside a string)

No error is given if readline is absent or is incompatible with compilation flags inherited from GMP; in these cases CoCoAInterpreter works as it has done until now. [well, that's the theory...]

It's not perfect (e.g. prints out READLINE twice in the list of ext libs).
Checking in anyway, as I must go now.

Strictly the headers for readline are needed only for compiling LineProviders.C.
Similarly libreadline.a is needed only when linking CoCoAInterpreter.

The flag CoCoA_WITH_READLINE is needed only in LineProviders.C, and should not be passed to the qmake files for compiling the GUI.

JAA thinks that the readline defines, flags, etc. need to be handled separately from those of other external libs.

My first try was not successfull. Durign the configure I got

/tmp/ccdhDbN0.o: In function `main':
test-readline.C:(.text+0xf): undefined reference to `readline'
collect2: error: ld returned 1 exit status

I now investigated it and the problem is the compile command. The library is put in front of the .C file and therefore not used to resolve dependencies from the .C, at least on my compiler (g++ 4.8.2). Here is a patch for readline-check-cxxflags.sh:

-"$CXX" $CXXFLAGS $* test-readline.C -o test-readline
+"$CXX" $CXXFLAGS test-readline.C $* -o test-readline

And it also works fine for me. Is it also possible to include a tab-completion? :)

Only problem is that the tests of CoCoAInterpreter fail because the .found now also includes the input commands.

And one minor point, on start it reports readline twice:

With CoCoALib and external libraries NORMALIZ READLINE READLINE 

Clearly, I was too hasty with my hack to add readline :-(

I know READLINE appears twice at the start -- don't know why, not so important.

The echoing is a nuisance; Anna had already noticed it when running CoCoA inside emacs. I suppose readline turns echoing on when the input is not from a tty. There's probably an easy flag to turn it off... just have to read the documentation (and add the right line somewhere).

I have just read some documentation for readline and also looked online. We're not the first people to have problems with undesired echoing, and it seems there is no very clean solution (i.e. guaranteed portable standard C++).

There is a function called isatty but that is designed to work with C file descriptors rather than C++ streams.

Probably the safest solution is to have a command line option which disables readline, or maybe an internal flag which is set when the interpreter knows that it is reading from a file...

A commandline option to disable readline is probably a good idea. It is the most flexible.
You can then also add some automatic behaviour (then include also a "force enable readline" option).