I ssh into a remote linux sever from my Mac, and run gdbtui to debug a program. The source code displays, but the cursor line in the source code window frequently is not highlighted. I can enter commands such as 'next' and 'list' in the command line window, but the source code window doesn't redraw correctly. It sometimes shows lines in the source file out of order (the line numbers are displayed out of order.)
I have my TERM environment variable set to xterm-16color which vim is very happy to use. I'm at a loss as to what I should try.
gdb in ordinary command-line mode works fine.
Ideas?
What gdb version are you using? Try the latest one. At least gdb 6.5 had similar problems with tui mode.
I have the exact same configuration as you: I ssh into an Ubuntu server (currently 11.10) from a Mac and I'm currently experimenting with gdbtui.
I recommend that you use iterm2 as your Apple Terminal replacement. Besides 256 colors and a ton of other features, it seems to play decently with gdbtui (line highlighting is fine).
Related
I am learning to program in Python and Rust. On different versions of Ubuntu these programs compiled and ran perfectly. Now that I have a dedicated Fedora 30 KDE system, every time I try and build a program, I get a warning: Failed to load module "appmenu-gtk-module"
I have tried looking this up and have re/installed anything GTK on my system. The programs otherwise function well, but no menus are drawn. I was also trying things in GNOME and hit the same thing.
I am also using QT. Those programs also build and run fine, but again, no menu.
I'm going bonkers with this. Any help is appreciated.
The appmenu-gtk module is not packaged on Fedora. (GNOME doesn't support them anyway.)
The real questions are:
Why is it configured to load? Did you copy or share GTK config files from an Ubuntu system? You should remove this module from your settings.
Even with improper configs I don't believe this should result in menus not appearing. It should just fail to load and work as normal. How is your application using menus?
I finally got so fed up with getting this error that I went full nerd-diagnosis, and ran this command to find out which file contained the errant reference to the appmenu-gtk (the package that would provide this is not installable on my system either).
(Replace "dolphin" with the command that is giving you the error.)
strace -e openat,access dolphin 2>&1 |grep -v ENOENT |awk '/appmenu-gtk/ {exit} !/appmenu-gtk/ {print}'|cut -d '"' -f2 |sort|uniq|xargs grep appmenu-gtk 2>/dev/null
This will then give you a list of files which contain the line appmenu-gtk, and in my case it was ~/.config/gtk-3.0/settings.ini. From there I just commented it out, and that gets rid of the error message (not sure if this will fix your problem of not having any menus, but you might just be able to edit that line to fix it in another way if commenting it out doesn't work).
I'm using Fedora 21 with GNU Emacs 24.5.1 and ESS version 15.03. In GUI mode I can use C-RET to pass code from an R script I'm editing to an inferior R process (it starts one up if I haven't yet), but that doesn't seem to work in console mode. Now C-RET just creates a new line in my R script. I've tried this using both emacs and emacs-nox installations.
I compiled ESS from source instead of using the outdated version in Fedora's package manager. Could that have anything to do with it?
The problem is that C-RET isn't a valid sequence in the terminal, so the C- is getting ignored and it's just interpreting the RET. See this answer for more explanation. Following some of the links there will take you to some workarounds, but they are not ideal. It doesn't look like there are any ways to completely change this behavior in the terminal (but I'd love to be told I'm wrong).
I have just installed the latest versions of R (3.1.0) and Rstudio (v0.98.507) on a Windows 7 machine, 64 bit.
The R GUI works OK, but when I open the RStudio.exe only a blank window opens. I've tried re-installing R and RStudio.
Any suggestions?
By choosing the R version I wanted to use I was able to use Rstudio again.
To choose the R version you want to use with Rstudio do the following;
Click the CTRL key (don't let go)
Click on the Rstudio icon
Choose the version you want in the pop-up window.
For Ubuntu users where #neal's solution doesn't work.
$ rstudio --no-sandbox
related to: https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1944468
Download the 64bit version and reinstall it.
The same for Linux
FOR LINUX: this happens to me on cloud instances. A solution is forcing software rendering of RStudio. You need to start RStudio, get to the black screen, close Rstudio black screen, do my solution below in the terminal with Rstudio closed, then start Rstudio again.
In terminal:
sudo nano ~/.config/RStudio/desktop.ini
APPEND THE FOLLWING TO [General] section (leave whatever is there and add the line below):
[General]
desktop.renderingEngine=software
Again this is for Linux, but there may be a similar issue in Windows and you may be able to force software rendering.
Press down Ctrl key and then click on RStudio icon to launch. A dialog box asks you about the R version. Choose the one that actually exists (you might see an R version which does not exist; confusing RStudio)
For Windows10 64bit.
After following the hold Ctrl and clicking RStudio icon.
Change the Rendering Engine: to Software.
This fixed the problem on my machine.
I'm using a Macbook Pro (Snow Leopard, 10.6.8) and have been a regular emacs user for the past few months. I'm trying to install a modified version of Emacs 24.2 provided here to utilize Emacs Speaks Statistics (ESS) from the downloads page. I currently have 22.1.1:
M-x emacs-version
GNU Emacs 22.1.1 (mac-apple-darwin) of 2011-06-07 on b1030.apple.com
I installed the emacs linked earlier, put it in Applications, and set this in .bashrc:
alias emacs="/Applications/Emacs.app/Contents/MacOS/Emacs -nw"
So it seems like it's working correctly as I wrote and successfully ran a short R program.
M-x emacs-version
GNU Emacs 24.2.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-08-27 on bob.porkrind.org
Is this the usual way to upgrade to a "newer version" of Emacs? Sorry if this question seems trivial, but I've never done this before (I typically used emacs on a different computer) and the Installation step on the previous website consists of just one sentence. The all-in-one installation method also isn't explained in the official documentation.
A brief side note while I was searching on the web: I believe calling 'emacs file_name' should open a GUI version, while 'emacs -nw file_name' is the console, so I remain using the terminal. But on my Mac, using emacs has the same effect as using emacs -nw. In other words, I can't get a GUI or separate window to show up. Can anyone confirm that this Super User question has the 'correct' answer? (I don't really have a problem with this, as I hate having another pop-up window, but it would be nice to know for completeness.)
The Emacs that comes with Mac OS X /usr/bin/emacs does not have a graphical interface, just the terminal one, so calling emacs is the same as emacs -nw.
Your upgraded Emacs by default starts with the graphical interface, so you need to specify -nw to force it to use the terminal.
There is no "usual" way to upgrade OS X's default Emacs (i.e. Apple does not provide an upgraded Emacs); what you've done is fine. Or you could install a binary from http://emacsformacosx.com/ or use a package manager like homebrew.
I am using Scinote 5.4.0 with OSX 10.7.4. I am unable to execute script files from the console using the exec("path") command; when I do so, only the first line of the script file is read.
Example:
-->exec("plot1.sce")
-->x=[0:.1:10]'; //(the first line of my code)
If however I "execute with echo" from the editor Scinote, the script will run just fine.
Does anybody know what is going on? (The script files I am trying to run are in my present working directory).
Thanks!
Update: I just installed Scilab on an identical machine and the same thing is happening.
Update: Per Scilab's bugtracker, it appears to be caused by Scinote defaulting to cr eol on a mac. I don't really know what this means or how to fix it, but the adventure continues!
Update: I found the solution!:http://comments.gmane.org/gmane.comp.mathematics.scilab.user/6184
In the preferences, I changed the eol to Unix, and the default file encoding to iso-8859-1. I restarted and exec is now working!
The link is not easy to follow so here's the answer (pasted)
The problem is actually scinote's, not scilab's. I don't have a Lion
machine to check if I'm correct, but it seems scinote's file encoding
is no longer compatible in ML. I discovered that when I opened scinote
generated files with a different text editor (vi) the new lines
weren't encoded right for my machine. The other give-away was that
executing scripts written prior to upgrading worked fine.
Go to preferences and in the scinotes tab, switch default file
encoding to iso-8859-1. I also switched the end-of-line to Unix.