Project

General

Profile

Bug #1093

GUI: bugs and slugs

Added by John Abbott almost 7 years ago. Updated over 1 year ago.

Status:
In Progress
Priority:
Low
Assignee:
John Abbott
Category:
GUI
Target version:
CoCoA-5.?.?
Start date:
23 Jul 2017
Due date:
% Done:

10%

Estimated time:
Spent time:
3.00 h

Description

I know the GUI is on "life support" (or worse), but I'd like to gather in one place some of the problems it has just in case someone wants to improve it (or make a new one).

Related issues

Related to CoCoA-5 - Slug #741: C5 GUI: slow to closeClosed2015-06-26

Related to CoCoA-5 - Slug #750: C5 GUI: very slow when printing many short linesClosed2015-07-27

Related to CoCoA-5 - Support #1393: GUI with Qt5Feedback2020-01-13

History

#1 Updated by John Abbott almost 7 years ago

  • Related to Slug #741: C5 GUI: slow to close added

#2 Updated by John Abbott almost 7 years ago

  • Related to Slug #750: C5 GUI: very slow when printing many short lines added

#3 Updated by John Abbott almost 7 years ago

The GUI really seems to have trouble with big outputs; my guess is that this is a QT "feature" :-/

factorial(10^5) takes a long time to print, and then "fills the screen" with digits.
factorial(5*10^6) produces a "scrambled" line (it looks like overprinting); I think this puts the GUI in a near coma (consuming 99% CPU).
factorial(10^7) causes a complete crash of the GUI; output is a bit more than 64Mbyte on one line.

PS I'm pretty sure that printing out factorial(10^7) would floor Emacs as well.

#4 Updated by John Abbott almost 7 years ago

I have changed the way CoCoALib handles signals. This forced me to make some changes to the source of the GUI (but without really understanding what the code was supposed to do).

In particular, I replaced two fn calls by calls to GetAndResetSignalReceived (in lines 80 and 120 of C5.C).

At two points the GUI also wants to "set" the signal received (lines 1634 and 1922 in C5.C). I don't know why; anyway I had to make available a public fn for setting the signal received (see SignalWatcher.H)

It is possible that my "blind" changes have broken something, but I am sure this is unrelated to the problems of large outputs.

#5 Updated by John Abbott over 4 years ago

Ulrich reported that the GUI fails to compile now that we are using nullptr.
I had a quick search online, and found something on StackOverflow. I tried putting the compilation flag -std=c++14 for the compiler and also c++14 as a CONFIG parameter, but the error persists: it complains that nullptr is a keyword in C++11 (so is presumably trying to compile as if in c++03 mode... no idea why).

Anyway, I think I shall change the CoCoA-5 configuration so that the user must explicitly request that the Qt GUI be compiled (even if it does not currently work). The current default is that it will attempt to compile the GUI if qmake was found; so users who have qmake will see failed compilations even if the normal textual interface compiled fine.

#6 Updated by John Abbott over 4 years ago

  • Status changed from New to In Progress
  • Assignee set to John Abbott
  • % Done changed from 0 to 10

I have changed configure so that it sets a flag saying whether to build the Qt GUI; this is determined by a command line option (default is NOT to build the GUI).

Configuration will fail if the user requests building the GUI, but qmake is not found or does not work properly.

I have done some other tidying in the configure script.
Now testing on my machine...

#7 Updated by John Abbott over 4 years ago

#8 Updated by John Abbott over 1 year ago

Interrupt messages from CoCoALib functions are discarded/ignored.

There does not appear to be a "kill" option for a running CoCoA-5; the only
way seems to be to kill the whole GUI.

Also available in: Atom PDF