libcdio-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] OS/2 patches


From: KO Myung-Hun
Subject: Re: [Libcdio-devel] OS/2 patches
Date: Wed, 30 Jul 2014 11:48:26 +0900
User-agent: Mozilla/5.0 (OS/2; Warp 4.5; rv:10.0.6esrpre) Gecko/20120715 Firefox/10.0.6esrpre SeaMonkey/2.7.2

Hi/2.

Rocky Bernstein wrote:
> Ok, then you can be responsible for OS/2 . That means that you will be
> expected to test, in advance, releases. Note that this is a change from the
> laxness we've had in the past with respect to releases.
> 

No problem.

> If you disappear and there is no one else to take responsibility, the
> ability to test OS/2 disappears, then OS/2 support in libcdio may disappear
> as well.
> 

Ooops... I feel the very much responsibility. ^^

>> What about testing an OS getopt first ?
> 
> We have 7 or so drivers that work with the supplied getopt.c and one that
> doesn't. And for that one driver we have maybe two people who use that.
> Even here, their use is probably infrequently for say Mplayer while the
> uses elsewhere span audio ripping, other media players, making boot CDs and
> lots of other things I probably don't know about. So guess which way causes
> the least disruption to the majority of users and developers?
> 

Hmmm... I don't think this is a problem of quantity. But this is not a
important part.

> Couple that with the fact currently we don't have rigorous tests either
> getopt routine to make sure that works.  It's possible, though that in one
> of the larger integration tests, we might catch a malfunctioning getopt,
> but I wouldn't want to count on that.
> 
> If you want to start writing a test suite for getopt whether it the
> provided one or the OS-supplied one, we can reconsider. But given things
> are currently the way they are, if the supplied getopt works, it's better
> to to use that, because assuming the getopt.c compiles as it was intended,
> we *know* what the intended behavior is.
> 

Ok. I agree. So I approach in other way.

Review, please...

> 
> 
> On Mon, Jul 28, 2014 at 10:12 PM, KO Myung-Hun <address@hidden> wrote:
> 
>>
>>
>> Rocky Bernstein wrote:
>>> Sorry for the delay. Things have been busy for me.
>>>
>>
>> No problem. ^^
>>
>>> It is interesting to hear back after the 5 or so years. About a month
>> and a
>>> half ago we were discussing dropping libcdio's OS/2 driver altogether.
>>  See
>>> http://lists.gnu.org/archive/html/libcdio-devel/2014-06/msg00004.html
>>>
>>> What motivated this was the desire to change the API to add
>> get_track_isrc
>>> and Robert Kausch mentioned he had no way to test OS/2. In that, we
>>> realized that basically no one *is* actively testing OS/2.
>>>
>>> Aside from yourself and possibly Natalia, do you know anyone else that is
>>> using this?
>>>
>>
>> I don't know. But those who want to build MPlayer with audio cd
>> supports, would be using libcdio.
>>
>>> Given the low activity and difficulty for finding developers and testers,
>>> I'm inclined to have this maintained by you and Natalia in separately.
>> She
>>> already has a fork on github of libcdio-paranoia.
>>>
>>> If OS/2 is to survive in libcdio, someone needs to commit to handle
>>> problems and API changes as such things arise. Are you willing to commit
>> to
>>> this?
>>>
>>
>> Of course. Five years ago, it's me to submit OS/2 patches as you know. ^^
>>
>>> Lastly, on the first patch. It has to do with deciding on whether the use
>>> the libcdio-supplied getopt.c,and this is based purely on OS. OS/2 is the
>>> only one to not used the supplied getopt.c
>>>
>>> Rather than have a test by OS, I'd prefer a test to compile the supplied
>>> getopt;  if that fails, then run a test to see if there is an OS getopt.
>>>
>>
>> Ok. What about testing an OS getopt first ? I think, it's better to
>> consider libcdio-getopt as a fallback.
>>
>>>
>>>
>>> On Sat, Jul 26, 2014 at 11:50 PM, KO Myung-Hun <address@hidden> wrote:
>>>
>>>> Ping ?
>>>>
>>>> KO Myung-Hun wrote:
>>>>> Hi/2, long tiem no see. ^^
>>>>>
>>>>> I attach the patches to build libcdio and to enhance memory usage on
>>>> OS/2.
>>>>>
>>>>> Review, please...
>>>>>
>>>>>
>>>>>
>>
>> --
>> KO Myung-Hun
>>
>> Using Mozilla SeaMonkey 2.7.2
>> Under OS/2 Warp 4 for Korean with FixPak #15
>> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
>>
>> Korean OS/2 User Community : http://www.ecomstation.co.kr
>>
>>
>>
> 

-- 
KO Myung-Hun

Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM

Korean OS/2 User Community : http://www.ecomstation.co.kr

Attachment: 0001-Fix-linkage-on-OS-2.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]