Hi,
On Sat, 16 Aug 2008, Sergei Steshenko wrote:
> 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 not saying you need to submit patches, and I appreciate the feedback
as always. It's just frustrating when your things-to-do piles up all the
time and you are running out of time. And especially now as I've been
trying to prepare 2.5.0 for months now and every time things seem ready,
something new comes up. It's of course not your fault, so sorry about
that.
And, to be honest, I was a bit annoyed by your comment "Is there the same
kind of lazy coding in the latest prerelease version ?". I did already
admit in an earlier mail that I had been sloppy (and not really happy
about it). I took your comment as a bit of insult -- i.e. that I would
some how be proud of my sloppy coding and refuse to change the code. And
thus the "Patches are welcome" comment. But maybe I was a bit thin skinned
with this one...
But yeah, I think we both agree "-i:fooloop" should return a proper error.
I'll try to include this in 2.5.0 and if not, file it to the bug tracker
so it's not forgotten.
> If, say, the newest version gets on command line
>
> loopaudioloop
>
> , what will it do - act as if it's 'loop' or as if 'audioloop' ?
The latest 2.5.0pre will treat that as a loop device.
> 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.
Ecasound has a regex based parser for the types, and sanity checking for
most arguments, but unfortunately, loop devices are handled as a special
case (added already eight years ago and the code hasn't really been
changed much since then).
> 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.
In ecasound, command-line parsing actually goes beyond the command line
parsing as the argument syntax (formalized as Ecasound Options Syntax -
EOS) is used in many other parts of the system as well (for instance when
saving/restoring chainsetups, and with interactive commands). But yeah,
this doesn't really invalidate anything you say -- just makes it even more
beneficial to thoroughly test the parser. For this we have unit and batch
testing, but these don't really cover all functionality yet.
-- ------------------------------------------------------------------------- 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-listReceived on Sun Aug 17 00:15:02 2008
This archive was generated by hypermail 2.1.8 : Sun Aug 17 2008 - 00:15:02 EEST