Subject: Re: [ecasound] ruby-ecasound
From: Jan Weil (Jan.Weil_AT_web.de)
Date: Fri Nov 28 2003 - 00:22:56 EET
Am 2003.11.27 01:13 schrieb(en) Kai Vehmanen:
[...]
> 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. :)
That's fine by me.
> 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.
While custom prefix and builddir are no problems the fact that there
actually is no "ruby setup.rb uninstall" is crucial! So, Amen!
[...]
>
> I've made the following directory tree for rubyecasound:
>
> rubyecasound
> rubyecasound/README
> rubyecasound/Makefile.am
> rubyecasound/ecasound.rb
> rubyecasound/control-interface.rb
>
Hmmm - my suggestion:
For now that we stick with the native ECI I would say let's
consequently move everything into one file called 'ecasound.rb'.
But if we should ever decide to add my additional oo-layer I would
really prefer seeing the subdir 'ecasound' reappear :)
The thing is that all these files go into one directory with all other
locally installed ruby libraries.
To prevent cluttering up this directory we would at least have to add a
common prefix to all files.
But I would really prefer the subdirectory.
Anyway, for now let's stay with 'ecasound.rb' so that eventually the
'interface' (require "ecasound") won't change.
[...]
> > 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.
OK
> > 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
I fixed the version checking ("2.2.2" < "2.2.10" => true) but the
current implementation requires that your version number is of the form
major.minor.micro. Otherwise an exception is raised :)
Is there any chance that your version numbering does not follow this
scheme?
> (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.
Fixed.
>
> > 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.
>
Well, this one is actually a little bit more complicated as Ruby does
not have destructors because it does not use reference counting but
garbage collection.
You can define so-called finalizers which get called _after_ the object
is GCed but there's a pretty good chance that you effect some kind of
cyclic redundancy while defining this finalizer so that your object
always is referenced somewhere and therefor actually never gets GCed.
I still have to think about this but for now there's never been a
zombie for me so I won't send for one of them.
I prepared a diff (attached) which patches ecasound.rb, README and
Makefile.am conforming to my suggestions.
I did a 'cvs diff -up > patch' in the rubyecasound subdirectory so you
will have to apply the patch in this directory.
Additionally, you will have to 'cvs remove' contol-interface.rb.
I also translated your stress tests to ruby.
Well, what do you think? :))
Jan
This archive was generated by hypermail 2b28 : Fri Nov 28 2003 - 00:18:55 EET