what is the workspace of Limbo?
In other words, where can i write code in Limbo and exceute it?
(like visual studio for C#,C++,VB and eclipse for Java,PHP )
Limbo is a programming language.
http://en.wikipedia.org/wiki/Limbo_(programming_language)#Hello_world
Thanks.
This link might help you:
From the link:
Inferno is not only an operating system, it is also a complete development environment, providing all the tools necessary for creating, testing and debugging the applications that run within it.
Acme IDE: includes editor, shell, advanced pattern matching tools & more
Fast Compiler: with full syntax and compile time type checking
Graphical Debugger: with full stack trace for currently executing threads
Powerful Shell: with sophisticated scripting capabilities
UNIX like commands: including bind, grep, gzip, mount, ps, tar, yacc...
Related
I'm using Emacs + Typerex for OCaml programming. I have tried OcaIDE before in Windows. It's not as nice as Typerex, but it does have a good feature: Ocaml Browser
Is there anyway to have such a browser in Typerex?
(eclipse + OcaIDE in linux might work, but I do not like it as much as typerex)
Thanks
ocamlbrowser is actually the name of a program that has been distributed with the OCaml compiler for a very long time. It is written with LablTk, maintained by Jacques Garrigue, and was inside the "ocaml distribution" (instead of an external tool) because it accessed .cmi files in ways that rely on internal details of the compiler.
So the short answer is: "yes, just call ocamlbrowser in your terminal" (assuming your distribution packaged ocamlbrowser with the compiler, which may or may not be the case; there may be a separate ocamlbrowser package instead). The look&feel of the tool may be a bit dated compared to a shiny Eclipse version, but it indeed exists and works fine.
Is there a good 'how-to' or 'getting started' guide for getting started using g++ and gdb?
Some background. Decent programmer, but so far I have done everything on Windows in Visual Studio.
I have a little experience using terminal to compile files (not much beyond a .h and 1 or 2 .cpp). But nothing beyond that.
Anyone know of a good primer on on how to get started coding on Linux?
Read some good books, notably Advanced Linux Programming and Advanced Unix Programming. Read also the advanced bash scripting guide and other documentation from Linux Documentation Project
Obviously, install some Linux distribution on your laptop (not in some VM, but on real disk partitions). If you have a debian like distribution, run aptitude build-dep gcc-4.6 gedit on it to get a lot of interesting developers packages.
Learn some command line skills. Learn to use the man command; after installing manpages and manpages-dev packages, type man man (use the space bar to "scroll text", the q key to quit). Read also the intro(2) man page. When you forgot how to use a command like cp try cp --help.
Use a version control system like git, even for one person tiny projects.
Backup your files.
Read several relevant Wikipedia pages on Linux, kernels, syscalls, free software, X11, Posix, Unix
Try hard to use the command line. For instance, try to do everything on the command line for a week or more. Avoid using your desktop, and possibly your mouse. Learn to use emacs.
Read about builder programs like GNU make
Retrieve several free software from their source code (e.g. from sourceforge or freecode or github) and practice building and compiling them. Study their source code
Basic tips to start (if a command is not found, you need to install the package providing it) in command line (in a terminal).
run emacs ; there is a tutorial menu; practice it for half an hour.
edit a helloworld.c program (with a main calling some hello function)
compile it with gcc -g -Wall helloworld.c -o helloworld; improve your code till no warnings are given. Always pass -Wall to gcc or g++ to get almost all warnings.
run it with ./helloworld
debug it with gdb ./helloworld, then
use the help command
use the b main command to add a breakpoint in main and likewise for your hello function.
run it under gdb using r
use bt to get a backtrace
use p to print some variable
use c to continue the execution of the debugged program.
write a tiny Makefile to be able to build your helloworld program using make
learn how to call make (with M-x compile) and gdb (with M-x gdb) from inside Emacs
Learn more about valgrind (to detect most memory leaks). Perhaps consider using Boehm's GC in some of your applications.
You've got a lot of things to learn. I won't give you details, but as someone who's done unix and c/c++ development for a couple decades now I'll try to give you some topics to start with.
My main advice is to start experimenting. Write the most trivial program you can in C or C++ (something that prints "Hello there, world!" is traditional) and figure out how to compile and run it from the command line. Then, once you've got a compiled version, start it up under the debugger and play around with breakpoints, printing expressions, etc, etc. Once you've got this simplest program up and running and you sort of understand what the debugger is telling you, add a class, function, struct, or whatever else feels like a good small step and go through the cycle again. You'll proceed much faster this way than if you start with a very large program.
Still at a very high level, here are a handful of topics you'll need to figure out at least a bit about. Note that the "learn by starting small" approach works well for any of the topics below.
Running g++: it has pretty good online documentation for the command line syntax, and although you're bound to find it intimidating at first, try to look for the simplest starting point.
Find a text editor to use. Vim and emacs are traditional (and very very powerful) but both have a relatively steep learning curve. If you have someone around to help you, that's so much the better. There are other alternatives, but as an emacs user myself, I'm afraid I'm not that familiar with them.
Get familiar with gdb. It's an incredibly powerful tool for understanding your program. Again, it has extensive online documentation that will repay close reading.
Some familiarity with standard unix commands will be useful: ls, cd, and moving basics of the navigating unix directories; grep for quickly searching source files.
You'll have to get used to the command line approach versus the ide approach. The former is the traditional unix developer model, where you put together the operations you want from a collection of other tools, rather than having the ide hide most of this knowledge from you.
If your project is multi-file, and especially if it's a full-semester project, you might also consider learning something about the following topics.
Make is a tool for describing how to compile and link a multi-file project so that you don't have to remember how to do it by hand each time. Make, unfortunately, has a well-deserved reputation for being tricky to use, but this is mostly true in very large projects spanning multiple directories, and there are probably good simple examples online.
I would strongly consider making use of a source code control system such as git or hg, even for a few relatively small project. It's so much safer to have an archived version of what you've done so that you can back up quickly. Both git and hg are overkill for a small one-shot project, but they are worth learning on their own. Conventional wisdom as I understand it today is that they're very similar in philosophy and core functionality, but that hg is definitely a bit more consistent at the command line level, and therefore easier to start with.
I suspect this is rather intimidating, especially if you've got effectively no exposure to a unix command environment before. I re-emphasize my first piece of advice above: learn by starting simple and experimenting. This minimizes the amount of new stuff you're having to wrap your head around at any given point in time.
Under Windows I installed MinGW and Eclipse, and created a new C++ project with the inspiring name of foo, using the MinGW GCC toolchain, and this compiles, runs and even debugs. Wonderful.
Still under Windows, I installed Cygwin, an epic undertaking that stressed my internet connection. Eventually I specified Cygwin GCC toolchain and a projectname of bar. This compiles and runs but can't do step through debugging (claims it can't find source).
Under Linux, mint13 specifically, I installed the all-singing all-dancing C++ edition of Eclipse with all the trimmings and created a new C++ project, with the even more inspiring name of baz and the Linux GCC toolchain selected. Eclipse complains that it cannot find iostream.
I am rather confused by this. If I launch a terminal window and run g++ it is found, so clearly I have at least some of the GNU C++ stuff. I don't know what is missing. Linux is a new world for me. Can anyone offer guidance?
For the record, the generated code is in a file called foo.cpp (or bar.cpp according to project name) and looks like this:
#include <iostream>
using namespace std;
int main() {
cout << "Hello World" << endl; // prints Hello World
return 0;
}
#bmargulies - I know your comment was tongue in cheek but I wouldn't use emacs in a pink fit. I'd set up SAMBA and use Textpad on a Windows workstation because I have enough to learn without unnecessarily learning to use a new text editor. The reason I chose Eclipse was a vain hope that it might provide a working baseline with an integrated debugger from which to explore the brave new world of C++ on Linux. Combined with MinGW it did provide that on Windows.
I know the big problem here is not the tools, it is my ignorance and a set of expectations from a different world. This is compounded by a lack of experience with C++ - my sole experience with C++ was using TurboC fifteen years ago.
A source of great confusion is the mechanism used to resolve library references.
A lot of projects seem to use make, which as far as I can tell is a sort of script file for compiling and linking a project or set of projects. Make seems to come in a variety of flavours and there also seem to be alternatives that use makefile as well as alternatives that don't.
[expletive] what a mess.
#Basile - I am not wedded to the use of Eclipse, and I am well aware of the benefits of scripts over point and click use of IDE configuration (not least among which is that you can source-control the build process). I thank you for your reading list. Perhaps this is a silly (or premature) question but I have to ask: without an IDE like Eclipse that integrates an editor with a build tool, is it possible to do step-through debugging?
#bmargulies - I agree with you that there's probably something wrong with the toolchain definition but I lack the background and experience to conduct a meaningful investigation of that. As mentioned above, I had varying levels of success with different toolchains under Windows, so it is reasonable to conclude that the toolchain is a significant factor in the problem. Alas, I can't choose a MinGW toolchain under Linux.
Following Norm's advice I was able to compile foo.cpp from a command line. The hello world program executes with the desired behaviour, but I still don't know how g++ knew how to resolve iostream when the fancy IDE tool didn't.
Added a few more lines of code to foo and compiled it, to try out gdb. It works! Whoever would have imagined you could do step-through debugging with a teminal window! It's a bit clumsy though.
While Basile is clearly correct that a fancy IDE is not necessary, that's a bit like saying that I don't need my motorcycle because I can walk. I'll have a look at the other IDEs mentioned, but I suspect they will all make use of the same toolchains and therefore all be similarly afflicted by whatever I have misconfigured.
Basile, forgive me for moving the goalposts. My original goal was indeed "compile and run hello.cpp" but gdb was inevitably the next step. It works, and if this were the early 80s using a teletype at uni I would probably be pretty happy right now. But it's not the early eighties and I've spent the last decade with syntax-colouring, autocompletion, variable sniffing edit-and-continue debugging so (ungrateful sod that I am) now I want, well, everything!
I've used eclipse c/C++ version before and had a lot of the same problems. For me, eclipse was very difficult to work with. I would recommend using the command line to compile c/c++ programs to start with. Its easier and important to understand how executable are created, in my opinion.
g++ -Wall -g Hello.cpp -o Hello
will produce an executable Hello. -Wall is a option that gives you more warnings when you are compiling your programs. Some warnings will crash your program if you don't fix them so its nice to see them up front. -g gives you the debugging symbols so that gdb will be able to step through the program step by step.
When you do get into gdb by using gdb Hello you can check out this gdb cheatsheet.
Once you start writing programs with more than one source file you're going to need to understand the two main steps in compilation. The first step turns each individual source file into an object file. The next step links all the object files together to make an executable. This link might explain compiling and linking, obviously wikipedia is also a good source for that info.
You don't need a fancy IDE like Eclipse. The usual way of developing under Linux is to use several tools.
Use an editor like emacs or gedit to edit your helloworld.cpp file. Type emacs or gedit in your terminal to start the editor (possibly followed by helloworld.cpp i.e. the name of the edited file[s]).
Then, compile with the following command
g++ -Wall -g helloworld.cpp -o helloworld
that you type in your terminal. Improve your code till no warning is given. You might add -O after -g above if you want GCC to optimize (and -O2 or -O3 to optimize even more). You should ask GCC to optimize if you want to benchmark or release your binary executable program. Notice that g++ knows how to link the standard C++ library (libstdc++.so), and the headers are located in a standard location known to g++ (you could add a -v argument to g++ to make it show what is happenning). You'll need more arguments if you want to use additional libraries.
the order of arguments to g++ is important, particularly for -I options (include directories) and -l (libraries).
If you want to debug your program (avoid asking optimizations to GCC), type
gdb helloworld
which will run the debugger. Learn more about gdb (of course you can do step by step with gdb; you'll use the next, step, break, backtrace commands of gdb at first, and others -e.g. watch is very useful sometimes.)
If you want to run your program without a debugger, just type
./helloworld
Later, you'll want to develop a program in several compilation units. Learn to use a bulder like make for that. There are other builder programs, like omake and many others.
Read more about GCC (providing g++), Gnu Make, GDB (the gnu debugger), Emacs, GIT version control
I have configured my emacs to run make inside it by pressing the F12 key. You can compile under emacs if you want to.
For graphical user interface applications coded in C++, learn to use Qt.
PS. Linux is much more command line oriented that other systems. Believe us, this has incredible strengths. But it is a different way of working that on other systems, such as those sold by Microsoft.
PS. If you are fond of IDE, you could consider geany, anjuta, kate. However, few free software - coded in C or C++ - in a typical Linux distribution (Debian, Ubuntu, Fedora, ...) are built using these (or with Eclipse, which on Linux is often related to Java development). IMHO, this is significant.
Ok this is a 2 parter.
First of all, this may sound stupid, but are all Unix Commands on Linux Distros? Does any Linux Distro add any.
And commands like....pwd or......ssh, like what are these "written" in programming language wise. C?
Second part, What is a good book that lists and explains all the Unix commands (or at least most of them)
thanks
The biggest difference you will find
between the Unix (and its
derivatives) and Linux commands are
the options that exist for those
commands. Specifically, the GNU
versions tend to add more
functionality to their commands but
their use is not portable to non-GNU
systems like BSD or Unix.
A common example of this would be
the GNU sed -i option which allows
you to do an in-place edit on the
file. Non-GNU versions of sed
require you to first write to a temp
file then copy the temp file over
the original.
In order to help define what is
portable code and what is not, there
are the
POSIX
and
SUS
specifications. Any shell which
claims to be POSIX compliant
guarantees that any code written
against the POSIX standard will
perform identically. The bash
shell is a POSIX compliant shell but
that doesn't mean all bash
commands are POSIX compliant.
For your second question, yes, most
commands in binary form were
written in the C language.
Sometimes you'll find certain
commands that are written in
scripting languages such as perl,
python or bash. The rename
command is one example that exists
in both perl and binary form
written from C.
For your 3rd question on Book
Recommendations, see this SO
question
Not all linux distributions come with one and the same set of commands. There is, however, The Single UNIX® Specification, which lists canonical commands and utilities.
In short: The majority of programs is written in C.
Again, take a look at The Single UNIX® Specification to get an overview. Once you have opened a terminal with a shell, just press Tab - this will yield a list of commands on your machine.
$ # press
Display all 3358 possibilities? (y or n)
Most commands have man pages, too, if you want to know more about them.
$ man pwd
First off, I think it would be better to refer to shells here, since each *nix distro can come with numerous shells. To answer your questions:
Many commands are available on all shells, but of course each shell can add their own commands. Additionally, many programs can add their own shell accessible programs.
I found the O'Reilly book on learning unix shells to be extremely useful.
I learned much of the basics from http://linuxcommand.org/. Maybe that will help you and the price is right
And visiting it just now I see that the author has compiled it into book for free under a CC licence. Check out the description and a download link here.
1. Yes / C. 2. O'Reilly, and Apress
I. Common Commands
There is a core set of commands that true Unix and all of the Linux distros have.
For some time, the distributions have been evolving to install a set of packages, and since there are thousands and thousands to choose from, the idea of a "base system" has given way to that of a "default install". For example, some can be installed without X or graphics.
Some of the original Unix commands or rewrites of them are available with BSD licenses, and you will run into many of those on true Unix, *BSD, and on the Mac. There are also a set of GPL-licensed rewrites of the Unix commands. These tend to be quite elaborate, leading to confusing manpages, but sometimes they are considerably more useful than the original Unix program. Groff is a good example of a case where the original code has been completely superseded. In any case, Linux distros stick as much as possible to the GPL/GNU versions.
Language: The core commands are almost entirely written in C. As the C++ and C compilers have merged, a few packages are written in C++. A few are written in Posix shell code. As the distributions have grown in scope and size, more packages that are included are written in languages like Perl and Python. I presume you may see packages written in Ruby as well. (Ruby comes with the Mac now.)
II. Books
O'Reilly and Apress are two good sources for Unix and Linux publications.
III. Well, there wasn't a III but Mac OS X is built on a version of Unix. You can learn Unix perfectly well in the Terminal app on your Mac.
I've taken the plunge and installed Linux (Linux Mint 9 if that's important) on one of the boxes - and I'd like to start some small-time programming... but where to start.
My background:
Mostly LOB-applications in C#/WPF
Some XAL-basic
A wee bit of VB/VBA and SilverLight
I would like to turn to a new programming language - but still focused on desktop applications.
What I need:
An editor - preferably with good intellisense
A programming languages and the resources to get started
If anyone can point me in the right direction, I'd be happy for a little push...
EDIT:
Thanks for all the advice - I've come up with the following:
I'll start out with Python - and use Vim for the editor
I'll definetly try out Vala and Perl later and have MonoDevelop as backup editor - and if all else fails, I'll turn to C++. I've upvoted all answers as they all helped me.
EDIT2:
Okay - Vim was a bit too hardcore... Installed Cream on top.
Unlike the Windows world, where everything is designed to be Windows-only, I think it is quite typical to find that the rest of the world designs software to specifications, not to implementations. If you are developing in Java, then it doesn't matter what platform you intend to use, and Eclipse and NetBeans provide excellent tooling for Java on all platforms, Linux included. If you are developing in C++, then Boost and Qt provide excellent cross-platform support. If you need to go outside of Boost or Qt, then before delving into Linux-specific features, it is best to target the Single UNIX Specification also known as IEEE Std. 1003.1 POSIX, which will ensure that your application not only runs on Linux, but also on any UNIX-compliant operating system (including Mac OS X, FreeBSD, Solaris, and others).
As for IDEs and other editors... I think most programmers on UNIX platforms build from the commandline (using CMake, Make, scons, or some other standard build tool); however, there are plenty of IDEs with support for those that can run such tools automatically. Anjuta C++ and KDevelop are probably the easiest IDEs to use on Linux. Emacs (emacs, emacs-gtk, xemacs) and Vim (vim, gvim) provide a great deal of power and flexibility, but take a little bit more time to get used to. You might also want to consider a basic text editor such as GEdit (Gnome) or Kate (KDE); GEdit, though billed as a simple text editor, supports some more advanced coding features via a number of plugins. I don't recall whether it supports autocompletion, but it does support line numbers, automatic indenting, using spaces instead of tabs, commenting a block of code en-masse, and executing a Makefile with a shortcut.
Depends on how much you want to learn (from the easiest option to the hardest one):
Just use C# via Mono - that gives you access to most of the POSIX interfaces via Mono.UNIX, access to GTK# so you can do desktop apps, access to many linux libraries, so you can do more advanced stuff / integrate better. (you can program in Monodevelop - it's a Sharpdevelop clone, kind of VS-ish)
Learn Vala - it's a language compiled down to C, very similar to C# but closer to the bare minimum. It's gathers anti-MS people who wanted a response to C# IMHO. (never really used it, but apparently there's a Vala plugin for Monodevelop and the language itself is becoming more popular)
Learn Python - it's a scripting language. It's got bindings to most popular libraries (also GTK and QT) (IDE: anything that can edit text - you won't get good intellisense from a dynamic language anyways)
Learn C++ and QT, or C and GTK - although those are very low level languages where you will spend a lot of time just getting used to the environment. (IDE: Anjuta, Kdevelop, Monodevelop with C++ plugin, Eclipse+CDT, emacs, vim, etc. - anything goes really)
If you want "something new", but don't want to spend loads of time learning a completely new environment, I'd recommend trying out Vala. If you're more curious about different styles, go for Python, which I think has a very good tutorial for new people (but not new to programming): Tutorial or Beginner's Guide. With Python you also have an advantage of having the whole environment available in packages in any distribution, no such luck with Vala (yet).
Try perl and python and see what appeals to you. Learn bash to get around happily at the command-line. If you're feeling adventurous, give C/C++ a shot.
As for editors, this will probably spark up a holy war, but if you're using at the command line, check out vim and emacs, pick one, and lament never making friends of those in the "enemy camp." :-)
I say Python + Emacs or gEdit (what ever suits you)
Linux Mint is a KDE environment, right? That would make it pretty convenient for you to get started writing KDE apps in C++. The Qt toolkit which KDE is based on is widely considered to be relatively developer-friendly, which should make it easy for you to get started.
If you want to go on that route, I'd suggest downloading KDevelop, which is KDE's IDE (optimized for developing KDE programs, but it can handle several different languages). Alternatively, you could use Eclipse, which has C++ capability. You can find tutorials on how to develop KDE apps at http://techbase.kde.org/Development/Tutorials. (Unfortunately I think those are not as good as the documentation they used to have before KDE 4 came out, but it should be enough to get you started.)
EDIT: Come to think of it, you may want to try your hand at writing some C++ console (non-GUI) applications first, since it's probably easier to get comfortable with basic C++ before you jump into GUI programming. Given your experience, it shouldn't be too hard to pick up. Unfortunately I don't know of any particularly good resources to learn C++ with, but I'm sure that information is somewhere on this site, and KDevelop or Eclipse would work fine as an IDE for simple C++ console apps as well.
Weird that nobody suggested ALP, even if it is a bit outdated, it teached me a lot of things regarding the UNIX way of programming.
First, Learning C is a MUST!
Perl is underused for most stuff and you'll want to learn BASH Shell Scripting instead.
Grock the C code of existing (stable, well-written software) example is the Linux kernel itself! Google "Linux LXR"
Once you learn the basics to C (in Linux) the manpages are an invaluable resource. Just do man printf for information on writing characters to the screen, for example.
If you are talking GRAPHICAL GUI Programs, you need to learn GTK+ or one of the many cross-platform GUI toolkits (e.g. wxWidgets). Do not learn to program the X Windows System directly unless you are crazy.
For text editors, I like Komodo Edit and SciTE.