From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 16 Jul 2003 14:08:37 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 150 ************************************************** Tuesday 15 July 2003 Number 150 ************************************************** Subjects for today 1 Re: [EMX] Re: libc : Andreas Buening 2 Re: [EMX] Re: libc : Andreas Buening 3 Re: [EMX] Re: libc : Stefan Neis 4 Re: [EMX] Re: libc : Stefan Neis 5 Re: [EMX] Re: libc : Adrian Gschwend" **= Email 1 ==========================** Date: Wed, 16 Jul 2003 00:08:32 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Adrian Gschwend wrote: > > On Sat, 12 Jul 2003 15:47:08 +0200, Andreas Buening wrote: > > >- Who will run the CVS server? > > I volunteer to do that if you don't want to do it at sourceforge. But > sourceforge is fine as well for me. For me, too. :-) As long as nobody objects or tells us of any "must have" features at sourceforge, I'd say set up a CVS repository at netlabs. Btw, what's the "current" emx source? The sources from the gcc 2.8.1 package plus emx 0.9f? And I think we should also add the emx docs in an extra directory (but what do we want to use as "source" language for the docs?). [snip] Bye, Andreas **= Email 2 ==========================** Date: Wed, 16 Jul 2003 00:08:39 +0200 From: Andreas Buening Subject: Re: [EMX] Re: libc Ilya Zakharevich wrote: [snip] > My point is very simple: obviously, no merge should happen until the > documentation *of what the things do exactly* is available. So the > proponents of the merge should at least: > > a) convert the docs to EMX format; > > b) have the list of implemented functions in one bulk; > > c) have the list of limitations (comparing to BSD) in one bulk; > > d) merge the description of limitations with entries for specific functions. > > I do not see how one can discuss the merge without having lists of `b' > and `c' before our eyes. The steps `a' and `d' may be postponed > indeed - at least if one can access the BSD manpages through a > convenient URL (which I expect is available). This makes sense. A patch should contain of - a ChangeLog entry (who did what and when) - a short description (why and what) - the patch itself - the updated docs (if necessary) - the updated Makefile (if necessary; can also be done by someone else if the contributor of the patch doesn't know how to do it). Bye, Andreas **= Email 3 ==========================** Date: Wed, 16 Jul 2003 07:58:35 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Tue, 15 Jul 2003, Ilya Zakharevich wrote: > > > c) have the list of limitations (comparing to BSD) in one bulk; > > > - Not all functions are well tested > > > - Emulating links via extended attributes is not yet incorporated. > > > - None else known. > > I see no reason to include things about which "nothing is known". Nobody used the phrase "nothing is known". I said "no limitation (comparing to BSD) is known", i.e. works as designed. > Of course it is easier. But I do not think that this is a viable > approach. Even for the functions with no architecture dependence, > somebody need to analyse the diffs. Functions without > architecture-dependence which were NOT available on OS/2 do not need a > lot of discussion. That (i.e. analyzing the differences between e.g. BSD implementation of log and EMX implementation of log) is what a group of five or more people has been doing over the past 2 years. There are a couple of special cases (mostly involving NaN somehow) where both implementations are slightly different where BSD implementation is surprisingly more correct according to Posix standard (some code like "if (arg is special) return special value" having been added over the past three or so years, while nothing happened to EMX), but otherwise the code is not very different (it quite looks like EMX math library is based on some antique BSD version as well). Feel free to restart evaluating those files, if you feel like it, though... > > Does this huge list help in any way? > > Of course. Without this list it was absolutely unclear what you were > talking about... Is it that much clearer now? > P.S. To speed up the discussion, this list should be broken into two > parts: functions which were available as functions or macros in > EMX, and the rest. Feel free to do so... Regards, Stefan **= Email 4 ==========================** Date: Wed, 16 Jul 2003 08:03:22 +0200 (CEST) From: Stefan Neis Subject: Re: [EMX] Re: libc On Wed, 16 Jul 2003, Andreas Buening wrote: > This makes sense. A patch should contain of > > - a ChangeLog entry (who did what and when) > - a short description (why and what) > - the patch itself > - the updated docs (if necessary) > - the updated Makefile (if necessary; can also be done by someone else > if the contributor of the patch doesn't know how to do it). You do realize that it would take decades to incorporate all the missing functions from Posix/2 that way, don't you? I guess, that's the point where I definitely loose interest in doing the project this way (or even at all, actually, though that later part might change once I calm down again). Regards, Stefan **= Email 5 ==========================** Date: Wed, 16 Jul 2003 11:08:35 +0200 (CDT) From: "Adrian Gschwend" Subject: Re: [EMX] Re: libc On Wed, 16 Jul 2003 00:08:32 +0200, Andreas Buening wrote: >As long as nobody objects or tells us of any "must have" features >at sourceforge, I'd say set up a CVS repository at netlabs. fine for me >Btw, what's the "current" emx source? The sources from the gcc 2.8.1 >package plus emx 0.9f? And I think we should also add the emx docs >in an extra directory (but what do we want to use as "source" language >for the docs?). Should I create an empty repository or should I take some codebase as initial repository? The second option means less work for the person who would checkin the initial source otherwise. If someone can point me to this "current" OS/2 source I will set up the repository tomorrow. I have to hurry a bit because I will be in holidays for three weeks soon (leaving monday). So all who would like to have access to this repository should send me a proposal for a username and (if you want) a password (otherwise I generate one for you). Please send that ASAP. btw how do we want to call the repository? simply libc? cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org