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

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

[Vasili Galchin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=us-ascii, Size: 373 bytes --]

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?
 
Regards, Vasili


---------------------------------
Do you Yahoo!?
Yahoo! Search - Find what you’re looking for faster.

[-- Attachment #2: Type: text/html, Size: 503 bytes --]

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

[Richard Jones]

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

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.

Rich.

[1] http://www.engelschall.com/~sb/download/Date-Calc/

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Learning Objective CAML for C, C++, Perl and Java programmers:
http://www.merjis.com/richj/computers/ocaml/tutorial/

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

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

[Shawn Wagner]

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

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

[Eric Stokes]

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

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

[Vasili Galchin]

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

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

[Eric Stokes]

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

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

[Vasili Galchin]

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

OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Matt Gushee]

On Wed, Mar 17, 2004 at 04:19:05PM -0800, Vasili Galchin wrote:

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

(Sorry about the grandiose title. I have nothing suitably profound to
 say ... just couldn't think of a better way to express the subject.)

I wonder if it is possible to persuade INRIA to do anything.

I have no inside information on the process at INRIA, but my impression
from reading this list over the past year or so is:

 1) The OCaml team at INRIA care about the community, but there are too
    few of them to meet all our needs, and I suppose their work is also
    subject to institutional pressures that we are only vaguely aware
    of. Maybe they are struggling to keep enough resources for OCaml
    work.

 2) INRIA as an institution finds it convenient to release OCaml as open
    source, but doesn't really care about the community. They benignly
    neglect everything that doesn't relate to their research goals.

 3) OCaml-as-project (i.e. I'm talking about how OCaml is developed, not
    what it is) is a fragile enterprise. E.g., one developer leaves, and 
    the future of Camlp4 becomes uncertain. Not good.

I'm not saying you should give up hope just yet, but maybe it's time to
consider alternatives.

What if there were an "OCaml Community Library Project"--a group outside
INRIA that would take responsibility for extending and perhaps partially
replacing the standard library--maybe a bit like the current ExtLib
project, only more extensive (BTW, why are there two ExtLibs?? One of
you change the name, please! Thank you.). Maybe if that project showed
itself to be responsible, credible, reliable, etc. etc., after a while
it could become the de facto standard library.

The idealistic scenario is a division of labor wherein INRIA continues
to develop the parts of OCaml that are interesting to them, while other
parts (of more interest to those of us working to create practical
and/or commercial software) would be taken over by the community.

I can't say whether this idea is feasible, or whether INRIA would be
willing to go along with it, but maybe it's something to consider.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

I broadly agree with Matt's analysis of the situation.  Here are some
observations of my own.

(1) Perl gets along quite nicely with a loosely defined and broadly
distributed standard library.  However what Perl has which OCaml does
not is a central repository (CPAN) where you can find all those
libraries.  I don't just mean find pointers to the libraries (the
Humps), but I mean a place where you can get the actual source.

The need for a CPAN for OCaml has been extensively discussed on this
list already, so I won't go into that much further, except to say that
my company would be prepared to fund a [virtual] server and put a
little time into developing this repository.

(2) The QPL license for the compiler itself is a Problem.  I'm
interested to know why the compiler isn't licensed under the GPL, or,
if the commercial interests are so great, under a dual GPL-and-
commercial license similar to (I think) Qt on Unix.

If OCaml was licensed under the GPL then we could consider setting up
a public CVS to create experimental versions of the compiler.  I'd
like to see a load of things going in - GCaml, regexps, ## for single
line comments, # operator for module types, fix for printf FAQ bug,
custom printf operator, ...

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
"One serious obstacle to the adoption of good programming languages is
the notion that everything has to be sacrificed for speed. In computer
languages as in life, speed kills." -- Mike Vanier

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Nicolas Cannasse]

> I broadly agree with Matt's analysis of the situation.  Here are some
> observations of my own.
>
> (1) Perl gets along quite nicely with a loosely defined and broadly
> distributed standard library.  However what Perl has which OCaml does
> not is a central repository (CPAN) where you can find all those
> libraries.  I don't just mean find pointers to the libraries (the
> Humps), but I mean a place where you can get the actual source.
[...]

I don't think the main issue is technical. I'm not sure that a CPAN will
help OCaml to spread, that it will turns the community into a self
organizing decentralized one that makes the power of Perl, Python and other
languages out there. OCaml have more social issues. Let's see the facts :

A programming language need either a very good community support (so the
whole community is helping developping it) or a very good businness backup
( Sun and Java ). OCaml doesn't have any : the community is mainly academic
folks that are using OCaml as a (very useful) tool for their research, the
INRIA is a centralized system with only small openness to user's
contributions - through the wish list for example, neither having a whole
team of people working 24/7 at improving the language (they're academics
people, they need time to write papers, attend conferences, etc.). Industry
adoption of ocaml is in earlier stages, and is not enough wide to push the
language as fast as expected from the community.

The language itself is still evolving, there is people doing great work on
OCaml itself or other librairies, but a lot of OCaml hackers here are
feeling quite quickly frustrated with the social interactions, the void of
official answers when some important questions are raised, and the unability
to simply discuss about what should be added/modified in the standard
library. There is several ways of dealing with this :
- keep continuing without changing anything, but how much time will Ocaml
continue being the best language around ?
- try to build librairies with the hope that they'll one time become
standard (de facto , or integrated into official release) : that's what
we're doing with ExtLib ( http://ocaml-lib.sf.net )
- ask INRIA to open source OCaml ( means : either GPL or recruit language
team among community hackers )
- stop writing Ocaml, and switch to another language with better community
integration
- write your own language, and build your own community :-)

One question is : will we get a single official answer to this thread ?

Nicolas Cannasse

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Wolfgang Müller]

I probably don't qualify, as I use OCaml only very rarely, however, I do have 
an opinion regarding your mail:

On Thursday 18 March 2004 12:22, Nicolas Cannasse wrote:
> I don't think the main issue is technical. I'm not sure that a CPAN will
> help OCaml to spread, that it will turns the community into a self
> organizing decentralized one that makes the power of Perl, Python and other
> languages out there. OCaml have more social issues. Let's see the facts :

Oh, I do think that it would help a lot, as people know CPAN, now how it 
works, know what to expect. It becomes one's own risk to use a library, yet 
there is an easy way to access and one easy way to tell people where to get 
it from. This makes it especially more simple for people who are surrounded 
by FP haters ;-) , and who are forced to give out slick installation packages 
if they want their OCaml stuff to be used.

The same, it can be a goal to say: "we want this on CPAN, so anyone can 
install it easily".

Cheers,
Wolfgang

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Diego Olivier Fernandez Pons]

    Bonjour,

> - try to build librairies with the hope that they'll one time become
> standard (de facto, or integrated into official release) : that's
> what we're doing with ExtLib (http://ocaml-lib.sf.net)

Autant je suis tout a fait favorable aux initiatives qui comme ExtLib
(les deux versions), Baire, MLlib ou OCamlGraph (pour ne citer que
celles la) s'efforcent de mettre a disposition de la communaute des
bibliotheques a usage general, autant je trouve votre position sur
leur integration tout a fait contestable.

Integer une bibliotheque a une distribution est un choix quasi
irrevocable. Les mesaventures de SML sont suffisamment demonstratives
: les differentes equipes ne sont toujours pas parvenues a se mettre
d'accord et a implementer uniformement une norme qui change tout le
temps alors qu'elle ne prevoit rien de plus que des tableaux, quelques
foncteurs et des entrees sorties basiques.

Mieux vaut ne pas imposer de bibliotheque par defaut que d'en imposer
une mauvaise, quitte a paraitre peu reactif. Or aucune des
bibliotheques citees ne fait l'objet d'un consensus, meme partiel.

Je ne pretends pas que l'INRIA puisse pour autant faire l'economie
d'une reflexion approfondie quant aux besoins des utilisateurs mais on
ne saurait a mon avis condamner toutes les precautions dont il fait
preuve.

        Diego Olivier

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Benjamin Geer]

Diego Olivier Fernandez Pons wrote:
> Mieux vaut ne pas imposer de bibliotheque par defaut que d'en imposer
> une mauvaise, quitte a paraitre peu reactif. Or aucune des
> bibliotheques citees ne fait l'objet d'un consensus, meme partiel.

The problem is not simply that INRIA is too cautious, it's that there is 
no visible process for accepting enhancements to Caml or its libraries 
from outside INRIA.  INRIA very rarely responds at all, either 
positively or negatively, to proposed modifications from outsiders (the 
sole exception seems to be bug fixes).

Recently there has been a long discussion on this list about enhancing 
the Unix module, and no one from INRIA has said a word about it; this is 
very discouraging.  Has ocaml-lib.sourceforge.net been rejected?  Is 
INRIA silently working on its own library enhancements which will be 
incompatibly replace some of the enhancements developed by the 
community?  Is there a plan for the future development of Caml?  We are 
like the man in Kafka's novel _The Trial_, who stands for years at the 
door of the Law, and is never told whether he will be seen, or when, or 
if not, why not.

Compare this to what happens in successful, healthy open-source 
communities: GCC has a development plan 
(http://gcc.gnu.org/develop.html).  The core developers discuss all 
proposed enhancements on the mailing list.  The steering committee makes 
clear, timely decisions about which changes will be included in each 
release.  Thanks to this plan, a wide variety of companies and 
individuals contribute to GCC.

Python has excellent standard libraries not because there is always 100% 
consensus on what to put in them, but because there is a clear process 
for extending them (http://www.python.org/peps/).  The Python project 
leader responds quickly to proposals, participates in discussion, and 
makes clear, justified decisions.

I think Caml desperately needs an explicit development plan and a clear, 
efficient process for accepting enhancements from the community.  Until 
it has these, it will not be able to meet the needs of its users; many 
of its users will be increasingly frustrated, and will eventually 
abandon it.

Ben

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Xavier Leroy]

This discussion is heating up, so allow me to make a few points.

One should carefully distinguish between the core OCaml distribution
(the one that comes out of INRIA) and the whole OCaml programming
environment, which includes a lot of third-party libraries and tools.

The core OCaml distribution should and will remain just that: the
core, i.e. the compilers, run-time system and the tools and libraries
that are closely intertwined with the first two.  We at INRIA do not
have the manpower to maintain, document and make distributions of a
much larger software set.  (Witness the problems with the CDK.)  We are
commited to developing and maintaining that core.  I agree we do this
in a "cathedral" style, but this is intended and unlikely to change.

For everything else, bazaar-style developments from members of this
community are most welcome, and indeed the preferred way to enrich the
OCaml programming environment.  A developer has an itch to scratch,
develops and releases a library or tool, gets it listed on the Hump,
users pick it up if it's good, discuss bugs, features and enhancements
with the developer, etc.  There is absolutely no reason we at INRIA
should interfere with this process: in general, we don't have the
manpower to play a significant role, and we don't have the competences
either (many libraries and tools require expertise in application
domains that we're not familiar with, e.g. database interfaces).

There remains a problem of how to make it easy for everyone to install
and use these third-party contributions.  CPAN managed to do it
through standardization on naming conventions, configuration and
installation procedures, and a *lot* of discipline from the
contributors.  We aren't quite at this point with OCaml, although Gerd
Stolpmann's GODI is an impressive first step in this direction.
Again, it's up to this community to tell whether this is a good
approach that should be pursued, e.g. by providing GODI packaging from
your own libraries.  One cannot just wish there would be a CPAN for
OCaml and just wait for us INRIA folks to come up with it overnight.

> The problem is not simply that INRIA is too cautious, it's that there is 
> no visible process for accepting enhancements to Caml or its libraries 
> from outside INRIA.  INRIA very rarely responds at all, either 
> positively or negatively, to proposed modifications from outsiders (the 
> sole exception seems to be bug fixes).

Don't attribute to malice what is generally a lack of time.  What do
you prefer: that I pontificate on every idea proposed on this mailing
list, or that I fix bugs?

As I said above, the preferred way to contribute to Caml is through
independent libraries and tools, not by aiming at getting your stuff
in the core OCaml distribution.  There are good reasons why we are
very careful indeed with what goes in it:

- As Diego said, it's extremely painful to roll back a change or
  addition that turns out to be a bad idea, because of backward
  compatibility issues.

- Maintenance and documentation takes a lot of time.  Often, it looks
  like contributors expect us to maintain their contributed code.

- Copyright issues are not trivial.  It's important for INRIA and the
  Caml consortium to own the copyright on everything in the core
  distribution.  Significant contributions by others would therefore
  require copyright transfers, whose legality in the French copyright
  law is unclear.

Moreover, a *lot* of the suggested enhancements can be done equally
well, if not better, without touching the core OCaml distribution.
A typical example is syntactic sugar (for regexps, for hashtables, etc):
all this can easily be done as Camlp4 syntax extensions, so don't
expect it to end up in the (already way too rich) core language syntax.

> Recently there has been a long discussion on this list about enhancing 
> the Unix module, and no one from INRIA has said a word about it; this is 
> very discouraging.

Again, this is essentially by lack of time.  If you want my opinion on
this discussion:

- Changing the organization and naming of the Unix library is out of
the question.  Yes, it could be organized a bit more nicely, but that
doesn't deserve breaking all the existing code that uses it.  Still,
the Caml module system makes it easy to wrap existing code in a
different interface, so everyone is welcome to come up with a
differently-structued OS interface.

- IPv6 support is on my to do list.  Missing POSIX syscalls can be
added on a case by case basis if there is clear need.  Having a full
POSIX interface just for the sake of it is low on my priorities.

- Extending the Unix library is a lot harder than what most
contributors realize, because of portability and autoconfiguration
issues.  The world isn't just the latest Linux release.  Writing and
testing the autoconf code for an extension (e.g. IPv6) is often harder
than writing the C-Caml wrapper code for it.

> Has ocaml-lib.sourceforge.net been rejected?

By whom?  It seems like ExtLib is progressing, and if it's good it
will be widely adopted by OCaml users (just like, say, Markus Mottl's
PCRE library was widely adopted).  I don't have anything to say on
this matter.

> INRIA silently working on its own library enhancements which will be 
> incompatibly replace some of the enhancements developed by the 
> community?

As a matter of fact, no, we're not.  But even if we were, these would
not "replace" the work done by others, but at most compete with it.
Users get to choose.

> Is there a plan for the future development of Caml?

The short-term plans are stabilizing the core distribution, preserve
compatibility, and refrain from major user-visible changes.  We are
discussing some internal changes e.g. on the run-time representation
of objects, but these should not change the user's view of the system.
If GODI doesn't take up, maybe we'll invest more efforts into library
packaging and installation frameworks.

> We are like the man in Kafka's novel _The Trial_, who stands for
> years at the door of the Law, and is never told whether he will be
> seen, or when, or if not, why not.

Aren't you overdoing it a little bit? :-)

- Xavier Leroy

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Benjamin Geer]

Xavier Leroy wrote:
> What do
> you prefer: that I pontificate on every idea proposed on this mailing
> list, or that I fix bugs?

I think you should do what you do best and have time to do, which is 
work on the core of OCaml, and delegate the development of the standard 
libraries to a community structure, as Alex Baretta proposed.  I think 
the community has shown that it can do at least as good a job as INRIA 
at developing the standard libraries, and (more importantly) has more 
time to do so and is much more interested in doing so.

> As I said above, the preferred way to contribute to Caml is through
> independent libraries and tools,

It is not in anyone's interest for there to be different competing 
versions of the Unix module, just to take one example.  It is much 
easier to reuse code (or just to read other people's code) if there is 
one standard library module for each of the most basic problem domains. 
  I don't mind seeing several different XML parsers, but it makes 
programmers' lives very difficult if there are several different 
versions of, say, List, all incompatible with each other.

>>Has ocaml-lib.sourceforge.net been rejected?
> 
> By whom?  It seems like ExtLib is progressing, and if it's good it
> will be widely adopted by OCaml users (just like, say, Markus Mottl's
> PCRE library was widely adopted).  I don't have anything to say on
> this matter.

If I understand correctly, ExtLib changes the behaviour of certain 
standard library modules in a way that's incompatible with the official 
distribution.

>>INRIA silently working on its own library enhancements which will be 
>>incompatibly replace some of the enhancements developed by the 
>>community?
> 
> As a matter of fact, no, we're not.  But even if we were, these would
> not "replace" the work done by others, but at most compete with it.
> Users get to choose.

Users emphatically do not want to have to choose between using the 
standard library and using a third-party library.  This forces them to 
place a bet: which library is more likely to provide more useful 
features in the future?  This is surely one reason why ExtLib has not 
been more actively developed and more widely adopted.

This problem would be solved if INRIA allowed the community to take 
responsibility for the standard libraries.

Ben

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Alex Baretta]

Benjamin Geer wrote:

> Users emphatically do not want to have to choose between using the 
> standard library and using a third-party library.  This forces them to 
> place a bet: which library is more likely to provide more useful 
> features in the future?  This is surely one reason why ExtLib has not 
> been more actively developed and more widely adopted.
> 
> This problem would be solved if INRIA allowed the community to take 
> responsibility for the standard libraries.
> 
> Ben

I agree. And, let me add, Inria can get quite a bit of resources, 
financial and human, by delegating to the community. We are willing to 
participate, and like us a lot of others.

Xavier, what you guys must do is not pontificate but define once and for 
all the official role of the community in relation to Inria and to the 
Caml team. Hey, after all we are as eager as you guys to see Ocaml grow 
and thrive. But the effort cannot start from the community. It must be 
backed by authoritative leaders, M. Xavier Leroy being a reasonable 
candidate. Take advantage of the opportunity of tapping the community's 
time and work for the benefit of Ocaml as a whole: research project, 
industrial product, free-software community. See what Mozilla has been 
to Netscape.

Alex

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Markus Mottl]

On Thu, 18 Mar 2004, Alex Baretta wrote:
> Xavier, what you guys must do is not pontificate but define once and
> for all the official role of the community in relation to Inria and
> to the Caml team.

Well, to add my two cents to this discussion, I don't think we can say
"you guys must do", the simple reason being that the question is rather
whether they "can do" (in terms of time/resources).

I mostly agree with Xavier that the "Cathedral style" is the better choice
for the development of the language and compilers.  I also believe that
the standard libraries shipped with the compiler should remain in the
"Cathedral", too.

But I also agree with Alex that INRIA should more clearly define
standards that give the community some stability what concerns the
way of contributing.  This is an age-old topic!  Some kind of package
management in the spirit of GODI would be very nice indeed, and I think
that this should also become part of the "Cathedral", because it would
otherwise not take off easily.  Package management is such a basic and
important tool that really everybody using OCaml would need.

As an incentive to INRIA, just imagine how much peace and time for
research you could have with good, portable package management: no more
silly user requests about adding more stuff to the standard libraries!

What concerns other contributions, be it datastructures, more fully
featured system libraries, etc., this is all too specific to be done in
a cathedral and should therefore remain part of the "Bazaar".  I don't
expect INRIA to develop or maintain such libraries for us (even though
I'd be very grateful :-).

Regards,
Markus

-- 
Markus Mottl          http://www.oefai.at/~markus          markus@oefai.at

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

Re: [Caml-list] Structuring the Caml community

[Christophe TROESTLER]

Hi,

Here is my grain of salt about this issue.

On Fri, 19 Mar 2004, oliver@first.in-berlin.de (Oliver Bandel) wrote:
> 
> "The community" [...] is not orgenized enough to set up such a website.

On Thu, 18 Mar 2004, Richard Jones <rich@annexia.org> wrote:
> 
> [...] except to say that my company would be prepared to fund a
> [virtual] server and put a little time into developing this repository.

On Thu, 18 Mar 2004, Alex Baretta <alex@baretta.com> wrote:
> 
> a central repository would be cool, and my company, too, would help
> finance it or staff it.

Interested people please go ahead!  Why not have two (or more)
machines that are mirror of each other?  Also, one could reuse the
Savanah software so as to provide development support, forums,
documentation,... -- the list of available Caml packages could
automatically be computed from the projects.  Moreover dependencies
with other project could conveniently be generated from META (or
other) files and be rendered on-line as links.

On Thu, 18 Mar 2004, Markus Mottl <markus@oefai.at> wrote:
> 
> Some kind of package management in the spirit of GODI would be very
> nice indeed, and I think that this should also become part of the
> "Cathedral", because it would otherwise not take off easily.
> Package management is such a basic and important tool that really
> everybody using OCaml would need.

I agree with Markus here.  Not only coming with the standard
distribution would make it the de facto standard but, what is more
important, INRIA developers probably know more than anybody else about
the various portability issues.  Indeed I am not sure how well GODI or
findlib work on M$ Win32 for example.  Also, one needs to cooperate
with Debian (or Redhat,...) packagers -- they have some experience and
it would be good that the package system integrates well with their
efforts.  Finally, there should exist some minimal Makefile or such so
that when one library binds to C/Fortran/... code, it is "easy" to do
cross platform compilation.  Lots of us I believe only have access to
few of the platforms that OCaml supports ; tools and guidelines would
be very helpful.

My 2¢,
ChriS

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

Re: [Caml-list] Structuring the Caml community

[Yamagata Yoriyuki]

From: Christophe TROESTLER <debian00@tiscali.be>
Subject: Re: [Caml-list] Structuring the Caml community
Date: Fri, 19 Mar 2004 11:58:12 +0100 (CET)

> On Thu, 18 Mar 2004, Alex Baretta <alex@baretta.com> wrote:
> > 
> > a central repository would be cool, and my company, too, would help
> > finance it or staff it.
> 
> Interested people please go ahead!  Why not have two (or more)
> machines that are mirror of each other?  Also, one could reuse the
> Savanah software so as to provide development support, forums,
> documentation,... -- the list of available Caml packages could
> automatically be computed from the projects.  Moreover dependencies
> with other project could conveniently be generated from META (or
> other) files and be rendered on-line as links.

This kind of move is great indeed.  Actually, I am considering moving
away Camomile from Sourceforge.  Souceforge is unreachable from here
more than half a time, which impedes a development.  I have purchased
a hosting service already, but it is really cheap one and does not
provide CVS and so on.

I will also welcome donation of hosting specific to Camomile.  If you
are interested, please contact to me.

--
Yamagata Yoriyuki

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

[Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Alain.Frisch]

On Thu, 18 Mar 2004, Alex Baretta wrote:

> Xavier, what you guys must do is not pontificate but define once and for
> all the official role of the community in relation to Inria and to the
> Caml team.

Isn't it precisely what Xavier did in his last mail to the list ?

In my opinion, the problem does not come from the Caml team, but from the
Caml community. The community needs to be more structured, define its
goals, organize discussions, and develop missing tools. Do we really need
an intervention from Above to create a structure that would allow to
foster collaborative work within the community ?  There is a common
interest, collaboration shouln't be impossible.

It would be great to see one of the companies committed to OCaml setting
up a "community web site", lauching specific mailing lists / forums to
discuss technical issues (like "best practices" for packaging libraries)
and less technical ones ("shall we better have a wiki or blogs to make
the community visible ?"), and organizing a somewhat formal system to
reach conclusions in a bounded amount of time (vote ?). Then publish the
results, and call for participation if some resources are necessary to
develop or set up something. This does not seem out of reach, we "just"
need someone to take some responsibility and organize the process. Many
people will be happy to help if some initial impulsion is given.


-- Alain

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

Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Oliver Bandel]

On Fri, Mar 19, 2004 at 12:44:24AM +0100, Alain.Frisch@ens.fr wrote:
> On Thu, 18 Mar 2004, Alex Baretta wrote:
> 
> > Xavier, what you guys must do is not pontificate but define once and for
> > all the official role of the community in relation to Inria and to the
> > Caml team.
> 
> Isn't it precisely what Xavier did in his last mail to the list ?
> 
> In my opinion, the problem does not come from the Caml team, but from the
> Caml community. The community needs to be more structured, define its
> goals, organize discussions, and develop missing tools. Do we really need
> an intervention from Above to create a structure that would allow to
> foster collaborative work within the community ?  There is a common
> interest, collaboration shouln't be impossible.


Yes, that's the point.
"The community" is discussing since years that their software
should be part of the OCaml distri but is not orgenized enough
to set up such a website.

Not able to do that, but interested in hacking in the core
of OCaml?!

Please, don't let such people hacking around in the core...!


So, first results in what we need (another unix-lib, maybe
an additional Unix2-lib, which can be added to Unix-lib
and the other stuff we need...).

BTW.: Such additions like Hashtbl.fold are much more qualified
      for going into the Caml-Lib than (the relatively easy to achieve)
      calls to some Unix-API-calls.
      And this Hashtbl.fold was added some vesions ago...
      ... so it was better to add this than wasting time in
      adding Unix-API-stuff.
      This  can be done by external additional unix2-lib developpers.

Ciao,
   Oliver

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

Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Eric Stokes]

I've done a bit of looking around, and comparing our (Ocaml's) web 
presence with perl's.
I've been trying to boil things down a bit to something more 
fundamental, so here is my humble attempt :P

The structural components of the web presence for a language seem to be.
1. The overall index. A place where all the junk associated with the 
language lives,
a good place to point a beginner, or a pointy haired boss. Should 
contain some high
level description of what the language is like, and some general 
fanfare, logos, etc. Should
also sit on a dns name closely related to the name of the language.

Should always have links to
- Documentation, tutorials, high level descriptions (for the pointy 
haired ones (pls excuse my dilbert references))
- A compiler download
- An index of libraries written in the language
- A forum for communication with other members of the community 
(mailing list, wiki, irc, forum, whatever)
- News about the language

2. The documentation, which can be spread out in various places, and in 
various formats, so long as
most all of it occurs no more than 3 levels of indirection (or so) away 
from the index.

3. Some index (or indexes) of libraries available for the language. One 
index is usually better, but if there are
two they tend to mirror each-other anyway (witness the hump, and the 
link database).

Given all this, I claim that the Ocaml web presence is actually pretty 
good. See embedded.

On Mar 18, 2004, at 3:44 PM, Alain.Frisch@ens.fr wrote:

> It would be great to see one of the companies committed to OCaml 
> setting
> up a "community web site"

(the index site, see #1)
http://www.ocaml.org/

Actually is a very good index site, almost on par with perl's. Has all 
the relevant requirements,
I like the logo/fanfare better than perl's (what can I say, its a cool 
picture). The only area
where it really lacks is the news section. The news items are old, 
which makes it look like
there is nothing happening with the language community, which is in 
fact, not true.
I can sympathize with the effort required to correctly maintain a 
website (as I maintain several),
and I'd say that INRIA is doing a pretty darn good job with the limited 
resources that they have.
	With respect to the datedness of the news items, There is probably a 
clean way for the community
to have some input about what goes up there. My first crack at the 
problem would be to have the news
part of the page included by an SSI or similar, and have a web 
interface by which members of the
community could propose new news items, subject to approval by INRIA. 
That would leave INRIA
only with the task of reading and approving new news items, which as 
long as the
approval interface is clean and simple seems to me to be less work than 
actually writing them.

> , lauching specific mailing lists / forums to
> discuss technical issues (like "best practices" for packaging 
> libraries)
> and less technical ones

(the mailing list)
caml-list@inria.fr

and lots of other off site ones besides that.

> ("shall we better have a wiki or blogs to make
> the community visible ?"),

A wiki is not a bad idea at all

>  and organizing a somewhat formal system to
> reach conclusions in a bounded amount of time (vote ?). Then publish 
> the
> results, and call for participation if some resources are necessary to
> develop or set up something.

I'm with Gerd on this one. Formal systems develop out of need, and I 
don't
see the need. Our web presence is pretty organized. INRIA has done a 
good job
with the index, and the community has provided a pretty good index of 
software.
Honestly, I'm a bit in awe of all the fuss on this thread. What 
specifically is wrong
with the link database, or the hump? There is a metric fuckton (to use 
a colloquialism)
of high quality libraries and documentation indexed on both of them! 
GODI looks promising,
personally I commit to adding the libraries I maintain to GODI soon.

> This does not seem out of reach, we "just"
> need someone to take some responsibility and organize the process. Many
> people will be happy to help if some initial impulsion is given.
>

On the community side GPS (Gerd Stolpmann) has been at this for years, 
and its had a
very positive effect on things. I suggest interested parties check out 
his web site, join the GODI
mailing list, check out the link database, etc.. He is leading in the 
direction you all seem to want to go,
and he has a lot of the work done already!

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

Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Benjamin Geer]

Eric Stokes wrote:
> (the index site, see #1)
> http://www.ocaml.org/
> 
> Actually is a very good index site, almost on par with perl's. Has all 
> the relevant requirements,

I think it's an embarrassment.  It's an unmaintained site that hasn't 
updated since 2002.  It's actually worse than no site at all, because it 
contains links to dead projects (e.g. the Caml Development Kit and the 
OCaml IRC Server, which doesn't even exist anymore).  As you point out, 
the news items haven't been updated since 2002, which strongly gives the 
impression that Caml is completely dead.  Worst of all, it uses the word 
'hacker', which to most managers means 'criminal that tries to attack my 
servers'.  Whoever created this site would be doing the Caml community a 
great service by taking it off the web.  The caml.inria.fr site is ugly, 
but at least it's correct and up to date.

Ben

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

Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Matthew O'Connor]

Benjamin Geer wrote:
> Eric Stokes wrote:
> 
>> (the index site, see #1)
>> http://www.ocaml.org/
>>
>> Actually is a very good index site, almost on par with perl's. Has all 
>> the relevant requirements,
> 
> 
> I think it's an embarrassment.  It's an unmaintained site that hasn't 
> updated since 2002.  
<snip>
> As you point out, 
> the news items haven't been updated since 2002, which strongly gives the 
> impression that Caml is completely dead.  

This is also especially bad for people like me who didn't know until 
recently that it's not the official site (but there's no mention on 
caml.inria.fr that it is).

Oh, and it's the first hit on Google for 'ocaml'.


Matt

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

Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Eric Stokes]

And what makes all that you've said really bad is that www.ocaml.org is 
the first site I found. And I've found
it referenced in lots of other places. I still claim that the current 
www.ocaml.org site HAS the right idea,
and has a decent format. It isn't perfect, but what is. If some of the 
links to dead end projects were cleaned
off it, and the news items were updated, it would be a very good site.

On Mar 19, 2004, at 2:34 PM, Benjamin Geer wrote:

> Eric Stokes wrote:
>> (the index site, see #1)
>> http://www.ocaml.org/
>> Actually is a very good index site, almost on par with perl's. Has 
>> all the relevant requirements,
>
> I think it's an embarrassment.  It's an unmaintained site that hasn't 
> updated since 2002.  It's actually worse than no site at all, because 
> it contains links to dead projects (e.g. the Caml Development Kit and 
> the OCaml IRC Server, which doesn't even exist anymore).  As you point 
> out, the news items haven't been updated since 2002, which strongly 
> gives the impression that Caml is completely dead.  Worst of all, it 
> uses the word 'hacker', which to most managers means 'criminal that 
> tries to attack my servers'.  Whoever created this site would be doing 
> the Caml community a great service by taking it off the web.  The 
> caml.inria.fr site is ugly, but at least it's correct and up to date.
>
> Ben
>
> -------------------
> 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

Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar)

[Karl Zilles]

Eric Stokes wrote:
> And what makes all that you've said really bad is that www.ocaml.org is 
> the first site I found. And I've found
> it referenced in lots of other places. I still claim that the current 
> www.ocaml.org site HAS the right idea,
> and has a decent format. It isn't perfect, but what is. If some of the 
> links to dead end projects were cleaned
> off it, and the news items were updated, it would be a very good site.

Yes.

I just mailed the maintainer:

> There is currently a discussion about the ocaml.org web page going on in the ocaml mailing list.
> 
> Someone points out that the lack of updates in the news section makes it looks like ocaml is a dead language.  Since there is no indication on ocaml.org that it is not an "official" ocaml page, and since it is currently the #1 hit when you search for ocaml on google...

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

ocaml.org (was: Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar))

[Richard Jones]

On Fri, Mar 19, 2004 at 11:03:35AM -0800, Eric Stokes wrote:
> (the index site, see #1)
> http://www.ocaml.org/
>
> The only area where it really lacks is the news section. The news
> items are old, which makes it look like there is nothing happening
> with the language community, which is in fact, not true.

Perhaps a (T)Wiki?  One of the TWiki core developers is in fact very
interested in OCaml and might be persuaded to set something up, but it
would obviously have to be part of / closely associated with the
ocaml.org domain.

BTW, two things about ocaml.org:

(1) Who owns it?  It doesn't look like it's associated with INRIA
in any way (registered to someone in .AU).

(2) Do you think we could set up the v-hosting correctly so that
http://ocaml.org would do the right thing.  This is very
unprofessional and confusing.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

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

Re: ocaml.org (was: Re: [Caml-list] Structuring the Caml community (Re: OCaml's Cathedral & Bazaar))

[Richard Jones]

On Sat, Mar 20, 2004 at 11:44:35AM +0100, Henri DF wrote:
> at some point last year when xavier leroy had asked on this list 
> volunteers to take over management of www.ocaml.org, i had offered to do 
> so, but the owner of the domain never replied.... so this never happened.

This sounds like a problem then ...

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
MAKE+ is a sane replacement for GNU autoconf/automake. One script compiles,
RPMs, pkgs etc. Linux, BSD, Solaris. http://www.annexia.org/freeware/makeplus/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Gerd Stolpmann]

This whole discussion is interesting because it shows that the users of
ocaml have expectations for a good language environment. There seems to
be some confusion, however, that the core ocaml product is not a
complete environment, and that third-party tools and libraries are
needed. The confusion is that it becomes unclear who can be made
responsible for improving the environment. The Unix module was mentioned
as an example.

For me, I am quite happy that the Cathedral limits itself, and that it
does not try to incorporate more components than needed. There would be
also lots of problems in a world where the Cathedral delivers all
important components, e.g. it would be harder to get bugs fixed. So
please, don't dream of that. It might turn into a nightmare.

In the case of Unix, I do not see any advantages of developing
improvements within the Cathedral, this can really be done on the
Bazaar. Maybe there are some corner cases (e.g. IPv6 sockets) that would
require cooperation, but my experience is that INRIA finally accepts
good proposals (e.g. remember of DLLs, users urged INRIA to implement
it).

Of course, the Bazaar needs a bit more organisation, and as you know, I
wrote software supporting this: Findlib and GODI. Findlib is mature
software, even from a professional point of view, and many people are
already using it. GODI is already usable. So the technical solutions
exist (that means: THERE IS A CPAN FOR OCAML, although it uses a
different implementation for a different language, and does not match
C.*AN), and the remaining question is: Does the community accept it?

I don't mean technical acceptance here, because this is usually not the
barrier keeping people away when the software works, but acceptance in a
social way: GODI would be accepted when it would be the usual way to
install ocaml. Of course, this a quite ambitious goal, but also the
natural one for such a project. I am glad to hear encouraging words from
Xavier Leroy. 

In order to reach this goal, a number of questions should be answered
(best as some kind of community process):

- How can people participate (add packages, fix bugs, improve the base
  software)?

- How can the quality be ensured?

- How are decisions made?

- How can the platform be kept open?

My vision for GODI is that it limits itself to a platform for software
authors, i.e. some kind of distribution channel, and organises things
only where necessary (the question of policies). I don't want to build a
second Cathedral that fixes the errors of the first. (So there will be
place for an alternate stdlib if people want it, but it won't replace
the official one.)

Expect an announcement about a mailing list for the details of this
discussion soon. Of course, we can already start on caml-list, it's you
who decides.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Kenneth Knowles]

> Of course, the Bazaar needs a bit more organisation, and as you know, I
> wrote software supporting this: Findlib and GODI. Findlib is mature
> software, even from a professional point of view, and many people are
> already using it. GODI is already usable. So the technical solutions
> exist (that means: THERE IS A CPAN FOR OCAML, although it uses a
> different implementation for a different language, and does not match
> C.*AN), and the remaining question is: Does the community accept it?

CPAN is much more than an automatic-installation tool.  The social organization
of the perl namespaces is by far the most important aspect of CPAN.  The module
to automatically install dependencies etc is just a minor convenience next to
the over-arching organizational structure.  My comments with regards to
namespacing and modules are focused on how to present a wide range of extended
libraries in a hierarchy that seems "standard" to someone browsing the archives,
to inspire confidence in the completeness and authoritativeness of the archive.
GODI doesn't (and doesn't intend to, so that's fine) solve this issue, but
clearly the auto-installer on top of such an organization is ready.

Kenn

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

On Thu, Mar 18, 2004 at 04:47:42PM -0800, Kenneth Knowles wrote:
> 
> > Of course, the Bazaar needs a bit more organisation, and as you know, I
> > wrote software supporting this: Findlib and GODI. Findlib is mature
> > software, even from a professional point of view, and many people are
> > already using it. GODI is already usable. So the technical solutions
> > exist (that means: THERE IS A CPAN FOR OCAML, although it uses a
> > different implementation for a different language, and does not match
> > C.*AN), and the remaining question is: Does the community accept it?
> 
> CPAN is much more than an automatic-installation tool.  The social organization
> of the perl namespaces is by far the most important aspect of CPAN.  The module
> to automatically install dependencies etc is just a minor convenience next to
> the over-arching organizational structure.  My comments with regards to
> namespacing and modules are focused on how to present a wide range of extended
> libraries in a hierarchy that seems "standard" to someone browsing the archives,
> to inspire confidence in the completeness and authoritativeness of the archive.
> GODI doesn't (and doesn't intend to, so that's fine) solve this issue, but
> clearly the auto-installer on top of such an organization is ready.

Indeed.  Being a diehard Debian user myself I always install CPAN
modules and OCaml modules from Debian directly.  This solves any
dependency problems, and integrates with the operating system, and
automatically upgrades modules when new versions are available.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://www.YouUnlimited.co.uk/ - management courses

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Gerd Stolpmann]

On Fre, 2004-03-19 at 01:47, Kenneth Knowles wrote:
> > Of course, the Bazaar needs a bit more organisation, and as you know, I
> > wrote software supporting this: Findlib and GODI. Findlib is mature
> > software, even from a professional point of view, and many people are
> > already using it. GODI is already usable. So the technical solutions
> > exist (that means: THERE IS A CPAN FOR OCAML, although it uses a
> > different implementation for a different language, and does not match
> > C.*AN), and the remaining question is: Does the community accept it?
> 
> CPAN is much more than an automatic-installation tool.  The social organization
> of the perl namespaces is by far the most important aspect of CPAN.  The module
> to automatically install dependencies etc is just a minor convenience next to
> the over-arching organizational structure.  My comments with regards to
> namespacing and modules are focused on how to present a wide range of extended
> libraries in a hierarchy that seems "standard" to someone browsing the archives,
> to inspire confidence in the completeness and authoritativeness of the archive.
> GODI doesn't (and doesn't intend to, so that's fine) solve this issue, but
> clearly the auto-installer on top of such an organization is ready.

This is also my point: We need some organization. Of course, as we don't
have namespaces in ocaml, so this aspect does not apply (and it would be
nonsense to implement namespaces only to have something people can talk
about). But there are lots of other aspects, e.g. which libraries are
missing, how accessibility of software can be ensured, etc.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

[Caml-list] Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Benjamin Geer]

Gerd Stolpmann wrote:
> In order to reach this goal, a number of questions should be answered
> (best as some kind of community process):
> 
> - How can people participate (add packages, fix bugs, improve the base
>   software)?
> 
> - How can the quality be ensured?
> 
> - How are decisions made?
> 
> - How can the platform be kept open?

How about a structure like this:

    * A GCC-like steering committee composed of very
      experienced, respected Caml developers, who would be
      responsible for setting overall policy and resolving
      conflicts in the community.

    * Mozilla-like module owners, designated by the
      steering committee.  Module owners would review and
      accept patches for their modules after public
      discussion.

    * Rotating GCC-like release managers, also chosen by the
      steering committee.  The release managers would be
      responsible for coordinating regular releases and
      determining when each release was ready.

People could participate by posting proposals to a mailing list; 
discussion would ensue, and the relevant module owner would be expected 
to accept or reject the proposal within a reasonable amount of time, 
taking into account the consensus on the list.  A Mozilla-like review 
process could be used: the author submits a patch, the module owner 
reviews it and requests changes, and they iterate until the module owner 
is satisfied.  For major enhancements, a more formal, detailed proposal 
format could be used, like Python's PEPs.

If INRIA was willing, such a structure could also take over development 
of the standard libraries.

Ben

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

[Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Gerd Stolpmann]

On Fre, 2004-03-19 at 13:44, Benjamin Geer wrote:
> Gerd Stolpmann wrote:
> > In order to reach this goal, a number of questions should be answered
> > (best as some kind of community process):
> > 
> > - How can people participate (add packages, fix bugs, improve the base
> >   software)?
> > 
> > - How can the quality be ensured?
> > 
> > - How are decisions made?
> > 
> > - How can the platform be kept open?
> 
> How about a structure like this:
> 
>     * A GCC-like steering committee composed of very
>       experienced, respected Caml developers, who would be
>       responsible for setting overall policy and resolving
>       conflicts in the community.

I hope we don't need such a committee. First we should try to seek a
consensus. I suppose this will almost always be successful, and over
time we will have a situation where the voices of some people will have
more weight than the voices of others, simply because they are naturally
respected.

So I would suggest to postpone such a committee until it is really
needed, when everything else failed.

>     * Mozilla-like module owners, designated by the
>       steering committee.  Module owners would review and
>       accept patches for their modules after public
>       discussion.

GODI currently has packages which are comparable with modules. Every
package has a maintainer. Initially, the maintainer is the person who
adds the package to the repository.

Technically, I don't plan any sort of access control, i.e. everybody
with an account can change everything. Of course, it is bad practise to
change the package maintained by somebody else without notification.

I simply believe that a good practise of cooperation is better than
formal rules.

>     * Rotating GCC-like release managers, also chosen by the
>       steering committee.  The release managers would be
>       responsible for coordinating regular releases and
>       determining when each release was ready.

It is currently unclear for me whether we should have releases at all.
GODI has the ability to update every package separately, so what is a
release?

Of course, for the outer world a formal release is something valuable.

We definitely need a process to determine when each package is ready for
release. We'll see how to do that.

> People could participate by posting proposals to a mailing list; 
> discussion would ensue, and the relevant module owner would be expected 
> to accept or reject the proposal within a reasonable amount of time, 
> taking into account the consensus on the list.  A Mozilla-like review 
> process could be used: the author submits a patch, the module owner 
> reviews it and requests changes, and they iterate until the module owner 
> is satisfied.  For major enhancements, a more formal, detailed proposal 
> format could be used, like Python's PEPs.

There is now a mailing list, see the separate announcement.

I think we will see whether we need formal rules or not. This depends a
lot of parameters that are currently uncertain, e.g. the number of
developers.

> If INRIA was willing, such a structure could also take over development 
> of the standard libraries.

I guess they have their own internal process which is incompatible with
such a structure.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Matt Gushee]

