Since gdb is getting onerous to work with on a Mac these days (at least I feel like I am fighting uphill against Apple), I've started to play around with lldb.
Is there an equivalent mode to gdb -tui that shows a nice, persistent view of the source and where you are in it when running lldb standalone from the command line? Obviously, in Xcode, there is such a display, but I deploy most of my code to Linux boxes eventually and would prefer to use the same development environment on both platforms (i.e., vim, Makefiles, autotools, etc.).
In top of tree svn source lldb there's a very new command line GUI mode that's been added by Greg Clayton. It's pretty neat with separate windows for the source, local variables, stack, threads, registers, etc. No console window yet. It's pretty cool. See http://lldb.llvm.org/build.html for how to build lldb from source if you'd like to check it out. To enter the GUI mode, just type gui from the lldb command line when you're debugging.
UPDATE: this gui feature is included in the lldb that ships in Xcode 6 and later. It's a nights-and-weekends side project that isn't seeing a lot of active development right now but give it a try.
Sadly, no.
However, I did came across this:
https://github.com/snarez/voltron
If you are familiar with screen/tmux it works pretty good.
Type gui in lldb's prompt after you're at an interesting breakpoint. It has a small tutorial the first time it's opened and built-in help.
I'm having good luck with a free GUI facade from Affinic. It's not perfect (or, at least, my understanding of it is not perfect). I must occasionally restart it and sometimes it gets unsynchronized from particularly gnarly / fancy C++ code, e.g., code that does a lot of implicit stuff in constructors. But overall it has saved me a lot of time over the old-fashioned way at the command line.
I have not been able to get the ncurses GUI mode in the LLDB CLI to work, and I have not tried Voltron.
Related
I can't figure out how a desktop environment developer test his code. Usually, a C or C++ programmer compiles his code an then run it (i'm not one of those programmers, i'm a web one).
So, you usually build your gui application over some kind of desktop environment (windows, mac os x, gnome, kde, xfce...), sow how they build and test their gui desktop?
And if this is a silly question, how does a kernel programmer test his code? for example linux kernel? how do you know that what you just wrote works?
Testing is a very broad term there are many types (partial list):
unit tests - test small pieces of code. test that the code behaves as expected.
system tests - test whole application in real world scenarios.
performance tests - test what is the performance of the application or part of it.
GUI testing - test operation of GUI elements (not so common as automated tests)
static analysis - compiler warnings on steroids
dynamic analysis - at a minimum memory checks - check mem allocations and usage
coverage tests - check that all code is executed.
formal verification tests (very advanced) - e.g. check when assertions/assumptions are broken.
Kernel code can be debugged by connecting using a 2nd computer (host). Virtual machines uses the same principal and simplify the setup but can't always work as HW might not exist in the guest VM.
The kernel (all OSes) has trace mechanism(s) for printing progress/problems. In Linux the simple trace is shown via the dmesg command (prints a cyclic buffer).
User mode code can easily be stopped and debugged via a debugger.
Desktop Environments
Testing Desktop Environments in real world scenarios can be kind of annoying, so the developer would have to watch out for every small error he makes, if he doesn't, he will have a hard time developing the DE.
As stated by #egur, there are multiple ways of testing his code, the easiest one and most important (but cannot be used in some cases, of course), he can test that code in a simplified program.
A Desktop Environment consists of many parts, however, in your case, I suppose you're talking about the session manager (or window manager) which is responsible for almost everything. So, if he were to test that, he would simply exit his current DE and use the new executable. In case of some error, he can always keep a backup of the old executable or fix the faulty code using some commandline text editor (like vim, or nano).
Kernel
It's quite hard to test, some kernel developers just write some code and make sure it's fine and compiles, then simply let his users test (by ACK'ing the code, etc.), then it can be submitted into the kernel code. Reasoning behind that is, the developer may not have the hardware needed to test the code.
Right now, you can compile and run the kernel in usermode (UML) if you have heard of it, so some developers may go for it. However, some developers may also want to test it themselves (They of course back up the current kernel incase of a screw up).
The way to test a desktop application is related to the way of control the application unassisted or remotely.
The Cross Platform GUI Test Automation tool (I don't know if this project has a web) project helps you to chose the interfaces/libraries required to solve the problem.
In Linux[1] uses the accessibility libraries to control the application, you have Cobra[2] for Windows and PyATOM[3] for MacOS, but I don't know what kind of technology uses in this platforms.
http://ldtp.freedesktop.org/wiki/
https://github.com/ldtp/cobra
https://github.com/pyatom/pyatom
I just started making my first couple of apps for iOS, which involves using XCode for the first time. I'm amazed how effortless coding becomes with the code completion in this. Everything from data types, to function names, to syntax templates, the IDE will suggest to you and write it in if you choose. It makes coding so smooth, and means you never need to struggle to remember what you named some function, or what order the arguments come in.
Until now, I've been using Eclipse to code in C, as well as a little Java. I've seen how to modify the content assist options for Java such that it will give suggestions based on almost any input, which simulates what XCode does. But attempting to do the same thing under the preferences for the C/C++ editor, I'm unable to find similar settings.
Is there anything else natively I can do to configure Eclipse so that it will match, or at least come close to, the same level of code completion in XCode, or am I into plug-in territory? To be clear, I'm referring to the C/C++ editor in Eclipse (specifically C), which I want to imitate XCode's code completion functionality.
You can go to "Content Assist" under Preferences for your language of choice, and make sure Auto Activation is turned on. Then, decrease the delay (100ms works for me), and in the Auto Activation Triggers box, put any characters you want auto activation for. For something like Xcode, that'd be: .abcdefghijklmnopqrstuvwxyz, plus caps if you want them. Voila!
i have a unix c programming assignment in which i do some advanced C network programming.this is my first step into advance programming. so i was wondering what is the best combination of tools for this on a mac. using an IDE like Eclipse is how i'd normally do it but i have to make my own makefiles and stuff. so i would like to learn how it can be done effectively using may be emacs or vim + other tools. it will be quite a big project so i am worried about project management and debugging issues mostly as well as the productivity factor. in essence i want to learn how programmers do it in the professional environment without the bloated IDE part. i am using Snow Leopard.i would also delve into C++ and python in the future so may be something that will be useful for those as well.
I know you're asking for how to do it with makefiles/VI/etc. but on the Mac, Xcode is really the way to go, especially for large projects. It's a very effective wrapper that will call gcc and gdb and the linker for you. Especially when moving to a new platform, not having to worry with many of the pesky details will be a big leap in productivity. It's IDE debugger is quite awesome.
Of course you can also use makefiles etc. Many projects (just to take OpenSSL as an example) come with makefiles and you can compile them on the Mac from the commandline just like under the *ix operating systems, i.e. calling ./configure and then make. But setting up stuff like that (e.g. compiler options for universal binaries and such) is tedious while the IDE it's just a few options. Also, if you google for specific questions, you will find far more answers on how to do it with Xcode.
If you want to get started with Xcode, it's either on your Mac operating system CD (it just does not pre-install automatically) or you can download it from Apple. When you run it, just open a Mac OS X Project of type "Application - Commandline Tool" and you'll have a project with a main.c set up in a minute. You can then just run it or run it in the debugger like that and adding more source files to it is rather easy.
Xcode can be quite a beast for setting up an already large project (we ported a large project with DLLs and depending exes (overall 250000 lines of code) to the Mac and just getting that all set up wasn't what you call a piece of cake) but if you start from scratch you'll easily grow into it.
Bottom line is that Xcode certainly is equipped to deal with large projects and I can not imagine a more productive way of doing it (I have used hand written makefiles and such in the past so I know both worlds).
Xcode is your friend. It's free and is a very nice IDE. When you launch XCode, just start a new Console application (it'll be ANSI C).
Enjoy.
If learning the rudiments of unix editors, shell programming, make, etc., are part of the assignment, then you just need to dive in and learn what you need to learn. Some good books will help. Obviously you need K&R. I always liked the O'Reilly books for Unix stuff, usually because they are the thinnest. I hate thick computer books because they never get read. You should also learn how to use the man pages.
Vim vs. Emacs is a religious choice. If you ask any Unix guy what is the best, he will invariably tell you the one he learned first, because chances are he never learned the other. In my case, I've been using Vim so long that my escape key is worn out and the commands are hard-wired into my brain. Obviously, I think it's way better than emacs (which I never learned!) If you are lucky enough to have a Mac as a work station, install mac vim. It's great.
Make is complicated enough so that you will never really master it. Just learn enough to compile and link your program. You can always learn more if you need it.
Version control is an interesting question... I use RCS for small stuff. Like vi, it is on every Unix machine. For really big projects, I use subversion, but like editors, most people use whatever they learned first. Git people will say its the only one to use, etc.
Command line debuggers are a pain, which is a main selling point for Xcode. I've used gdb, but I don't remember it as a pleasant experience. Its been so long since I used it, I can't even remember how to start it up. There must be better debuggers by now. Try google.
Bottom line, all the things you mentioned are big topics. You need to take realistic bites of each and not get tangled in the weeds. It can take years to master them all.
Finally, I'd stay as far away from C++ as possible! Objective C is much better. Personal prejudice!
I'm currently learning C from some Harvard screencasts. They're great. I'm currently, because I'm used to it, using this process for running my code:
Type it it TextMate
Save it
gcc filname
run "./a.out"
goto 1
Is there a major process, program, or best practice I'm missing here? I've tried apple-R in TextMate, but to compile something bare-bones like...
#include <stdio.h>
int
main(int argc, char * argv[])
{
int x = 342;
int y = 92;
int z = x + y;
printf("these values added are: %d\n", z);
return 0;
}
...takes 4 seconds which is clearly no good. Is there a great environment/compiler shortcut, or anything else I could be doing to make the actual testing more streamlined?
Thanks!
I use text mate and gcc in the terminal. I find Xcode too bulky for small commandline programs in C. It's great if you want to do cocoa GUI applications, need a quick Apple API reference or want a graphic frontend to gdb etc. 4 seconds sounds excessive for the program you have above, but it's probably due to Textmate cmd-R shortcut. I have never used that for anything else than scripts. But I agree that you should install Xcode, it's on your Mac OS install disk.
I disagree if you want to code ANSI C then this is what I'd suggest. Get familiar with a more powerful text editor, be it vim, emacs or whatever. I prefer vim.
See here:
http://macvim.org/OSX/index.php
Now, you should try to setup GNU Make for Mac OS X.
Doing this you will learn the methods most C programmers have used for ages. I think you'll get a lot more out of this than using Xcode straight out. With Xcode you want to make sure you are doing C and not Objective-C.
Now, with an editor like vim, you can do everything from a single terminal and waste fewer cycles switching around in your workflow.
So your workflow becomes:
$vim foo.c
(save)
$make
$./a.out
If you want to do any serious C programming that has any relevance to the UNIX envirnoment (and I suspect that Harvard course does), you will need to learn make at some point.
Install Apple's development tools, and use the XCode IDE. It may or may not increase your compile time, but it will greatly decrease much of the pain of hand coding and compiling on the command line.
To create a simple command-line C program (like the one you're describing above) do this:
File->New Project
Choose Command Line Tool as the project type.
The template includes a "hello world" program with a main.c file.
Edit the main.c file to include the code you're working on.
Run the project by choosing the Build and Run button.
**be sure to open the Console to view the output of your program. (Run->Console)
Good luck!
As mentioned before, XCode is the Mac way of doing it.
Just to give you an alternative solution, you can also use vi/vim from within a terminal. You open the file for the first time by typing vi filename.c. Then you type :w to save the file, :!gcc filename.c to compile it and :!./a.out to run it. The exclamation point does the trick of calling a shell command, so the last two commands can be replaced by one :!gcc filename.c; ./a.out . You also have a command history ("arrow up", "arrow down") from within vi, after pressing the colon.
Getting used to vi is a different story...
Try to build with gcc -Wall -Werror and try to understand and fix your warnings. That is always good practice.
I wouldn't recommended switching to XCode unless you need to use the debugger. GDB integration with XCode is pretty nice, and non-existent with Textmate.
To improve your Textmate workflow for smallish projects, learn to use make and install the Makefile bundle for Textmate. You can find it on GitHub.
This will give you a new Build ("Command-B") option in Textmate that will run make, parse the output, and let you easily correct compile time errors.
I think you should continue what you're doing. 4 seconds isn't that much time to wait, especially once your programs grow more extensive. Just using a basic text editor and gcc will let you master the basics of C. Once you're ready to start making GUI apps, then I would suggest to start using XCode to take advantage of the tools to make those kind of applications. I think an IDE is overkill at this point.
There should use Emacs or Vim with a Makefile. They can do anything.
For example, in Emacs, compiling is as simple as M-x Compile (But of course you could bind any key to it). Emacs is also cross-platform (Unlike XCode and TextMate).
Emacs also provides various other features useful for debugging (Built-in gdb support, ability to parse compile output, etc)
Using an IDE-Specific build tool is the exact wrong way to do things (Especially if that IDE happens to be platform specific, like XCode and TextMate)
I have learned C and I would like to start to improve open source software. I would like to hack away one irritating bug in GTK+. To see the bug I need to use Gedit.
How can I download the sources of GTK+ and gedit and compile both of them so that I can see where the bug is? And I have never used any debugger in Linux so is there somewhere a tutorial for that?
You can get information about downloading and compiling of gedit here:
http://projects.gnome.org/gedit/developers.html
My Debugger of choice is GDB:
http://www.gnu.org/software/gdb/
GDB is a console application that may be hard to handle for a beginner. Try an IDE like Eclipse that provides a GUI to GDB.
Almost all Linux debuggers are front-ends for or adaptations of the gdb debugger. You should therefore learn how to use this first, preferably by starting on
small programs of your own construction, not giant FOSS codebases. The gdb manual,
available from here is actually a pretty good tutorial.
The information on building and installing GTK+ should be here:
http://www.gtk.org/development.html
The sources should be here:
http://www.gtk.org/download-linux.html
You can check out gdb:
http://www.gnu.org/software/gdb/ That's a pretty standard linux debugger. I would spend time with it on something simple first, or get an IDE that uses it. Learning gdb can be worth the time though.
gdb is a dinosaur which should long since have been made extinct. Debugging is one area where (gasp!) Windows beats Unix. Having got that off my chest, I advise you to start with the Data Display Debugger (DDD) graphical front end to gdb. Yes, the GUI is quaint, but you will be far more productive, quicker, than if you start with gdb.
Also don't overlook valgrind for finding and diagnosing memory errors. The KDE project actually mandates use of valgrind; I'm not sure about Gnome.
It is possible that you won't see the bug if you download the latest gedit and gtk+ sources. It might be fixed in the latest sources or the latest sources might be different enough to not trigger your bug.
What Linux distribution are you running?
First of all I'd suggest consulting your distribution's bug database to see if someone has filed a similar bug. If you don't find anything, I'd suggest using your distribution's tools to obtain the source that corresponds to the binary that you have installed on your sytem (e.g. apt-get source libgtk-2.0 on Debian or Ubuntu).
Also, your distribution might also make a debug package available (e.g. libgtk2.0-0-dbg on Debian) which will let you run a debugger on the binary that you already have without requiring the source. While this is no substitute for having the sources, it can be useful for running valgrind or making sense out of a core file.