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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 <[email protected]> >> 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 >> >> >
