Re: [Libcdio-devel] OS/2 patches

[Rocky Bernstein]

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
>
>