Subject: Re: [ecasound] ruby-ecasound
From: Kai Vehmanen (k_AT_eca.cx)
Date: Thu Nov 27 2003 - 02:13:26 EET
On Thu, 27 Nov 2003, Jan Weil wrote:
>> 1. decide the module (ecasound/rubyecasound?) and filenames
> 'apt-cache search ruby' tells me that (at least for Debian) pakages for
> ruby extension usually are called 'libwhithrubybindings-ruby" while
> packages for python are usually called pythonx.y-something.
> On the other hand many ruby projects call themself ruby-somewhat (e. g.
> ruby-gnome2, ruby-qt, ruby-kde).
> I would therefor vote for ruby-ecasound.
After some consideration, I created the directory "ecasound/rubyecasound".
None of the existing directory names in the ecasound tree have hyphens
(unless to mark a version number), and 'ruby_ecasound' didn't look good,
so 'rubyecasound' it is. :)
The official package name (used if the module is distributed separately,
for instance in Debian), can still be ruby-ecasound.
> I understand one way of distributing a ruby library like this is by the
> help of http://www.loveruby.net/en/setup.html.
> You only have to stick to a certain subdirectory layout to make this
> work.
Hmm, I've considered using similar scripts that are available for Python,
but there are few tricky problems - basicly these scripts don't cover all
installation scenarios allowed by autoconf/automake:
- installing to a custom prefix
- buildir (i.e. where configure is run and where all files are
created) is different from srcdir
- handling uninstalling in the above cases
- etc...
So in the end it's almost easier to find out the correct directory to
install to yourself and use the existing makefile rules to do the copying.
I've made the following directory tree for rubyecasound:
rubyecasound
rubyecasound/README
rubyecasound/Makefile.am
rubyecasound/ecasound.rb
rubyecasound/control-interface.rb
... i.e. no subdirs. I made one change to ecasound.rb to adjust to the new
dir layout. Otherwise no changes. I also made an initial Makefile.am - it
is not ready, but shows how the install/uninstall can be done.
Is this ok? If yes, I'll commit this to CVS.
> Now my medium-term aim is a module which lets you do something like the
> following:
[...]
> without ever having to send a single iam command (while the latter
> stays an option).
Hmm, this kind of more wide API is probably best first developed as part
of your application (on top of the simple IAM-based API), and if it proves
generic/complete enough, only then add it to the Ruby Ecasound module.
I say this because I've not had much success with wide APIs in the past.
I've spent a lot time developing and documenting libecasound, which
provides an O-O C++ API to Ecasound, but it never really was used by other
developers than me. The ECI API on the other hand, although very very
simple, has proven to be a kind of success. Developers now build their own
abstractions on top of it. This leads to duplicated work, but also means
that developers have the freedom to customize the layers above basic ECI
to their specific apps.
Janne Halttunen has written a lot of Python stuff above the Python ECI
API, but it too has so far been only used by Janne's own apps.
> While there are some things which I would like to investigate (version
> checking would fail if you released 2.10 because "2.2" > "2.10" =>
This should probably be fixed, although I doubt I ever release 2.10.x
(3.x.y much more likely). ;) Btw; another issue, with the current release,
if an error occurs, the whole program fails as 'EcaError' is not defined.
This is probably not intended (or should the caller define the error
type)...?
> true, is there a chance that the ecasound child becomes a zombie
> process?) my local tests showed a good behaviour.
Zombies should be rare. A terminating 'kill <pid-of-child>' from the
eci-instance destructor a'la ecacontrol.py should be enough.
-- http://www.eca.cx Audio software for Linux!
This archive was generated by hypermail 2b28 : Thu Nov 27 2003 - 02:10:49 EET