help-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Translators in Ruby


From: Wolfgang Jährling
Subject: Translators in Ruby
Date: Tue, 8 Jan 2002 02:57:48 +0100
User-agent: Mutt/1.0.1i

Hello, world!

I want to write translators in the Ruby programming language, so I thought
about what would need to be done to achive this. Probably I got several
things wrong, so please add your comments and thoughts.

First, one general issue with Ruby:

- Ruby is not threadsave. When using Ruby and POSIX threads, the Ruby
  interpreter crashs badly. It would be very surprising if it would work
  with cthreads, but afaik nobody actually tried this up to now. Ruby has
  its own threading model, which is working with select (). This means that
  if you want to write a multithreaded translator in Ruby at all, you will
  have no other choice than to use Rubys own implementation. So, would
  implementing a function which does essentially the same thing as libports'
  ports_manage_port_operations_multithread () does, but with Ruby threads,
  be a good idea (i.e. a solution for this problem)?

Then, there are basically two ways how one could connect the world of Ruby
with the translator world:

- The first one might be seen as a quick hack by some people, but it's the
  way one usually extends Ruby. One would write a wrapper for libtrivfs, one
  for libnetfs and so on. Interfacing Ruby and C is pretty simple. This is
  not a "generic" solution however, and one would need to modify the wrapper
  whenever the interface of the underlying library changes. In Ruby, it is
  common to write wrappers for libraries and I think one could get it
  working in a short time (see below). One would do the interface in Ruby
  different than in C, since Ruby is a 100% objectoriented language, like
  SmallTalk, so a C-like interface would not make much sense in Ruby, but
  nevertheless using the libraries should simplify the job by an order of
  magnitude. We also would end up with an interface that has much in common
  with the existing C interface, which means it would be easier for
  programmers to switch between languages. The Ruby hello translator at
  <http://www.8ung.at/shell/hellotriv.rb.txt> should demonstrate what I
  mean. Yes, I already wrote a Ruby module for libtrivfs, which you may find
  at <http://www.8ung.at/shell/trivruby-0.0.tar.gz>. I did this for three
  reasons: a) I wanted to exercise using both libtrivfs and Ruby's nice C
  interface. b) I wanted so see if it is as easy to do as I thought (It
  turned out to be even easier!) c) Now we can claim that it's possible to
  write translators in Ruby. :) I did _not_ assume that this is the way it
  should be done and I have no problem with throwing away the code if the
  Hurd hackers think that this approach is wrong.

- The second way would be to extend MiG (or flick or something else). One
  could for example add an option to flick/MiG which causes it to produce
  two additional C source files. The first would provide wrapper functions
  that first convert Ruby types to C types and then call the C
  implementation that is normaly produced by flick/MiG; this would be the
  client part. The second file would implement the S_* (server) functions.
  This automatically produced implementation would convert the C types to
  Ruby types and call a Ruby method with an identical name, passing it the
  converted arguments. A Ruby script would then load such a module and
  implement those functions and we would be able to use a Ruby script as a
  Mach server. Of course, nobody would like to use this interface directly
  in Ruby, so we also need a wrapper here, but in this case it could be
  written in Ruby and it would only depend on the interface definitions in
  $(HURD)/hurd/*.defs, which probably won't change often, if at all. A huge
  disadvantage in my eyes is that one would end up reimplementing large
  parts of the existing libraries in Ruby. Maybe this would be even harder
  to maintain than a thin C layer, maybe not, I don't know.

What would you suggest?

Cheers,
GNU/Wolfgang

-- 
Wolfgang Jährling <wolfgang@pro-linux.de> `-:._ "Omnis enim res, quae dando
Debian GNU/Linux user && Debian GNU/Hurd user  `-:. non deficit, dum habetur
Hurd Hacking Guide - http://stdio.cjb.net/hhg.html )  et non datur, nondum
www.debian.org || www.gnu.org || hurd.gnu.org _,-:' habetur, quomodo habenda
["Accelerate your PC - with 9.81 m/s^2."] ,-:'   est." --> fsfeurope.org <--



reply via email to

[Prev in Thread] Current Thread [Next in Thread]