On Fri, Mar 19, 2004 at 06:30:12PM +0100, Gerd Stolpmann wrote:

> I hope we don't need such a committee. First we should try to seek a
> consensus. I suppose this will almost always be successful, and over
> time we will have a situation where the voices of some people will have
> more weight than the voices of others, simply because they are naturally
> respected.
> 
> So I would suggest to postpone such a committee until it is really
> needed, when everything else failed.

Yes. As a veteran of many committees (though in a very different context
than this), I can testify that the structure and process of an
organization can far too easily become an occupation in itself. If you
have to decide how to form a committee, well that leads (backward) to
the need to decide how to decide ... and surely one of the reasons Open
Source has been so successful is that formal organization has been kept
to a minimum, making it very easy for motivated people to get involved.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

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

Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Vasili Galchin]

Linus Torvalds

Eric Raymond ...

--- Matt Gushee <mgushee@havenrock.com> wrote:
> On Fri, Mar 19, 2004 at 06:30:12PM +0100, Gerd
> Stolpmann wrote:
> 
> > I hope we don't need such a committee. First we
> should try to seek a
> > consensus. I suppose this will almost always be
> successful, and over
> > time we will have a situation where the voices of
> some people will have
> > more weight than the voices of others, simply
> because they are naturally
> > respected.
> > 
> > So I would suggest to postpone such a committee
> until it is really
> > needed, when everything else failed.
> 
> Yes. As a veteran of many committees (though in a
> very different context
> than this), I can testify that the structure and
> process of an
> organization can far too easily become an occupation
> in itself. If you
> have to decide how to form a committee, well that
> leads (backward) to
> the need to decide how to decide ... and surely one
> of the reasons Open
> Source has been so successful is that formal
> organization has been kept
> to a minimum, making it very easy for motivated
> people to get involved.
> 
> -- 
> Matt Gushee                 When a nation follows
> the Way,
> Englewood, Colorado, USA    Horses bear manure
> through
> mgushee@havenrock.com           its fields;
> http://www.havenrock.com/   When a nation ignores
> the Way,
>                             Horses bear soldiers
> through
>                                 its streets.
>                                 
>                             --Lao Tzu (Peter Merel,
> trans.)
> 
> -------------------
> 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! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Ville-Pertti Keinonen]

On Mar 20, 2004, at 8:49 AM, Vasili Galchin wrote:

I'm not sure what you're presenting these names as examples of, but 
IMHO...

> Linus Torvalds

He's done good job maintaining the Linux kernel, but maybe wouldn't be 
that good of a compiler-writer (probably just lack of experience in 
that area), see e.g.:

http://gcc.gnu.org/ml/gcc/2002-08/msg00544.html

The single lead developer model is a good development model, though.

> Eric Raymond ...

It's nice to have someone extroverted speak for you when you agree with 
him, but people who feel a need to insult those that don't agree with 
them (see http://www.catb.org/~esr/aim/ for a non-technical example) 
are probably not the most trustworthy community-builders...

If anything, the OCaml developers seem like one of the most reasonable 
groups of developers I've seen (not that I've actually seen any of them 
in person).  The core works well, and its development methods seem to 
be working.

As for the community/library side...planning on committees or on the 
lack thereof is probably premature.  Successful communities don't seem 
to organize by planning, but by accident.  Once there is sufficient 
weight behind the effort, that's when it should be evident what needs 
to be adjusted; nothing needs to be set in stone from the start.

Personally, I don't think becoming popular is important, or that 
something has failed if it doesn't.  Besides, OCaml actually already 
seems to be gaining quite a bit of attention.

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

Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Vasili Galchin]

Hello,

  The reason I mention these two names is because we
started to "OCaml's Cathedral and Bazaar" metaphor on
this thread. I am not saying these guy are panacea. I
am merely saying that OCaml seems to be somewhat
directionless and there are a lot of loose ends, e.g.
existing code that has not been incorporated into the
mainstream. On the other hand, there are also a lot of
very talented people working on/using OCaml. I would
sincerely like to see OCaml get more into industry.

Regards, Vasili

--- Ville-Pertti Keinonen <will@exomi.com> wrote:
> 
> On Mar 20, 2004, at 8:49 AM, Vasili Galchin wrote:
> 
> I'm not sure what you're presenting these names as
> examples of, but 
> IMHO...
> 
> > Linus Torvalds
> 
> He's done good job maintaining the Linux kernel, but
> maybe wouldn't be 
> that good of a compiler-writer (probably just lack
> of experience in 
> that area), see e.g.:
> 
> http://gcc.gnu.org/ml/gcc/2002-08/msg00544.html
> 
> The single lead developer model is a good
> development model, though.
> 
> > Eric Raymond ...
> 
> It's nice to have someone extroverted speak for you
> when you agree with 
> him, but people who feel a need to insult those that
> don't agree with 
> them (see http://www.catb.org/~esr/aim/ for a
> non-technical example) 
> are probably not the most trustworthy
> community-builders...
> 
> If anything, the OCaml developers seem like one of
> the most reasonable 
> groups of developers I've seen (not that I've
> actually seen any of them 
> in person).  The core works well, and its
> development methods seem to 
> be working.
> 
> As for the community/library side...planning on
> committees or on the 
> lack thereof is probably premature.  Successful
> communities don't seem 
> to organize by planning, but by accident.  Once
> there is sufficient 
> weight behind the effort, that's when it should be
> evident what needs 
> to be adjusted; nothing needs to be set in stone
> from the start.
> 
> Personally, I don't think becoming popular is
> important, or that 
> something has failed if it doesn't.  Besides, OCaml
> actually already 
> seems to be gaining quite a bit of attention.
> 
> -------------------
> 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! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Benjamin Geer]

Gerd Stolpmann wrote:
> I hope we don't need such a committee. First we should try to seek a
> consensus. I suppose this will almost always be successful, and over
> time we will have a situation where the voices of some people will have
> more weight than the voices of others, simply because they are naturally
> respected.
> 
> So I would suggest to postpone such a committee until it is really
> needed, when everything else failed.

OK.  I think eventually, though, we will need an explicit process for 
resolving conflicts.

On some projects, the process is simply that when there is a conflict, 
the leader makes a decision.  Good free-software project leaders are 
mainly people whose judgement is respected, and who are good at 
mediating between people with conflicting opinions.  I don't think we 
have one single person who would clearly be the best one for that role, 
so I suggested a group, which seems to work well for GCC.

Another way is to vote, as Debian does.  But you can't vote every day; 
there still need to be people who are trusted by the community to settle 
important questions.  In Mozilla, these are module owners and 
super-reviewers.

> GODI currently has packages which are comparable with modules. Every
> package has a maintainer. Initially, the maintainer is the person who
> adds the package to the repository.

What concerns me is that we could end up with redundant packages in the 
repository.  I think it would be awful to have five different competing 
versions of the Unix module or the List module, or five different 
attempts to implement Unicode support.  I think the structure of the 
project should require people to pool their efforts.  On the Linux 
kernel, this is done very simply: since people working on the same 
problem know that only one patch will be accepted into the official 
kernel, they have a strong incentive to cooperate.  If they can't 
cooperate because their work is too different, Linus chooses what he 
thinks is the better solution.  This works because Linus takes into 
account the consensus of the community, but I don't think it would work 
without Linus, or without a Linus-like process.

> I simply believe that a good practise of cooperation is better than
> formal rules.

Not everyone knows how to cooperate well.  It may be better to say 
explicitly what a good practice of cooperation is.

Ben

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

