Re: [Caml-list] Completeness of "Unix" run-time library

[Vasili Galchin <vasiliocaml@yahoo.com>]

--- Eric Stokes <eric.stokes@csun.edu> wrote:
> Splitting up the single large interface of the unix
> library into 
> several smaller ones seems a
> very natural thing to do as the library grows.
> 	The point I was trying to make though is that INRIA
> currently has the most complete Posix library in the
> Ocaml community,
> and so, those of us who have created bindings for
> other Posix functions 
> should
> try to work with them to get our code merged. This
     Eric, it sounds to me that you and I are on the
same page, i.e. in total agreement. What prompted my
posting is that I feel a tad frustrated when I read
code that I believe is very good (e.g. Georgi's ipv6
socket code where he split socket stuff out from
unix.ml by itself making readibility much better and
esaier multiple people to work and not having big
merge problems) and I hear about other code. In both
cases, these new code seems to have been sitting
around and not code reviewed and put into CVS, where
it should be. Also there is a danger of some
divergence because someone will use some of this
non-checked in code and it becomes defacto standard.
So, OCaml community, how do we move forward to get
this new processed and potentially merged into the
mainline. This has been my point from the beginning.
Does INRIA have a code gatekeeper? If so, who? I can
mention another language that starts with an 'H'. I
have quite a bit of respect for 'H', but frankly I
have found OCaml code base very impressive. However,
with all of this dangling new functionality, it is not
a good situation. So again who is gatekeeper?

Regards, vasili

> avoids fragmentation 
> of the code
> base for the Posix api and the confusion which comes
> with it. IMHO of 
> course.
> 
> On Mar 15, 2004, at 9:32 PM, Vasili Galchin wrote:
> 
> > Hi Eric,
> >
> >     You have made a good point. Is there a way
> though
> > so that there is one unix.cma (I would still
> suggest
> > posix.cma because we should really IMO speak in
> terms
> > of POSIX API vs Win32 API) library that is built
> from
> > several binaries like socket, process, (p)thread?
> In
> > this way, the end-user would like against one
> library
> > not N libraries (I agree with your point about
> link
> > hassles). I guess i questioning current
> granularity of
> > unix.mli. This is, of course, somewhat of a
> judgemnet
> > call, but one doesn't want to have all of the
> source
> > in the kitchen sink. I.e. source module division
> vs
> > link library division. (Sorry ... perhaps I didn't
> say
> > in an eloquent way .. hope everybody gets my
> point).
> >
> > Regards, Vasili
> >
> > --- Eric Stokes <eric.stokes@csun.edu> wrote:
> >> It is nice to access these things through a
> single
> >> interface like the
> >> Unix library, instead of
> >> having to link to multiple libraries. Does INRIA
> not
> >> allow submissions
> >> for inclusion
> >> into the standard library?
> >>
> >> On Mar 9, 2004, at 10:11 AM, Shawn Wagner wrote:
> >>
> >>> On Tue, Mar 09, 2004 at 05:55:27PM +0000,
> Richard
> >> Jones wrote:
> >>>> On Tue, Mar 09, 2004 at 09:30:09AM -0800,
> Vasili
> >> Galchin wrote:
> >>>>> Hello,
> >>>>>
> >>>>>       I have yet to finish reading through
> >> otherlibs/unix/unix.mli.
> >>>>> I kind of consider this POSIX API support. In
> >> any case, is there is
> >>>>> a consensus that what is in unix.mli is
> >> complete? Or does new
> >>>>> functionality have to be added? If so, what?
> >>>>
> >>>> No way!!  There's lots of missing stuff which
> >> could be added.  eg. off
> >>>> the top of my head, strftime(3).
> >>>
> >>> <Plug>
> >>> Some missing functions from the C and POSIX
> >> standards are in my extlib
> >>> library (strftime is Time.format_time).
> >>> http://raevnos.pennmush.org/code/extlib/
> >>>
> >>> More (The numeric ones added in C99) are in the
> >> companion mathlib.
> >>> http://raevnos.pennmush.org/code/mathlib/
> >>> </Plug>
> >>>
> >>>>
> >>>> It would also be useful to have a comprehensive
> >> time / date library,
> >>>> probably outside the Unix module.  As part of
> the
> >> perl4caml project
> >>>> I've wrapped up Perl's Date::Parse,
> Date::Format
> >> and Date::Calc[1]
> >>>> modules, but a general OCaml library would be
> >> great.
> >>>
> >>> Agreed.
> >>>
> >>> -- 
> >>> Shawn Wagner
> >>> shawnw@speakeasy.org
> >>>
> >>> -------------------
> >>> To unsubscribe, mail caml-list-request@inria.fr
> >> Archives:
> >>> http://caml.inria.fr
> >>> Bug reports: http://caml.inria.fr/bin/caml-bugs
> >> FAQ:
> >>> http://caml.inria.fr/FAQ/
> >>> Beginner's list:
> >> http://groups.yahoo.com/group/ocaml_beginners
> >>>
> >>
> >> -------------------
> >> To unsubscribe, mail caml-list-request@inria.fr
> >> Archives: http://caml.inria.fr
> >> Bug reports: http://caml.inria.fr/bin/caml-bugs
> FAQ:
> >> http://caml.inria.fr/FAQ/
> >> Beginner's list:
> > http://groups.yahoo.com/group/ocaml_beginners
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Mail - More reliable, more storage, less
> spam
> > http://mail.yahoo.com
> >
> > -------------------
> > To unsubscribe, mail caml-list-request@inria.fr
> Archives: 
> > http://caml.inria.fr
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
> FAQ: 
> > http://caml.inria.fr/FAQ/
> > Beginner's list:
> http://groups.yahoo.com/group/ocaml_beginners
> >
> 
> -------------------
> To unsubscribe, mail caml-list-request@inria.fr
> Archives: http://caml.inria.fr
> Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ:
> http://caml.inria.fr/FAQ/
> Beginner's list:
http://groups.yahoo.com/group/ocaml_beginners


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners