I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!
http://www.cs.umd.edu/projects/PL/druby/
Diamondback Ruby (DRuby) is a research project that aims to bring the
benefits of static typing to Ruby without compromising the feel of the
language. The main features of DRuby are:
Type inference: DRuby uses inference to model most of Ruby’s idioms
as precisely as possible without any need for programmer
intervention.
Type annotations: Methods may be given explicit type annotations
with an easy to use syntax inspired by RDoc.
Dynamic checking: When necessary, methods can be type checked at
runtime, using contracts to isolate and properly blame any errant
code, similar to gradual typing.
Metaprogramming support: DRuby includes a combined static and
dynamic analysis to precisely model dynamic meta-programming
constructs, such as eval and method_missing.
Although still in development, DRuby is already able to type small,
self-contained applications. We are working to improve DRuby’s
analysis so that it can type larger code bases, including the standard
library which is not yet supported. Most of DRuby is implemented in
OCaml, but pre-compiled binary gems are available for several
platforms from our webpage. Anyone who is interested in developing
their own program analyses for Ruby are also encouraged to check out
DRuby, as the core implementation is intended to be of general use.
If you are interested in hearing about future releases, or have any
questions or comments, please join our mailing list (see the above
webpage).
webpage).
How about the language journal all the results of running the
user-programmer’s unit tests, and use them to determine the actual types
currently in use?
webpage).
How about the language journal all the results of running the
user-programmer’s unit tests, and use them to determine the actual types
currently in use?
We do use the programmer’s test suite to augment the typing analysis
(for things like eval), but one of the main advantages of the static
analysis, is that it can determine the types used at every program
point, even those not covered by the test suite.
Looks interesting. I managed to get all the dependencies installed (I
think), but I got stuck here:
— Checking for ocamlgraph… ocamlfind: Package ‘ocamlgraph’ not
found
I can see the graph* files under /usr/local/lib, though.
Could this be because they’re called “graph” instead of “ocamlgraph”?
Otherwise I’m lost.
The way DRuby detects dependencies is by querying ocamlfind, so if
you’re installing the dependencies by hand, you need to be sure you
install the ocamlfind “META” files. For ocamlgraph, you need to run
“make install-findlib” to install these and I think that should fix your
problem.
Type annotations: Methods may be given explicit type annotations
with an easy to use syntax inspired by RDoc.
Cool. I wonder if it could integrate with yard or what not.
Dynamic checking: When necessary, methods can be type checked at
runtime, using contracts to isolate and properly blame any errant
code, similar to gradual typing.
Nice. I wonder if a psyco-like JIT could leverage this
-=r
I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!
http://www.cs.umd.edu/projects/PL/druby/
Diamondback Ruby (DRuby) is a research project that aims to bring the
benefits of static typing to Ruby without compromising the feel of the
language. The main features of DRuby are:
I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!
What’s an example of it in use? Could it theoretically be used to create
a ruby->c translator?
(i.e. here’s all my ruby–spit it all out as C for me
Thanks!
-=r
Diamondback Ruby is intended to be another development tool in the
Rubyist’s toolbox. When developing an application, you can use it to
discover bugs that may have been missed by your test suite or to verify
documentation through the use of explicit type signatures.
gotcha–it shows you paths you may not have anticipated.
Could it theoretically be used to create a ruby->c translator?
Diamondback Ruby is built on top of a framework for Ruby source code
analysis and transformation, so “theoretically” you could use that to
build such a translator. However, the framework only gives you a
representation of the Ruby syntax (not unlike RubyParser) and does not
directly reason about the evaluation of this code. Thus, a C translator
would need significantly more information about the semantics of Ruby,
as all of this would have to be encoded in the emitted C code.
Interesting. There are a few projects like ruby2c [1] that have
attempted “something like that” I wonder if, given a code base of say a
few ruby files that together make up a system, and, operating under the
assumption that the code never uses define_method or eval or
method_missing, you could convert the whole thing into C
Interesting. There are a few projects like ruby2c [1] that have
attempted “something like that” I wonder if, given a code base of say a
few ruby files that together make up a system, and, operating under the
assumption that the code never uses define_method or eval or
method_missing, you could convert the whole thing into C
Has anything similar been invented?
There have been several projects that attempt to translate high level
languages into C (e.g., the Scheme Chicken compiler). However, I don’t
know why you would want to do this for Ruby now that 1.9 uses a proper
VM. Instead of developing a compiler to target C, why not just target
the YARV bytecode? If you are trying to really optimize Ruby, then
you’ll likely want both static optimizations (generating efficient
bytecode, minimizing GC pressure), and dynamic optimizations (hotspot
JIT compilation). The latter is especially important for Ruby since you
could support for features like eval (just eject any optimizations that
are invalidated by the eval’d code and recompile as necessary). In
fact, I believe that many of the ideas that went into making the JVM so
efficient came out of the Smalltalk community’s work on optimizing
dynamic VMs.
I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!
What’s an example of it in use?
Diamondback Ruby is intended to be another development tool in the
Rubyist’s toolbox. When developing an application, you can use it to
discover bugs that may have been missed by your test suite or to verify
documentation through the use of explicit type signatures.
Could it theoretically be used to create a ruby->c translator?
Diamondback Ruby is built on top of a framework for Ruby source code
analysis and transformation, so “theoretically” you could use that to
build such a translator. However, the framework only gives you a
representation of the Ruby syntax (not unlike RubyParser) and does not
directly reason about the evaluation of this code. Thus, a C translator
would need significantly more information about the semantics of Ruby,
as all of this would have to be encoded in the emitted C code.
There have been several projects that attempt to translate high level
languages into C (e.g., the Scheme Chicken compiler). However, I don’t
know why you would want to do this for Ruby now that 1.9 uses a proper
VM. Instead of developing a compiler to target C, why not just target
the YARV bytecode?
Perhaps you can explain this slightly more so I know what you meant
exactly? As you mentioned there’s kind of two sides to the
optimizing–the initial static stuff and the dynamic “oh this has
changed let’s recompile” stuff. Ahh so you are referring to the dynamic
side when you refer to “targeting bytecode”?
If you are trying to really optimize Ruby, then
you’ll likely want both static optimizations (generating efficient
bytecode, minimizing GC pressure), and dynamic optimizations (hotspot
JIT compilation). The latter is especially important for Ruby since you
could support for features like eval (just eject any optimizations that
are invalidated by the eval’d code and recompile as necessary). In
fact, I believe that many of the ideas that went into making the JVM so
efficient came out of the Smalltalk community’s work on optimizing
dynamic VMs.
Yeah I still wish for a psyco for Ruby – wishes are cheap. I’d imagine
the first step is to get the static side going, though, hence my
focusing on that.
I suppose that’s all you’d need for “small scripts that don’t use eval
or change methods after a fixed load time”
but you’re right–being able to JIT compile [either to c, like ruby
inline, or to llvm/libjit] would be best. There have been some limited
efforts in this regard (ludicrous, jruby), but not much for KRI.
Thoughts?
-=r
I am pleased to announce that the first public release of the
Diamondback Ruby static type inference system is now available!
What’s an example of it in use?
Diamondback Ruby is intended to be another development tool in the
Rubyist’s toolbox. When developing an application, you can use it to
discover bugs that may have been missed by your test suite or to verify
documentation through the use of explicit type signatures.
Gotcha–so currently diamondback ruby is basically used to “double check
your unit tests” to make sure that there is no chance you would pass in
an object to a method that doesn’t “quack right” [i.e. wrong object
somehow]. Does it with both static and dynamic analysis. That’s cool.
My first request from such a project would be it being able to generate
the rdoc style
##% something -> something_else
for you so that it could be fed into a C translator or what not.
i.e. druby file.rb > file_with_types.rb
Cheers!
-=r
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.
