I am not even a newbie to erlang yet, I am just using RabbitMQ, which is written in Erlang. After I run configure/make/make install, the build output directories have plenty of .c and .erl files. Is this necessary? What's the reasoning behind it?
some examples:
./lib/erlang/lib/erl_interface-3.7.6/src/misc/show_msg.c
./lib/erlang/lib/cosNotification-1.1.18/src/oe_CosNotification.erl
Yes, it's necessary. The runtime system of Erlang is written in C, and most of the standard library is written in Erlang.
What's the reasoning behind it?
What would be the alternative? In order to execute any Erlang code, you need to have the runtime system already started, and so it can't be written in Erlang. It could be written in:
Assembly
C
C++ or some other language
Erlang could be executed without a runtime
Assembly is obviously a bad choice: you'd have to rewrite it nearly completely for any new CPU target and it would be much harder to maintain.
C provides excellent performance and portability, and ability to call C code from Erlang would at any rate be required. This is the choice made not only by Erlang, but by Python, Ruby, Perl, etc. as well.
C++ complicates portability (some OSes have C compilers available, but not C++ compilers; quality of C++ compilers varies more); other languages even more so (along with performance, possibly requiring their own runtime, etc.).
The final option would make Erlang a completely different language.
Related
I've searched a lot on the internet about if Dart is a compiled or interpreted language, also I searched in the documentation and didn't get a clear answer about if Dart is compiled or interpreted or both, and how that works
Yes!
The concepts of "compiled language" and "interpreted language" are not well defined.
Dart is definitely compiled in some cases. Say, when compiling to JavaScript for the web. That translates the program to a program in a different language, while preserving runtime behavior, which is the definition of compilation. (So "compilation" is well defined!)
To be pedantic, languages are not inherently compiled or interpreted. Implementations of languages may compiling or interpreting.
When running Dart on the native VM, directly from source code, it looks very much interpreted. But "interpretation" is a much mushier concept than compilation.
The only thing which is fundamentally and unequivocally interpretation is executing code directly by interpreting the source code, with no intermediate representation.
Nobody does that, not since BASIC. It's just too inefficient.
These days, you at least convert the source code to an abstract syntax tree. That's technically a compilation (converts a program from one representation to another, while preserving semantics). Then you might compile to a different internal representation. Maybe to byte code. Maybe even to native code.
Sometimes you do all of these, doing just-in-time compilation to the next level when optimization calls for it.
The Dart VM compiles source code, through a number of steps, into native machine code. (Which is then interpreted by the CPU.)
Whether that counts as "interpretation" or not is really a philosophical question.
From the outside, it matches one of the definitions of interpretation ("program goes in, runtime behavior occurs", as opposed to compilation which is "program goes in, other program comes out").
Internally, the VM is very much considering itself a compiler.
I know these technologies are all related but could someone please explain what each one is used for and how they fit together?
Oversimplification:
Graal - Java bytecode compiler. Can be used just in time (as part of a JVM) or ahead of time.
SubstrateVM - other things (runtime) needed to actually run ahead-of-time compiled Java bytecode without a JVM. This powers the "native-image" command of GraalVM.
Truffle - framework for implementing languages as AST interpreters which can be just-in-time compiled using graal. Some notable languages implemented are JavaScript, Ruby, R and LLVM bitcode.
GraalVM - most of these technologies packaged together in order to support different use cases, for example: running JVM programs (i.e. anything that compiles to Java bytecode) using Graal as the JIT compiler for better peak performance, ahead-of-time compiling JVM programs for fast startup and low memory footprint, running fast dynamic languages (JS, R, Ruby) that can interoperate without overhead, and so on.
Is there any VM for Erlang that allows you to do compilation on the fly instead of compiling before?
There is a possibility to compile from the shell, thanks Martin.
Now, from the Erlang shell (or some other module!):
1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe
Is there any pros or cons with doing this?
Will you still be able to hot swap code?
Is it the regular use-case to handle code?
What benefits does the compiler give you in the end then?
From the Erlang shell, you can compile a module on the fly using c("path/to/module.erl"). You can also access this functionality through the compile module, specifically the compile:file/{1,2} functions.
For example, suppose we have a file mymod.erl:
-module(mymod).
-export([myfun/0]).
myfun() -> io:format("Hello Joe~n").
Now, from the Erlang shell (or some other module!):
1> compile:file("mymod.erl").
{ok,mymod}
2> mymod:myfun().
Hello Joe
See Erldocs on the compile module for more information.
You can do a great deal with the Erlang compiler in runtime. For example, you can dynamically generate code for a module (use erl_syntax!) and then compile it without even writing it to a file using compile:forms/{1,2}.
(Insert standard speech on great power and great responsibility.)
Will you still be able to hot swap code?
Yes.
Is it the regular use-case to handle code?
No. Normally Erlang code is compiled ahead of time into BEAM bytecode. Depending on whether Erlang was started in embedded or interactive mode, the modules are either loaded on startup, or dynamically as they are referenced. If you are building a release, you basically have to compile ahead of time.
What benefits does the compiler give you in the end then?
Well, for one thing, we can build compact releases without unnecessary components like the compiler. Of course, we also get all the traditional benefits of ahead-of-time compilation, particularly that of not having to waste time compiling all the time.
To sum it up, unless you fully understand the implications and have a very good reason not to compile your code ahead of time, please follow the standard practices.
The Erlang VM can only run compiled code! If you want to interpret Erlang code then you need an interpreter. The module erl_eval implements an Erlang interpreter and is part of the standard Erlang/OTP distribution. It is used by the Erlang shell to interpret the expressions entered.
All code handling in the Erlang VM, whether compiling, loading or updating, is done at the module level so it is impossible to compile or load a just one function. The Erlang compiler is written in Erlang and always available and can compile to either a file or a binary which can be immediately loaded into the system. As #MartinTörnwall has pointed out compiling a module from the shell using c(module) is in essence compiling on the fly.
So there would be no problems in automatically compiling code on the fly when it is used, at the module level. It is just that the current system is not designed to work that way and by default when it tries to load a module it only looks for the pre-compiled object file, the .beam file.
Erlang has an interpreter escript. Entire Erlang archive can be written in script. Almost all features are available.
By default, the script will be interpreted. You can force it to be compiled by including the -mode(compile). in the script.
Though it depends on the way you design your application, regular practice is to have .erl files which are compiled and run than having escript files.
So now you have many options.
Compile .erl file to .beam using c(my_module) this auto loads the .beam file. So the existing VM can run it on the fly. On in code you can use compile module functions like file, purge and load to load and run it on the fly.
Compile and keep the .erl files using erlc, erl -make, rebar, etc (Erlang has rich support) and then run it. You can build archives, boot scripts, rel etc to manage running and release of the Erlang software. This usually is the practice for production.
Use escript and run everything in interpreted mode.
Use escript and give -mode(compile) option to tell Erlang VM that at runtime (when starting to run escript) compile the code and run the compiled code (in memory)
Is there any pros or cons with doing this?
Compiled code is faster than interpreted code. I dont see any other right now in Erlang as pretty much everything is supported in both. Erlang even supports combination (Calling compiled code from interpreted code)
Will you still be able to hot swap code?
Yes in all cases. Your code also should be able to handle this.
Is it the regular use-case to handle code?
Option 2 for production. Option for 1 for learning / simple development. Option 3 and 4 in need basis for specific requirements (May be one time running).
What benefits does the compiler give you in the end then?
To make it clear, erlc program provides a common way to run all compilers in the Erlang system and compile module gives an interface to Erlang compilers. Compiler gives intermediate binary .beam file which helps in running Erlang code faster than interpreted counterpart. They also catch syntax errors (compilation errors).
How can I build and compile my own Lua files on Windows? And make them executable.
I am reading Beginning Lua programming, and I have Windows 7 and MacOS Lion both installed. I am having the hard time to follow the instructions. They do not work for me.
On MacOS I open the terminal and put these in:
export LUA_DIR=/usr/local/lib/lua/5.1
mkdir -p /usr/local/lib/lua/5.1 (it tells me, mkdir: illegal option) and I can not follow from here
SET LUA_DIR=”c:\program files\lua\5.1”
As for Windows I do this according to the book.
This what I see in my shell c:\Users\bd>
mkdir "c:\program files\utility" and it tells me access is denied
I have tried to right click on this folder and check off read only, but it does not work.
Any clues would be appreciated, this part has been really confusing for me.
To package your Lua files into an executable on Windows you have several options. There is srlua, there is wxLuaFreeze from wxLua (available as a binary for Windows), and there are more options in this SO answer.
Essentially, the main two options are: (1) append your Lua code to a precompiled exe file, such that it will be loaded and executed when that exe file is run, and (2) convert your Lua code into real executable by compiling it to bytecode, then to C, and then to your target platform.
As to your MacOS issue, mkdir -p means that mkdir is asked to create intermediate directories (for example, you asked to create /a/b/c, it will also create /a/b if those don't exist). As you don't say which version of MacOS you run, it's difficult to provide more detailed answer.
For now the standard distribution of Lua does not compile a script to native executable code; it execute your scripts by first compiling it to bytecode, then by interpreting the bytecode with a reasonnably fast static interpret (this also means that it is easily portable across native or virtual systems, and very resistant to attacks (that could be targetting bugs in the native compiler itself).
Also Lua still does not feature a runtime JIT compiler like Java and .Net: Lua still does not features a VM to produce a safe sandbox.
There exists Lua packages that convert your bytecode (or directly a source script) to a C source that can be used to convert a Lua library into native mode via the same C compiler used to compile the Lua engine itself (this is how the builtin libraries are produced, though they are slightly optimized manually in some time-critical parts).
However it is possible to compile Lua to a javascript source, and run it with fast performance using Javascript, because today's Javascript interprets do have good performance with their implemented VM featuring a JIT compiler for their own bytecodes.
It is also possible by converting it the Lua bytecode to a .Net or Java source that can then be executed directly from Lua (for that you need a version of Lua that has been ported to .Net or Java or Javascript, something that is not so complicate than developing in C/C++ directly a VM with a JIT compiler (a moderately complex part is the bytecode verifier, but the really complex part is the memory manager its garbage collector and its sandbox so that your Lua script will be fully isolated from the Lua engine itself for itw own memory, but the most complex part if the runtime optimizer and collection of profiling statistics: this has been done in the modern VMs for Java, .Net, Javascript, PHP/Zend, Python, Perl...).
I dont know which other language VM would offer the best performance to port Lua and implement on it a compiler to their own bytecode running at near native speed in their VM. But my own small experience with programs (in a much simpler language) self-generating a bytecode that they can run themselves, has always shown me Java winning in performance over .Net and Javascript. This is most probably because Java features an profiling-based dynamic code optimizer
(On the opposite the .Net optimizer runs only once during program installation, using some profiling data collected during the installation of the .Net VM itself, or at first instanciation of the script, without really knowing any profiling data collected during execution of the compiled program itself, and based on some cheked assumptions about the platform capabilities).
I also don't if would be faster in PHP, Python or Perl; the comparison with newer Javascript engines was never attempted though. Porting/compiling a Lua program to Javascript is relatively easy because it implements closures relatively easy for the resolution of linkages. Then the generated Javascript will compile to native code with the excellent Javascript's JIT compilers we have today (and never cease to improve in performance, so much that I've seen various appliactions running now faster in Javascript than before when they were written in C++ or plain C; as well the memory footprint has largely been reduced, we no longer have memory leaks, and even if there's a garbage collector, today's Javascript VM have a very efficient one, which is even better than the GC implemented in the native Lua).
But Lua remains useful as it is easy to secure and sandbox and offers various security benefits (but there are security issues in Lua as well for some kinds of applications, where Javascript offers some solutions, notably for side-channel attacks based on variation of time of execution; but these side-channel attacks are very hard to solve and can affect any system, any program, any programming language, and this starts becoming a critical issue because they are now more esily exploitable; the reason of that comes from hardware optimizations that we depend more and more today when we want to maximize the performances). And with Lua you may be more immune to these problems that a sandboxing sofware environment cannot solve alone.
Probably later we'll see a true VM implementation of Lua with a JIT and self-generating code and the possibility to instanciate new sandboxed VMs to run their self-generated code. It will take more time to generate an EXE file for distribution; notably because it generally requires adding also an installer and a distribution manager.
So for now we could imagine distributing Lua applications compiled to the bytecode of another JIT-capable VM: this generated bytecode would be faster than the Lua bytecode, and would then be extremely complex to reverse-engineer to the semantics of Lua because it would require two separate reverse engineering first from the bytecode of the other VM to the bytecode of Lua, both bytecodes loosing some easiy inferable rules and options tested and foll, and then again to sme Lua source
For the OSX terminal issue:
This command should work
export LUA_DIR=/usr/local/lib/lua/5.1
This command will probably give you permission problems:
mkdir -p /usr/local/lib/lua/5.1
You may try this to solve that. You will be prompted for your password:
sudo mkdir -p /usr/local/lib/lua/5.1
This command has nothing to do with OSX and will not work. This is a windows command:
SET LUA_DIR=”c:\program files\lua\5.1”
You have a permissions problem with Windows- try creating your cmd or PowerShell in Administrator mode. C:\Program Files is a protected directory that a regular user account doesn't have permission to write to.
As for the OS X issue, check out the mkdir OS X manual page to make sure you have the command correct.
So, if I understood your question correctly, you are trying to build Lua on Windows.
This is of course possible, but not easy for beginners. I would highly recommend you to use a binary distribution, which is much easier to install, unless you have special requirements.
Here are several Windows distributions :
Lua Binaries (Lua 5.1 and 5.2)
LuaForWindows (Lua 5.1)
LuaDist (Lua 5.2)
From the Wikipedia defination,
Programming language is
Scripting languages are languages that allow you to send commands directly to a system that executes these commands. These commands are read line by line and executed-interpreted, but not compiled.
Whilst, Scripting language is
Programming languages are languages that allow you to create a program by writing structured code that is read all at once by the system, checked for errors, and translated into an unreadable format that the machine can then execute(compiled).
ActionScript is now quite developed language(Which runs after compilation not interpreted) and after ActionScript 3,Flex and Air, Its hard to believe ActionScript is still dubbed as Scripting language.
The line between a programming language and a scripting language is blurry. Once upon a time, a "programming language" was a compiled language like C or C++, because only those languages were really efficient enough to write non-trivial programs in. Scripting languages were languages that were typically not compiled and thus slower; their relative inefficiency relegated them to systems maintenance tasks or "gluing" parts of a compiled program together. Now, computers are getting faster and language interpreters are getting more advanced, so even a traditional "scripting" language like Python or Tcl can be used to write a full-fledged application. However, once a language is dubbed a scripting language, it's hard to shirk off the title.
Don't believe everything in the Wikipedia.
PHP for example is compiled into bytecode at runtime, while java is compiled into bytecode at compilation time. The php interpreter executes the bytecode, and the java VM executes its bytecode both doing about the same thing.
A bash script is not compiled at all and is interpreted run line by line.
C is compiled into machine code that is read directly by the hardware.
According to the wiki entry, only the bash is truly a script which is a misnomer.
It is much more nuanced than the wiki entry implies.
JavaScript is a scripting language in browsers because it scripts the browser.
Bash is a scripting language because it scripts the OS.
Python and ActionScript are called scripting languages because they share things in common with real scripting languages (dynamically typed, sometimes interpreted, higher-level than C). I think "scripting language" as a term is far too over-used, and is mainly used to put down dynamically typed languages.
Reading the definitions above, the machine can't execute the format that the Flex compiler creates, therefore ActionScript is a scripting language.
Of course, anything that compiles to a VM would be considered a scripting language by that definition, including Java. Forth, being a threaded interpreted language, would also be a scripting language.
So forget Wikipedia. These distinctions used to make more sense than they do now.
JavaScript is getting faster monthly, and will probably soon be faster than ActionScript, if it isn't already.
I'd say a better definition for "scripting language" is, "a scripting language controls an application or enclosed environment, like a browser or a word processor or Flash."
But with the Chrome OS, even that definition is in peril, as the browser (including Flash, which Google has embraced) threatens to become an OS.