I am doing my first steps with GDB in TUI mode.
During the debug session I see that each line outputted to console occurs in a single line (in the picture you see 222222 highlighted in red). It is like having an output pane of one single line.
On top of that, each \n doesn't cleanup that line so all the strings do overwrite each other making my output very confusing.
Can you help me a bit with this issue or point me to some key command to look for in order to have a clean output?
I also highlighted another area (in the picture 1111111) because the first string is outputted there and then all other on the frame of the source code window.
You can always refresh tui screeen every time your program outputs something with Ctrl+L key binding. Or you can temporarily swith to normal mode, step and watch program output and switch back to tui mode (Ctrl+X A). See all key bindings here.
Related
I am trying to create a program which will have live updates from some data source. And I also want to wait for user input just like a normal terminal. Right now, whenever there is update, I will print the content and print the prompt message for input again which create something like this:
Enter command >
This is a live update message
Enter command >
This is a multi-line li......
......ve update message
Enter command > quit
Bye bye!
The problem is that for every live message I received, I will print it and the "Enter command >" will be displayed again again and again, which is not desired. I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
The closest package I can found on Github is https://github.com/gizak/termui but most of the examples inside is trying to display text, gauge and graphs. So I am not quite sure how to get started.
Is there any package or example of the termui package to achieve this? Thank you.
With github.com/gizak/termui you're heading in the correct direction.
To understand why you can't get that
I want the live update to be update on the main part of the terminal, while the "Enter command >" always stay at the bottom
part sorted out, a little excursion to the history of computing is due. ;-)
The thing is, the mode your teminal emulator¹ works by default originated
in how computers would communicate to the operator in the era which predated
alphanumeric displays — they would print their responses using a line printer. Now think of it: a line printer works like this: it prints whatever is sent to it on a roll of paper. What was output, was output.
The new output always appears physically below the older.
When alphanumeric displays (screens) came into existence they
naturally continued to support this mode:
the line text to be output was rendered at the bottom of the screen
with the text above it scrolled upwards.
That's what you see in your typical terminal emulator all the time when you're working in the command line of a shell (such as bash) running by the emulator window.
This, default, work mode of a terminal is called "canonical" or "cooked".
Then came more advanced displays, for which it was possible to change
individual positions on the screen — identified by their column and
row numbers.
This changed the paradigm of how the information was output: the concept
of a so-called "full-screen application" was born.
Typical examples of them are text editors such as Vim and Emacs.
To support full-screen text output, terminals (and terminal emulators)
were adapted by implementing certain extensions to their protocols.
A full-screen application first requests the terminal to switch into another
mode called "raw", in which the terminal sends most of what is input by the
user directly to the program running on the terminal.
The program handles this input and orders the terminal where and what
to draw.
You can read this good summary
of the distinction between the both modes.
As you are supposedly suspecting by now, to be able to keep some block
of information at a certain fixed place of the terminal's text screen,
you want your program to be a full-screen program and use the terminal's
raw mode and its special commands allowing you to directly modify
text at certain character cells.
Now the problem is that different terminals (and terminal emulators)
have different commands to do that, so there exist libraries to isolate
the programs from these gory details. They rely on the special "terminal
information databases" to figure out what capabilities a terminal has
and how to make it do what the program asks.
See man terminfo for more background.
The most widely known such library (written in C) is called ncurses,
and there exist native solutions for Go with supposedly the most visible
one being github.com/nsf/termbox-go.
The github.com/gizak/termui makes use of termbox-go but for you it might
suffice to use the latter directly.
¹ Chances are very high you're not sitting at
a real hardware terminal
connected to a UNIX® machine but are rather working in a GUI application
such as GNOME Terminal or xterm or Termial.app etc.
These are not "terminals" per se but are rather
terminal emulators —
that is, pieces of software emulating a hardware terminal.
I'm having a problem with debugging Fortran code within emacs using gdb.
Gdb starts up fine and the program loads OK and stops on the first breakpoint, which I set at the beginning main. Then when I type n to go to the next line, the program proceeds to run all the way through (as if I typed c), instead of going to the next line. To get around this, I set another breakpoint further down. After hitting c, (at the first breakpoint in main) the code skips to and stops at the latter breakpoint (which is what I want).
However, at this point, I can no longer enter gdb commands, as the source code has moved to the top window, and the output to the bottom window (whereas normally all the gdb input commands and program output occur in the top window, and the source code being traversed through on the bottom). So now at this point, when I enter gdb commands, it becomes part of the source code and I cannot navigate through it with n and c and such - instead the code has a bunch of n's an c's in it!
I'm running Fedora 18, and GNU Emacs 24.3.1. Also, to run gdb in emacs, it insists I use the switch -i=mi. After I hit M-x gdb, the line at the bottom pops up as: Run gdb (like this): gdb -i=mi .... I tried playing around with the switches, such as -annotate=3 to no avail.
If I understand correctly, you only have two windows open within emacs, and what has happened is that the output and source code buffers have replaced the gdb command buffer.
You can switch back to the gdb command buffer with C-x b *gud-programname* RET, where programname is the name of the program you are debugging. You might find it helpful to create a new window and switch to the gdb command buffer in that.
This happens because the gdb mode isn't clever enough to keep the command window on top. You can use M-x gdb-many-windows which improves on this a bit.
These two questions may also be helpful.
I am using Vimperator 3.8.1 with Firefox 25.0. I have created a macro to solve a problem (details below), and this macro fails at the following point.
Vimperator Macro e:
/foo<Return>cv<Down>y
My macro searches for a string ('foo') in the page, then goes into caret mode, then into the visual mode, and then selects one line of text and then copies that text.
My problem is that when I record this macro, the one selected line gets copied, but when I play it (using play command), nothing gets copied onto the clipboard. Thus, due to this, I am unable to retrieve that info in an automated manner. I don't know what to Google for in this case, so I posting this here on SO.
I will be highly obliged if someone can also explain why this happens the way it does. Please also let me know if something is not clear.
Problem Details
I am using Vimperator 3.8.1 with Firefox 25.0. I have a lot of tabs (about 300 tabs) which contain similar information (only one line is different on each tab). I want to copy that single line from each tab and collate it in one place. That one line begins with the string 'foo' in every case, and each of the 300 tabs has links that can be incremented using Ctrl+a in Vimperator (i.e. ...page=1, ...page=2)
How I plan to accomplish this is as follows. I have an online notepad open in tab 1, and the very first of my 300 tabs open in tab 2. I copy my single line from tab 2, and paste it into tab 1, then go back and increment tab 2 to point to the next tab. I will repeat this macro 300 times to get all the info.
Thus my complete macro will look like
/foo<Return>cv<Down>y<C-PageUp><C-t>p<C-PageDown><C-a>
I am not sure what's going on here.
I set up a breakpoint.
I start code in debug mode.
Debugger jumps to the breakpoint
I step over
Debugger goes somewhere but the next line ...
Is this a known issue? Am i not using the tool correctly?
Here is an example:
Debugger starts, we stop at the breakpoint.
Instead of going to the constructor of the class i asked to step into to (expect to get to line 29)
It's jumping to superclass automatically (!#$!#)
But then ... when i step over it skips lines ..
I would like (when i step over) to go to the next line and when i step in to think less and do what it's told. Is this a configuration issue somewhere in my instance?
To get behavior similar to Eclipse use Run | Smart Step Into, this will skip directly to the constructor ignoring any other executable code that can run before it. Note that step over will not step through lines that do not contain executable code (line #21).
While using keyboard shortcut is much faster, you can still add Smart Step Into action to the toolbar in File | Settings | Menus and Toolbars, Main Toolbar.
Is there a way in which I can debug my compiled Matlab components, using native Matlab debugger, like Visual Studio "Attach to process" option, or something like that?
I mean EXE stand-alone files, DLLs, COM in-process servers or .NET components.
You can't debug them in the sense of being able to step through the MATLAB code line by line, as you can with MATLAB's own debugger prior to compilation. One of the steps that the MATLAB deployment products take is to encrypt the MATLAB code (so you can preserve your IP when distributing the deployed component). The ability to step through the code in a debugger after deployment would defeat the purpose of that.
I experimented with using something like :
try
catch ME
waitbar(0,ME.message)
end
This was quite an effective and generic solution.
you may want to break down the code into multiple parts and debug each to save compiling time.
good luck,
dan
You can follow the instructions to debug:
Debugging:
Using the Debugging Tool will let you stop your program in mid-execution to examine the contents of variables and other things which can help you find mistakes in your program. M-file programs are stopped at "breakpoints". To create a breakpoint, simply press F12 and a red dot will appear next to the line where your cursor is. You can also click on the dash next to the line number on the left side of the M-file window to achieve the same result.
Then press F5 or Debug->Run from the menu to run the program. It will stop at the breakpoint with a green arrow next to it. You can then examine the contents of variables in the workspace, step, continue or stop your program using the Debug menu. To examine contents of a variable, simply type its name into the workspace, but be warned: you can only look at the values of variables in the file you stop in, so this means that you'll probably need multiple breakpoints to find the source of your problem. There are several different ways you can move through the program from a breakpoint. One way is to go through the whole program, line by line, entering every function that is called. This is effective if you don't know where the problem is. There's also a way to simply step through the function you're currently stopped in, one line at a time, and instead of going through the child functions line by line MATLAB will simply give you the results of those functions.
Finally, note that you cannot set a breakpoint until you save the M-file. If you change something, you must save before the breakpoint "notices" your changes. This situation is depicted in MATLAB by changing the dots from red to gray. Sometimes, you'll save but the dots will still be gray; this occurs when you have more than one breakpoint in multiple files. To get around this (which is really annoying), you have to keep going to "exit debug mode" until it turns gray. Once you're completely out of debug mode, your file will save and you'll be ready to start another round of debugging. Using comments to help you debug code. you want to test the effects of leaving out certain lines of code (to see, for example, if the program still returns Inf if you take them out), you can comment out the code. To do this, highlight it and then go to:
Text -> Comment
Or press CTRL+R. This will simply put a '%' in front of every line; if the line is already commented out it will put another '%' there so when you uncomment them the pattern of comment lines will not change. Commented lines will be ignored by the compiler, so the effect will be that the program is run without them.
To uncomment a line go to
Text -> Uncomment
Or press CTRL+T.
Another use of commenting is to test the difference between two different possible sets of code to do something (for example, you may want to test the effect of using ODE113 as opposed to ODE45 to solve a differential equation, so you'd have one line calling each). You can test the difference by commenting one out and running the program, then uncommenting that one and commenting the other one out, and calling the program again.
How to escape infinite loops?
MATLAB can't directly tell you you have an infinite loop, it does attempt to give you some hints. The first comes when you terminate the program. Terminate it by pressing CTRL+C and MATLAB will give you a message telling you exactly what line you stopped on. If your program is running a long time, it is likely the line you stopped in is in the middle of an infinite loop. sometimes MATLAB won't even let you return to the main window to press CTRL-C. In this case you probably have to kill the whole MATLAB process. After this, add a "pause (0.001)" or a similarly small value in the loop you suspect to be the infinite one. Whenever MATLAB passes this instruction you will be able to interact with MATLAB for a (very) short time, e.g. go to the main window and press CTRL-C with MATLAB being able to respond to your command.