I recently started using OCaml on my Windows machine and I have been using cygwin for compilation and execution of my programs. I recently had to create a program which takes user input from stdin using Lexing.from_channel stdin. The Problem I am running into is that I type in the input, but nothing happens. After checking out some things I found that there is no indication the input is being finished so the program is just waiting on more input. I have tried ctrl-D after I type in the input and nothing happens and ctrl-z which just displays Stopped and ends the program. Additionally, when i use these keys cygwin will often crash. Does anyone have an idea on how to indicate end of input for user inputs in OCaml?
My personal recommendation: if you can access Unix or Mac OS X, use them. Using OCaml over Windows is pain unless you get paid for it. Using OCaml in a virtual Unix environment like VMWare is another option.
Currently we have 3 OCaml flavors in Windows: Native MS, Native MinGW and Cygwin. See http://caml.inria.fr/distrib/ocaml-4.01/notes/README.win32 for details.
Any question about OCaml in Windows, you must first state clearly which flavour of OCaml you use. I suspect you use MinGW OCaml over Cygwin. With this combination I have the exactly same troubles you have described.
Ctrl-D is not considered as closing stdin in MinGW OCaml, since it is Windows console app.
Ctrl-Z is to close stdin in MinGW OCaml, but it is first fetched by your Cygwin terminal, then it suspends the process
Once 'Stopped' by Ctrl-Z, normally the OCaml process and the terminal go into strange states and you have to kill them. (I want to walk away from it, rather than tracking what is really happening.)
If you execute your MinGW OCaml apps over Command Prompt, your stdin works fine.
If you prefer Cygwin and your work does not involve with selling your binary executables, using Cygwin OCaml is the way to go. But still, there are very few people working there. I am afraid that any Cygwin OCaml specific questions may not be answered even in StackOverflow.
Maybe my view is too pesimistic. I hope some OCaml + MingW experts would give some more insights.
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.
Is there some graphical shell like ghci for Haskell and Linux? I know about Winghci and it is very good interpreter but it is Windows only.
Regarding "what does WinGHCi do that GHCi does not?":
The command prompt, user input and program output are different colours. I can't begin to tell you how helpful this is when you're scrolling through huge pages of text trying to find the last command you typed. I wish more Haskell programs would produce coloured output...
You can load files using an actual GUI, rather than having to memorise a 200-mile long file path.
It has a whole bunch of buttons and menu items for common operations, which can be useful if you're new to GHCi and don't know the corresponding command names.
On Windows, terminal windows look horrifyingly ugly, while WinGHCi does not. Whether this problem exists on Linux is a matter of opinion.
Regarding the actual question asked: I'm not aware of any nice GUI tool for GHCi on Linux. Probably the best you can do is use the Emacs operating system; I'm sure somebody will have built some kind of GHCi support for that by now...
ghci runs fine on Linux, although I don't know of any graphical versions of it.
A few options if you want more features:
Use a powerful terminal emulator
Integrate ghci into your editor with something like 'Emacs Haskell Mode' or 'SHIM for Vim'
Have you heard of HUGS ? I only used it for Windows, but on the website you can download it for some Linux distributions, too.
It's a long time ago since I used it, but as far as I can remember it was an easy to use but powerful and fairly good documented interpreter.
hope this helps
Does anyone have experience using SLIME on the console for Common Lisp? I'm trying to go through Practical Common Lisp but the commands in the book don't seem to work for the console version of emacs/SLIME. I suppose my question is: is there somewhere where I can find documentation specifically for SLIME on the console? Or if you have a suggestion for a completely different approach on the console, I'm all ears.
I assume you mean running slime with emacs on the console ie without X. Slime requires emacs (eq slime 'superior lisp interaction mode for emacs').
I ran it with emacs -nw (which just uses the terminal and no X facilities that I can see) and slime worked fine (Ubuntu 10.04 X86-64).
Are you running in emacs?
Is slime set up in your .emacs file?
Did you start slime via alt-X slim?
Tell us more about what you did and what you have set up and what output you get and we may be able to help more.