Re: [Caml-list] Re: Proposed community structure (was Re: OCaml's Cathedral & Bazaar)

[Gerd Stolpmann]

On Sam, 2004-03-20 at 12:23, Benjamin Geer wrote:
> Gerd Stolpmann wrote:
> > I hope we don't need such a committee. First we should try to seek a
> > consensus. I suppose this will almost always be successful, and over
> > time we will have a situation where the voices of some people will have
> > more weight than the voices of others, simply because they are naturally
> > respected.
> > 
> > So I would suggest to postpone such a committee until it is really
> > needed, when everything else failed.
> 
> OK.  I think eventually, though, we will need an explicit process for 
> resolving conflicts.
> 
> On some projects, the process is simply that when there is a conflict, 
> the leader makes a decision.  Good free-software project leaders are 
> mainly people whose judgement is respected, and who are good at 
> mediating between people with conflicting opinions.  I don't think we 
> have one single person who would clearly be the best one for that role, 
> so I suggested a group, which seems to work well for GCC.
> 
> Another way is to vote, as Debian does.  But you can't vote every day; 
> there still need to be people who are trusted by the community to settle 
> important questions.  In Mozilla, these are module owners and 
> super-reviewers.

All these projects you mention are much larger, and there are stronger
interests involved that want to push the whole group into certain
directions. In the short term, we will certainly not face these
problems. In the long run, however, it might turn out that we will need
some formalism. I think it is not a good idea to think about it _now_,
because nobody has here enough experience to say which kind of formalism
would be a good one.

So I think this discussion has no real basis.

> > GODI currently has packages which are comparable with modules. Every
> > package has a maintainer. Initially, the maintainer is the person who
> > adds the package to the repository.
> 
> What concerns me is that we could end up with redundant packages in the 
> repository.  I think it would be awful to have five different competing 
> versions of the Unix module or the List module, or five different 
> attempts to implement Unicode support. 

On the one hand, we have this situation already. For example, both
ocamlnet and camomile implement aspects of Unicode, but with different
intentions (ocamlnet targets at network protocols, camomile at
applications). There are also a lot of incompatible database interfaces.
Of course, it would be nice to have some cleanup here.

On the other hand, it is problematic to enforce cooperation. If GODI
tried to do that, it might happen that GODI loses overall acceptance.

So I would suggest to support any such cooperation, but not to try to
make pressure. In my opinion, the first goal of GODI is to get accepted
by distributing software that already exists, no matter whether there
are parallel solution to the same area. It may happen over time that the
need for selection arises, but let us see how this can be handled.

>  I think the structure of the 
> project should require people to pool their efforts.  On the Linux 
> kernel, this is done very simply: since people working on the same 
> problem know that only one patch will be accepted into the official 
> kernel, they have a strong incentive to cooperate.  If they can't 
> cooperate because their work is too different, Linus chooses what he 
> thinks is the better solution.  This works because Linus takes into 
> account the consensus of the community, but I don't think it would work 
> without Linus, or without a Linus-like process.

GODI is more comparable to a Linux distribution than to Linux.

> > I simply believe that a good practise of cooperation is better than
> > formal rules.
> 
> Not everyone knows how to cooperate well.  It may be better to say 
> explicitly what a good practice of cooperation is.

IMO, the normal principles apply that everybody would expect:

- Communicate the changes you are doing

- Respect the work of others

- Don't put in a selfish way your own interests over those of the whole
  group

You see, these are principles, and by nature, they are quite vague. This
is why I prefer the term "good practise", because it is better to see by
example how general norms are applied to real matters. I am not afraid
of different views on these matters and maybe conflicts that may arise,
because I feel myself able to remind people of general principles that
should be respected, and believe that people can act in a reasonable
way.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

[Caml-list] Re: OCaml's Cathedral & Bazaar

[Dmitry Bely]

Gerd Stolpmann <info@gerd-stolpmann.de> writes:

> Of course, the Bazaar needs a bit more organisation, and as you know, I
> wrote software supporting this: Findlib and GODI. Findlib is mature
> software, even from a professional point of view, and many people are
> already using it. GODI is already usable. So the technical solutions
> exist (that means: THERE IS A CPAN FOR OCAML, although it uses a
> different implementation for a different language, and does not match
> C.*AN), and the remaining question is: Does the community accept it?

Do you know if anybody tried to build GODI under Windows? Is it
theoretically possible? If not, GODI can hardly be considered as a _standard_
solution to distribute Ocaml packages...

- Dmitry Bely


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

Re: [Caml-list] Re: OCaml's Cathedral & Bazaar

[Gerd Stolpmann]

On Sam, 2004-03-20 at 14:07, Dmitry Bely wrote:
> Gerd Stolpmann <info@gerd-stolpmann.de> writes:
> 
> > Of course, the Bazaar needs a bit more organisation, and as you know, I
> > wrote software supporting this: Findlib and GODI. Findlib is mature
> > software, even from a professional point of view, and many people are
> > already using it. GODI is already usable. So the technical solutions
> > exist (that means: THERE IS A CPAN FOR OCAML, although it uses a
> > different implementation for a different language, and does not match
> > C.*AN), and the remaining question is: Does the community accept it?
> 
> Do you know if anybody tried to build GODI under Windows? Is it
> theoretically possible? If not, GODI can hardly be considered as a _standard_
> solution to distribute Ocaml packages...

There is a development version that almost works on the Cygwin port.
This means it bootstraps, and it can build various packages, but there
are some Windows-specific problems with file locking that must still be
solved. I hope I can do this soon.

For thoughts on a MinGW port, see this message:
http://caml.inria.fr/archives/200403/msg00235.html

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: [Caml-list] Re: OCaml's Cathedral & Bazaar

[brogoff]

On Sat, 20 Mar 2004, Gerd Stolpmann wrote:
> On Sam, 2004-03-20 at 14:07, Dmitry Bely wrote:
> > Do you know if anybody tried to build GODI under Windows? Is it
> > theoretically possible? If not, GODI can hardly be considered as a _standard_
> > solution to distribute Ocaml packages...
>
> There is a development version that almost works on the Cygwin port.
> This means it bootstraps, and it can build various packages, but there
> are some Windows-specific problems with file locking that must still be
> solved. I hope I can do this soon.

I haven't done any serious Windows programming in several years, but when I
did, building on Windows implicitly meant "with the MS toolchain" and
emphatically *not* with Cygwin, MinGW, etc.

Certainly, a Cygwin or MinGW port is a good step, but unless the Windows world
has changed, not having a Windows GODI in the sense I describe above will
be a hindrance to acceptance.

-- Brian

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

[Caml-list] Re: OCaml's Cathedral & Bazaar

[Alex Baretta]

Diego Olivier Fernandez Pons wrote:
> 
> Integer une bibliotheque a une distribution est un choix quasi
> irrevocable. Les mesaventures de SML sont suffisamment demonstratives
> : les differentes equipes ne sont toujours pas parvenues a se mettre
> d'accord et a implementer uniformement une norme qui change tout le
> temps alors qu'elle ne prevoit rien de plus que des tableaux, quelques
> foncteurs et des entrees sorties basiques.

Diego is right. We don't need to integrate all external contributions to 
the standard library. Yes, a central repository would be cool, and my 
company, too, would help finance it or staff it. Yet, the Caml team 
should consider some necessary completions or corrections to the 
standard library. Here are some points worth considering:

* We have functional Maps and imperative Hashtbls; we have imperative 
Queues but no functional BatchedQueues or the like. I have a 
BatchedQueue module which I'd be more than glad to contribute to the 
standard library, but it's really a half hour job anyway.

* We have data structure modules with grossly incoherent signatures:
(* Hashtbl module *)
val add : ('a, 'b) t -> 'a -> 'b -> unit

e.g. Hashtbl.add table key value

(* Map.S signature *)
val add : key -> 'a -> 'a t -> 'a

e.g. MyMap.add key value map

* Ocaml is a functional programming language but the only regular 
expression library in the standard distribution (Str) is stateful 
(hence, non-reentrant) library. A better approach that would guarantee 
an ample degree of backward compatibility would be to create and 
Str.Make functor instantiating a copy of all the state variables, so 
that multithreaded programs could instantiate a copy of Str for every 
thread. It would be something. Yet a functional regexp library is needed 
in the standard distribution.

I could probably think of a couple more issues if I had time enough. 
Anyhow, such inconsistencies and deficiencies should be avoided in 
well-thought standard library for a well thought and well supported 
"programming tool of choice for the discriminating hacker". In my 
opinion, it would be reasonable for INRIA to delegate the development of 
such a replacement standard library to a managed community project (see 
Mozilla, the Linux kernel, the Fedora project and whatnot). The 
community could do a lot to support the Ocaml development effort, if 
only there were some official protocol for cooperation with the official 
Caml team.

***

In consideration of our common belief that all Camlers are created equal 
and endowed by their License with certain unalienable rights, and that 
among these are Use, Modification, and the pursuit of Higher 
abstractions, it is their duty, to throw off such a Standard Library, 
and to provide new Modules for their future software development.

Alex "Hancock" Baretta, with some help from Tom Jefferson ;)

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Thu, Mar 18, 2004 at 12:55:43PM +0100, Diego Olivier Fernandez Pons wrote:
>     Bonjour,
> 
> > - try to build librairies with the hope that they'll one time become
> > standard (de facto, or integrated into official release) : that's
> > what we're doing with ExtLib (http://ocaml-lib.sf.net)
> 
> Autant je suis tout a fait favorable aux initiatives qui comme ExtLib
> (les deux versions), Baire, MLlib ou OCamlGraph (pour ne citer que

MLlib qui n'est pas libre cependant, et lorsque j'ai voulu en faire un
package debian, tout allait bien jusqu'au moment ou j'ai demande si une
modification de la licence etait possible, depuis, aucun de mes mails
n'a eu de reponse.

Amicalement,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 09:54:52AM +0100, Sven Luther wrote:
> On Thu, Mar 18, 2004 at 12:55:43PM +0100, Diego Olivier Fernandez Pons wrote:
> >     Bonjour,
> > 
> > > - try to build librairies with the hope that they'll one time become
> > > standard (de facto, or integrated into official release) : that's
> > > what we're doing with ExtLib (http://ocaml-lib.sf.net)
> > 
> > Autant je suis tout a fait favorable aux initiatives qui comme ExtLib
> > (les deux versions), Baire, MLlib ou OCamlGraph (pour ne citer que
> 
> MLlib qui n'est pas libre cependant, et lorsque j'ai voulu en faire un
> package debian, tout allait bien jusqu'au moment ou j'ai demande si une
> modification de la licence etait possible, depuis, aucun de mes mails
> n'a eu de reponse.

Mille excuse, j'ai evidement confondu MLlib et MLgraph. J'ai jamais eu
de problemes avec MLlib (jamais utilise non plus, donc ...).

Amicalement,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Carr]

> Industry adoption of ocaml is in earlier stages, and is not enough
> wide to push the language as fast as expected from the community.

There is a significant barrier to entry that is mostly independent of
the development model.  Here's what my boss told me when I suggested
using ocaml in a commercial product:

1. Nobody else knows the language.
2. It doesn't run on our platform.
3. It will break and we can't get support.

An open or closed development model will not by itself change the
perceptions that prevent me from using ocaml at work.  The only way I
could have overcome objections 2 and 3 would have been to show a way
to get contract support, as is available for operating system
components and commercial compilers.

Perl was so popular that it became an OS component.  gcc was so
popular that companies were willing to invest the money to turn
it into a commercial product.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

On Thu, Mar 18, 2004 at 08:12:36AM -0500, John Carr wrote:
> 1. Nobody else knows the language.
> 2. It doesn't run on our platform.
> 3. It will break and we can't get support.

These things will always be a problem until OCaml becomes (to use a
marketing term) a "whole product".  This means that it has a full
suite of supporting skills and documentation.  There are currently two
books, and a few web tutorials.  For OCaml to become a whole product
we'd need to see a few shelves full of books at the local bookstore,
and specialists in each city offering support, and major external
companies signing on.

Nevertheless, these things happen: if no one was ever an early
adopter, then nothing new would ever happen!  Perhaps your company
isn't ready to be an early adopter for risky new technologies.  Others
will adopt, and the whole product may come about eventually from this.

But, the structure of OCaml development might prevent this from
happening in the long run.  The timescales for a product to turn from
early adopter to widely adopted whole product are on the order of ten
years.  [ http://www.joelonsoftware.com/articles/fog0000000017.html ]
(It's no accident that Ruby is about ten years old, and for the first
time there's now a shelf of books on Ruby at Foyles on Charing Cross
Road).  Because of these long timescales, I believe that the process
is very sensitive to small differences along the way.  Potentially, a
small change in the OCaml development process might either kill off
adoption of OCaml, or might make it more rapid.

To give you an example of this thinking: computer languages are in a
constant race with each other to add new features.  In the last decade
I personally have gone from C compilers where the most innovative
feature might have been support for threads, or an ANSI-compatible
string library, all the way to languages like Perl where in a few
lines of code you can download a web page, parse it into a DOM and
insert the results into a database, or display it in an embedded Gtk
Mozilla widget.  The number and range of libraries that you need today
in a new computer language is just staggering to compete with what is
already available in the likes of Perl or Java SDK or .NET (Microsoft
was able to throw thousands of developers at the problem which is why
they created the whole of .NET in relatively few years - no other
company on earth has that luxury).

This means that if OCaml's development process is, on average, just
slightly slower than the average (however that would be measured) then
OCaml will NEVER overtake other languages and become widely adopted.
In this sense, an open, rapid development model is vital, and an
unresponsive team at INRIA could kill adoption, and eventually any
chances the language has of becoming widely used.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://www.YouUnlimited.co.uk/ - management courses

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Oliver Bandel]

On Thu, Mar 18, 2004 at 01:56:50PM +0000, Richard Jones wrote:
> On Thu, Mar 18, 2004 at 08:12:36AM -0500, John Carr wrote:
> > 1. Nobody else knows the language.
> > 2. It doesn't run on our platform.
> > 3. It will break and we can't get support.
> 
> These things will always be a problem until OCaml becomes (to use a
> marketing term) a "whole product".  This means that it has a full
> suite of supporting skills and documentation.  There are currently two
> books, and a few web tutorials.  For OCaml to become a whole product
> we'd need to see a few shelves full of books at the local bookstore,
> and specialists in each city offering support, and major external
> companies signing on.

Point 1 => same problem as with Linux about ten years ago

Point 2 => really not running on that platform?

Point 3 => The INRIA-cathedral will help to prevent this problem
           in the sense of "we do not allow any hacker to make
           changes in the core language"




[...]
> 
> This means that if OCaml's development process is, on average, just
> slightly slower than the average (however that would be measured) then
> OCaml will NEVER overtake other languages and become widely adopted.
> In this sense, an open, rapid development model is vital, and an
> unresponsive team at INRIA could kill adoption, and eventually any
> chances the language has of becoming widely used.

IMHO OCaml is some decades in the future... what you can do with
OCaml right now (the language, not necessarily the additional 
libraries and the programs you can find as free-software) is
much, much more powerful than what you can do in other languages.

I was astouned how powerful the language is, compared to
Perl. If I prefer OCaml to Perl, even if Perl has more libraries
and modules (via CPAN), becaus eof the power of the language,
then this is MY decision. An d I think I have reasons for this decision.

When "the other people" don't decide to use Ocaml, so that is not
my problem. Yes, it would be nice to use that language on a job,
not only in own provate projects. But I don't think that the
bazaar-method will change one of the above prejudices.

It's not a matter of the developing method, it's a matter of
hype, of marketing and many prejudices, as you also can see
on the topic of fuzzy logic.
It's bad, stupid, silly.... and functional programming....
...most people think that "functional programming" is what
imperative non-OO languages provide: They have problems
with the name "functional".
Often people think: C++ is object-oriented and C is functional.
So when you mention a functional language, people often say
it's old stuff, because you don't mention OOP.

You can't stop ignorance and prejudice with a different developing
method!


Ciao,
   Oliver

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Carr]

> > 1. Nobody else knows the language.
> > 2. It doesn't run on our platform.
> > 3. It will break and we can't get support.
>
> Point 1 => same problem as with Linux about ten years ago
> 
> Point 2 => really not running on that platform?
>
> Point 3 => The INRIA-cathedral will help to prevent this problem
>            in the sense of "we do not allow any hacker to make
>            changes in the core language"

Suppose we find a bug in ocaml that impacts our product.
Whose job is it to fix the bug?  Neither "a network of
hackers" nor "some academic researchers in France, if they
have the time" is an acceptable answer.  We pay a company
to provide us with an embedded Linux environment including
cross-compilation tools.  While in reality ocaml will be
more reliable than g++ due to the vast difference in
complexity, that doesn't overcome the fear.

Consider points 2 and 3 as axioms.  They were dictated to
me by management and were not subject to debate.  As long
as there is a shadow of a doubt about support, ocaml won't
be used where I work.

The library system is troublesome -- non-core libraries need
other libraries, which need other libraries, and so on -- but
in this case it didn't make a difference.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

On Thu, Mar 18, 2004 at 03:10:20PM -0500, John Carr wrote:
> Suppose we find a bug in ocaml that impacts our product.
> Whose job is it to fix the bug?  Neither "a network of
> hackers" nor "some academic researchers in France, if they
> have the time" is an acceptable answer.

This is really why the licensing of the compilers *does* matter.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Learning Objective CAML for C, C++, Perl and Java programmers:
http://www.merjis.com/richj/computers/ocaml/tutorial/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Jacques Garrigue]

From: Richard Jones <rich@annexia.org>
> On Thu, Mar 18, 2004 at 03:10:20PM -0500, John Carr wrote:
> > Suppose we find a bug in ocaml that impacts our product.
> > Whose job is it to fix the bug?  Neither "a network of
> > hackers" nor "some academic researchers in France, if they
> > have the time" is an acceptable answer.

Well, I understand this is hard to explain to companies.
Yet I believe that we have a good record for correcting bugs.
It is not because we are academic researchers that we don't take
seriously our responsibilities.
(Microsoft is certainly not faster, and does not offer more guarantees.)
 
> This is really why the licensing of the compilers *does* matter.

Possibly, but may I remind you that ocaml is open-source?
The QPL is a recognized open-source license, even if it isn't GPL
compatible (but almost all open-source licenses are not
GPL-compatible).
Anybody is perfectly free to release fixes and improvements for ocaml,
including binary releases, as long as they provide a patch with
respect to the corresponding version of ocaml.

For me, it's not even clear that a public CVS based on ocaml would be
a problem: CVS actually works by creating diffs.

Could you explain by which mechanism a different license would help in
making ocaml's maintenance more reliable for companies?

Also note that all this is irrelevant to libraries, which are already
released under a slightly relaxed version of the LGPL.

Jacques Garrigue

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[skaller]

On Fri, 2004-03-19 at 12:30, Jacques Garrigue wrote:
> From: Richard Jones <rich@annexia.org>
> > On Thu, Mar 18, 2004 at 03:10:20PM -0500, John Carr wrote:
> > > Suppose we find a bug in ocaml that impacts our product.
> > > Whose job is it to fix the bug?  Neither "a network of
> > > hackers" nor "some academic researchers in France, if they
> > > have the time" is an acceptable answer.
> 
> Well, I understand this is hard to explain to companies.
> Yet I believe that we have a good record for correcting bugs.
> It is not because we are academic researchers that we don't take
> seriously our responsibilities.
> (Microsoft is certainly not faster, and does not offer more guarantees.)

Falls over laughing... no comparison! I found 3 bugs in 
Ocaml compiler. The first one took a while to convince the team
there really was a bug .. several versions were unusable.
But once convinced, the fix in one day. Two other bugs
fixed in several hours.

Experience with MS: a complex application using Borland C++
had to be converted to MS due to some moron accountant
manager idiot. MSVC++ couldn't handle it due to both serious
bugs and size limitations.

Yes, the company was VERY BIG player with MS contract support
and ISO quality assurance procedures (falls over laughing again)
yes the MS representative was on site quickly enough to
examine the problem.

What did he do? Report the bug (which we already knew) to the
MSVC++ compiler team in Redmond. That's it. Even the representative
got no feedback from them, let alone a fix. AFAIK the problem
was never fixed .. I didn't hang around long enough to find out
the eventual outcome .. it seems doubtful the accountant got
fired though :D

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 10:30:54AM +0900, Jacques Garrigue wrote:
> From: Richard Jones <rich@annexia.org>
> > On Thu, Mar 18, 2004 at 03:10:20PM -0500, John Carr wrote:
> > > Suppose we find a bug in ocaml that impacts our product.
> > > Whose job is it to fix the bug?  Neither "a network of
> > > hackers" nor "some academic researchers in France, if they
> > > have the time" is an acceptable answer.
> 
> Well, I understand this is hard to explain to companies.
> Yet I believe that we have a good record for correcting bugs.
> It is not because we are academic researchers that we don't take
> seriously our responsibilities.
> (Microsoft is certainly not faster, and does not offer more guarantees.)
>  
> > This is really why the licensing of the compilers *does* matter.
> 
> Possibly, but may I remind you that ocaml is open-source?
> The QPL is a recognized open-source license, even if it isn't GPL
> compatible (but almost all open-source licenses are not
> GPL-compatible).
> Anybody is perfectly free to release fixes and improvements for ocaml,
> including binary releases, as long as they provide a patch with
> respect to the corresponding version of ocaml.
> 
> For me, it's not even clear that a public CVS based on ocaml would be
> a problem: CVS actually works by creating diffs.
> 
> Could you explain by which mechanism a different license would help in
> making ocaml's maintenance more reliable for companies?
> 
> Also note that all this is irrelevant to libraries, which are already
> released under a slightly relaxed version of the LGPL.

Just as a small note, as the debian ocaml maintainer, i have to say that
the QPL+LGPL used by the ocaml distribution is no problem, we discussed
long with debian-legal and even RMS to achieve the current situation,
which is quite ok.

Also, i have to say that the ocaml team is quite fast to solve licencing
issues that arise, like the bignum problem we encountered last year, or
the emacs files which are QPLed, and they agreed to change to the LGPL
or a dual GPL+QPL licence (didn't check yet if this realy happened
though).

Now, the last domain where the licence remains non-free is naturally the
ocaml documentation, where even to transfer info from the manual to a
man page is not easily possible. It would be really nice if a free
licence be chosen for the ocaml documentation, altough it seems that
this is not the intention of the ocaml team. This will be problematic in
case the debian projects vote to remove the non-free section which
currently hosts the ocaml-docs (and the Oreilly ocaml-books too). We
will know the answer to this by monday, but even if the vote doesn't
pass, which it most probably will not, freeing the ocaml documentation
will be a good thing, and i think there are enough means to ensure that
proper aknowledgement are given back, by using for example the FDGL
(err, or whatever the FSF documentation licence is named) with invariant
sections covering only the copyright attribution info. Also, i do
believe that the gains of doing this outweigh the fear of someone making
silently use of said documentation.

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

On Fri, Mar 19, 2004 at 10:30:54AM +0900, Jacques Garrigue wrote:
> > This is really why the licensing of the compilers *does* matter.
> 
> Possibly, but may I remind you that ocaml is open-source?
> The QPL is a recognized open-source license, even if it isn't GPL
> compatible (but almost all open-source licenses are not
> GPL-compatible).
> Anybody is perfectly free to release fixes and improvements for ocaml,
> including binary releases, as long as they provide a patch with
> respect to the corresponding version of ocaml.

Well, that's sort of free software plus extra problems.  I have to go
and make a patch against the original and release the patch.

If it's OK to release the original + patch, why not just make the
compiler GPL, then I and the end users don't have to go through all
the extra patching hassle?

I'm not convinced either that a CVS repository would be within the
license terms.  INRIA may not mind, but that's a different issue.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Learning Objective CAML for C, C++, Perl and Java programmers:
http://www.merjis.com/richj/computers/ocaml/tutorial/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 08:58:19AM +0000, Richard Jones wrote:
> On Fri, Mar 19, 2004 at 10:30:54AM +0900, Jacques Garrigue wrote:
> > > This is really why the licensing of the compilers *does* matter.
> > 
> > Possibly, but may I remind you that ocaml is open-source?
> > The QPL is a recognized open-source license, even if it isn't GPL
> > compatible (but almost all open-source licenses are not
> > GPL-compatible).
> > Anybody is perfectly free to release fixes and improvements for ocaml,
> > including binary releases, as long as they provide a patch with
> > respect to the corresponding version of ocaml.
> 
> Well, that's sort of free software plus extra problems.  I have to go
> and make a patch against the original and release the patch.
> 
> If it's OK to release the original + patch, why not just make the
> compiler GPL, then I and the end users don't have to go through all
> the extra patching hassle?

Because the QPL allows for modification to be reused by the ocaml team
in other licences, while the GPL doesn't allow for this.

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Alex Baretta]

Sven Luther wrote:

> Because the QPL allows for modification to be reused by the ocaml team
> in other licences, while the GPL doesn't allow for this.
> 
> Friendly,
> 
> Sven Luther

In my opinion it would be sensibile for INRIA to allow redistribution of 
patched sources, so long as the author of the modifications allows INRIA 
to include such modifications in its distributions under whichever 
license INRIA chooses to use.

I would be more willing to contribute work on a GODI style ocaml 
distribution if it were easily possible to walk through core Ocaml code 
and modify if and when this may be needed.

Alex

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 11:03:38AM +0100, Alex Baretta wrote:
> Sven Luther wrote:
> 
> >Because the QPL allows for modification to be reused by the ocaml team
> >in other licences, while the GPL doesn't allow for this.
> >
> >Friendly,
> >
> >Sven Luther
> 
> In my opinion it would be sensibile for INRIA to allow redistribution of 
> patched sources, so long as the author of the modifications allows INRIA 
> to include such modifications in its distributions under whichever 
> license INRIA chooses to use.

Alex, ...

I am not entirely sure, but since i distribute the patched ocaml in
debian, and there has been no problem with that, i think there is some
horrible confusion going on here.

The named 'inria copyright' used for caml-light and earlier versions of
ocaml did indeed restrict redistribution in other form than pristine
source and patches. But this has been solved since many years now, and
in particular the introduction of the QPL was part of that change.

