I know that for some code to work on computer, it should be compiled or interpreted, but some programs such as games or other desktop applications are run when clicked on. I wonder where the compiler or interpreter is. Is it embedded inside the program or there is something extremely advanced to understand?
exe programs like games are already the result of compiling. When you click on a exe, no compiler is necessary anymore. The compiler is on the computer of the developer.
Interpreted languages like Python or JavaScript need an engine to run on your computer. That is not the same as a compiler.
Related
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.
here is an interesting question that, if answered positively, would make cross compiling a whole lot easier.
Since gcc is written in C++, would it be possible to recompile the Linux gcc compiler on Windows MinGW G++ or VSC++ compiler, so that the resulting Windows executable would be able to compile c code to linux programs?
If so, what would be needed to do that?
So to simplify, here is what I want to do.
mingw32-g++ gcc.cpp -o gcc.exe
The command will probably not work because it would probably have been done before if it were that easy. What I ask is if this concept would be even possible.
Edit: thanks and expanding the question to NVCC
fvu was able to answer the question for the gcc compiler (please use the answer button next time), so if you had the same question you can thank him (or her) .
As an extention to the question, would it be possible to edit or recompile nvcc or the things it uses so that nvcc.exe can create a linux program from CUDA C code? I read that the windows variant of nvcc can only use the Visual Studio cl.exe and not MinGW or CygWin.
Is it possible to create linux programs with cl.exe? And if so, could that be used to generate linux programs with nvcc.exe?
Read the chapter on cross compiling in the gcc manual, gcc's architecture makes it quite easy to set up a toolchain where the target is different from the development machine.
I never went the exact route you describe, but I have built toolchains under Windows that target ARM9 embedded Linux machines, works like a charm - using cygwin btw. Look here for a gentle introduction. Also very useful info here.
I am not going to comment on what can be done with respect to nvcc, CUDA is somewhere on my (long) list of stuff to tinker with...
Now, can cl generate Linux binaries? The answer to this question is "sort of" : as long as the target processor is from a processor family that's supported by cl, the object files generated by it should probably not contain anything that would inhibit its execution on Linux, as they'll just contain machine code. That's the theory. However:
as Linux uses another executable format, you will need a Windows-hosted linker that understands Windows style object files (afaik, COFF), and links them together to a Linux style (ELF) executable. I never heard of such a beast, although in theory it could exist
the startup code (a tiny program that wraps around your main function) will also be different and needs to be written
and some more, eg library related issues
So, the practical answer is no, although it might be a nice summer project for a bored student :)
I have started to use Haxe to convert my ActionScript 3 projects into NME, but, I like to know please what is Neko in the world of Linux? I searched for it, I found its an animated cat!
Can any one please explain to me?
Neko for most people is nothing more than a Haxe target. That's not technically true (it does have its own language, and could potentially be a target for other languages), but for most people, Neko is one of the Haxe output targets.
In the same way the Java Virtual Machine (JVM) can be targeted from multiple languages (See the list on wikipedia), Neko is a bytecode format that can theoretically be written to from multiple languages. For Neko however, most people seem to use Haxe to create their *.n files.
For Haxe programmers, the Neko target lets you:
Write command line tools and utilities (for example, haxelib and haxedoc are written in Haxe targeting Neko)
Write web apps or dynamic web pages - using mod_neko (or mod_tora) you get a web processor with the same sort of capabilities as PHP, but a fair bit faster.
Create games with NME (which originally started with Neko, it stands for Neko Media Engine), and compile them quickly, having a target closer to what CPP has, but which compiles a lot faster and where the output is cross platform.
A runtime that is closely tied into Haxe and can be used from within macros etc - so you can use all of the neko.* classes inside Macros.
If you're only interested in targetting SWF or JS, you'll probably not have much need for Neko. But if you are writing server side code, you'll appreciate the performance, and if you are writing CPP, you may appreciate having a simple target that is dead easy and super quick to compile, and which behaves similarly to CPP.
Of course, outside of Haxe neko is it's own language... but to me at least it seems most people just use it with Haxe.
More Info:
If you want to write in the Neko language (See this tutorial) you might save your code as "myfile.neko" and compile with nekoc myfile.neko, which will compile a Neko bytecode file "myfile.n".
If you want to write in the Haxe language, you might save your file as "MyFile.hx" and compile with "haxe -neko myfile.n -main MyFile".
The "myfile.n" that is generated by both of these doesn't have human readable source code - this is the Neko bytecode. You can run it on any computer that has Neko installed by running neko myfile.n. You can turn it into an executable (that runs without Neko installed) for your platform/OS by running nekotools boot myfile.n.
Here is a tutorial on Getting Started With Neko, which covers both command line programs you write and (very very basic) web pages.
"Neko" is Japanese for "cat", which is probably why you found what you did.
Neko is also a virtual machine (a "VM") like the Java Virtual Machine ("JVM") or the .Net Common Language Runtime (".Net CLR").
Neko has a custom high-level language made as an easily targeted language backend (like C-- in a way, but not like LLVM, which is closer to an assembly language). In other words: It's something that a programming language can be translated into rather than a more involved "full" compilation (like to assembly, to bytecode, or to machine code). Neko's language can be translated into a bytecode, which is portable and is usually stored in a ".n" file.
Neko was made by Nicolas Cannasse (the same person that made the Haxe Programming language), which is probably why Haxe has a Neko target in its compiler, and the Haxe tools, such as "haxelib" use it. Because the tools are compiled into ".n" files, they only need to be built once, and then they work on any platform with the VM executable "neko" installed.
Perhaps a more interesting bit about neko, and why you should learn it for Haxe development is that it's the runtime used for compile-time macros. See this tutorial for how part of your program can be run at compile time with full access to the build machine, which means you could even do complex tasks, such as parse a data file, at compile time.
Neko provides a common runtime for several different languages, including javascript and haxe. the compiler converts a source file (.neko) into a bytecode file (.n) that can be executed with the virtual machine. you can use the compiler as standalone commandline executable separated from the virtual machine, or as a neko library to perform compile-and-run for interactive languages. neko was written by nicolas cannasse.
you can find Neko Tutorial here
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.
i have a visual C++ program which performs image matching. I am using openCV. I am looking to run the exe on a linux server. But i dont know how to compile visual C++ code in linux?
Can anyone plz help me in this regard . . .
If you did things smartly while writing the C++ code in MSVC, you isolated all platform-dependent code (i.e., Microsoft extensions to C++ and uses of Windows-only libraries) from the rest right from the start, and know exactly where to do the modifications to make it run on Linux as well.
Unfortunately, your question hints at this being your first attempt at cross-platform coding, and in that case, you probably littered Microsoft-isms all over your code, and have to pick through them one by one. Start the compiler, have a look at its error messages, and go from there. Good luck, it will be a pain, but also a very valuable lesson for your next project.
(I'm not finger-pointing at MSVC here. The very same is true for people who litter their code with GNU-isms and then want to have it compile on MSVC...)
The usual construct looks like this:
#if defined( _MSC_VER )
// Microsoft version
#elif defined( __GNUC__ )
// GCC version
#else
#error Platform / compiler not supported.
#endif
Edit: In case it is not obvious, the idea is to keep the ifdef'ed code above at an absolute minimum. Use typedef's, forwarding functions (i.e., log() to use either Unix or Windows logging), or - if all else fails - macros. Don't use the above all over the code, isolate it in a few header / implementation files, kept in a separate source folder.
You will also want to familiarize yourself with Makefiles (shameless plug: Makefile tutorial) or CMake, because MSVC project files don't work on Linux (obviously).
There's also winelib and stuff. Point your build system to using winegcc/wineg++ as your compiler, and go for it. It can compile a fairly large subset of windows programs. This should be a good option if all you need is to get one or two programs to work.