Are you able to reproduce this? I launch the program and, even though it's only waiting for input, it takes up 100% CPU. Apart from that, everything seems normal. I've already tried removing all related (wxMaxima, and maxima) config files.
I am going to test it and I will tell you the results. Thanks for reporting.
I reproduced your issue on a machine with the following settings: - FreeBSD 13.0-CURRENT r360656; - ports tree r535995; - walyand with hikari compositor. I CC lbartoletti who recently (2020-05-17) updated wxgtk30 and thus might know something about the issue. Peter: can you tell if the issue was already present before the wxgtk30 update?
(In reply to Lorenzo Salvadore from comment #2) Versions from before -- I believe -- April didn't exhibit this problem. I can't tell whether it's been introduced by one of the intermediate wxMaxima updates or by wxgtk30.
I tested wxmaxima precedent version of wxgtk30 and found the same issue. Next step I will try is testing the precedent version of wxmaxima, then I will probably open an issue upstream. If anyone is willing to help, using a profiler to determine the cpu consuming function would be very useful.
As you can see in my proposed fork in https://reviews.freebsd.org/D24959 I had to move the inline documentation from the classical $DOCSDIR to $DATADIR/$PORTVERSION/doc. Without that, wxmaxima was looking for these docs and emitted an error message (but I did not notice abnormal CPU consumption, just a little slowness). Another possibility could be to patch every occurrence of this directory in the code, but it is easier this way.
I tested wxmaxima 20.03.1 and determined that this version has the same bug. I am going to try to determine what is the cpu consuming function. (In reply to Thierry Thomas from comment #5) Thanks Thierry, however please note that this bug is about wxmaxima, not about maxima, so I doubt the problem is caused by the documentation.
(In reply to Thierry Thomas from comment #5) Sorry, I read better your sentence "Without that, wxmaxima was looking for these docs and emitted an error message" and now I understood what you mean. I will check into this.
lbartoletti: I get lots of error message as the following: (wxmaxima:51809): Gtk-WARNING **: 23:59:04.953: gtk_widget_size_allocate(): attempt to underallocate wxPizza's child GtkButton 0x804f166c0. Allocation is 70x28, but minimum required size is 94x34. (wxmaxima:51809): Gtk-WARNING **: 23:59:04.953: gtk_widget_size_allocate(): attempt to underallocate wxPizza's child GtkButton 0x804f16880. Allocation is 70x28, but minimum required size is 110x34. (wxmaxima:51809): Gtk-WARNING **: 23:59:04.953: gtk_widget_size_allocate(): attempt to underallocate wxPizza's child GtkButton 0x804f16a40. Allocation is 70x28, but minimum required size is 106x34. Do you think this can be related to the issue? Do you have any idea for fixing it? Thanks.
Still no success with finding the cause of the high cpu usage, but I opened an issue upstream if anyone wants to follow it: https://github.com/wxMaxima-developers/wxmaxima/issues/1290
(In reply to Lorenzo Salvadore from comment #2) > I CC lbartoletti who recently (2020-05-17) updated wxgtk30 and thus might know something about the issue. Nope sorry :/ I have not this issue with other ports using wxgtk30
(In reply to Lorenzo Salvadore from comment #8) wxgtk uses gtk, and gtk (as qt some times) is ... verbose with this can of warning (or assert). I don't think that is related to the issue.
@Peter Can we get a process trace to see what it's spinning on? ^Triage: Reset to Open
Peter Kien is the issue still present?
Hello. Sorry, to have dropped wxmaxima without fixing the bug, but I had to take a break from FreeBSD and I have returned only very recently. As I am planning to adopt wxmaxima again, I re-assign the bug to myself. I am going to investigate if the issue is still present. If I cannot reproduce it anymore I am going to close the bug report, unless Peter Kien confirms that he still encounters the bug.
I have finally tested the port and I could not reproduce the bug anymore: it must have been fixed someway.