This is the main reason for debian not distributing caml-light, which
still use the old problematic licence, as do caml-light derivative like
moscow-ML, but this doesn't apply to Ocaml.

Naturally, if you were meaning something else, please explain.

> I would be more willing to contribute work on a GODI style ocaml 
> distribution if it were easily possible to walk through core Ocaml code 
> and modify if and when this may be needed.

Noting is stopping you from doing that, Please read the QPL and LGPL
before making such uninformed claims.

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Benjamin Geer]

Sven Luther wrote:
> I am not entirely sure, but since i distribute the patched ocaml in
> debian, and there has been no problem with that, i think there is some
> horrible confusion going on here.

The QPL says:

     You may make modifications to the Software and
     distribute your modifications, in a form that is
     separate from the Software, such as patches.

This means that you cannot distribute modified compiler source code; you 
can only distribute patches.  Someone who wants to use your modified 
compiler is therefore forced to install the standard compiler, then 
apply your patch.

Ben

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Gerd Stolpmann]

On Fre, 2004-03-19 at 12:49, Benjamin Geer wrote:
> Sven Luther wrote:
> > I am not entirely sure, but since i distribute the patched ocaml in
> > debian, and there has been no problem with that, i think there is some
> > horrible confusion going on here.
> 
> The QPL says:
> 
>      You may make modifications to the Software and
>      distribute your modifications, in a form that is
>      separate from the Software, such as patches.
> 
> This means that you cannot distribute modified compiler source code; you 
> can only distribute patches.  Someone who wants to use your modified 
> compiler is therefore forced to install the standard compiler, then 
> apply your patch.

Where is the problem? If you have an auto-installer like GODI or
Debian's dpkg this can be automated. So there is actually no hindrance
to distribute a patched compiler to the masses.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 11:49:12AM +0000, Benjamin Geer wrote:
> Sven Luther wrote:
> >I am not entirely sure, but since i distribute the patched ocaml in
> >debian, and there has been no problem with that, i think there is some
> >horrible confusion going on here.
> 
> The QPL says:
> 
>     You may make modifications to the Software and
>     distribute your modifications, in a form that is
>     separate from the Software, such as patches.
> 
> This means that you cannot distribute modified compiler source code; you 
> can only distribute patches.  Someone who wants to use your modified 
> compiler is therefore forced to install the standard compiler, then 
> apply your patch.

But then, it says : 

  4. You may distribute machine-executable forms of the Software or
  machine-executable forms of modified versions of the Software,
  provided that you meet these restrictions:

  ...

So, i see no problem here. This is opposed to the old inria stuff, which
prohibited binary distribution of modified works.

Friendly,

Sven Luther


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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Issac Trotts]

On Fri, Mar 19, 2004 at 11:49:12AM +0000, Benjamin Geer wrote:
> Sven Luther wrote:
> >I am not entirely sure, but since i distribute the patched ocaml in
> >debian, and there has been no problem with that, i think there is some
> >horrible confusion going on here.
> 
> The QPL says:
> 
>     You may make modifications to the Software and
>     distribute your modifications, in a form that is
>     separate from the Software, such as patches.
> 
> This means that you cannot distribute modified compiler source code; you 
> can only distribute patches.  Someone who wants to use your modified 
> compiler is therefore forced to install the standard compiler, then 
> apply your patch.

After taking the time to modify the compiler, it's probably not too hard
to write a little script that automates the process of applying a patch,
something like this:

#/bin/sh
wget -c http://mallorn.ucdavis.edu/~ijtrotts/software/ocaml-install.sh
bash ./ocaml-install.sh   # Get GODI and run it.
cd $wherever_the_ocaml_source_is/..
wget -c http://www.foo.com/my_patch
patch -p0 < my_patch
cd $wherever_the_ocaml_source_is
./configure && make world && make opt && make install

Anyway, in the case when you want to have more than one set of changes
to the compiler, patches would be more convenient than getting source
tarballs, extracting patches yourself, and then applying them.

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[skaller]

On Fri, 2004-03-19 at 23:34, Issac Trotts wrote:

> After taking the time to modify the compiler, it's probably not too hard
> to write a little script that automates the process of applying a patch,
> something like this:
> 
> #/bin/sh
> wget -c http://mallorn.ucdavis.edu/~ijtrotts/software/ocaml-install.sh

Not too hard??

I'm really sick of glue and sticky tape:


[skaller@pelican] ~>wget -c
http://mallorn.ucdavis.edu/~ijtrotts/software/ocaml-install.sh
--20:12:34-- 
http://mallorn.ucdavis.edu/%7Eijtrotts/software/ocaml-install.sh
           => `ocaml-install.sh'
Resolving mallorn.ucdavis.edu... done.
Connecting to mallorn.ucdavis.edu[128.120.141.141]:80... connected.
HTTP request sent, awaiting response... 404 Not Found
20:12:35 ERROR 404: Not Found.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Issac Trotts]

On Sun, Mar 21, 2004 at 08:13:59PM +1100, skaller wrote:
> On Fri, 2004-03-19 at 23:34, Issac Trotts wrote:
> 
> > After taking the time to modify the compiler, it's probably not too hard
> > to write a little script that automates the process of applying a patch,
> > something like this:
> > 
> > #/bin/sh
> > wget -c http://mallorn.ucdavis.edu/~ijtrotts/software/ocaml-install.sh
> 
> Not too hard??
> 
> I'm really sick of glue and sticky tape:
> 
> 
> [skaller@pelican] ~>wget -c
> http://mallorn.ucdavis.edu/~ijtrotts/software/ocaml-install.sh
> --20:12:34-- 
> http://mallorn.ucdavis.edu/%7Eijtrotts/software/ocaml-install.sh
>            => `ocaml-install.sh'
> Resolving mallorn.ucdavis.edu... done.
> Connecting to mallorn.ucdavis.edu[128.120.141.141]:80... connected.
> HTTP request sent, awaiting response... 404 Not Found
> 20:12:35 ERROR 404: Not Found.

Thanks for pointing out my typo.  I put up a symbolic link from
ocaml-install.sh to install-ocaml.sh so now it should work.

-- 
Issac Trotts
http://redwood.ucdavis.edu/~issac

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Issac Trotts]

