In Python, after you run a program, there are caches saved in the folders named __pycache__. For futher explanation of the functionality of these folders, please see this question. Does Ruby have an equivalent of this? If not, why?
Ruby doesn't haven an equivalent. It just wouldn't make sense: Ruby is a programming language. A programming language is an abstract mathematical concept, a specification. Putting such detailed things as the name of the directory of the byte code cache in a language would be way too restrictive: what if somebody wants to implement Ruby on a platform which doesn't have files? What if someone wants to implement Ruby on a platform where underscores are illegal in directory names? What if someone wants to implement Ruby with an interpreter instead of a compiler?
There are, however, some Ruby implementations which do compile to byte code. YARV and Rubinius are two examples of those. YARV only compiles in memory, whereas Rubinius caches the compiled byte code on disk. In fact, it must have the ability to save and read the compiled byte code because the compiler itself is written in Ruby, and otherwise it would have to compile itself in order to be able to compile any code, but in order to compile itself it would first have to compile itself and in order to that it would first have to …
But that is a private internal implementation detail of Rubinius. It is not part of Ruby nor should it be.
Related
I'm working in Ruby, and realized that it would be incredibly beneficial to be able to use some of the built-in gcc functions (and x86 architecture built-ins for that matter as well). It seems like having to write an extension to use these is impractical, so I was wondering if there was a way I could call built-ins. For example, if I wanted to call int __builtin_popcount(unsigned int), on a number in Ruby, is there a way I could somehow do
a = rand(1..10000)
__builtin_popcount(a)
I know that I obviously can't do something that basic, but is there a way that I could include gcc and x86 architecture built-ins in Ruby?
It is not quite clear what you want to do.
If you want to call into GCC, you could wrap libgcc in a C extension and design a Ruby API for it.
If you want to generate native code using GCC dynamically, that is currently not possible AFAIK. There is a project for a JIT compiler library based on GCC, but I don't know what its status is. You could wrap that library into a C extension and design a Ruby API for it. At any rate, you will also have to modify the Ruby implementation you are using to be able to link dynamically generated native code with your Ruby code. (And on some implementations that is simply impossible, e.g. on Opal, which is a pure static compiler.)
And of course, not all Ruby implementations actually support C extensions; they are a non-standard feature of YARV and are not guaranteed to work or even exist on other implementations.
If I had a "host" application that was executed at some point and knew the location of some code. What would it be called if it then read that code real-time and then did the proper response such as creating a window in this code:
int main()
{
create magical mystical window()
}
I know that if a language compiled the code directly into binary it would be called a compiled language and that if a language converted the code into another language it would be called a interpreted language.
I know programming languages that read the code and convert it to another language and then compiled it would be called an interpreted language.
No, that's a compiled language with an extra step.
What you are describing is an interpreted language where an interpreter figured out what each line of code means while it is running.
Actually, you're wrong in what you know.
A piece of software that takes code and converts it to binary that
can run on the machine's OS and/or hardware directly is often called
compiler.
If the compiler produces code for a different platform than the one on which it itself executes then this is sometimes called a cross compiler.
A piece of software that takes code and executes it
directly, converting its high-level structures into low level
structures that run on the machine's OS and/or hardware is usually called an
interpreter.
A piece of software that takes code and converts it into
another set of code that can then be compiled or interpreted is
sometimes called a transpiler.
However, things aren't quite as simple as that. For example, java is interpreted but it dynamically compiles some of the code it runs, but, we still call it an interpreted language. C is called a compiled language, but a lot of compilers will turn C into assembler, then assemble that into bytecode that the processor will run. So, C is a transpiled language in reality, but we call it a compiled language both by convention, and by the fact that some modern compilers (unfortunately) bypass the assembler step.
So, for a lot of languages, what they are is determined by convention and how it's being used. But, as David Schwarz has just said in his comment to his own answer to this question:
Really, it's not a particularly good idea to describe the execution process as an attribute of the language.
After much searching, I can't figure how Ruby implements General Delimited Inputs.
All I can find is Kernel#`, which is used by %x{...}.
Any help would greatly appreciated. Thanks
This is handled in the parsing code, which is written in YACC and C. Check out the source code on GitHub. Specifically, the token that handles this type of quoting begins with tQWORDS_BEG (search within parse.y).
A detailed discussion of the YACC implementation would be long, but if you want to get started, that's where it lives in the code.
Note that the above link is for MRI Ruby. I don't know how other Ruby interpreters handle it, but they all do it in a parser somewhere, and most of those are written in C and likely use YACC to parse. Notable exceptions are JRuby, written in Java, and druby, in OCaml.
According to the official ruby About page it's easier to extend Ruby with C than Perl. I'm not a (perl) XS guy, but I find it dirt simple to write something quick and simple with Inline::C, so why is it easier in Ruby?
Writing C extensions in Ruby is easier than in Perl or Python, with a very elegant API for calling Ruby from C. This includes calls for embedding Ruby in software, for use as a scripting language. A SWIG interface is also available.
Any further explanation from those that do more C extensions would be useful.
(Full disclosure, I am a Perl programmer)
The Ruby C API certainly looks much nicer than Perl's. It looks like a regular C library with functions that correspond to Ruby code. Perl's API is a mess of macros within macros within macros and magic threading flags. Using the Perl API outside of the Perl core is certainly a secondary concern. Ruby definitely wins on not being bowel clenchingly terrifying.
While Ruby has a better C API, Perl has the better tutorials on how to do anything with it. The generated Ruby documentation lacks any sort of cohesive tutorial or often any descriptive text at all. It's possible I'm looking in the wrong place but that's all that was offered. In contrast, the Perl API documentation is hand written prose with useful information about what each function does. In addition, there's over a dozen documents in the core docs about using Perl and C. I'd say Perl wins on docs.
FFI looks quite impressive. The closest thing Perl has to FFI is Inline::C which is a wrapper around the mess of XS. It's primary use is to inline C code into your Perl program, but you can also use it to access C library functions.
Here's a trivial example similar to nash's getpid example.
use Inline
C => Config =>
ENABLE => "AUTOWRAP";
use Inline C => q{ int getpid(); };
print getpid();
Now, I am cheating because technically getpid returns pid_t on my system, but that's just an integer. FFI seems to have an awful lot of special cased code for getpid, so I suspect it's ease of use will correspond directly to whether FFI has already taken care of it. Trivial examples are trivial. It would be interesting to see what happens when typical complications arise, such as functions that return pre-allocated memory and have odd types and throw around structs.
While FFI and Inline::C can be used to do the same thing, how they do it looks very, very different. Inline::C is actually compiling and caching C code. FFI is somehow not doing any compiling. I'm not sure if that's really for real, or if the compilation is done for you at install time for common libraries.
In addition, FFI smooths the portability problems across the various Ruby implementations and their different ways of calling native APIs. This is something Inline::C doesn't have to do, and quite frankly it's amazing if it really works. One benefit is the FFI interface is much smoother than Inline::C. With Inline::C, it's very clear that you're writing a wrapper around a C compiler.
With FFI it's very easy to extend Ruby with C. This is an example from github
require 'rubygems'
require 'ffi'
module Foo
extend FFI::Library
ffi_lib FFI::Library::LIBC
attach_function :getpid, [ ], :int
end
puts "My pid=#{Foo.getpid}"
You don’t need a compiler installed on
your system to be able to run FFI
extensions. On linux, you also do not
need to install the development
versions of libraries, just the
runtime versions. Of course, the
libraries you link against will need
to have been compiled at some point,
but odds are you won’t have had to do
it.
https://github.com/ffi/ffi/wiki/why-use-ffi
This question already has answers here:
Encoding Ruby on Rails code?
(5 answers)
Closed 4 years ago.
Is there a ruby obfuscator or "compiler"?
There are a few options, like RubyScript2Exe or AllInOneRuby. However, all obfuscators of interpreted languages tend to have a serious flaw: they usually don't understand more sophisticated metaprogramming techniques.
That is, they can't necessarily tell that something like foo.send(:bar, ...) is an invocation on the bar method in a completely different library, or that eval("require %w{abc def ghi}") means to require three different libraries. These are trivial examples -- things get much more complex when you throw method_missing and its ilk into the mix.
When an obfuscator encounters this sort of code, it will dutifully compile the appropriate instructions, but it may not know to also include certain libraries or other code from elsewhere. That can cause serious issues, since the dynamically included or required will not be available at runtime in a statically linked executable.
Unfortunately, many gems and libraries use sophisticated metaprogramming techniques. You'll likely get into trouble here if you try to use obfuscation and expect your program to have the same behavior. Worse still, because there are so many levels of indirection, if a bug occurs in the obfuscated version, you may never know what exactly happened or how to reproduce it.
Depending on what you are trying to do, there is a Gem that will allow you to create a C extension from a Ruby script which can then be used as a require inside your Ruby app. Its called ruby2cext. It will obfuscate all of your code into C and the you can require the .so in a separate Ruby script and it will function like a normal Ruby script.
RubyScript2Exe - http://www.erikveen.dds.nl/rubyscript2exe/