Re: [Libcdio-devel] OS/2 patches

[Rocky Bernstein]

I shhould have also mentioned that this has only been applied in the
"static analysis" branch. When I get a chance, I think all of this will be
merged back into the main branch.



On Wed, Jul 30, 2014 at 6:37 AM, Rocky Bernstein <address@hidden> wrote:

> Ok. Both patches have been applied. Thanks.
>
> Still waiting on Natalia to get OS/2 access set up for developers. If
> however you want to or set up some sort of access to OS/2 for folks to test
> on that'd be great.
>
> (Five years ago this wasn't a requirement. Things have changed - it now
> is.)
>
>
> On Tue, Jul 29, 2014 at 10:48 PM, KO Myung-Hun <address@hidden> wrote:
>
>> 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
>>
>>
>