On Mon, Mar 22, 2004 at 02:54:44PM +1100, skaller wrote:
> On Mon, 2004-03-22 at 07:05, Issac Trotts wrote:
> > On Sun, Mar 21, 2004 at 08:13:59PM +1100, skaller wrote:
> 
> > > I'm really sick of glue and sticky tape:
> > > 
> > > 
> > > [skaller@pelican] ~>wget -c
> > > http://mallorn.ucdavis.edu/~ijtrotts/software/ocaml-install.sh
> > > --20:12:34-- 
> > > http://mallorn.ucdavis.edu/%7Eijtrotts/software/ocaml-install.sh
> > >            => `ocaml-install.sh'
> > > Resolving mallorn.ucdavis.edu... done.
> > > Connecting to mallorn.ucdavis.edu[128.120.141.141]:80... connected.
> > > HTTP request sent, awaiting response... 404 Not Found
> > > 20:12:35 ERROR 404: Not Found.
> > 
> > Thanks for pointing out my typo.  I put up a symbolic link from
> > ocaml-install.sh to install-ocaml.sh so now it should work.
> 
> Now it hangs trying to connect ;(

The server seems to be down.  I'm on a trip and can't bring it back up
right now, so please try this instead:

  http://redwood.ucdavis.edu/~issac/software/install-ocaml.sh

-- 
Issac Trotts
http://redwood.ucdavis.edu/~issac

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[skaller]

On Mon, 2004-03-22 at 17:51, Issac Trotts wrote:

> The server seems to be down.  I'm on a trip and can't bring it back up
> right now, so please try this instead:
> 
>   http://redwood.ucdavis.edu/~issac/software/install-ocaml.sh

OK! This works .. its compiling Ocaml now .. 

.. hmmm .. but i actually want to use the CVS version of Ocaml
rather than an official release .. is there a way to tell GODI
about using CVS instead of FTPing a tarball?


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Gerd Stolpmann]

On Die, 2004-03-23 at 20:48, skaller wrote:
> On Mon, 2004-03-22 at 17:51, Issac Trotts wrote:
> 
> > The server seems to be down.  I'm on a trip and can't bring it back up
> > right now, so please try this instead:
> > 
> >   http://redwood.ucdavis.edu/~issac/software/install-ocaml.sh
> 
> OK! This works .. its compiling Ocaml now .. 
> 
> .. hmmm .. but i actually want to use the CVS version of Ocaml
> rather than an official release .. is there a way to tell GODI
> about using CVS instead of FTPing a tarball?

Not yet. This is something on my todo list.

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany 
gerd@gerd-stolpmann.de          http://www.gerd-stolpmann.de
------------------------------------------------------------

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Dustin Sallings]

On Mar 23, 2004, at 11:48, skaller wrote:

> .. hmmm .. but i actually want to use the CVS version of Ocaml
> rather than an official release .. is there a way to tell GODI
> about using CVS instead of FTPing a tarball?

[mumble something about gnuarch making the world a better place]

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Kenneth Knowles]

On Fri, Apr 02, 2004 at 10:36:49PM -0800, Dustin Sallings wrote:
> 
> On Mar 23, 2004, at 11:48, skaller wrote:
> 
> >.. hmmm .. but i actually want to use the CVS version of Ocaml
> >rather than an official release .. is there a way to tell GODI
> >about using CVS instead of FTPing a tarball?
> 
> [mumble something about gnuarch making the world a better place]

[mumble something about DARCS being a generalization of the same concepts with a
fraction of the complexity]

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Dustin Sallings]

On Apr 2, 2004, at 23:43, Kenneth Knowles wrote:

>>> .. hmmm .. but i actually want to use the CVS version of Ocaml
>>> rather than an official release .. is there a way to tell GODI
>>> about using CVS instead of FTPing a tarball?
>>
>> [mumble something about gnuarch making the world a better place]
>
> [mumble something about DARCS being a generalization of the same 
> concepts with a
> fraction of the complexity]

	I'm hoping to get darcs built so I can play with it soon.  The main 
point is decentralizing all of this stuff so people can work on new 
concepts without losing track of head-of-line (or anyone else's 
branch).

	My point is that arch was designed to solve problems like the above.  
darcs seems to have a lot in common with arch (but doesn't seem to have 
as mature of an implementation).  In a cathedral vs. bazaar 
conversation, it seems that making the bazaar possible with tools 
designed for a cathedral makes contributions more difficult, thus less 
likely.

	This is the second message regarding darcs I've received.  I was 
actually interested in darcs before finding arch, but had problems 
getting it built.  I'm interested in trying it again, but it's going to 
take something amazing to get me to switch the majority of my code.  :)

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <dustin@spy.net>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Vasili Galchin]

--- Dustin Sallings <dustin@spy.net> wrote:
> 
> On Apr 2, 2004, at 23:43, Kenneth Knowles wrote:
> 
> >>> .. hmmm .. but i actually want to use the CVS
> version of Ocaml
> >>> rather than an official release .. is there a
> way to tell GODI
> >>> about using CVS instead of FTPing a tarball?
> >>
> >> [mumble something about gnuarch making the world
> a better place]
> >
> > [mumble something about DARCS being a
> generalization of the same 
> > concepts with a
> > fraction of the complexity]
> 
> 	I'm hoping to get darcs built so I can play with it
> soon.  The main 
> point is decentralizing all of this stuff so people
> can work on new 
> concepts without losing track of head-of-line (or
> anyone else's 
> branch).
    ^^^ As a reminder the original post 'Completeness
of "Unix" run-time library' was my post! I like OCaml
very much BUT if people cannot "checkin" their
contributions, e.g. ipv6 socket code, then OCaml is
only a "science experiment"!! I am sorry for being
brutal but from a pragmatic viewpoint, this is true.
By definition a "community" has access to all good
resources. I frankly didn't know about unchecked-in
IPV6 socket code until I posted a notice about my ipv4
multicast code. Bottom line: there are a lot of
valuable contributions to OCaml that should be code
reviewed and if good checked-in! Alternative: C++,
i.e.  sh*t!

Regards, Vasili

> 
> 	My point is that arch was designed to solve
> problems like the above.  
> darcs seems to have a lot in common with arch (but
> doesn't seem to have 
> as mature of an implementation).  In a cathedral vs.
> bazaar 
> conversation, it seems that making the bazaar
> possible with tools 
> designed for a cathedral makes contributions more
> difficult, thus less 
> likely.
> 
> 	This is the second message regarding darcs I've
> received.  I was 
> actually interested in darcs before finding arch,
> but had problems 
> getting it built.  I'm interested in trying it
> again, but it's going to 
> take something amazing to get me to switch the
> majority of my code.  :)
> 
> --
> SPY                      My girlfriend asked me
> which one I like better.
> pub  1024/3CAE01D5 1994/11/03 Dustin Sallings
> <dustin@spy.net>
> |    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8
> 0F 3E 65 51 98 D8 BE
> L_______________________ I hope the answer won't
> upset her. ____________
> 
> -------------------
> 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! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[skaller]

On Tue, 2004-04-06 at 14:20, Vasili Galchin wrote:

> Bottom line: there are a lot of
> valuable contributions to OCaml that should be code
> reviewed and if good checked-in! Alternative: C++,
> i.e.  sh*t!

C++ has a formal ISO review process plus a community
based development site (Boost), and other media (eg USENET).

The code is free for any use, the specifications are not 
but they're cheap (thanks mainly to the USA national 
standards body).

Caml has a different development model, and one can 
imagine a reluctance to move it closer to the C++
model for fear the result might be similar ..


-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Benjamin Geer]

skaller wrote:
> Caml has a different development model, and one can 
> imagine a reluctance to move it closer to the C++
> model for fear the result might be similar ..

Do you mean wide use of the language in industry? :)

Ben

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Kip Macy]

Widespread adoptance of C++ pre-dates the ISO committee's bloating of
the language.

					-Kip

On Tue, 6 Apr 2004, Benjamin Geer wrote:

> skaller wrote:
> > Caml has a different development model, and one can
> > imagine a reluctance to move it closer to the C++
> > model for fear the result might be similar ..
>
> Do you mean wide use of the language in industry? :)
>
> Ben
>
> -------------------
> 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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Vasili Galchin]

C++ has many more problems than that, e.g. gluing OO
on a legacy languages, pointers, etc. Even without
bloat it would be a terrible language. I am in no way
suggesting making OCaml into some bloatware.

Vasili

--- Kip Macy <kmacy@fsmware.com> wrote:
> Widespread adoptance of C++ pre-dates the ISO
> committee's bloating of
> the language.
> 
> 					-Kip
> 
> On Tue, 6 Apr 2004, Benjamin Geer wrote:
> 
> > skaller wrote:
> > > Caml has a different development model, and one
> can
> > > imagine a reluctance to move it closer to the
> C++
> > > model for fear the result might be similar ..
> >
> > Do you mean wide use of the language in industry?
> :)
> >
> > Ben
> >
> > -------------------
> > 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! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Vasili Galchin]

I (Vasili) mean wide use of OCaml in the industry. An
example of a FPL that has little chance is Haskell. I
saw one poster on haskell group call it a science
project. I agree. The Haskell is nibbling around the
edges but not providing industrial-strength libraries,
etc. Fortunately OCAML seems to have a big base and a
lot of people working on various projects. HOWEVER,
core functionality like IPV6 socket library code is
not checked in! Why?

Vasili

--- Benjamin Geer <ben@socialtools.net> wrote:
> skaller wrote:
> > Caml has a different development model, and one
> can 
> > imagine a reluctance to move it closer to the C++
> > model for fear the result might be similar ..
> 
> Do you mean wide use of the language in industry? :)
> 
> Ben


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Dustin Sallings]

On Apr 7, 2004, at 16:08, Vasili Galchin wrote:

> I (Vasili) mean wide use of OCaml in the industry. An
> example of a FPL that has little chance is Haskell. I
> saw one poster on haskell group call it a science
> project. I agree. The Haskell is nibbling around the
> edges but not providing industrial-strength libraries,

	I'm not so sure, there seems to be a lot here:

	http://www.haskell.org/ghc/docs/latest/html/libraries/index.html

	I've been wanting to look at Haskell a bit more as a serious 
development language.  There are a couple of problems, but it actually 
looks pretty good.

	I don't expect it to provide me the same kind of execution speeds (or 
compile speeds...ghc is really slow), but it does seem to have a more 
open development environment.

	I still think I'd rather use OCaml, though.

> etc. Fortunately OCAML seems to have a big base and a
> lot of people working on various projects. HOWEVER,
> core functionality like IPV6 socket library code is
> not checked in! Why?
>
-- 
Dustin Sallings

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Goerzen]

On Wed, Apr 07, 2004 at 04:31:01PM -0700, Dustin Sallings wrote:
> >saw one poster on haskell group call it a science
> >project. I agree. The Haskell is nibbling around the
> >edges but not providing industrial-strength libraries,
> 
> 	I'm not so sure, there seems to be a lot here:
> 
> 	http://www.haskell.org/ghc/docs/latest/html/libraries/index.html

Actually, much of what is there are just basics that you'd find anywhere
-- directory scanning, etc.  Though it does seem to have better support
for POSIX libraries than OCaml (which is a sad commentary itself).

Things that are notably missing from Haskell, judging by that list, include:

 * Generic URL handling and HTTP client libraries
 * IMAP
 * POP
 * SMTP
 * NNTP
 * Databases of any sort
 * XML and XML-RPC
 * E-mail/MIME parsing (another huge problem right there)
 * Thread support
 * Curses

Compare that to, for instance:

  http://www.python.org/doc/current/modindex.html

You'll see even more there, including MacOS resource forks, audio
support, etc.  Not to mention the huge Python add-on community or the
even larger Perl one.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Keith Wansbrough]

John Goerzen <jgoerzen@complete.org> writes:
> On Wed, Apr 07, 2004 at 04:31:01PM -0700, Dustin Sallings wrote:
> > 	I'm not so sure, there seems to be a lot here:
> > 
> > 	http://www.haskell.org/ghc/docs/latest/html/libraries/index.html
[..]
> Things that are notably missing from Haskell, judging by that list, include:
> 
>  * Generic URL handling and HTTP client libraries

Exists to some degree.

>  * IMAP
>  * POP
>  * SMTP
>  * NNTP

agree

>  * Databases of any sort

At least two low-level bindings (each binding to MySQL, ODBC, ...)
exist, and work is continuing on a higher-level API.

>  * XML and XML-RPC

XML exists - three bindings.

>  * E-mail/MIME parsing (another huge problem right there)

agree.

>  * Thread support

GHC has a rather mature and advanced threading model.

>  * Curses

Not sure.


The FFI is fully documented and easy to use, and there are tools that
take an annotated C header file or IDL file and automatically convert
to foreign-function declarations.


HTH.

--KW 8-)

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Goerzen]

On Wed, Apr 07, 2004 at 04:08:10PM -0700, Vasili Galchin wrote:
> I (Vasili) mean wide use of OCaml in the industry. An
> example of a FPL that has little chance is Haskell. I
> saw one poster on haskell group call it a science
> project. I agree. The Haskell is nibbling around the
> edges but not providing industrial-strength libraries,
> etc. Fortunately OCAML seems to have a big base and a
> lot of people working on various projects. HOWEVER,
> core functionality like IPV6 socket library code is
> not checked in! Why?

These are good points.  One thing that must *constantly* be considered
by someone looking at a language is the size, flexibility, and quality
of libraries available to help reduce the time to implement a project.
Haskell is absolutely terrible in this regard, so while I actually
prefer its more pervasive lazy evaluation (or even that of a logic
language like Prolog), the fact that I would have to be doing a
tremendous amount of wheel reinventing quickly soured me on Haskell.

OCaml is better, good enough to be a player, but not good enough to be a
good tool.  Here are some examples:

 * OCaml has no library for IMAP.

 * OCamlDBI supports only two database servers.  OcamlODBC supports many
   more through the system's ODBC support, but loads the entire result
   set into memory before handing it over to the user, which makes it
   unusable for many serious projects.

 * Your socket-related point is completely accurate and on-target.

 * String processing and list processing -- especially slicing -- remain
   weaknesses.

 * Time calculations and formatting are also largely missing.

-- John

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

On Thu, Apr 08, 2004 at 08:48:47AM -0500, John Goerzen wrote:
>  * OCaml has no library for IMAP.
>  * Time calculations and formatting are also largely missing.

Actually there are some of Perl libraries that can be used for this,
and the OCaml wrappers around the time libraries are already done.

>  * String processing and list processing -- especially slicing -- remain
>    weaknesses.

Agreed!

>  * OCamlDBI supports only two database servers.  OcamlODBC supports many
>    more through the system's ODBC support, but loads the entire result
>    set into memory before handing it over to the user, which makes it
>    unusable for many serious projects.

Sure.  Needs money and/or time.  OCamlDBI tries to be a generic layer,
but the specific database drivers don't appear by magic.  I'm more
than willing to integrate any straight away, and actually they're not
too hard to write.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
http://www.YouUnlimited.co.uk/ - management courses

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Goerzen]

On Thu, Apr 08, 2004 at 03:06:50PM +0100, Richard Jones wrote:
> On Thu, Apr 08, 2004 at 08:48:47AM -0500, John Goerzen wrote:
> >  * OCaml has no library for IMAP.
> >  * Time calculations and formatting are also largely missing.
> 
> Actually there are some of Perl libraries that can be used for this,
> and the OCaml wrappers around the time libraries are already done.

Where can I find those wrappers?

> >  * OCamlDBI supports only two database servers.  OcamlODBC supports many
> >    more through the system's ODBC support, but loads the entire result
> >    set into memory before handing it over to the user, which makes it
> >    unusable for many serious projects.
> 
> Sure.  Needs money and/or time.  OCamlDBI tries to be a generic layer,
> but the specific database drivers don't appear by magic.  I'm more
> than willing to integrate any straight away, and actually they're not
> too hard to write.

I know, and agree, and BTW have found OcamlDBI to have come a long way
in a very short time.  It is now a great tool for working with my
PostgreSQL server, and I appreciate the hard work that went into making
it that.  I know too that OcamlDBI supports OcamlODBC, but it is
unfortunately still limited by the OcamlODBC limitations.

I'm not trying to cast blame anywhere, I'm just saying that I think that
"Ocaml has a robust set of tools for real-world uses" is inaccurate.  To
be sure, databases are probably a small part of that vs. the string,
list, and POSIX problems.

-- John

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

[Caml-list] Re: OCaml's Cathedral & Bazaar

[Christophe TROESTLER]

On Thu, 8 Apr 2004, John Goerzen <jgoerzen@complete.org> wrote:
> 
> On Thu, Apr 08, 2004 at 03:06:50PM +0100, Richard Jones wrote:
> > Sure.  Needs money and/or time.  OCamlDBI tries to be a generic layer,
> > but the specific database drivers don't appear by magic. [...]
> 
> [...]  I know too that OcamlDBI supports OcamlODBC, but it is
> unfortunately still limited by the OcamlODBC limitations.
                                     ^^^^^^^^^^^^^^^^^^^^^

They will be worked out.  Like Richard said the problem is "money
and/or time".  (So you are welcome to pay us to accelerate the
process :-)).

Cheers,
ChriS

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Evan Martin]

On Thu, Apr 08, 2004 at 03:06:50PM +0100, Richard Jones wrote:
> >  * OCamlDBI supports only two database servers.  OcamlODBC supports many
> >    more through the system's ODBC support, but loads the entire result
> >    set into memory before handing it over to the user, which makes it
> >    unusable for many serious projects.
> 
> Sure.  Needs money and/or time.  OCamlDBI tries to be a generic layer,
> but the specific database drivers don't appear by magic.  I'm more
> than willing to integrate any straight away, and actually they're not
> too hard to write.

Er, speaking of which, I have a driver for SQLite that I had forgotton
to send to you.

(Not that three is much better than two, but it's at least a start.)

-- 
Evan Martin
martine@danga.com
http://neugierig.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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Kenneth Knowles]

On Thu, Apr 08, 2004 at 01:47:25PM -0700, Evan Martin wrote:
> On Thu, Apr 08, 2004 at 03:06:50PM +0100, Richard Jones wrote:
> > >  * OCamlDBI supports only two database servers.  OcamlODBC supports many
> > >    more through the system's ODBC support, but loads the entire result
> > >    set into memory before handing it over to the user, which makes it
> > >    unusable for many serious projects.
> > 
> > Sure.  Needs money and/or time.  OCamlDBI tries to be a generic layer,
> > but the specific database drivers don't appear by magic.  I'm more
> > than willing to integrate any straight away, and actually they're not
> > too hard to write.
> 
> Er, speaking of which, I have a driver for SQLite that I had forgotton
> to send to you.
> 
> (Not that three is much better than two, but it's at least a start.)

Well, as long as we are on the subject, I have wrapped FreeTDS (ct-lib) and in
the process created an ocamldbi module for it (in additional to a more
one-to-one mapping with the C API).  As soon as I get it nicely packaged...

Kenn

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Vasili Galchin]

John,

   You misunderstood my point. I was saying that if
OCaml and other nice declarative languages like it
don't stop being science projects then all we in
industry have for alternatives are terrible languages
like C++! I wasn't in anyway suggesting a process that
has been adopted for C++. Instead I was merely
suggesting (prodding) for everybody to get off the
dime and see code somehow make it through a gatekeeper
and into the mainstream. 

Regards, Vasili

--- skaller <skaller@users.sourceforge.net> wrote:
> On Tue, 2004-04-06 at 14:20, Vasili Galchin wrote:
> 
> > Bottom line: there are a lot of
> > valuable contributions to OCaml that should be
> code
> > reviewed and if good checked-in! Alternative: C++,
> > i.e.  sh*t!
> 
> C++ has a formal ISO review process plus a community
> based development site (Boost), and other media (eg
> USENET).
> 
> The code is free for any use, the specifications are
> not 
> but they're cheap (thanks mainly to the USA national
> 
> standards body).
> 
> Caml has a different development model, and one can 
> imagine a reluctance to move it closer to the C++
> model for fear the result might be similar ..
> 
> 
> -- 
> John Skaller, mailto:skaller@users.sf.net
> voice: 061-2-9660-0850, 
> snail: PO BOX 401 Glebe NSW 2037 Australia
> Checkout the Felix programming language
> http://felix.sf.net
> 
> 
> 


__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[james woodyatt]

On 07 Apr 2004, at 16:03, Vasili Galchin wrote:
>
>    You misunderstood my point. I was saying that if
> OCaml and other nice declarative languages like it
> don't stop being science projects then all we in
> industry have for alternatives are terrible languages
> like C++!

I think it would be ever so convenient for industry if the scientists 
would stop hoarding all the perfectly good technology solutions in 
their palatial research laboratories where industry has absolutely no 
control over their development.  If the scientists were only a little 
more accommodating, then industry wouldn't have to use all those 
terrible alternative technologies they've been saddled with all these 
years.  It's so unfair.  </sarcasm>

> I wasn't in anyway suggesting a process that
> has been adopted for C++. Instead I was merely
> suggesting (prodding) for everybody to get off the
> dime and see code somehow make it through a gatekeeper
> and into the mainstream.

It wouldn't be the first time a language forked because of diverging 
interests between researchers and commercial interests.  Perhaps there 
is nothing really new under the sun.

Seriously, and I'm trying to be helpful here, it is not the scientists 
who decide what is useful to industry.  It is industry that decides 
what are the useful applications of research.  If industry wants a 
standard definition of a language system with all the features of 
Ocaml, then industry will make one.


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Stijn De Saeger]

> Seriously, and I'm trying to be helpful here, it is not the scientists 
> who decide what is useful to industry.  It is industry that decides 
> what are the useful applications of research.  If industry wants a 
> standard definition of a language system with all the features of 
> Ocaml, then industry will make one.

agreed.
As for examples, I suppose Erlang is as good as they come.
stijn.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[skaller]

On Thu, 2004-04-08 at 09:03, Vasili Galchin wrote:
> John,
> 
>    You misunderstood my point.

No I didn't :) YOu said at one point 

"I'm an old man and I'd love to see a 
decent language in the mainstream"

.. or words to that effect. Me too, both
parts!

The issue here is how to get the result we want.
I'd go for Ocaml 4 with the existing Ocaml team
remaining in full control of the compiler,
but relinquishing *totally* the standard library
to a public process.

The new library starts off EMPTY, and compatility
isn't allowed as an argument except as a tie breaker.

On the other hand accepted principles are valid arguments, 
for example functions operating on a container type shall take
the container as the first argument.

There's no way this process would work without
the Ocaml team being an active part of it!

[And I'm going to vote for Ocamlgraph being included
first thing!]

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net



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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Andreas Rossberg]

skaller wrote:
> 
> On the other hand accepted principles are valid arguments, 
> for example functions operating on a container type shall take
> the container as the first argument.

Ah, here controversy already starts. AFAICS, this is neither an accepted 
nor a good principle in a language with currying. For example, there is 
good practical reason that map, fold, etc take the container as their 
last argument. ;-)

Cheers,

     - Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Florian Hars]

Andreas Rossberg wrote:
> Ah, here controversy already starts. AFAICS, this is neither an accepted 
> nor a good principle in a language with currying. For example, there is 
> good practical reason that map, fold, etc take the container as their 
> last argument. ;-)

Except that the folds in Hashtbl, Map.S and Set.S have the container in the 
second position (as does List.fold_right).
But having both add tbl k v in Hashtbl and add k v tbl in Map.S is evil, indeed.

Yours, Florian.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Andreas Rossberg]

Florian Hars wrote:
> 
>> there is good practical reason that map, fold, etc take the 
>> container as their last argument. ;-)
> 
> Except that the folds in Hashtbl, Map.S and Set.S have the container in 
> the second position (as does List.fold_right).

Which I consider a design error indeed. :-)

	- Andreas

-- 
Andreas Rossberg, rossberg@ps.uni-sb.de

Let's get rid of those possible thingies!  -- TB

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Jacques Garrigue]

From: Andreas Rossberg <rossberg@ps.uni-sb.de>

> >> there is good practical reason that map, fold, etc take the 
> >> container as their last argument. ;-)
> > 
> > Except that the folds in Hashtbl, Map.S and Set.S have the container in 
> > the second position (as does List.fold_right).
> 
> Which I consider a design error indeed. :-)

open MoreLabels

(Sorry, but sometimes I want to remind people that parameter order is
not really relevant)

To be precise with labels you have:
* the container is the first unlabelled argument
* it can be in the last position simultaneously

  Jacques Garrigue

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Richard Jones]

On Thu, Apr 08, 2004 at 11:35:37AM +0200, Andreas Rossberg wrote:
> skaller wrote:
> >
> >On the other hand accepted principles are valid arguments, 
> >for example functions operating on a container type shall take
> >the container as the first argument.
> 
> Ah, here controversy already starts. AFAICS, this is neither an accepted 
> nor a good principle in a language with currying. For example, there is 
> good practical reason that map, fold, etc take the container as their 
> last argument. ;-)

That's right.  Make the argument ordering good for currying.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
"One serious obstacle to the adoption of good programming languages is
the notion that everything has to be sacrificed for speed. In computer
languages as in life, speed kills." -- Mike Vanier

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Alex Baretta]

Sven Luther wrote:
> On Fri, Mar 19, 2004 at 11:03:38AM +0100, Alex Baretta wrote:
> 
> Noting is stopping you from doing that, Please read the QPL and LGPL
> before making such uninformed claims.
> 
> Friendly,
> 
> Sven Luther

Sven, I am aware of the QPL.

You do realize that it is an inconvenience to maintain the stock Ocaml 
tree and the patch, or tree of patches. It is not impossibile, but it is 
an inconvenience. I have a number of patches to the stock ocaml--minor 
stuff--which would be easier to maintain if I were allowed to distribute 
the modified source as opposed to source-and-patches.

Since my company is under-staffed at present, I do not have time to 
spare for distributing patches. So we just keep our patched core for 
internal use and wait until there will be a coordinated effort to which 
we can contribute.

This thread seems to indicate that the only viable proposal for creating 
a community project around Ocaml is Gerd's GODI. I'm glad that Xavier 
gave Gerd some informal backing. However, managing GODI is going to be 
troublesome (not impossibile, just troublesome) until the licensing will 
allow GODI to incorporate in its codebase any patches which the GODI 
maintainer/team will consider appropriate.

I am expressing the need for the community project to make only 
additions, but actually modifications to the core project. I have no 
trouble with QPL 3.b, which is probably what INRIA cares most about. I 
am simply stating that QPL 2 is an unnecessary hassle for everyone.

Alex

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 01:17:58PM +0100, Alex Baretta wrote:
> Sven Luther wrote:
> >On Fri, Mar 19, 2004 at 11:03:38AM +0100, Alex Baretta wrote:
> >
> >Noting is stopping you from doing that, Please read the QPL and LGPL
> >before making such uninformed claims.
> >
> >Friendly,
> >
> >Sven Luther
> 
> Sven, I am aware of the QPL.

Ok, i missed the part about source modifications only being allowed as
separate patches. This is ok though.

> You do realize that it is an inconvenience to maintain the stock Ocaml 
> tree and the patch, or tree of patches. It is not impossibile, but it is 
> an inconvenience. I have a number of patches to the stock ocaml--minor 
> stuff--which would be easier to maintain if I were allowed to distribute 
> the modified source as opposed to source-and-patches.

Well, the debian package, apart from being a pristine upstream +
patch format, also now comes in a form where the debian patch only adds
the debian directory, and has a set of patches in debian/patches,
conveniently applied and unapplied by dpatch. Very nice.

> Since my company is under-staffed at present, I do not have time to 
> spare for distributing patches. So we just keep our patched core for 
> internal use and wait until there will be a coordinated effort to which 
> we can contribute.

You could use a revision system, like CVS or more modern subversion or
arch, and maintain a pristine upstream branch, and easily generate the
patch in question. No difficulties there.

> This thread seems to indicate that the only viable proposal for creating 
> a community project around Ocaml is Gerd's GODI. I'm glad that Xavier 
> gave Gerd some informal backing. However, managing GODI is going to be 
> troublesome (not impossibile, just troublesome) until the licensing will 
> allow GODI to incorporate in its codebase any patches which the GODI 
> maintainer/team will consider appropriate.

Yeah, i know, GODI is nice, but i prefer native support as what we
provide for debian, but then, i guess you are using an inferior OS
anyway, so ... :))

> I am expressing the need for the community project to make only 
> additions, but actually modifications to the core project. I have no 
> trouble with QPL 3.b, which is probably what INRIA cares most about. I 
> am simply stating that QPL 2 is an unnecessary hassle for everyone.

But still free software. I would be more concerned about rights to
modify the documentation, but everyone its priority.

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Issac Trotts]

> This thread seems to indicate that the only viable proposal for creating 
> a community project around Ocaml is Gerd's GODI. I'm glad that Xavier 
> gave Gerd some informal backing. However, managing GODI is going to be 
> troublesome (not impossibile, just troublesome) until the licensing will 
> allow GODI to incorporate in its codebase any patches which the GODI 
> maintainer/team will consider appropriate.

GODI packages can be made that include both the source and the patches,
and the patches can be automatically applied by GODI just before it
compiles OCaml.  What would be wrong with doing it this way?  

-- 
Issac Trotts
http://mallorn.ucdavis.edu/~ijtrotts
(w) 530-757-8789

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Benjamin Geer]

John Carr wrote:
> We pay a company
> to provide us with an embedded Linux environment including
> cross-compilation tools.  While in reality ocaml will be
> more reliable than g++ due to the vast difference in
> complexity, that doesn't overcome the fear.

Moreover, because g++ has an open development process, if that company 
fixes a bug in g++, or adds a generally useful feature, you can be 
pretty sure that it will end up in an official release of g++ as long as 
it is well-written and well-tested.  This very fact encourages such 
companies to appear.

Ben

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Michael Vanier]

> Date: Thu, 18 Mar 2004 15:10:20 -0500
> From: John Carr <jfc@mit.edu>
> 
> 
> > > 1. Nobody else knows the language.
> > > 2. It doesn't run on our platform.
> > > 3. It will break and we can't get support.
> >
> > Point 1 => same problem as with Linux about ten years ago
> > 
> > Point 2 => really not running on that platform?
> >
> > Point 3 => The INRIA-cathedral will help to prevent this problem
> >            in the sense of "we do not allow any hacker to make
> >            changes in the core language"
> 
> Suppose we find a bug in ocaml that impacts our product.
> Whose job is it to fix the bug?  Neither "a network of
> hackers" nor "some academic researchers in France, if they
> have the time" is an acceptable answer.  We pay a company
> to provide us with an embedded Linux environment including
> cross-compilation tools.  While in reality ocaml will be
> more reliable than g++ due to the vast difference in
> complexity, that doesn't overcome the fear.
> 
> Consider points 2 and 3 as axioms.  They were dictated to
> me by management and were not subject to debate.  As long
> as there is a shadow of a doubt about support, ocaml won't
> be used where I work.
> 

Sounds like there may be an opportunity for people who want to provide
for-profit support for ocaml projects.  I suspect that the idea of getting
paid to work in ocaml would be highly appealing to most of the people on
this list.  An analogy would be to the early Linux distributions
(e.g. Slackware).

Mike

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Thu, Mar 18, 2004 at 03:10:20PM -0500, John Carr wrote:
> 
> > > 1. Nobody else knows the language.
> > > 2. It doesn't run on our platform.
> > > 3. It will break and we can't get support.
> >
> > Point 1 => same problem as with Linux about ten years ago
> > 
> > Point 2 => really not running on that platform?
> >
> > Point 3 => The INRIA-cathedral will help to prevent this problem
> >            in the sense of "we do not allow any hacker to make
> >            changes in the core language"
> 
> Suppose we find a bug in ocaml that impacts our product.
> Whose job is it to fix the bug?  Neither "a network of
> hackers" nor "some academic researchers in France, if they
> have the time" is an acceptable answer.  We pay a company
> to provide us with an embedded Linux environment including
> cross-compilation tools.  While in reality ocaml will be
> more reliable than g++ due to the vast difference in
> complexity, that doesn't overcome the fear.

Well, nothing is stopping you from paying a programmer to fix the bug,
and have it integrated in the upstream release. In fact, i do believe
the Ocaml Consortium was set up for just that, and have access to the
ocaml code under other licencing i think. So, contribute to it, help
paying programmer to fix bugs and furthermore develop the part of ocaml
you feel are important, in other word, put your money were your mouth
is.

> The library system is troublesome -- non-core libraries need
> other libraries, which need other libraries, and so on -- but
> in this case it didn't make a difference.

Well, i never noticed such troubles in debian :)) But then, it is your
fault if you did chose an inferior OS :))

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Carr]

[In reply to management concerns about support for ocaml and
commercial product development:]

> Well, nothing is stopping you from paying a programmer to fix the bug,
> and have it integrated in the upstream release.

Telling management that we need to hire a compiler expert won't
persuade them to allow ocaml.

I and other programmers tried to convince the company to use
ClearCase.  It would have made some of our work a lot easier.
We were told no, because conventional wisdom says ClearCase
needs a dedicated system administrator and they didn't want to
hire another person.  Real costs win over hypothetical savings.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Fri, Mar 19, 2004 at 08:20:37AM -0500, John Carr wrote:
> 
> [In reply to management concerns about support for ocaml and
> commercial product development:]
> 
> > Well, nothing is stopping you from paying a programmer to fix the bug,
> > and have it integrated in the upstream release.
> 
> Telling management that we need to hire a compiler expert won't
> persuade them to allow ocaml.
> 
> I and other programmers tried to convince the company to use
> ClearCase.  It would have made some of our work a lot easier.
> We were told no, because conventional wisdom says ClearCase
> needs a dedicated system administrator and they didn't want to
> hire another person.  Real costs win over hypothetical savings.

I don't understand. You wrote :

  have the time" is an acceptable answer.  We pay a company
  to provide us with an embedded Linux environment including
  cross-compilation tools.  While in reality ocaml will be
  more reliable than g++ due to the vast difference in
  complexity, that doesn't overcome the fear.

So, how is that different participating in the Ocaml Consortium, and
thus making sure someone is paid to do the things you need ? Or is payng
for one thing ok, but not for the other ? 

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[John Carr]

> So, how is that different participating in the Ocaml Consortium, and
> thus making sure someone is paid to do the things you need ? Or is payng
> for one thing ok, but not for the other ? 

I read the OCaml Consortium contract and it is not a support
contract as far as I can tell.  Does Inria have an obligation
to fix bugs reported by members?

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Sun, Mar 21, 2004 at 04:11:23PM -0500, John Carr wrote:
> 
> > So, how is that different participating in the Ocaml Consortium, and
> > thus making sure someone is paid to do the things you need ? Or is payng
> > for one thing ok, but not for the other ? 
> 
> I read the OCaml Consortium contract and it is not a support
> contract as far as I can tell.  Does Inria have an obligation
> to fix bugs reported by members?

I believe the ocaml team will fix bug all the same, even if they have no
contract with you. That is the difference between a serious developer
team, and folk only there to milk money from you, like microsoft.

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Sven Luther]

On Thu, Mar 18, 2004 at 07:41:18PM +0100, Oliver Bandel wrote:
> On Thu, Mar 18, 2004 at 01:56:50PM +0000, Richard Jones wrote:
> > On Thu, Mar 18, 2004 at 08:12:36AM -0500, John Carr wrote:
> > > 1. Nobody else knows the language.
> > > 2. It doesn't run on our platform.
> > > 3. It will break and we can't get support.
> > 
> > These things will always be a problem until OCaml becomes (to use a
> > marketing term) a "whole product".  This means that it has a full
> > suite of supporting skills and documentation.  There are currently two
> > books, and a few web tutorials.  For OCaml to become a whole product
> > we'd need to see a few shelves full of books at the local bookstore,
> > and specialists in each city offering support, and major external
> > companies signing on.
> 
> Point 1 => same problem as with Linux about ten years ago
> 
> Point 2 => really not running on that platform?
> 
> Point 3 => The INRIA-cathedral will help to prevent this problem
>            in the sense of "we do not allow any hacker to make
>            changes in the core language"

Again, as the debian maintainer of the ocaml package, i have to agree
here. I package mostly the pure ocaml distribution, with a serie of
patches, applied as needed, but always either picked up from CVS or
discussed with upstream.

The time i choose to apply a random patch, like the early ocaml -i
support one, i had the bad surprise of breaking .cmi generation
compatibiliy between the native and byte code compilers, which was a
cold water shower for me (err, bad french translation, i suppose you
don't say that in english). Anyway, since then i refrained from applying
random external patches.

Now, what would really make my day would be for the ocaml team to decide
to go the professional way, and to maintain both a development CVS
branch, and a stable bugfix CVS branch, which would avoid having to get
some random brokeness when one want to get serious bug fixes. Sorry
Xavier, i know i told you that many times already, and you told me that
your devel model was yours to choose, but i couldn't resist a gentle
proding :). I also don't believe this will be so much of a cost over the
current model, and maybe even be less expensive in the long run.

Friendly,

Sven Luther

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Shawn Wagner]

On Thu, Mar 18, 2004 at 01:56:38AM -0700, Matt Gushee wrote:
> 
> What if there were an "OCaml Community Library Project"--a group outside
> INRIA that would take responsibility for extending and perhaps partially
> replacing the standard library--maybe a bit like the current ExtLib
> project, only more extensive (BTW, why are there two ExtLibs?? One of
> you change the name, please! Thank you.). Maybe if that project showed
> itself to be responsible, credible, reliable, etc. etc., after a while
> it could become the de facto standard library.
> 

There are two extlibs because two different people decided to release
libraries filling in gaps in the standard library, using the obvious name,
without knowing about the existance of another such effort. When the other
extlib was announced quite a while ago, I talked with its author, and that
the time neither one of us were willing to change names. Since then, the
other one (That most people have mentioned here) doesn't seem to be being
actively maintained the way mine is; as of a couple of days ago, when I
checked, there hadn't been any commits to its CVS tree in months. That makes
me, at least, even less likely to change my extlib's name than I was 6
months ago.

Even if one of us did change the name of ours, there would still be problems
if someone wanted to use both, because some modules have the same names.
I've also noticed other libraries recently where that sort of colllision
would be a problem. As the available number of libraries for ocaml grows,
it'll get worse. High on my wish-list for the core ocaml system is
namespaces or something similiar to help resolve this problem.

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Kenneth Knowles]

On Thu, Mar 18, 2004 at 10:57:23AM -0800, Shawn Wagner wrote:
> On Thu, Mar 18, 2004 at 01:56:38AM -0700, Matt Gushee wrote:
> Even if one of us did change the name of ours, there would still be problems
> if someone wanted to use both, because some modules have the same names.
> I've also noticed other libraries recently where that sort of colllision
> would be a problem. As the available number of libraries for ocaml grows,
> it'll get worse. High on my wish-list for the core ocaml system is
> namespaces or something similiar to help resolve this problem.

I was just thinking about this today on the train... The thing that solves it
for perl is for modules to appear to be inside each other even though they are
developed/installed separately.  I agree that the ocaml syntax already gives
more sugar and different ways of doing things than is really necessary, so I
really feel namespaces and modules would be redundant.

For ocaml, since modules are not first-class, wouldn't it just be a compilation
frontend issue to do this merging (in addition to some syntax to declare module
X.Y)?  I'm just pondering, but it seems possible and remarkably useful in order
to move towards a CPAN-like module repository.  Dependencies between modules
would naturally cause compile-time failure if they were not present, which is
desirable.  This seems like one simple step which would enormously increase the
ability of the community to more effectively contribute libraries and modules,
and halt a lot of complaints to the INRIA team.

On the bright side, at least the collisions are only at the module level... if
each library contained all modules in a larger module, such as with the -pack
option, then only this outer name need be unique.

Kenn

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Fernando Alegre]

On Thu, Mar 18, 2004 at 01:16:15PM -0800, Kenneth Knowles wrote:

> > it'll get worse. High on my wish-list for the core ocaml system is
> > namespaces or something similiar to help resolve this problem.
> 
> For ocaml, since modules are not first-class, wouldn't it just be a compilation
> frontend issue to do this merging (in addition to some syntax to declare module
> X.Y)?  I'm just pondering, but it seems possible and remarkably useful in order
> to move towards a CPAN-like module repository.  Dependencies between modules
> would naturally cause compile-time failure if they were not present, which is
> desirable.  This seems like one simple step which would enormously increase the
> ability of the community to more effectively contribute libraries and modules,
> and halt a lot of complaints to the INRIA team.


I also think a few more switches in the compiler would mostly put an end to
most complaints and give the community the necessary tools to extend/replace
the libraries. In particular, I feel this is needed:

1) A -pre_open switch that opens a given module (searched along the -I path)
   This would allow people to replace Pervasives with a custom module.

2) -stdlib switches that change the path for the standard library so that
   subsequent -I +path is searched under the current standard library path.
  Several -stdlib switches should be allowed in the same compilation.

3) A firm commitment by the Ocaml team to maintain camlp4 in the future in
   the same terms as the rest of the ocaml core. This would be essential
   for extensions that depend on syntactic manipulation (such regexps) to
   become widespread.

The -pre_open switch seems powerful enough to allow namespace management, since
an extLib module could then be something like this:

extLib.ml:

module List = ExtList
module Array = ExtArray
...

Then, users would be able to switch between the standard library and extLib
without modifying their code by compiling like this:

ocamlc -pre_open extLib.cmo mycode.ml

Fernando

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

[Caml-list] Re: OCaml's Cathedral & Bazaar

[Remi Vanicat]

Fernando Alegre <fernando@cc.gatech.edu> writes:

[...]

>
> I also think a few more switches in the compiler would mostly put an end to
> most complaints and give the community the necessary tools to extend/replace
> the libraries. In particular, I feel this is needed:
>
> 1) A -pre_open switch that opens a given module (searched along the -I path)
>    This would allow people to replace Pervasives with a custom module.
>
> 2) -stdlib switches that change the path for the standard library so that
>    subsequent -I +path is searched under the current standard library path.
>   Several -stdlib switches should be allowed in the same compilation.
>
> 3) A firm commitment by the Ocaml team to maintain camlp4 in the future in
>    the same terms as the rest of the ocaml core. This would be essential
>    for extensions that depend on syntactic manipulation (such regexps) to
>    become widespread.

I believed that the Ocaml team have already tell us that they will
continue to maintain camlp4 inside OCaml several time.

-- 
Rémi Vanicat

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

[Caml-list] Demande clarification nomenclature ocaml*

[Diego Olivier Fernandez Pons]

    Bonjour,

> There are two extlibs because two different people decided to
> release libraries filling in gaps in the standard library, using the
> obvious name, without knowing about the existance of another such
> effort. When the other extlib was announced quite a while ago, I
> talked with its author, and that the time neither one of us were
> willing to change names. Since then, the other one (That most people
> have mentioned here) doesn't seem to be being actively maintained
> the way mine is; as of a couple of days ago, when I checked, there
> hadn't been any commits to its CVS tree in months. That makes me, at
> least, even less likely to change my extlib's name than I was 6
> months ago.

La communaute ne semble meme pas capable de se mettre d'accord sur la
nomenclature de ses bibliotheques. Verra-t-on ensuite une querelle
pour savoir qui detient le veritable "ocamlmakefile", "ocamlxml" ou
encore "ocamlyacc" ?

Il me semble raisonnable que l'utilisateur ait une vision claire de ce
qui est officiellement developpe par l'INRIA et de ce qui ne l'est
pas.

Raison pour laquelle il me semble que l'INRIA devrait etre plus
vigilant au sujet de la nomenclature, par exemple en affirmant sa
primaute sur le suffixe ocaml* en demandant aux autres bibliotheques
de migrer vers caml* telle CamlImages, ou encore en demandant aux
contributeurs d'eviter des noms equivoques tels ExtLib.

Je me trouve apres coup bien aimable de n'avoir pas nomme Baire plutot
OCamlStdLib : c'est bien plus vendeur.

        Diego Olivier



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

Re: [Caml-list] Suggestion (was: Demande clarification nomenclature ocaml*)

[Wolfgang Müller]

[2nd try. The first went to DOFP only]

> La communaute ne semble meme pas capable de se mettre d'accord sur la
> nomenclature de ses bibliotheques. Verra-t-on ensuite une querelle
> pour savoir qui detient le veritable "ocamlmakefile", "ocamlxml" ou
> encore "ocamlyacc" ?
>
> Il me semble raisonnable que l'utilisateur ait une vision claire de ce
> qui est officiellement developpe par l'INRIA et de ce qui ne l'est
> pas.
>
> Raison pour laquelle il me semble que l'INRIA devrait etre plus
> vigilant au sujet de la nomenclature, par exemple en affirmant sa
> primaute sur le suffixe ocaml* en demandant aux autres bibliotheques
> de migrer vers caml* telle CamlImages, ou encore en demandant aux
> contributeurs d'eviter des noms equivoques tels ExtLib.
>
> Je me trouve apres coup bien aimable de n'avoir pas nomme Baire plutot
> OCamlStdLib : c'est bien plus vendeur.
>
>         Diego Olivier
En fait, tout le monde parle Francais ici?

To get back to the perl example:

This is a point where a *central* repository for libraries with good search 
feature is important. For example: I once had a neat way of writing 
(creating, parsing) simplified DOM trees in Perl, and when I wanted to 
publish it, I found out that there actually was a module doing practically 
the same thing. So, unless you're unlucky and two people develop at home 
during 2 years one library and then submit it within one week, there is not 
much probability of unintentionally duplicated work within Perl.

However, for toplevel namespaces, you have to write to a mailing list, and 
there is a group of people who decide if to accept the new toplevel namespace 
or not. This is a (AFAIK also known) bottleneck..

My suggestion:
___
While waiting for nested namespaces one could do namespace-by-convention. One 
would keep INRIA (or possibly something convenient and shorter) as prefix for 
INRIA OCaml stuff, leaving other useful prefixes for the normal people. This 
namespace could then be maintained in a perlish style. Reading this list from 
time to time it is quite clear that there is a number of people who mail a 
lot to this list, who know a lot about OCaml (as far as I can judge this as 
someone who knows little about OCaml), and who would be suitable for being 
maintainers of the toplevel namespace.

Sounds good?

Cheers,
Wolfgang

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

[Caml-list] Modules and namespaces

[Richard Jones]

On Fri, Mar 19, 2004 at 10:49:27AM +0100, Wolfgang Müller wrote:
> To get back to the perl example:
[perl example]
> However, for toplevel namespaces, you have to write to a mailing
> list, and there is a group of people who decide if to accept the new
> toplevel namespace or not. This is a (AFAIK also known) bottleneck..

Actually, getting a toplevel namespace accepted is not necessary with
Perl.  It's advisable, a nice thing to do, etc., but not necessary for
uploading a module to CPAN.

Another thing which is being overlooked here is that ocaml has two
types of namespace:

(1) The normal module namespace

(2) Which paths get searched using -I +subdir

For instance, I have a module called Dbi which is located in the
-I +dbi subdirectory.

It would be quite possible for someone else to write a Dbi module
located in the -I +anotherdbi directory.  No conflict would arise
unless some strange person wanted to use both types of Dbi module
in their program - an unlikely occurrence presumably.

As for complex module namespaces: Perl gets away with a very loose
definition.  All modules which count are at either the top level or
the second level, eg:

CGI
Net::FTP
IO::Handle

Java, by contrast, has a horrible ham-fisted namespace mechanism which
is great example of overengineering a problem to death.

Stick with short 1- or 2-level names for modules, please.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
Perl4Caml lets you use any Perl library in your type-safe Objective
CAML programs. http://www.merjis.com/developers/perl4caml/

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

Re: [Caml-list] Modules and namespaces

[Wolfgang Müller]

On Friday 19 March 2004 11:19, Richard Jones wrote:
> It would be quite possible for someone else to write a Dbi module
> located in the -I +anotherdbi directory.  No conflict would arise
> unless some strange person wanted to use both types of Dbi module
> in their program - an unlikely occurrence presumably.

Oh, I do not agree. Problems like that are a *very* neat tripwire for people 
starting to use a language.

Cheers,
Wolfgang


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

Re: [Caml-list] Modules and namespaces

[Sven Luther]

On Fri, Mar 19, 2004 at 10:19:31AM +0000, Richard Jones wrote:
> On Fri, Mar 19, 2004 at 10:49:27AM +0100, Wolfgang Müller wrote:
> > To get back to the perl example:
> [perl example]
> > However, for toplevel namespaces, you have to write to a mailing
> > list, and there is a group of people who decide if to accept the new
> > toplevel namespace or not. This is a (AFAIK also known) bottleneck..
> 
> Actually, getting a toplevel namespace accepted is not necessary with
> Perl.  It's advisable, a nice thing to do, etc., but not necessary for
> uploading a module to CPAN.
> 
> Another thing which is being overlooked here is that ocaml has two
> types of namespace:
> 
> (1) The normal module namespace
> 
> (2) Which paths get searched using -I +subdir
> 
> For instance, I have a module called Dbi which is located in the
> -I +dbi subdirectory.
> 
> It would be quite possible for someone else to write a Dbi module
> located in the -I +anotherdbi directory.  No conflict would arise
> unless some strange person wanted to use both types of Dbi module
> in their program - an unlikely occurrence presumably.

You can achieve this by using the -pack option when creating libraries.
Sure it has still some problems, but it is the way to go to solve this
problem.

What is really missing is support for more than one OCAMLLIBDIR, in
order to be able to easily separate the libraries installed by your
package manager (/usr/lib/ocaml/3.07 for debian), by the one installed
locally by the sysadmin (/usr/local/lib/ocaml/3.07 for debian), and the
user specific ones (less important though, but still usefull).

Friendly,

Sven Luther

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

Re: [Caml-list] Modules and namespaces

[Fernando Alegre]

On Fri, Mar 19, 2004 at 11:45:14AM +0100, Sven Luther wrote:
> On Fri, Mar 19, 2004 at 10:19:31AM +0000, Richard Jones wrote:

> > It would be quite possible for someone else to write a Dbi module
> > located in the -I +anotherdbi directory.  No conflict would arise
> > unless some strange person wanted to use both types of Dbi module
> > in their program - an unlikely occurrence presumably.
> 
> You can achieve this by using the -pack option when creating libraries.
> Sure it has still some problems, but it is the way to go to solve this
> problem.
> 
> What is really missing is support for more than one OCAMLLIBDIR, in
> order to be able to easily separate the libraries installed by your
> package manager (/usr/lib/ocaml/3.07 for debian), by the one installed
> locally by the sysadmin (/usr/local/lib/ocaml/3.07 for debian), and the
> user specific ones (less important though, but still usefull).

It seems that you both also miss the -pre_open and -stdlib switches in
the compiler.

A pre_open switch would take care of 2 modules called Dbi without modifying
them:

(* wrapper1.ml *)

module DbiVendor1 = Dbi

====

(* wrapper2.ml *)

module DbiVendor2 = Dbi

===

ocamlc -c -I path_to_vendor1 wrapper1.ml -I path_to_vendor2 wrapper2.ml ...

===

A stdlib switch is what Sven is asking above.

Both switches, along with pack, is all we need to create our custom
packaging/namespace management systems independently of INRIA. What do you
think?

These switches would also be policy-neutral, so that nobody is _forced_ to
use GODI, debian packages or any other middleware if they do not fit their
environment, but still allow people to use external libraries without fear
of namespace clashes.

Fernando


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

Re: [Caml-list] Modules and namespaces

[Sven Luther]

On Fri, Mar 19, 2004 at 08:56:42AM -0500, Fernando Alegre wrote:
> ===
> 
> A stdlib switch is what Sven is asking above.
> 
> Both switches, along with pack, is all we need to create our custom
> packaging/namespace management systems independently of INRIA. What do you
> think?
> 
> These switches would also be policy-neutral, so that nobody is _forced_ to
> use GODI, debian packages or any other middleware if they do not fit their
> environment, but still allow people to use external libraries without fear
> of namespace clashes.

Nope, what i want is the $OCAMLPATH env var, or a similar mechanism,
maybe configured in /etc/ocaml.conf or whatever.

Sure, this can be achieved by using explicit path to those sysadmin
installed libraries in /usr/local, but it is less convenient.

Friendly,

Sven Luther

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

Re: [Caml-list] Demande clarification nomenclature ocaml*

[Benjamin Geer]

Diego Olivier Fernandez Pons wrote:
> La communaute ne semble meme pas capable de se mettre d'accord sur la
> nomenclature de ses bibliotheques.

There is currently no structure allowing the community to make decisions 
about the standard library; naming is just one part of this problem.  I 
agree that such a structure is needed.

I assume that names such as 'ExtLib' were intended to be temporary, 
because the authors' view was that they were working on the standard 
library, and expected their work to be accepted after a reasonable 
review process.

[Il n'y a pas actuellement de structure permettant à la communauté de 
prendre des décisions au sujet de la bibliothèque standard; la 
nomenclature n'est qu'un aspect de ce problème.  Je suis d'accord pour 
dire qu'une telle structure est nécessaire.

Je suppose que des noms tels que « ExtLib » étaient censés être 
provisoire, parce que les auteurs croyaient travailler sur la 
bibliothèque standard, et s'attendaient à ce que leur travail soit 
accepté au terme d'un processus raisonnable d'évalulation.]

> Il me semble raisonnable que l'utilisateur ait une vision claire de ce
> qui est officiellement developpe par l'INRIA et de ce qui ne l'est
> pas.

What I want as a user is for the standard libraries to be actively 
developed, so that they respond to the needs of the community.  The 
current approach to the development of the standard libraries seems to 
make this impossible.

INRIA cannot scale, because it has a limited number of developers.  The 
community can scale.

[En tant qu'utilisateur, je veux que la bibliothèque standard soit 
activement développée pour qu'elle réponde aux besoins de la communauté. 
  La façon dont elle est actuellement développée semble rendre cela 
impossible.

INRIA ne peut pas monter en charge, parce qu'il a un nombre limité 
d'informaticiens.  La communauté, elle, peut monter en charge.]

Ben

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Matt Gushee]

On Thu, Mar 18, 2004 at 10:57:23AM -0800, Shawn Wagner wrote:

> > project, only more extensive (BTW, why are there two ExtLibs?? One of
> > you change the name, please! Thank you.). Maybe if that project showed
> 
> There are two extlibs because two different people decided to release
> libraries filling in gaps in the standard library, using the obvious name,

[ .... ]

> Even if one of us did change the name of ours, there would still be problems
> if someone wanted to use both, because some modules have the same names.
> I've also noticed other libraries recently where that sort of colllision
> would be a problem. As the available number of libraries for ocaml grows,
> it'll get worse. High on my wish-list for the core ocaml system is
> namespaces or something similiar to help resolve this problem.

Agreed. Even in my fairly short time programming OCaml, I've had to
struggle several times to find a good name for a module.

Although I wasn't being exactly facetious in my remark about ExtLib, I'm
not terribly upset either, and I hope nobody takes my words too
seriously. I certainly understand the problem.

-- 
Matt Gushee                 When a nation follows the Way,
Englewood, Colorado, USA    Horses bear manure through
mgushee@havenrock.com           its fields;
http://www.havenrock.com/   When a nation ignores the Way,
                            Horses bear soldiers through
                                its streets.
                                
                            --Lao Tzu (Peter Merel, trans.)

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Benjamin Geer]

Matt Gushee wrote:
>>High on my wish-list for the core ocaml system is
>>namespaces or something similiar to help resolve this problem.
> 
> Agreed. Even in my fairly short time programming OCaml, I've had to
> struggle several times to find a good name for a module.

What I'd like is to be able to create a unique name for a project, and 
then use it as a namespace containing non-unique module names.  For 
example, I use the domain saucecode.org for my Caml work.  I'd like to 
be able to create a Saucecode namespace, and within it create module 
names representing libraries, without worrying about whether those names 
are unique in the whole Caml community.  So a user could use my 
Saucecode.Foo module, and someone else's Extlib.Foo module, without any 
conflict.

Today I can create a Saucecode module with a Foo module inside it, but I 
can only define Saucecode once.  That means that I would have to package 
all my libraries as a single download, and anyone who wanted to use one 
library would have to use them all.

Be

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Vasili Galchin]

Matt,

   Thank you! I was away for a bit. You are not being
grandiose at all. When I started the discussion about
"Unix completeness", I was tactfully (maybe not so
tactfully) asking why OCaml is not like Linux??!! Your
metaphor is exactly where I was going. I really want
to see to a functional language make it into the
mainstream (i.e. I have programmed in imperative
languages all of my 28 year career ... nothing has
changed). After looking at various FPL code bases, I
really believe taht OCaml has a shot assuming we all
take the challenge seriously (I have been in American
industry for 26 years ... which sadly is far too
pragmatic and conservative to change).

Regards, Vasili
--- Matt Gushee <mgushee@havenrock.com> wrote:
> On Wed, Mar 17, 2004 at 04:19:05PM -0800, Vasili
> Galchin wrote:
> 
> > > 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.
> 
> (Sorry about the grandiose title. I have nothing
> suitably profound to
>  say ... just couldn't think of a better way to
> express the subject.)
> 
> I wonder if it is possible to persuade INRIA to do
> anything.
> 
> I have no inside information on the process at
> INRIA, but my impression
> from reading this list over the past year or so is:
> 
>  1) The OCaml team at INRIA care about the
> community, but there are too
>     few of them to meet all our needs, and I suppose
> their work is also
>     subject to institutional pressures that we are
> only vaguely aware
>     of. Maybe they are struggling to keep enough
> resources for OCaml
>     work.
> 
>  2) INRIA as an institution finds it convenient to
> release OCaml as open
>     source, but doesn't really care about the
> community. They benignly
>     neglect everything that doesn't relate to their
> research goals.
> 
>  3) OCaml-as-project (i.e. I'm talking about how
> OCaml is developed, not
>     what it is) is a fragile enterprise. E.g., one
> developer leaves, and 
>     the future of Camlp4 becomes uncertain. Not
> good.
> 
> I'm not saying you should give up hope just yet, but
> maybe it's time to
> consider alternatives.
> 
> What if there were an "OCaml Community Library
> Project"--a group outside
> INRIA that would take responsibility for extending
> and perhaps partially
> replacing the standard library--maybe a bit like the
> current ExtLib
> project, only more extensive (BTW, why are there two
> ExtLibs?? One of
> you change the name, please! Thank you.). Maybe if
> that project showed
> itself to be responsible, credible, reliable, etc.
> etc., after a while
> it could become the de facto standard library.
> 
> The idealistic scenario is a division of labor
> wherein INRIA continues
> to develop the parts of OCaml that are interesting
> to them, while other
> parts (of more interest to those of us working to
> create practical
> and/or commercial software) would be taken over by
> the community.
> 
> I can't say whether this idea is feasible, or
> whether INRIA would be
> willing to go along with it, but maybe it's
> something to consider.
> 
> -- 
> Matt Gushee                 When a nation follows
> the Way,
> Englewood, Colorado, USA    Horses bear manure
> through
> mgushee@havenrock.com           its fields;
> http://www.havenrock.com/   When a nation ignores
> the Way,
>                             Horses bear soldiers
> through
>                                 its streets.
>                                 
>                             --Lao Tzu (Peter Merel,
> trans.)
> 
> -------------------
> 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! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

Re: OCaml's Cathedral & Bazaar (was Re: [Caml-list] Completeness of "Unix" run-time library)

[Vasili Galchin]

Matt,

   Thank you! I was away for a bit. You are not being
grandiose at all. When I started the discussion about
"Unix completeness", I was tactfully (maybe not so
tactfully) asking why OCaml is not like Linux??!! Your
metaphor is exactly where I was going. I really want
to see to a functional language make it into the
mainstream (i.e. I have programmed in imperative
languages all of my 28 year career ... nothing has
changed). After looking at various FPL code bases, I
really believe taht OCaml has a shot assuming we all
take the challenge seriously (I have been in American
industry for 26 years ... which sadly is far too
pragmatic and conservative to change).

Regards, Vasili
--- Matt Gushee <mgushee@havenrock.com> wrote:
> On Wed, Mar 17, 2004 at 04:19:05PM -0800, Vasili
> Galchin wrote:
> 
> > > 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.
> 
> (Sorry about the grandiose title. I have nothing
> suitably profound to
>  say ... just couldn't think of a better way to
> express the subject.)
> 
> I wonder if it is possible to persuade INRIA to do
> anything.
> 
> I have no inside information on the process at
> INRIA, but my impression
> from reading this list over the past year or so is:
> 
>  1) The OCaml team at INRIA care about the
> community, but there are too
>     few of them to meet all our needs, and I suppose
> their work is also
>     subject to institutional pressures that we are
> only vaguely aware
>     of. Maybe they are struggling to keep enough
> resources for OCaml
>     work.
> 
>  2) INRIA as an institution finds it convenient to
> release OCaml as open
>     source, but doesn't really care about the
> community. They benignly
>     neglect everything that doesn't relate to their
> research goals.
> 
>  3) OCaml-as-project (i.e. I'm talking about how
> OCaml is developed, not
>     what it is) is a fragile enterprise. E.g., one
> developer leaves, and 
>     the future of Camlp4 becomes uncertain. Not
> good.
> 
> I'm not saying you should give up hope just yet, but
> maybe it's time to
> consider alternatives.
> 
> What if there were an "OCaml Community Library
> Project"--a group outside
> INRIA that would take responsibility for extending
> and perhaps partially
> replacing the standard library--maybe a bit like the
> current ExtLib
> project, only more extensive (BTW, why are there two
> ExtLibs?? One of
> you change the name, please! Thank you.). Maybe if
> that project showed
> itself to be responsible, credible, reliable, etc.
> etc., after a while
> it could become the de facto standard library.
> 
> The idealistic scenario is a division of labor
> wherein INRIA continues
> to develop the parts of OCaml that are interesting
> to them, while other
> parts (of more interest to those of us working to
> create practical
> and/or commercial software) would be taken over by
> the community.
> 
> I can't say whether this idea is feasible, or
> whether INRIA would be
> willing to go along with it, but maybe it's
> something to consider.
> 
> -- 
> Matt Gushee                 When a nation follows
> the Way,
> Englewood, Colorado, USA    Horses bear manure
> through
> mgushee@havenrock.com           its fields;
> http://www.havenrock.com/   When a nation ignores
> the Way,
>                             Horses bear soldiers
> through
>                                 its streets.
>                                 
>                             --Lao Tzu (Peter Merel,
> trans.)
> 
> -------------------
> 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! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

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

[james woodyatt]

On 09 Mar 2004, at 09:30, Vasili Galchin wrote:
>  
>       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?

I think the Unix module could be regarded as incomplete.

The tactic I have taken with this problem is to regard the Unix library 
in the Ocaml distribution as the property of INRIA.  It has what it 
has, and it will get what INRIA decides is missing when the INRIA team 
decides to put it there.

I found the support for socket options to be lacking.  I wanted IPv6 
support.  I'll probably want all manner of other things eventually, 
e.g. multicast, raw sockets, routing sockets, etcetera.  The way to get 
this is to write a drop-in replacement for the features of the Unix 
library you need updated.

I released my code for extending socket support in Unix with my Cf 
library, which you can find on the Hump.  (It only builds on Mac OS X 
and probably other BSD-like platforms, because I used the sa_len field 
in socket address structures.  That should be easily fixed in my next 
release in a couple months.)


-- 
j h woodyatt <jhw@wetware.com>
markets are only free to the people who own them.
-------------------
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

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

[Sven Luther]

On Tue, Mar 09, 2004 at 09:59:20AM -0800, james woodyatt wrote:
> On 09 Mar 2004, at 09:30, Vasili Galchin wrote:
> > 
> >      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?
> 
> I think the Unix module could be regarded as incomplete.
> 
> The tactic I have taken with this problem is to regard the Unix library 
> in the Ocaml distribution as the property of INRIA.  It has what it 
> has, and it will get what INRIA decides is missing when the INRIA team 
> decides to put it there.
> 
> I found the support for socket options to be lacking.  I wanted IPv6 

I also have a bug report open against the debian ocaml package asking
quite intently for IPv6 supoprt, also claiming ocaml to be 'useless' to
him until it would support IPv6.

Is there any IPv6 support planed in the near future ? I know this
discussion did already happen, but i guess nothing came of it back then.

Friendly,

Sven Luther

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

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

[Vasili Galchin]

Hi Sven,

    There is one guy, Georgi (I don't know how to say
in French only on Russian), who IMO did a very nice
job on IPV6. I personally want this stuff folded into
the OCAML source. That is why I started this thread,
i.e. to light a fire under somebody. Georgi did this
last year(!!), but still not in OCaml source base!

Regards, Vasili

--- Sven Luther <sven.luther@wanadoo.fr> wrote:
> On Tue, Mar 09, 2004 at 09:59:20AM -0800, james
> woodyatt wrote:
> > On 09 Mar 2004, at 09:30, Vasili Galchin wrote:
> > > 
> > >      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?
> > 
> > I think the Unix module could be regarded as
> incomplete.
> > 
> > The tactic I have taken with this problem is to
> regard the Unix library 
> > in the Ocaml distribution as the property of
> INRIA.  It has what it 
> > has, and it will get what INRIA decides is missing
> when the INRIA team 
> > decides to put it there.
> > 
> > I found the support for socket options to be
> lacking.  I wanted IPv6 
> 
> I also have a bug report open against the debian
> ocaml package asking
> quite intently for IPv6 supoprt, also claiming ocaml
> to be 'useless' to
> him until it would support IPv6.
> 
> Is there any IPv6 support planed in the near future
> ? I know this
> discussion did already happen, but i guess nothing
> came of it back then.
> 
> Friendly,
> 
> Sven Luther
> 
> -------------------
> 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! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

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

[Sven Luther]

On Fri, Mar 19, 2004 at 10:15:15PM -0800, Vasili Galchin wrote:
> Hi Sven,
> 
>     There is one guy, Georgi (I don't know how to say
> in French only on Russian), who IMO did a very nice
> job on IPV6. I personally want this stuff folded into
> the OCAML source. That is why I started this thread,
> i.e. to light a fire under somebody. Georgi did this
> last year(!!), but still not in OCaml source base!

Do you have a reference to the stuff ? Altough i don't want to divert
the ocaml package too much from the official stuff, i could upload a
ipv6-aware implementation to debian/experimental, or maybe just the ipv6
library.

Friendly,

Sven Luther

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

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

[Vasili Galchin]

Hi Sven,

    Here is Gregoire aka Georgi ipv6 code (oops ...
maybe he is not Georgi but instead Henri) ... anyway I
read it and I like what he did:

1) it seems to be complete albeit seems to be minus
ipv4. Question: how to transition from ipv4 to ipv6?
Or how to have ipv4 and ipv6 namespaces?

2) After I read this code then I think it makes sense
to split unix.mli/unix.ml into socket.mli/socket.ml,
time.mli/time.ml, etc. as Gregoire Henry has done.

Regards, Vasili

--- Gregoire HENRY <gregoire.henry@etu.upmc.fr> wrote:
> Date: Tue, 9 Mar 2004 21:14:20 +0100
> From: Gregoire HENRY <gregoire.henry@etu.upmc.fr>
> To: Vasili Galchin <vasiliocaml@yahoo.com>
> Subject: Re: [Caml-list] multicast IP added to the
> Unix library
> 
> Hello,
> 
> >      I have added so far the multicast join and
> drop functionality to the unix (and threads) OCaml
> library. I have tested this functionality and it
> works. I do want to respect what has been
> implemented in the past (very fine work). I looked
> carefully at the various setsockopt functions in
> unix.mli and the multicast work didn't seem to fit
> easily within the bool, int, float paradigmn because
> the setsockopt call for multicast passes in a
> structure plus the setsockopt "level" actual
> parameter is not SOL_SOCKET (i.e. we are setting
> socket state at a different level, i.e. IPPROTO_IP).
> Hence, I implemented as two functions,
> multicast_join and multicast_drop. I, of course,
> amenable to changes in what I have done. Is there a
> code review process in order to get something into
> the mainline of OCaml?? Please someone supply me
> with details.
> 
> I believe there is no special review process yet,
> except perhaps filling a request's bug and attach
> your patch :
> http://caml.inria.fr/bin/caml-bugs
> 
> BTW, I missed your previous mail but I make some
> preliminary work
> this summer on bindings OCaml with IPv6 socket
> interface (RFC 3493).
> In particulary, introduce a new
> setsockopt_multicast.
> 
> I would be pleased to compare with your
> implementation.
> You can found mine here : 
> http://www.pps.jussieu.fr/~henry/ip6/
> 
> regards,
> -- Gregoire Henry

--- Sven Luther <sven.luther@wanadoo.fr> wrote:
> On Tue, Mar 09, 2004 at 09:59:20AM -0800, james
> woodyatt wrote:
> > On 09 Mar 2004, at 09:30, Vasili Galchin wrote:
> > > 
> > >      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?
> > 
> > I think the Unix module could be regarded as
> incomplete.
> > 
> > The tactic I have taken with this problem is to
> regard the Unix library 
> > in the Ocaml distribution as the property of
> INRIA.  It has what it 
> > has, and it will get what INRIA decides is missing
> when the INRIA team 
> > decides to put it there.
> > 
> > I found the support for socket options to be
> lacking.  I wanted IPv6 
> 
> I also have a bug report open against the debian
> ocaml package asking
> quite intently for IPv6 supoprt, also claiming ocaml
> to be 'useless' to
> him until it would support IPv6.
> 
> Is there any IPv6 support planed in the near future
> ? I know this
> discussion did already happen, but i guess nothing
> came of it back then.
> 
> Friendly,
> 
> Sven Luther
> 
> -------------------
> 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! Finance Tax Center - File online. File on time.
http://taxes.yahoo.com/filing.html

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

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

[Stefano Zacchiroli]

On Tue, Mar 09, 2004 at 09:30:09AM -0800, Vasili Galchin wrote:
> 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?

Yet another example: process group handling system calls are completely
missing.

Cheers.

-- 
Stefano Zacchiroli -*- Computer Science PhD student @ Uny Bologna, Italy
zack@{cs.unibo.it,debian.org,bononia.it} -%- http://www.bononia.it/zack/
If there's any real truth it's that the entire multidimensional infinity
of the Universe is almost certainly being run by a bunch of maniacs. -!-

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