Re: [TEAR-Devel] Redesign of tear?

[<tea...@li...>]

Hi all,

> 1) leading / on paths are not handled, treated as relative (split
> problem)
Yeah, someone just mentioned that to me. I am working on it, as quickly as
I can.

> 2) VERBOSE from defaults is not mapped and therefore overwriting
> config value NOISE
Yeah, a lot of that stuff is not yet mapped correctly, I thought I
mentioned that in the notes, if not I simply forgot to mention it I knew
it happened. There are also several other similar "errors" that are really
just incomplete code.


> I've tried to implement some of my 0.5.9.specialedition features and
> some failure catchup code.
Believe it or not, most of your special edition features are on my list
for 0.9.1, especially changing the PWD for WAVTMPDIR etc... There a few other
things on my list like, bladeenc, ID3v2, and a new man file as well.

I also realize that I tend to make more promises for the next version than
I keep :)

> So I have some questions:
>
> A) is there any newer code available than 0.9.0 where already a
> redesign was started?
Included is my current "test" copy, this is not the latest but it is the
best that I have. I believe it has updated "debug" handling to try and
make it clearer, it has the beginnings of looking for program errors and
exiting, etc. but not too much...

> B) if not, I'm close to do a complete redesign, because I want to use
> tear in the future, but I really miss my specialedition features.
>
> If no redesign is currently started, I will do so, let's say until
> new year, starting next week.
It is ok, I would love the "help." I have this PalmOS project I was
thinking of starting and I could use the time to research/start it.
** I will probably get bored or in over my head quite quickly, so don't
worry :) **

I do however have some requests for your impending project:
- I would like the new code to be more based on 0.9.0 then 0.4/0.5 since
there is a lot in there that I do like. Including the -debug tracing and
the multitasking capability. (You may also want to keep the cddb code base
since it works quite well)
- Frequent updates, once you get your new code base started I would like
to see a lot of updates, if they seem to run I will package them (gz/bz2)
and release them. That way I wont lose track of what you are doing while I
answer questions about bugs/feature requests. (The actual release can be
decided for each update, so dont worry about making sure that the code
actually works all of the time. It's mostly about me seeing where the new
development is occuring)
- Try not to break old standards this time... 0.9.0/1 looks for both : and =
and that is how we can both win (Probably only one other person on this
list will understand that one) If you're unsure if there is a standard
ask, I will try answer right away, that's one thing I do know well :)
- Use Mpeg::Info, or whatever it is that 0.9.0 supports, this is very
important since: it is Perl (always nice), it is in current development
(more than we can say for id3tool), it supports ID3v2 (or so I am told),
and because I said so.

> Missing and "want to implement" features:
>
> shorter:
> * clarify code and settings handling
> * bitwise selectable debug code to get clearer, what's going on
> * WAVTMPDIR to store ripped wav files on different dir
> * catchup as many as can failures due running external programs, file
> system and others
> * add configurable options for compressors (e.g. special lame options)
Sounds like a good list, actaully it's almost like my list...

> longer:
> * clean continue after interrupting, short cut modes for testing
Hmm, I've been facing the probelms of adding this type of suuport without
adding a lot more confusion to the code, but heaven knows it would be
useful. The way I do most testing now is to comment out the actual system
call, see how tear runs and then one by one run the calls (from
.tear-debug' and make sure thay all do what I would expect of them. It's a
PITA.

> notbreaking:
> * current config style should be not broken (hopefully)
We certainly hope so :)

> If ok, I'll take version number 1.0.0 for starting ;-)
> If not ok, I can call it "tearng" (tear new generation), starting on
> 0.0.1
no, lets leave 0.9.X to be the pre-development versions of 1.0, until it
gets further along and then move the code to 1.0/1.1
In other words, take over 0.9.X; It doesn't matter if all of the numbers
correspond to the same line of thinking since it is a development line
anyway and everyone who should care is reading (skimming, I imagine) this
right now.

> Developing scenario: Red Hat Linux 7.2 + cdparanoia + lame
> So if someone agrees for alpha testing, other scenarios will be
> welcome.
I will be adding Slackware 8.0 (Linux 2.4.10 ac12) + all open source
supported programs (cdparanoia, cdda2wav, lame, bladence, oggenc, etc.)
But of course if anyone else wants to specialize in any particualt beta
test; it will just help us all out, especially me :)

>         Peter

Greg
----
T.E.A.R Encodes And Rips
http://tear.sourceforge.net