Is there an existing library to write code for the PIC32 in Ruby?
Currently I've been writing code in C to perform tasks on it, but I would love to use Ruby.
Thanks,
Andy
I doubt that there is an existing library for that task, but it should be possible (surely not without some effort) to extend Metasm to include a new assembler backend for your processor. It also includes a C parser/compiler.
EDIT: I just realized you are looking for a Ruby interpreter on that platform, which I hardly can believe exists.
I also doubt that Ruby on iron exists, but it would be nice to be wrong. :)
If your pic32 can handle an OS that would run Ruby, that might be an option. Otherwise you may be able to prototype a lot of your algorithms in locally run Ruby and then translate them to C on the PIC32.
Probably too late, but according to this link, mruby can run on pic32
As a consequence, the interpreter is now much reduced in size and can
be cross compiled for low cost 32-bit microcontrollers including ….
the PIC32 (MX7)! The official repository on GitHub contains already
examples for a few embedded platforms including the chipKIT MAX32!
https://github.com/mruby/mruby
Related
Current status of truffleruby says:
TruffleRuby is progressing fast but is currently probably not ready for you to try running your full Ruby application on. Support for critical C extensions such as OpenSSL and Nokogiri is missing.
Why does truffleruby need C extensions? It's built on GraalVM which is built on top of the JVM, it is in fact a fork of JRuby:
TruffleRuby is a fork of JRuby, combining it with code from the Rubinius project, and also containing code from the standard implementation of Ruby, MRI.
Can't they use JRuby world gems instead of depending on their C variants?
EDIT link to the issue on github
Running C extensions is hard because the C extension API is just the entire internals of MRI exposed as a header file. You aren't programming against a clean API - you're programming against all the implementation details and internal design decisions of MRI.
JRuby's Java extensions have exactly the same problem! The JRuby Java extension API is just the entire internals of JRuby, and you aren't programming against an API, instead you're programming against all the implementations details and design decisions of JRuby.
We plan to eventually tackle both problems in the same way - which is to add another level of abstraction over the C or Java code using an interpreter which we can intercept and redirect when required, so that it believes it is running against MRI or JRuby internals, but really we redirect these to our internals.
We think C extensions are more important, so we're tackling those first. We haven't really started on Java extensions yet, but we have started the underlying interpreter for Java that we'll use.
This video explains all
https://youtu.be/YLtjkP9bD_U?t=1562
You have already gotten a good answer by the project lead himself, but I want to offer a different point of view:
Why does truffleruby need C extensions?
It doesn't need them. But they do exist and there is code out there which uses them, and it would sure be nice to be able to run that code.
First I'll show you an example of what I am talking about: GUI Example
I've been studying Lua for around a week now, and I'm really curious of how I would do this. Basically (for now, and learning purposes), I just want to make a GUI with 2 buttons, 1 to start the specified (.exe), and one to exit the GUI.
Is this possible? How would I go about doing this? Any information would be great!
I believe you may want to take a look:
http://lua-users.org/wiki/GraphicalUserInterfaceToolkits
If you want something well know and tested I would go to Qt, if something light: FLTK.
If you are an absolute beginner, i.e. you don't have any programming experience in other programming languages, I advice you to learn Lua very well without trying to mess with GUI programming, which is inherently much harder.
When you will have a good understanding of Lua, then go for a GUI toolkit for Lua. I use wxLua so I can only give you some hints on that.
Since it is not a "native" Lua toolkit, but it is a "binding" to a well-known cross-platform GUI library (wxWidgets) you must study both the wxLua documentation and wxWidgets manual (at least to some degree).
wxLua binary distribution comes with everything needed to use it (you don't even need a separate Lua interpreter, it has its own) and contains a good number of example applications.
The following script is a trivial approximation of what you want to do, but (I repeat myself) you should really learn the basics of Lua before attempting GUI programming.
local wx = require 'wx'
local PATH_TO_APPLICATION = [[notepad.exe]] -- Windows assumed for sake of exemplification
local ans = wx.wxMessageBox( "Should the application be started?", "Hi there!",
wx.wxOK + wx.wxCANCEL + wx.wxICON_QUESTION )
if ans == wx.wxOK then
wx.wxExecute( PATH_TO_APPLICATION )
end
To run the previous script you must be sure that wxLua is installed correctly in your interpreter search path. Otherwise you must use the wxlua.exe interpreter that comes with the distribution.
Note also that wxLua interpreter (latest wxLua stable release) runs with a version of Lua 5.1, so try not to use features of Lua 5.2 in your scripts. Basic Lua syntax and semantics is almost the same, but there are some slight differences and Lua 5.2 has a couple of added features. So be careful with your learning path.
IUP should be the easiest way to create a GUI with Lua. However you will meet a brick wall if you try to install IUP on Linux. You have to hope someone has pre-installed it or someone has pre-written an install package for your version of Linux. If you want other people to be able to run your code later it will be virtually impossible to set things up in reasonable way. That is really an error by the Lua/Iup team because I have no trouble in using Iup from the C programming language and it seems to be widely compatible with many versions of Linux. It is the opposite of the usual situation where it is very easy to set up a scripting language and difficult to set up a low level language like C.
Have you checked wxLua ? This is the only desktop gui framework I am aware of for Lua.
Another example is IUP:
http://www.tecgraf.puc-rio.br/iup/
It is supported for Microsoft Windows and Unix
What's the easiest way to add QR Code reading/writing capabilities to a Ruby (2.0) program (if it helps, the codes will be written to and read from PDFs)? All of the gems I've found seem to have not been updated in quite some time, and usually have a ton of dependencies. Are there any good options out there?
https://github.com/smparkes/zxing.rb
YMMV, I'm the author. But I'm also the primary C++ maintainer of zxing and I use zxing.rb for a lot of testing so it should be as up-to-date as the C++ port is.
No comment on the number of dependences: they're not a barrier for me, obviously.
Can the Ruby language be used to create an entire new mobile operating system or desktop operating system i.e. can it be used in system programming?
Well there are a few operating systems out there right now which use higher-level languages than C. Basically the ruby interpreter itself would need to be written in something low-level, and there would need to be some boot-loading code that loaded a fully-functional ruby interpreter into memory as a standalone kernel. Once the ruby interpreter is bootstrapped and running in kernel-mode (or one of the inner rings), there would be nothing stopping you from builing a whole OS on top of it.
Unfortunately, it would likely be very slow. Garbage collection for every OS function would probably be rather noticeable. The ruby interpreter would be responsible for basic things like task scheduling and the network stack, which using a garbage-collecting framework would slow things down considerably. To work around this, odds are good that the "performance critical" pieces would still be written in C.
So yes, technically speaking this is possible. But no one in their right mind would try it (queue crazy person in 3... 2...)
For all practical purposes: No.
While the language itself is not suited for such a task, it is imaginable (in some other universe ;-) that there a Ruby run-time developed with such a goal in mind.
The only "high level" -- yes, the quotes are there for a reason, I don't consider C very "high level" these days -- language I know of designed for Systems Programming is BitC. (Which is quite unlike Ruby.)
Happy coding.
Edit: Here is a list of "Lisp-based OSes". While not Ruby, the dynamically-typed/garbage-collected nature of (many) Lisp implementations makes for a favorable comparison: if those crazy Lispers can do/attempt it, then so can some Ruby fanatic ... or at least they can wish for it ;-) There is even a link to an OCaml OS on the list...
No, not directly
In the same way that Rails is built on top of Ruby, Ruby is built on top of the services that lower layers .. the real OS .. provide.
I suppose one could subset Ruby until it functionally resembled C and then build an OS out of that, but it wouldn't be worth it. Sure, it would have a nice if .. end but C syntax is perfectly usable and we already have C language systems. Also, operating systems don't handle character data very much, so all of the Ruby features to manipulate it wouldn't be as valuable in a kernel.
If we were starting from scratch today we might actually try (as various experimental projects have) to use garbage collected memory allocation in a kernel but we already have OS kernels.
People are making investments at the higher layers rather than redoing work already done. After all, with all the upper level software to run these days, a new kernel would need to present a compatible interface and the question would then be asked "why not just run the nice kernels we already have?".
Now, the application API for a mobile OS could indeed be done for Ruby. So, just as Android apps are written in Java, RubyPhone apps could be written in Ruby. But Ruby might not be the best possible starting point for a rich application platform. Its development so far has been oriented to server-side problems. There exist various graphical interface gems but I don't think they are widely used.
basically yes, but with a big disclamer .. which is basically Chris' answer but a different spin on it. Since for kernel performance it would kinda suck to use ruby, you'd probably want to build around a linux-ish kernel and just not load any of the rest of the operating system. This is basically what Android does: the kernel is a fork from Linux (and is maintained close to linux), the console is a webkit screen, and the interpreter is Java with some Android specific libraries. IE, Android is Java masquerading as an OS, .. you could do about the same thing with Ruby instead of Java and only a smallish hit to performance from java
While building a whole OS from scratch in Ruby seems like
a multi-billion project (think of all the drivers), a
linux kernel module that runs simple ruby scripts does
make sense for me - even it was only for prototyping
new linux drivers.
In Python, if I want to give out an application without sources I can compile it into bytecode .pyc, is there a way to do something like it in Ruby?
I wrote a much more detailed answer to this question in the question "Can Ruby, PHP, or Perl create a pre-compiled file for the code like Python?"
The answer is: it depends. The Ruby Language has no provisions for compiling to bytecode and/or running bytecode. It also has no specfication of a bytecode format. The reason for this is simple: it would be much too restricting for language implementors if they were forced to use a specific bytecode format, or even bytecodes at all. For example, XRuby and JRuby compile to JVM bytecode, Ruby.NET and IronRuby compile to CIL bytecode, Cardinal compiles to PAST, SmallRuby compiles to Smalltalk/X bytecode, MagLev compiles to GemStone/S bytecode. For all of these implementations it would be plain stupid to use any other bytecode format than the one they currently use, since their whole point is interoperating with other language implementations that use the same bytecode format.
Simlar for MacRuby: it compiles to native code, not bytecode. Again, using bytecode would be stupid, since one of the goals is to run Ruby on the iPhone, which pretty much requires native code.
And of course there is MRI, which is a pure AST-walking script interpreter and thus doesn't have a bytecode format.
That being said, there are some Ruby Implementations which allow compiling to and loading from bytecode. Rubinius allows that, for example. (Indeed, it has to have that functionality since its Ruby compiler is written in Ruby, and thus the compiler must be compiled to Rubinius bytecode first, in order to solve the Catch-22.)
YARV also can save and load bytecode, although the loading functionality is currently disabled until a bytecode verifier is implemented that prevents users from loading manipulated bytecode that could crash or otherwise subvert the interpreter.
But, of course, both of these have their own bytecode formats and don't understand each other's (nor tinyrb's or RubyGoLightly's or ...) Also, neither of those formats is understood by a JVM or a CLR and vice versa.
However, the whole point is irrelevant because, as Mark points out, you can always reverse engineer the byte code anyway, especially in cases like CPython, PyPy, Rubinius, YARV, tinyrb, RubyGoLightly, where the bytecode format was specifically designed to be very close to the source language.
In general it is simply impossible to protect code that way. The reason is simple: you want the machine to be able to execute the code. (Otherwise what's the point in writing it in the first place?) However, in order to execute the code, the machine must understand the code. Since machines are much dumber than humans, it follows that any code that can be understood by a machine can just as well be understood by a human, no matter whether that code happens to be in source form, bytecode, assembly, native code or a deck of punch cards.
There is only one workable technical solution: if you control the entire execution pipeline, i.e. build your own CPU, your own computer, your own operating system, your own compiler, your own interpreter, and so forth and use strong cryptography to protect all of those, then and only then might you be able to protect your code. However, as e.g. Microsoft found out the hard way with the XBox 360, even doing all of that and hiring some of the smartest cryptographers and mathematicians on the planet, doesn't guarantee success.
The only real solution is not a technical but a social one: as soon as you have written your code, it is automatically fully protected by copyright law, without you having to do one single thing. That's it. Your code is protected.
The short answer is "YES",
check rubini.us
It will solve your problem.
Here is how to compile ruby code:
http://rubini.us/2011/03/17/running-ruby-with-no-ruby/
Although Ruby's 1.9 YARV VM is a byte-code compiler I don't believe it can dump the byte-code to disk. You might want to look at the alternative compiler, Rubinius, I believe it has this ability. You should note though that byte-code pyc files (and I imagine the ruby equivalent) can be pretty easily "decompiled".
Not with the MRI interpretter, no.
Some newer VM's are being worked on where this is on the table, but these aren't widely used (or even ready to be used) at this point.
If you use Jruby, you can compile your Ruby code into Java .class files (including your Rails stuff) to execute them with (open)jdk out of the box!
You can even compile your complete stuff into a .war file to deploy it on Apache Tomcat or Jboss with a tool called "warbler"
https://rubygems.org/gems/warbler/
Depends on your ruby.
JRuby - https://github.com/jruby/jruby/wiki/JRubyCompiler
MRuby - http://mruby.org/docs/articles/executing-ruby-code-with-mruby.html
MRI (C)Ruby - https://devtechnica.com/ruby-language/compile-ruby-code-to-binary-and-execute-it