Re: [ecasound] ecasound-2.4.6.1: audioloop doesn't work ?

--- On Sat, 8/16/08, Kai Vehmanen <kvehmanen@email-addr-hidden> wrote:

> From: Kai Vehmanen <kvehmanen@email-addr-hidden>
> Subject: Re: [ecasound] ecasound-2.4.6.1: audioloop doesn't work ?
> To: ecasound-list@email-addr-hidden
> Date: Saturday, August 16, 2008, 1:24 AM
> Hi,
>
> On Fri, 15 Aug 2008, Sergei Steshenko wrote:
>
> > Is there the same kind of lazy coding in the latest
> prerelease version ?
>
> yes, there are no changes to the loop device code. But of
> course, as
> audioloop device _is_ supported, you don't get this
> weird result.
>
> > Command line parsing should really be flawless,
> otherwise there is no
> > way for end user to understand where his/her mistake
> is.
>
> Patches are welcome.
>
> I do agree with you -- we've been improving the parsing
> a lot during the
> whole 2.4.x series (ecasound can now identify many common
> errors and
> report them), but it's not perfect.
>
>

Regarding patches that are welcome - I can symmetrically suggest to
patch, say, my AppsFromScratch whenever I or somebody else finds a bug in
it.

At all, I think anyone who can write code should necessarily have an
open source project of his/her own, just to always be able to
symmetrically request patches.

I'm too lazy to look for a recent slashdot post which tells how to improve
Linux/FOSS adoption - one the items is _not_ to ask for patches from users.

We, users, are voluntary QA engineers. And sometimes not bad ones.

My main point is that the person who already knows code is much better in
fixing it than the one who doesn't know it.

...

Well, back to command line parsing and coding.

If, say, the newest version gets on command line

loopaudioloop

, what will it do - act as if it's 'loop' or as if 'audioloop' ?

Command line parsing is a wheel that has already been properly invented
many times.

When I write a command line parser, I first check syntax and then some
semantics, like range checking for numeric values if there are ones.

I also, of course check existence of mandatory and interdependent options.

The loop/audioloop issue is the one functionally equivalent to checking
whether a name is a keyword. Should be pretty easy in any language; from
debug output I see ecasound already uses regular expressions, so it's
probably easy to perform

\bkeyword\b

check ('\b' being word boundary in Perl) for every keyword.

I view command line parser as micro-compiler - in my scripts it parses,
performing syntax and semantic checks and fills a hash with option => value
pairs.

I guess I'm trying to say that command line parser is always a more rather
than less self-contained sub-project which can and should be debugged
separately from the rest of the program.

Thanks,
  Sergei.

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Ecasound-list mailing list
Ecasound-list@email-addr-hidden
https://lists.sourceforge.net/lists/listinfo/ecasound-list
Received on Sun Aug 17 00:15:01 2008