[Caml-list] Some comments on recent discussions

[Caml-list] Some comments on recent discussions

[Jonathan Protzenko]

[-- Attachment #1: Type: text/plain, Size: 4348 bytes --]

Dear OCaml hackers,

I'm very uneasy about the current opinions that are voiced on the 
caml-list. I have good reasons to think I'm not the only one in that 
situation, so please allow me to raise a few concerns about some recent 
discussions.

There's several subtopics in the "OCaml maintenance status / community 
fork" that I'd like to discuss.

= Improving the community =

I think the main point of the discussion is to improve "the community". 
If we really want to improve OCaml as a whole, then I think we can put 
our efforts on better areas than patching the compiler.

== Package management system ==

The thing that's most needed is, imho, a package manager that works. 
Oasis-db looked very promising as far as I could tell, but Sylvain 
doesn't have as much time as he used to do. Instead of hacking on our 
pet projects (which is, I admit, very rewarding), maybe someone could 
step up and make Oasis-db happen. We don't have a single, unified answer 
to "what should I install to easily hack with OCaml?". What made Python, 
Perl, Haskell successful is the package management systems. How much 
longer are we going to shy away from this issue? Sure, it's much more 
fun to hack on the compiler. Not as useful.

== Leaving our own corner of the web ==

The OCaml community likes to stay in its own corner of the web, in 
isolation. We live on obscure web sites: who knows about ocamlforge 
outside the OCaml community? Who knows about the caml hump? We could 
host our projects on Sourceforge or on GitHub. We could get recognition 
in the open-source world through our projects, we could be more social, 
we could boost the language stats on ohloh, we could attract more 
contributors (being a fervent user of GitHub, I must say I've attracted 
a significant amount of contributors that way ; being on an obscure 
forge, I'm certain it would've never happened). We stay away from that. 
Why? Because GitHub is not open-source. The whole point of git is that 
everyone, everywhere has a backup copy and that we don't care if GitHub 
falls down. Nevermind.

GitHub has a fantastic integration between the bug tracker, the commit 
messages (git commit -m "Fix #486" closes bug 486 on the bug tracker), 
the source repositories. You can discuss patches in-place. You can 
interact in a very easy manner. You can do peer-review in a snap. 
*GitHub is the only place that leverages the social nature of 
open-source collaboration!* That's precisely what we're trying to 
achieve here. Are we going to throw all that goodness away? What kind of 
signal are we sending, when we're considering hosting our own instance 
of gitorious? A very simple one: "we like to stay in our own corner --- 
don't come".

There are valid points: GitHub doesn't have a maliing-list list system. 
Is that really an excuse? How hard would it be to setup a website that 
lists OCaml projects, provides them with a mailing-list, and points to 
their GitHub page?

= What is this about ? =

If it's about improving the general situation with OCaml and its 
community (the title of this thread contains the word "community"), then 
I believe hacking on the compiler is not the most effective way to 
achieve that goal. We're hackers. We like to hack on things. And we 
often fail to ask ourselves: is it really worth implementing? Submitting 
patches is easy. Submitting quality patches that do solve a real problem 
is harder. The ARM backend does need a cleanup, and the patch does solve 
a stringent issue. That may not be the case for all patches.

There is indeed a problem w.r.t external contributions. I agree that the 
INRIA team could make it clearer what its stance on external 
contributions is. Maybe one solution would be to have a INRIA-endorsed 
ocaml-next on github that everyone can fork, where we would merge really 
outstanding features, before submitting them to INRIA, as you described. 
I don't think it is such a good idea creating a real fork. Maybe some 
sort of integration platform on GitHub would be the right solution to 
the "patch review" problem.

I'm not even sure what kind of patches you wish to see integrated. Can 
you clarify that?

= Conclusion =

This is indeed a long rant, but I'd like to see us being more practical 
and down-to-earth. I love OCaml. I think we can do better for the language.

Kind regards,

jonathan


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

Re: [Caml-list] Some comments on recent discussions

[Joel Reymont]

On Dec 6, 2011, at 4:24 PM, Jonathan Protzenko wrote:

> GitHub has a fantastic integration between the bug tracker, the commit messages (git commit -m "Fix #486" closes bug 486 on the bug tracker), the source repositories. You can discuss patches in-place. You can interact in a very easy manner. You can do peer-review in a snap. GitHub is the only place that leverages the social nature of open-source collaboration!

+100

I'm sorry but I don't care about OcamlForge, Gitorius, etc. as they do NOT facilitate collaboration.

Nowhere near the extent that Github does.

--------------------------------------------------------------------------
- for hire: mac osx device driver ninja, kernel extensions and usb drivers
---------------------+------------+---------------------------------------
http://wagerlabs.com | @wagerlabs | http://www.linkedin.com/in/joelreymont
---------------------+------------+---------------------------------------

Re: [Caml-list] Some comments on recent discussions

[Mihamina Rakotomandimby]

On 12/06/2011 06:24 PM, Jonathan Protzenko wrote:
> Dear OCaml hackers,
>
> I'm very uneasy about the current opinions that are voiced on the
> caml-list. I have good reasons to think I'm not the only one in that
> situation, so please allow me to raise a few concerns about some recent
> discussions.

I join you.

> = Improving the community =
> I think the main point of the discussion is to improve "the community".
> If we really want to improve OCaml as a whole, then I think we can put
> our efforts on better areas than patching the compiler.

1°)
According to me, enlarging the user base is the root solution to this.
We need more tiny-to-small projects (they woul more look like code 
snippets) in Ocaml.

2°)
There is a need for "common type" web apps in Ocaml:
- a CMS (as Drupal, Joomla,...)
- a Redmine-like
- a blog hosting, just like Wordpress
- ..

3°)
There need to be an Ocaml application that has a link with a need in web 
development:
- an Ocaml thing better than Sonar http://www.sonarsource.org/
- http://goo.gl/Oq6ew


> == Package management system ==
> The thing that's most needed is, imho, a package manager that works.

That works and ease packaging for OS package manager: it should be easy 
to build RPMs, .deb, so that it's easy to upgrade for system 
administrators in production environments and easy to get _exposed_ in 
the system package management tool.

> = Conclusion =
> This is indeed a long rant, but I'd like to see us being more practical
> and down-to-earth. I love OCaml. I think we can do better for the language.

I'm on the way of creating a computer science institute of my view and 
the goal is to teach Ocaml, and produce OCaml code. We'll see how it 
works :-).


-- 
RMA.

Re: [Caml-list] Some comments on recent discussions

[Benedikt Meurer]

On Dec 6, 2011, at 16:24 , Jonathan Protzenko wrote:

> [...]
> 
> If it's about improving the general situation with OCaml and its community (the title of this thread contains the word "community"), then I believe hacking on the compiler is not the most effective way to achieve that goal. We're hackers. We like to hack on things. And we often fail to ask ourselves: is it really worth implementing? Submitting patches is easy. Submitting quality patches that do solve a real problem is harder. The ARM backend does need a cleanup, and the patch does solve a stringent issue. That may not be the case for all patches.

You may be right, but I think you are also missing my point to some degree here. Improving the OCaml community as a whole is a worthwhile goal and more than welcome, but that is a far away, probably very difficult to achieve goal. What I am talking about and what I am trying to address is a rather practical problem: How to avoid pissing off possible contributors to the OCaml core (these are most likely different people than the ones that would help with web site, spreading the word, community stuff) and how to improve the maintenance status of the OCaml core? Or maybe: How to set OCaml free?

> There is indeed a problem w.r.t external contributions. I agree that the INRIA team could make it clearer what its stance on external contributions is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on github that everyone can fork, where we would merge really outstanding features, before submitting them to INRIA, as you described. I don't think it is such a good idea creating a real fork. Maybe some sort of integration platform on GitHub would be the right solution to the "patch review" problem.

As long as that would be INRIA-controlled, I fear that it would be the same story with different infrastructure (you'll have pull requests that don't get attention rather than bug reports that don't get attention).

> I'm not even sure what kind of patches you wish to see integrated. Can you clarify that?

Mantis is down currently.

> Kind regards,
> jonathan

Benedikt

Re: [Caml-list] Some comments on recent discussions

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 3194 bytes --]

I agree that package management, a *single* standard library, and a good
web presence are the most useful things we can do. We desperately need
oasis, oasis-db, and eventually an OCaml Platform to succeed. The standard
library contenders are Batteries and Jane St Core. Ideally these could be
merged, but that will take a lot of effort from both teams. On the web
side, we did start a project to build a new website for OCaml, announced at
the last User Meeting. We are continuing to work on it, although admittedly
progress has been slow.

Nothing wrong with compiler improvements. We don't have to pick between
these options. Let's just work on all of them.  :)


On Tue, Dec 6, 2011 at 11:03 AM, Benedikt Meurer <
benedikt.meurer@googlemail.com> wrote:

>
> On Dec 6, 2011, at 16:24 , Jonathan Protzenko wrote:
>
> > [...]
> >
> > If it's about improving the general situation with OCaml and its
> community (the title of this thread contains the word "community"), then I
> believe hacking on the compiler is not the most effective way to achieve
> that goal. We're hackers. We like to hack on things. And we often fail to
> ask ourselves: is it really worth implementing? Submitting patches is easy.
> Submitting quality patches that do solve a real problem is harder. The ARM
> backend does need a cleanup, and the patch does solve a stringent issue.
> That may not be the case for all patches.
>
> You may be right, but I think you are also missing my point to some degree
> here. Improving the OCaml community as a whole is a worthwhile goal and
> more than welcome, but that is a far away, probably very difficult to
> achieve goal. What I am talking about and what I am trying to address is a
> rather practical problem: How to avoid pissing off possible contributors to
> the OCaml core (these are most likely different people than the ones that
> would help with web site, spreading the word, community stuff) and how to
> improve the maintenance status of the OCaml core? Or maybe: How to set
> OCaml free?
>
> > There is indeed a problem w.r.t external contributions. I agree that the
> INRIA team could make it clearer what its stance on external contributions
> is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on
> github that everyone can fork, where we would merge really outstanding
> features, before submitting them to INRIA, as you described. I don't think
> it is such a good idea creating a real fork. Maybe some sort of integration
> platform on GitHub would be the right solution to the "patch review"
> problem.
>
> As long as that would be INRIA-controlled, I fear that it would be the
> same story with different infrastructure (you'll have pull requests that
> don't get attention rather than bug reports that don't get attention).
>
> > I'm not even sure what kind of patches you wish to see integrated. Can
> you clarify that?
>
> Mantis is down currently.
>
> > Kind regards,
> > jonathan
>
> Benedikt
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

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

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

> Dear OCaml hackers,
>
> I'm very uneasy about the current opinions that are voiced on the
> caml-list. I have good reasons to think I'm not the only one in that
> situation, so please allow me to raise a few concerns about some recent
> discussions.
>
> There's several subtopics in the "OCaml maintenance status / community
> fork" that I'd like to discuss.
>
> = Improving the community =
>
> I think the main point of the discussion is to improve "the community".
> If we really want to improve OCaml as a whole, then I think we can put
> our efforts on better areas than patching the compiler.

ACK. Of course, improving the compiler is a topic of its own. I can fully
understand Benedikt's frustration.

> == Package management system ==
>
> The thing that's most needed is, imho, a package manager that works.
> Oasis-db looked very promising as far as I could tell, but Sylvain
> doesn't have as much time as he used to do. Instead of hacking on our
> pet projects (which is, I admit, very rewarding), maybe someone could
> step up and make Oasis-db happen. We don't have a single, unified answer
> to "what should I install to easily hack with OCaml?". What made Python,
> Perl, Haskell successful is the package management systems. How much
> longer are we going to shy away from this issue? Sure, it's much more
> fun to hack on the compiler. Not as useful.

We discussed this often enough. I think Oasis-db is a part of that, but
not the answer to everything. It is more designed to package smaller
libraries.

If you want a more universal answer, you end up with something like GODI.

Btw, some quite popular languages can live entirely without package
management. What I mean: this makes life easier, but is not crucial to
adaption. Users choose languages because of other criteria.

> == Leaving our own corner of the web ==
>
> The OCaml community likes to stay in its own corner of the web, in
> isolation. We live on obscure web sites: who knows about ocamlforge
> outside the OCaml community? Who knows about the caml hump? We could
> host our projects on Sourceforge or on GitHub. We could get recognition
> in the open-source world through our projects, we could be more social,
> we could boost the language stats on ohloh, we could attract more
> contributors (being a fervent user of GitHub, I must say I've attracted
> a significant amount of contributors that way ; being on an obscure
> forge, I'm certain it would've never happened). We stay away from that.
> Why? Because GitHub is not open-source. The whole point of git is that
> everyone, everywhere has a backup copy and that we don't care if GitHub
> falls down. Nevermind.

This may all be true for a single person. A group is recognized
differently, though, especially by real social interaction (conferences,
meetings etc.), by press coverage, and by company support.

> GitHub

Can't we stop talking about such very technical things? There are ocaml
projects on GitHub, and ocaml popularity hasn't boosted because of this.

> = What is this about ? =
>
> If it's about improving the general situation with OCaml and its
> community (the title of this thread contains the word "community"), then
> I believe hacking on the compiler is not the most effective way to
> achieve that goal. We're hackers. We like to hack on things. And we
> often fail to ask ourselves: is it really worth implementing? Submitting
> patches is easy. Submitting quality patches that do solve a real problem
> is harder. The ARM backend does need a cleanup, and the patch does solve
> a stringent issue. That may not be the case for all patches.

You will for sure see troll patches - people trying to get something into
the compiler that should better not be solved there. I'm not sure whether
a community process can sort this all out. However, I'm not against trying
it, because there is a large class of undoubted problems (e.g. errors).

> There is indeed a problem w.r.t external contributions. I agree that the
> INRIA team could make it clearer what its stance on external
> contributions is.

I'd also like to hear this.

Gerd

> Maybe one solution would be to have a INRIA-endorsed
> ocaml-next on github that everyone can fork, where we would merge really
> outstanding features, before submitting them to INRIA, as you described.
> I don't think it is such a good idea creating a real fork. Maybe some
> sort of integration platform on GitHub would be the right solution to
> the "patch review" problem.
>
> I'm not even sure what kind of patches you wish to see integrated. Can
> you clarify that?
>
> = Conclusion =
>
> This is indeed a long rant, but I'd like to see us being more practical
> and down-to-earth. I love OCaml. I think we can do better for the
> language.
>
> Kind regards,
>
> jonathan
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

Re: [Caml-list] Some comments on recent discussions

[Alex Rubinsteyn]

[-- Attachment #1: Type: text/plain, Size: 439 bytes --]

>
>
> == Leaving our own corner of the web ==
>
> The OCaml community likes to stay in its own corner of the web, in
> isolation.
>

A narrow plug: I want to encourage people to post and comment on
http://www.reddit.com/r/ocaml. OCaml's web presence often looks like a
ghost town. I think it's starting to improve but we need a lot more in the
way of discussion, blogging, and meetups before anyone could call the OCaml
community vibrant.

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

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/06/2011 04:24 PM, Jonathan Protzenko wrote:
> I think the main point of the discussion is to improve "the community".
> If we really want to improve OCaml as a whole, then I think we can put
> our efforts on better areas than patching the compiler.

I completely disagree with you (and this is rare enough!). The 
discussion that Benedikt started is not about improving the community, 
it is about improving the core system.  Both are important issues, but 
discussing them together will not help make any progress.

If someone wakes up a morning with a strong desire to help OCaml and 
wonders how to contribute in the most efficient way, then it could make 
sense to compare the relative benefits of improving the compiler vs. the 
community vs. writing a book vs. etc.

But the situation is not like that: people work on different topics 
according to what they enjoy or need.  It happens that Benedikt has been 
working on issues which he (and others) considers important enough to 
deserve some attention.  The question is now how to turn this work into 
something useful for OCaml, and also how to avoid creating some 
frustration amongst people who are willing to contribute on the core system.


That said, I'd argue to avoid creating a "community" fork.

It should be noted that while INRIA maintains its primary role in the 
development of OCaml, the "core development team" is not entirely made 
of people from INRIA.  Historically, Jacques Garrigue has contributed a 
lot to OCaml without being affiliated with INRIA.  More recently, 
several people outside INRIA have gained and used direct commit rights 
to the OCaml SVN repository.  Experiments and proposals are typically 
carried on branches (which are publicly available), discussed amongst 
developers, and then sometimes integrated in the trunk.  This works 
quite well, and I'm happy that Xavier continues exercising his 
leadership to decide ultimately what goes into OCaml and what doesn't.

The problem is not so much the current process than the size of the 
"core development team" and the fact that many of its members can only 
contribute very little of their time to OCaml.  I'd thus argue to 
enlarge this group with more people who have demonstrated their skills 
for working on the core system.



Alain

Re: [Caml-list] Some comments on recent discussions

[Martin Jambon]

On 12/06/2011 07:31 AM, Joel Reymont wrote:
> 
> On Dec 6, 2011, at 4:24 PM, Jonathan Protzenko wrote:
> 
>> GitHub has a fantastic integration between the bug tracker, the
>> commit messages (git commit -m "Fix #486" closes bug 486 on the bug
>> tracker), the source repositories. You can discuss patches
>> in-place. You can interact in a very easy manner. You can do
>> peer-review in a snap. GitHub is the only place that leverages the
>> social nature of open-source collaboration!
> 
> +100
> 
> I'm sorry but I don't care about OcamlForge, Gitorius, etc. as they
> do NOT facilitate collaboration.
> 
> Nowhere near the extent that Github does.

Same here.

Re: [Caml-list] Some comments on recent discussions

[Paolo Donadeo]

I just want to add some erratic thoughts summoned by the recent
<strike>flame</strike>... discussion about "the state of the OCaml
union". For this reason I'm not pretending to be coherent or to have
an answer to each and every problem, I'm not John Wayne and I'll never
be.

OCaml community is basically composed by computer professionals that
have very few time to spend on the geek social networks (reddit,
stackoverflow, ...) to write how this language is beautiful, how it is
so "pure" (or "impure"), and so on. I write software in OCaml, and
this software is working right now in a production environment.
Nothing even comparable with Jane St. or LexiFy or Mylife, but I have
my customers and if something stops working, they complain A LOT ;-)

This pragmatical attitude of the OCaml community is not accidental and
is the clear expression of a language that *is* pragmatical.

And this attitude is the main reason why, in my very honest opinion,
the OCaml language haven't a hype comparable to, say, Haskell. Is this
bad? Are we frustrated because nobody writes on "Wired" about OCaml?
I'm not.

What I like in OCaml is that it's really stable, fast and in the last
years many key tools have been added to the tool chain. As an
engineer, I think that ocamlbuild + oasis (only an example) are MORE
valuable than first class modules and GADTs. Which, in turn, are not
"minor improvements" at all, and I don't see this supposed immobility
of the language.

The standard library problem: the core library is small, ugly, useless
and more. The standard library provided by INRIA can't even send
email, make a POST, or talk with a web service. Ok, but what exactly
can you do with the C, or C++ standard library? I *like* the elegant
simplicity of the standard library and, when something is missing I
can: 1) write my own solution or 2) search for library by other OCaml
developers. What's wrong with Google searching for a good library? Why
many people seems to advocate a unique library "to rule them all"? And
why this huge library should enter in the standard distribution? Why
many people complain about the poor visibility of the community, but
refuses to use ocamlcore.org (thanks Sylvain forever!) only because
GitHub has a nicer web2.0 interface? Yes, I like GitHub, but I think
we *ALL* should host our projects, at least the main web pages on
OCamlCore, to minimize the scatter.

There are many specialized library for almost everything in OCaml, and
2/3 big "standard libraries" (Batteries, Core, ExtLib?). Why can't we
simply choose one of these excellent libraries? I like
<ads>Batteries</ads> but there is NOTHING wrong with Core, and I hope
both of them will remain OUT of the standard distribution forever.
Why? Because the standard library is small and virtually bug-free or,
better said, it tends to be so, because it's *rare* that a new feature
is added, and this is *good*. It's like the basic building blocks of
Lego: if you want gears or you need a pulley, buy Lego Technic ;-)

Another example: reactive programming. Not using Google (I swear!) I
can remember LWT, react, Ocamlnet (in part...) and froc. Is this
situation to be considered harmful? I appreciate this wide range of
approaches to the same problem, it's the sign of a vital community.

I'm too seasoned as a programmer and I already experienced the
<irony>huge benefits</irony> of big standard libraries: the
Magnificent Java Standard Library, BOOST, the ACE framework, and many
others, all excellent examples of what a serial killer can design with
a cohort of programmers and a beautiful programming language ;-)

I don't say there are no problems, and everything is fine. But if I
have do point at a problem, especially for newcomers, I would say that
we need a book, an up to date book, written in good English and
published by O'Relly.

But this is a very hard issue to be solved, no GitHub (R) (TM) in help here ;-)


-- 
Paolo

Re: [Caml-list] Some comments on recent discussions

[oliver]

Hey! :-)


On Wed, Dec 07, 2011 at 01:18:35AM +0100, Paolo Donadeo wrote:
> I just want to add some erratic thoughts summoned by the recent
> <strike>flame</strike>... discussion about "the state of the OCaml
> union". For this reason I'm not pretending to be coherent or to have
> an answer to each and every problem, I'm not John Wayne and I'll never
> be.
[...]

Did you ever tried it? ;-)


> 
> OCaml community is basically composed by computer professionals that
> have very few time to spend on the geek social networks (reddit,
> stackoverflow, ...) to write how this language is beautiful, how it is
> so "pure" (or "impure"), and so on. I write software in OCaml, and
> this software is working right now in a production environment.
> Nothing even comparable with Jane St. or LexiFy or Mylife, but I have
> my customers and if something stops working, they complain A LOT ;-)
[...]

You happy guy...
...so i think you do your own software and sell it.
if freelancing for other companies, then most often (nearly always)
they decide the language to use.



[...]
> What I like in OCaml is that it's really stable, fast and in the last
> years many key tools have been added to the tool chain. As an
> engineer, I think that ocamlbuild + oasis (only an example) are MORE
> valuable than first class modules and GADTs. Which, in turn, are not
> "minor improvements" at all, and I don't see this supposed immobility
> of the language.
[...]

FULL ACK!


> 
> The standard library problem: the core library is small, ugly, useless
> and more. The standard library provided by INRIA can't even send
> email, make a POST, or talk with a web service. Ok, but what exactly
> can you do with the C, or C++ standard library? I *like* the elegant
> simplicity of the standard library and, when something is missing I
> can: 1) write my own solution or 2) search for library by other OCaml
> developers.
[...]

FULL ACK!





> What's wrong with Google searching for a good library?

The wrong thing?
Google is not using Ocaml for anything.
So it must be avoided ;-)



> Why
> many people seems to advocate a unique library "to rule them all"?


Because of Frank Zappa: One Size Fits All




> And
> why this huge library should enter in the standard distribution? Why
> many people complain about the poor visibility of the community, but
> refuses to use ocamlcore.org (thanks Sylvain forever!)


Easy (easier) installation and linking would maybe help a lot
that people don't wait for the big bloaty lib.

Some people are good admins, others are good programmers,
and only few people do like both....

But... hmhhh... there are a lot of tools now that can be used
to compaile/link or install Ocaml and related libraries.


This does mean:
  1) the tools provcded with OCaml maybe are not as good as most people want them
  2) there are already a lot of people contributing and providing tools for that problem


1) could be a point of criticism,
2) shows that the "missing effort in the community" is not true

If community effort would solve all problems, then 2) would
kill 1)

It seems not to be the case.

So 2) can't solve 1).

It either needs better installation tools in the official distribution,
or adapting one of those external tools, or at least recommending one of them
as "recommended by the core team".


Other options might also be possible.

Ideas someone?



> only because
> GitHub has a nicer web2.0 interface?

Even GitHub needs some more colors... ;-)



> Yes, I like GitHub, but I think
> we *ALL* should host our projects, at least the main web pages on
> OCamlCore, to minimize the scatter.

Ah, it needs a tool, named "camlscatter", which not only pushes the OCaml
projects to many servers, but of course also is written in OCaml (just be be
consequent).
(Should it be part of the official distribution?)


;-)



> 
> There are many specialized library for almost everything in OCaml, and
> 2/3 big "standard libraries" (Batteries, Core, ExtLib?). Why can't we
> simply choose one of these excellent libraries? I like
> <ads>Batteries</ads> but there is NOTHING wrong with Core, and I hope
> both of them will remain OUT of the standard distribution forever.
> Why? Because the standard library is small and virtually bug-free or,
> better said, it tends to be so, because it's *rare* that a new feature
> is added, and this is *good*.
[...]

FULL ACK!

Bloat is contrary to modularity.

Pick what you need, and build what you want.


(The customers might have different wishes, looking for monoliths (?!), but
 isn't this a programmers discussion?)


[...]
> I don't say there are no problems, and everything is fine. But if I
> have do point at a problem, especially for newcomers, I would say that
> we need a book, an up to date book, written in good English and
> published by O'Relly.
[...]

ACK.

But because the language is rapidly evolving (*) - despite any other
comments on that - I think it's hard to have a book that is
up to date.

But O'Reilly would not have a problem to make new editions from time to time...
...if there are people who would write the book and update it soon.


> 
> But this is a very hard issue to be solved, no GitHub (R) (TM) in help here ;-)

A book could be also done as a collaberative approach.

But documentation is all to often contrary to programming,
at least in "the masses", and "the masses" is what is looked for,
when it is asked for "community efforts".



Ciao,
   Oliver

(*): Maybe people look for bloaty libraries, and call that "progress" of a "language".

     But the issue on first class modules for example...
     ...can this be ignored, when people talk about progress of a LANGUAGE?

     How many libraries (or how much OOP) would be needed as a workaround for this?

     That even in times of urging Ocaml programmers the core team decided to implement this
     feature (and planned others too) is a huge plus, that shows me, that in the Ocaml core
     team, thinking and elegance has priotrity over hype issues and bloat.

Re: [Caml-list] Some comments on recent discussions

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 5376 bytes --]

A "standard library" does not imply "big" or that it is part of the
standard distribution. Both Batteries and Core would make fine standard
libraries. Neither is very big and both are independent of the standard
distribution. But having 5 different standard libraries is annoying
precisely because the library covers just basic concepts. We don't need 5
APIs for string functions. They are all easy to learn independently but a
pain if you have to know them all. A beginner won't bother taking the time
to do a google search and find which one to use; before that they'll use
another language.

I also think the debate about github, ocamlforge, etc is fruitless. People
have different preferences and who knows what new tools will be developed a
couple years from now. Instead of arguing about which one is best, we
should accept that we will not agree on this. And why do we need to? We can
aggregate the information from multiple sources and present it in a uniform
way on a community website.


On Tue, Dec 6, 2011 at 7:18 PM, Paolo Donadeo <p.donadeo@gmail.com> wrote:

> I just want to add some erratic thoughts summoned by the recent
> <strike>flame</strike>... discussion about "the state of the OCaml
> union". For this reason I'm not pretending to be coherent or to have
> an answer to each and every problem, I'm not John Wayne and I'll never
> be.
>
> OCaml community is basically composed by computer professionals that
> have very few time to spend on the geek social networks (reddit,
> stackoverflow, ...) to write how this language is beautiful, how it is
> so "pure" (or "impure"), and so on. I write software in OCaml, and
> this software is working right now in a production environment.
> Nothing even comparable with Jane St. or LexiFy or Mylife, but I have
> my customers and if something stops working, they complain A LOT ;-)
>
> This pragmatical attitude of the OCaml community is not accidental and
> is the clear expression of a language that *is* pragmatical.
>
> And this attitude is the main reason why, in my very honest opinion,
> the OCaml language haven't a hype comparable to, say, Haskell. Is this
> bad? Are we frustrated because nobody writes on "Wired" about OCaml?
> I'm not.
>
> What I like in OCaml is that it's really stable, fast and in the last
> years many key tools have been added to the tool chain. As an
> engineer, I think that ocamlbuild + oasis (only an example) are MORE
> valuable than first class modules and GADTs. Which, in turn, are not
> "minor improvements" at all, and I don't see this supposed immobility
> of the language.
>
> The standard library problem: the core library is small, ugly, useless
> and more. The standard library provided by INRIA can't even send
> email, make a POST, or talk with a web service. Ok, but what exactly
> can you do with the C, or C++ standard library? I *like* the elegant
> simplicity of the standard library and, when something is missing I
> can: 1) write my own solution or 2) search for library by other OCaml
> developers. What's wrong with Google searching for a good library? Why
> many people seems to advocate a unique library "to rule them all"? And
> why this huge library should enter in the standard distribution? Why
> many people complain about the poor visibility of the community, but
> refuses to use ocamlcore.org (thanks Sylvain forever!) only because
> GitHub has a nicer web2.0 interface? Yes, I like GitHub, but I think
> we *ALL* should host our projects, at least the main web pages on
> OCamlCore, to minimize the scatter.
>
> There are many specialized library for almost everything in OCaml, and
> 2/3 big "standard libraries" (Batteries, Core, ExtLib?). Why can't we
> simply choose one of these excellent libraries? I like
> <ads>Batteries</ads> but there is NOTHING wrong with Core, and I hope
> both of them will remain OUT of the standard distribution forever.
> Why? Because the standard library is small and virtually bug-free or,
> better said, it tends to be so, because it's *rare* that a new feature
> is added, and this is *good*. It's like the basic building blocks of
> Lego: if you want gears or you need a pulley, buy Lego Technic ;-)
>
> Another example: reactive programming. Not using Google (I swear!) I
> can remember LWT, react, Ocamlnet (in part...) and froc. Is this
> situation to be considered harmful? I appreciate this wide range of
> approaches to the same problem, it's the sign of a vital community.
>
> I'm too seasoned as a programmer and I already experienced the
> <irony>huge benefits</irony> of big standard libraries: the
> Magnificent Java Standard Library, BOOST, the ACE framework, and many
> others, all excellent examples of what a serial killer can design with
> a cohort of programmers and a beautiful programming language ;-)
>
> I don't say there are no problems, and everything is fine. But if I
> have do point at a problem, especially for newcomers, I would say that
> we need a book, an up to date book, written in good English and
> published by O'Relly.
>
> But this is a very hard issue to be solved, no GitHub (R) (TM) in help
> here ;-)
>
>
> --
> Paolo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

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

Re: [Caml-list] Some comments on recent discussions

[Mihamina Rakotomandimby]

On 12/07/2011 04:00 AM, oliver wrote:
> A book could be also done as a collaberative approach.

Yep, Ocsigen + Ocsimore + some coding and you have a good platform to 
host it.
by "good" I mean, a wiki way, so that everyone can access it.

-- 
RMA.

Re: [Caml-list] Some comments on recent discussions

[Goswin von Brederlow]

Ashish Agarwal <agarwal1975@gmail.com> writes:

> A "standard library" does not imply "big" or that it is part of the standard
> distribution. Both Batteries and Core would make fine standard libraries.
> Neither is very big and both are independent of the standard distribution. But
> having 5 different standard libraries is annoying precisely because the library
> covers just basic concepts. We don't need 5 APIs for string functions. They are
> all easy to learn independently but a pain if you have to know them all. A
> beginner won't bother taking the time to do a google search and find which one
> to use; before that they'll use another language.

We used to have 100 seperate little modules all over the place. Now we
have 2 contenders for a "standard library". I think we are going the
right way there. Lets leave that allone for at least a year or two.

And we do (initially) need 5 APIs for string functions and we need to
test them all and decide which one fits best. And there can be more than
one that should be kept. E.g. one API with exceptions and one with
option types.  But then all modules in the "standard library" should
provide those APIs we want to keep consistently across all modules.

Lets agree that we eventually want one standard library.

Can we also agree that the standard library can be external to the
compiler, like Batteries or Core is?

> I also think the debate about github, ocamlforge, etc is fruitless. People have
> different preferences and who knows what new tools will be developed a couple
> years from now. Instead of arguing about which one is best, we should accept
> that we will not agree on this. And why do we need to? We can aggregate the
> information from multiple sources and present it in a uniform way on a
> community website.

ACK. Totaly different fruit. Even talking about a standard library is
imho fruitless (at this point in time) and OT to the original problem.

MfG
        Goswin

Re: [Caml-list] Some comments on recent discussions

[Pierre-Alexandre Voye]

[-- Attachment #1: Type: text/plain, Size: 979 bytes --]

2011/12/7 Paolo Donadeo <p.donadeo@gmail.com>

>
>
> I don't say there are no problems, and everything is fine. But if I
> have do point at a problem, especially for newcomers, I would say that
> we need a book, an up to date book, written in good English and
> published by O'Relly.
>
The French book "Le langage Caml" is very great, althought it is quite old,
and althought examples used in the book (write a pascal compiler, a grep
tool and so on) is maybe too theoristic for engineer target.
Maybe a translation would be sufficient ?

>
> But this is a very hard issue to be solved, no GitHub (R) (TM) in help
> here ;-)
>
>
> --
> Paolo
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


-- 
---------------------
https://twitter.com/#!/ontologiae/
http://linuxfr.org/users/montaigne

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

Re: [Caml-list] Some comments on recent discussions

[Gabriel Scherer]

> The French book "Le langage Caml" is very great, althought it is quite old,
> and althought examples used in the book (write a pascal compiler, a grep
> tool and so on) is maybe too theoristic for engineer target.
> Maybe a translation would be sufficient ?

( For those interested, the book is available online at
http://caml.inria.fr/pub/distrib/books/llc.pdf )

I have contacted Xavier Leroy and Pierre Weis a few years ago to get
the TeX sources of the book. I didn't intend to translate from French
to English, but only, for a start, from Caml Light to Objective Caml.
Neither of them could find the sources (they must be about twenty
years old and buried in a 300Mio hidden hard disk somewhere), so I
didn't proceed further.

Remark: there have been at least two successful collaborative
translation efforts in the past:
  http://caml.inria.fr/pub/docs/oreilly-book/
  http://ocamlunix.forge.ocamlcore.org/

I would be ready to participate in such an effort again.
That said, I think the Oreilly book, and Jason Hickey's book draft,
are already good documents (I think "Le langage Caml" would be
significantly better suited to the specific audience of mathematics
undergraduate learning OCaml as their first language, but that's quite
a narrow target).
  http://files.metaprl.org/doc/ocaml-book.pdf

In the context of engineers-friendly OCaml learning document that
could possibly warrant translation, there is also Maxence Guesdon's
"Introduction au langage OCaml". I see it as a well-presented subset
of the Oreilly book, for people that do not need a complete reference
but only a reasonable first taste of the language.
  http://form-ocaml.forge.ocamlcore.org/

On Wed, Dec 7, 2011 at 11:33 AM, Pierre-Alexandre Voye
<ontologiae@gmail.com> wrote:
>
>
> 2011/12/7 Paolo Donadeo <p.donadeo@gmail.com>
>>
>>
>>
>> I don't say there are no problems, and everything is fine. But if I
>> have do point at a problem, especially for newcomers, I would say that
>> we need a book, an up to date book, written in good English and
>> published by O'Relly.
>
> The French book "Le langage Caml" is very great, althought it is quite old,
> and althought examples used in the book (write a pascal compiler, a grep
> tool and so on) is maybe too theoristic for engineer target.
> Maybe a translation would be sufficient ?
>>
>>
>> But this is a very hard issue to be solved, no GitHub (R) (TM) in help
>> here ;-)
>>
>>
>> --
>> Paolo
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa-roc.inria.fr/wws/info/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs
>>
>
>
>
> --
> ---------------------
> https://twitter.com/#!/ontologiae/
> http://linuxfr.org/users/montaigne
>

Re: [Caml-list] Some comments on recent discussions

[David MENTRE]

Hello Gabriel,

[ I should not participate to such a thread... anyway I'm participating. :-) ]

2011/12/7 Gabriel Scherer <gabriel.scherer@gmail.com>:
>> The French book "Le langage Caml" is very great,

Yes, yes and yes!

I especially loved the "do one *complete* program in one chapter of a
few pages" approach.

>> althought it is quite old,
>> and althought examples used in the book (write a pascal compiler, a grep
>> tool and so on) is maybe too theoristic for engineer target.
>> Maybe a translation would be sufficient ?
>
> ( For those interested, the book is available online at
> http://caml.inria.fr/pub/distrib/books/llc.pdf )

I thought about the same.

Another idea: adapt the book to ePub format extended with Javascript
(apparently latest ePub draft has such scripting capabilities) and use
js_of_ocaml tool to embed an OCaml toplevel inside the book: read the
examples, execute examples, play with the examples! Wouldn't it be
nice? ;-)

Unfortunately, it is available under a non Free license (Non
Commercial clause of CC-BY-NC-SA licence), this is a show stopper for
me. I would like such a book to be included in Debian or other Free
Software distributions.

> I have contacted Xavier Leroy and Pierre Weis a few years ago to get
> the TeX sources of the book. I didn't intend to translate from French
> to English, but only, for a start, from Caml Light to Objective Caml.
> Neither of them could find the sources (they must be about twenty
> years old and buried in a 300Mio hidden hard disk somewhere), so I
> didn't proceed further.

Wouldn't it be the non Free license, I would even start from the PDF. :-(

Best regards,
david

Re: [Caml-list] Some comments on recent discussions

[Alan Schmitt]

On 7 déc. 2011, at 14:15, David MENTRE wrote:

> 2011/12/7 Gabriel Scherer <gabriel.scherer@gmail.com>:
>>> The French book "Le langage Caml" is very great,
> 
> Yes, yes and yes!
> 
> I especially loved the "do one *complete* program in one chapter of a
> few pages" approach.

Yes, it's a great start to write a course on Caml. (I realize that the online version is the second edition, yet it is shorter than the paper version I have here. Either some chapters were removed in the 2nd edition or they are not available online.)

> Another idea: adapt the book to ePub format extended with Javascript
> (apparently latest ePub draft has such scripting capabilities) and use
> js_of_ocaml tool to embed an OCaml toplevel inside the book: read the
> examples, execute examples, play with the examples! Wouldn't it be
> nice? ;-)

This would be most useful for teaching. I'd be ready to help such a project.

Alan

Re: [Caml-list] Some comments on recent discussions

[Ashish Agarwal]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

On Wed, Dec 7, 2011 at 8:15 AM, David MENTRE <dmentre@linux-france.org>wrote:


> Another idea: adapt the book to ePub format extended with Javascript
> (apparently latest ePub draft has such scripting capabilities) and use
> js_of_ocaml tool to embed an OCaml toplevel inside the book: read the
> examples, execute examples, play with the examples! Wouldn't it be
> nice? ;-)
>

If you have an interest in doing this, please join the ocamlweb project
[1]. One of the features we'd like to support is good community generated
documentation, and this is exactly the kind of technology I'd like to see
implemented.
[1] https://sympa-roc.inria.fr/wws/arc/caml-list/2011-07/msg00093.html


 Wouldn't it be the non Free license, I would even start from the PDF. :-(
>

Unless the original authors gave permission to use it under a different
license. This is very likely if we just ask.

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

Re: [Caml-list] Some comments on recent discussions

[oliver]

On Wed, Dec 07, 2011 at 12:18:18PM +0100, Gabriel Scherer wrote:
[...]
> In the context of engineers-friendly OCaml learning document that
> could possibly warrant translation, there is also Maxence Guesdon's
> "Introduction au langage OCaml". I see it as a well-presented subset
> of the Oreilly book, for people that do not need a complete reference
> but only a reasonable first taste of the language.
[...]


A first taste?

I think there are a lot of first-taste docs.

One is in part I of the OCaml manual, starting with section 3:

  http://caml.inria.fr/pub/docs/manual-ocaml/manual003.html

Just some minutes ago I found a german starter doc (I think from
a lecture/workshop):
  http://homepage.uibk.ac.at/~c703463/ocaml/ocamlkurs.pdf

OCaml on youtube: :-)
  OCaml-Tutorial: Polymorphie und Kombinatoren
    http://www.youtube.com/watch?v=oEML3QIP2sA

I remember some web-tutorials also,
even I just do not have the links available.



But a good book would need to be more than just
"a first taste" of the language, or a printed
mix of intro-docs.



Ciao,
   Oliver

Re: [Caml-list] Some comments on recent discussions

[rixed]

> The French book "Le langage Caml" is very great, althought it is quite old,

I'd also like to advertise the book "Programmation Fonctionnelle, Générique et
Objet" by Philippe Narbel that I found very good and which is probably more
up to date.
Such a book translated into english would be very valuable IMHO.

(Note: since it's not the first time I raise attention for this book it's perhaps
worth saying that I have no link whatsoever with the author nor publisher)

Re: [Caml-list] Some comments on recent discussions

[oliver]

Hello,


On Thu, Dec 08, 2011 at 08:59:22AM +0100, rixed@happyleptic.org wrote:
> > The French book "Le langage Caml" is very great, althought it is quite old,
> 
> I'd also like to advertise the book "Programmation Fonctionnelle, Générique et
> Objet" by Philippe Narbel that I found very good and which is probably more
> up to date.
> Such a book translated into english would be very valuable IMHO.
[...]

Yes, english please, otherweise it's not accessible to most
potential readers.


Ciao,
   Oliver

[Caml-list] Wanted book (Re: Some comments on recent discussions)

[Mihamina Rakotomandimby]

On 12/08/2011 10:59 AM, rixed@happyleptic.org wrote:
> I'd also like to advertise the book "Programmation Fonctionnelle, Générique et
> Objet" by Philippe Narbel that I found very good and which is probably more
> up to date.

It's not sold anymore...
Has some a pdf/ps/whatever version of it?

I need to make some OOP in OCaml in an emergency right now and I 
remember I read it at my University library but now I want to buy it, 
it's difficult...

And I'm in Madagascar, it's hard...


-- 
RMA.

Re: [Caml-list] Some comments on recent discussions

[Martin Jambon]

On 12/06/2011 09:53 AM, Alain Frisch wrote:

> That said, I'd argue to avoid creating a "community" fork.

I would like to point out that in the GitHub jargon, a "fork" is just a
personal branch, usually intended to be merged back into the main
repository via a so-called "pull request".

I hope there won't be any misunderstanding because of that.


Martin

Re: [Caml-list] Wanted book (Re: Some comments on recent discussions)

[oliver]

On Thu, Dec 08, 2011 at 04:15:15PM +0300, Mihamina Rakotomandimby wrote:
> On 12/08/2011 10:59 AM, rixed@happyleptic.org wrote:
> >I'd also like to advertise the book "Programmation Fonctionnelle, Générique et
> >Objet" by Philippe Narbel that I found very good and which is probably more
> >up to date.
> 
> It's not sold anymore...
> Has some a pdf/ps/whatever version of it?
> 
> I need to make some OOP in OCaml in an emergency right now and I
> remember I read it at my University library but now I want to buy
> it, it's difficult...
> 
> And I'm in Madagascar, it's hard...
[...]


For OOP the Oreilley book is helpful.
It's online.

Ciao,
   Oliver

Re: [Caml-list] Some comments on recent discussions

[Xavier Leroy]

On 12/07/2011 12:18 PM, Gabriel Scherer wrote:

>> The French book "Le langage Caml" is very great, althought it is quite old,
>> and althought examples used in the book (write a pascal compiler, a grep
>> tool and so on) is maybe too theoristic for engineer target.
>> Maybe a translation would be sufficient ?
> 
> I have contacted Xavier Leroy and Pierre Weis a few years ago to get
> the TeX sources of the book. I didn't intend to translate from French
> to English, but only, for a start, from Caml Light to Objective Caml.
> Neither of them could find the sources

There must have been a misunderstanding: I have the full LaTeX
sources, of course.  What may have been lost is Pierre's first cut at
an OCaml version of the book.

Alan Schmitt adds:

> Yes, it's a great start to write a course on Caml. (I realize that
> the online version is the second edition, yet it is shorter than the
> paper version I have here. Either some chapters were removed in the
> 2nd edition or they are not available online.)

No, no, the online edition is identical to the 2nd edition, which has
one additional chapter.  It's just that pages are wider and taller
than those of the 1st edition, resulting in fewer pages overall.

David Mentré adds:

> Unfortunately, it is available under a non Free license (Non
> Commercial clause of CC-BY-NC-SA licence), this is a show stopper for
> me. I would like such a book to be included in Debian or other Free
> Software distributions.

I stand very firmly by the NC license.  If anyone wants to make money
out of this book or a derived work, the original authors and all the
future contributors should get their share, Debian orthodoxy
notwithstanding.

- Xavier Leroy

Re: [Caml-list] Some comments on recent discussions

[Andrei Formiga]

On Tue, Dec 6, 2011 at 12:24 PM, Jonathan Protzenko
<jonathan.protzenko@gmail.com> wrote:
>
> = Improving the community =
>
> I think the main point of the discussion is to improve "the community". If
> we really want to improve OCaml as a whole, then I think we can put our
> efforts on better areas than patching the compiler.
>
> == Package management system ==
>
> The thing that's most needed is, imho, a package manager that works.
> Oasis-db looked very promising as far as I could tell, but Sylvain doesn't
> have as much time as he used to do. Instead of hacking on our pet projects
> (which is, I admit, very rewarding), maybe someone could step up and make
> Oasis-db happen. We don't have a single, unified answer to "what should I
> install to easily hack with OCaml?". What made Python, Perl, Haskell
> successful is the package management systems. How much longer are we going
> to shy away from this issue? Sure, it's much more fun to hack on the
> compiler. Not as useful.
>

I think a good package system (with associated repository) and better
documentation are the two biggest things that can help OCaml's
adoption. It's true that there are languages that have become
successful without a package management system, but it has become
increasingly expected that languages have one. OCaml does not have
marketing or hype, so it has to win over new users by not creating
barriers to adoption. Plus it's much easier to work on a daily basis,
even for veterans. This is already true with GODI, which saves me a
lot of time when the library I need to install is available in its
repo.

The question is: what should be done? What must be done to enable
OASIS-DB? Or should everyone adopt GODI? What's the situation between
these two systems? Maybe having some kind of rough roadmap would help
there.

Regarding documentation, this is a problem in many fronts, beginning
with the book situation. Practical OCaml was a good idea, badly
executed. And Jason Hicks' fine book is probably stuck in limbo
because of legal battles and so it never came out. I recently had a
look at the Go language from Google, and the "A Tour of Go" tutorial
is very good (at http://tour.golang.org/ ). Maybe something similar
for OCaml would be a nice addition, especially given that the OCaml
Tutorial is apparently MIA. But I think having a good package manager
should come first (btw, Go has one).



-- 
[]s, Andrei Formiga

Re: [Caml-list] Some comments on recent discussions

[Edgar Friendly]

On 12/10/2011 03:32 PM, Andrei Formiga wrote:
> The question is: what should be done? What must be done to enable
> OASIS-DB?

Sylvain has worked with me to enable auto-installation of oasis-db 
packages via odb[2].  There's not a large repo of packages[1], but most 
of it is auto-installable (run odb to get a list), as long as you have 
ocaml and findlib to start from.  The dependencies are automatically 
handled and installed from source.  I even have confirmation that it 
works under windows, although it definitely needs cygwin there.

The repo could use some love with people uploading[3] new packages to 
it.  Just provide a tarball and optionally a link to the tarball on some 
other website.  Oasis dependencies are detected automatically, packages 
w/o an _oasis file need to have deps specified manually.  Odb is able to 
install findlib-enabled projects that use ([./configure &&] make && make 
install), (omake && omake install) and oasis' setup.ml for building. 
This last option is able to execute whatever sequence of configure, make 
and install commands are needed for your project, without replacing the 
current infrastructure.

Files uploaded to the repo are available with odb --unstable, they have 
to be manually approved to become part of the default --testing.  I hope 
that in time, the --stable option can become default.  Odb also installs 
by default to ~/.odb/lib.  --sudo tells it to use sudo for global 
install, --have-perms tells it to install to the global repo without 
sudo.  If anyone wants to auto-detect permissions on the ocamlfind 
global, we can get rid of --have-perms.

I'm on #ocaml most of the time, and will get back to you if I'm away. 
Tell me how things work or don't.

E.

[1] http://oasis.ocamlcore.org/dev/browse
[2] http://github.com/thelema/odb
[3] http://oasis.ocamlcore.org/dev/upload

Re: [Caml-list] Some comments on recent discussions

[rixed]

What I'd really like is a way to mix any version I want of the packages I
install, especially experimental versions for the packages I want to test or
contribute to.
I stopped using GODI some time ago because I wanted master of ocaml and
batteries but stable versions of everything else.  So I ended up rolling my
own makefile-based installation/upgrade tool which is both annoying and
archaic.

Is this in the planned feature list?

Re: [Caml-list] Some comments on recent discussions

[Edgar Friendly]

On 12/10/2011 04:12 PM, rixed@happyleptic.org wrote:
> What I'd really like is a way to mix any version I want of the packages I
> install, especially experimental versions for the packages I want to test or
> contribute to.
> I stopped using GODI some time ago because I wanted master of ocaml and
> batteries but stable versions of everything else.  So I ended up rolling my
> own makefile-based installation/upgrade tool which is both annoying and
> archaic.
>
> Is this in the planned feature list?
>
>
This is possible currently, by using the --stable, --testing and 
--unstable flags when installing different packages.  Of course, the 
downside of this is that there's no guarantee or test of compatibility 
between packages and different versions of OCaml (and possibly each 
other).  Oasis packages can have versioned dependencies, which helps, 
but the only real guarantee I think that odb can make is that the stable 
repo all works with each other.  Maybe the testing repo too, sometimes, 
but definitely not the unstable repo.

The above all assumes that the versions you want are packaged and in 
oasis-db.  Auto installation from repositories (or local directories) 
has been considered, but there's some more code to add, as currently the 
oasis-db server parses _oasis files for deps, and odb is designed to be 
extremely lightweight.

On that note, one more thing about odb - it has no configuration or 
database of what packages are installed.  It doesn't even have the 
ability to remove a package (not that this couldn't be hacked up in not 
too much time for library packages).  If you ask it to install a 
package, it checks for deps by asking findlib what's installed.  It 
doesn't try to control things as much as GODI seems to.  It just does 
the minimum necessary to get the job done.  This means it plays as 
nicely as possible with packages installed by whatever other means you 
wish, even GODI.

E.

Re: [Caml-list] Some comments on recent discussions

[rixed]

> This is possible currently, by using the --stable, --testing and
> --unstable flags when installing different packages.  Of course, the
> downside of this is that there's no guarantee or test of
> compatibility between packages and different versions of OCaml (and
> possibly each other).  Oasis packages can have versioned
> dependencies, which helps, but the only real guarantee I think that
> odb can make is that the stable repo all works with each other.

I will try to use it for some time.
But your description of it does not match my dreams.
Ideally, I would `odb install this-package --version=X.Y.Z`,
and `odb install another-one --branch=master`, and odb would
upgrade and/or rebuild what's required.
Very similar to the gentoo package system from what I know.

Thank you anyway for not being selfish with your time.

Re: [Caml-list] Some comments on recent discussions

[Edgar Friendly]

On 12/10/2011 04:49 PM, rixed@happyleptic.org wrote:
> I will try to use it for some time.
> But your description of it does not match my dreams.
> Ideally, I would `odb install this-package --version=X.Y.Z`,
> and `odb install another-one --branch=master`, and odb would
> upgrade and/or rebuild what's required.
> Very similar to the gentoo package system from what I know.
>
> Thank you anyway for not being selfish with your time.

Requesting specific package versions is not currently supported by the 
server, but if Sylvain can add something, I can probably support it in 
the client.

Odb's job is only to automate the boring parts of package installation, 
finding deps, downloading tarballs, extracting, building, installing. 
It's not a package manager.  It's an 80% solution, not an integrated, 
99.9%, takes control of everything solution.

E.

Re: [Caml-list] Some comments on recent discussions

[Hans Ole Rafaelsen]

[-- Attachment #1: Type: text/plain, Size: 3756 bytes --]

On Sat, Dec 10, 2011 at 10:12 PM, <rixed@happyleptic.org> wrote:

> What I'd really like is a way to mix any version I want of the packages I
> install, especially experimental versions for the packages I want to test
> or
> contribute to.
> I stopped using GODI some time ago because I wanted master of ocaml and
> batteries but stable versions of everything else.  So I ended up rolling my
> own makefile-based installation/upgrade tool which is both annoying and
> archaic.
>
> Here is a little trick that I did to get full control of which version of
each package gets installed.

In rocketboost, file 'godi-tools/mk/build/mk/bsd.prefs.mk' around line 700
change to use your private repository.

# The primary backup
site.

MASTER_SITE_BACKUP=
\

        http://192.168.100.100/godi/distfiles/

#       http://godi-backup2.camlcity.org/godi-backup/\

#       http://www.ocaml-programming.de/godi-backup/\

#       http://godi.0ok.org/godi-backup/



# Where to put distfiles that don't have any other master
site

MASTER_SITE_LOCAL=
\


${MASTER_SITE_BACKUP:=LOCAL_PORTS/}



GODI_BUILD_SITE?=
\

        http://192.168.100.100/godi/${GODI_SECTION}

#        http://www.ocaml-programming.de/godi-build/${GODI_SECTION}/

# This must only be one
URL.



GODI_BUILD_BACKUP_SITES=
\

        http://192.168.100.100/godi/${GODI_SECTION}

#       http://godi-backup2.camlcity.org/godi-build/${GODI_SECTION}/\

#       http://godi.0ok.org/godi-build/${GODI_SECTION}/



GODI_BUILD_SITES=
\

        ${GODI_BUILD_SITE}
\


${GODI_BUILD_BACKUP_SITES}



ROCKETBOOST_BUILD_SITES?=
\

        http://192.168.100.100/godi/

#       http://www.ocaml-programming.de/godi-build/rocketboost/\

#       http://godi-backup2.camlcity.org/godi-build/rocketboost/\

#       http://godi.0ok.org/godi-build/rocketboost/


You also need to patch godi-tools package in the same way, so that the
bsd.prefs.mk that gets installed with it and is used after the bootstrap is
also pointing to the private repository.

At your server you keep the distfiles in the godi/distfiles/ folder.  This
is similar to the http://www.ocaml-programming.de/godi-backup/ for the
official GODI.  For the build files you keep them and 'available.new' under
a section directory e.g. 3.12 similar to
http://www.ocaml-programming.de/godi-build/3.12 or have a dev section or
whatever section you want.

With this in place you can manage your own GODI "universe". You can mix
whatever version of packages you want, by editing the available.new. Guess
you might have to delete the local copy of a package in
build/buildfiles/<package>.tar.gz and also <apps-|godi-<package> if you
decide to rollback to an old version of the package.

With this setup you should also have an official version of GODI that fetch
from the official places. This is not the installation you work with but
occasionally you can switch to it (by changing the PATH variable or a
sym-link), do an update and see what new packages are available. You copy
the new distfiels you want to your distfiles/ directory at your server and
the buildfiles to the section you want them in and update the available.new
for that section.

Having this on a server makes it possible for a team to work with the same
versions of the packages in an easy way.

Maybe it is possible to override the locations without patching the '
bsd.prefs.mk' files, but this was the way I ended up doing it, and I would
be glad to hear if there is some easier way.

Hopes this helps



> Is this in the planned feature list?
>
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

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

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Samstag, den 10.12.2011, 17:32 -0300 schrieb Andrei Formiga:
> On Tue, Dec 6, 2011 at 12:24 PM, Jonathan Protzenko
> <jonathan.protzenko@gmail.com> wrote:
> >
> > = Improving the community =
> >
> > I think the main point of the discussion is to improve "the community". If
> > we really want to improve OCaml as a whole, then I think we can put our
> > efforts on better areas than patching the compiler.
> >
> > == Package management system ==
> >
> > The thing that's most needed is, imho, a package manager that works.
> > Oasis-db looked very promising as far as I could tell, but Sylvain doesn't
> > have as much time as he used to do. Instead of hacking on our pet projects
> > (which is, I admit, very rewarding), maybe someone could step up and make
> > Oasis-db happen. We don't have a single, unified answer to "what should I
> > install to easily hack with OCaml?". What made Python, Perl, Haskell
> > successful is the package management systems. How much longer are we going
> > to shy away from this issue? Sure, it's much more fun to hack on the
> > compiler. Not as useful.
> >
> 
> I think a good package system (with associated repository) and better
> documentation are the two biggest things that can help OCaml's
> adoption. It's true that there are languages that have become
> successful without a package management system, but it has become
> increasingly expected that languages have one. OCaml does not have
> marketing or hype, so it has to win over new users by not creating
> barriers to adoption. Plus it's much easier to work on a daily basis,
> even for veterans. This is already true with GODI, which saves me a
> lot of time when the library I need to install is available in its
> repo.
> 
> The question is: what should be done? What must be done to enable
> OASIS-DB? Or should everyone adopt GODI? What's the situation between
> these two systems? Maybe having some kind of rough roadmap would help
> there.

The plan is that OASIS-DB exports its packages in a format that is
understood by GODI. OASIS-DB would then appear as a second source for
packages. For users there would be practically no difference -
godi_console just fetches packages from a second site, too.

For package developers this will mean that there is a choice. More
complicated packages will probably remain native GODI ones (because of
the unlimited scripting) whereas the average library will be well
expressable in OASIS-DB.

Gerd


> Regarding documentation, this is a problem in many fronts, beginning
> with the book situation. Practical OCaml was a good idea, badly
> executed. And Jason Hicks' fine book is probably stuck in limbo
> because of legal battles and so it never came out. I recently had a
> look at the Go language from Google, and the "A Tour of Go" tutorial
> is very good (at http://tour.golang.org/ ). Maybe something similar
> for OCaml would be a nice addition, especially given that the OCaml
> Tutorial is apparently MIA. But I think having a good package manager
> should come first (btw, Go has one).
> 
> 
> 
> -- 
> []s, Andrei Formiga
> 

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Samstag, den 10.12.2011, 22:12 +0100 schrieb rixed@happyleptic.org:
> What I'd really like is a way to mix any version I want of the packages I
> install, especially experimental versions for the packages I want to test or
> contribute to.
> I stopped using GODI some time ago because I wanted master of ocaml and
> batteries but stable versions of everything else.  So I ended up rolling my
> own makefile-based installation/upgrade tool which is both annoying and
> archaic.
> 
> Is this in the planned feature list?

Well, for ocaml you can build any svn version in GODI instead of the
released one. This is implemented as a hack in the package makefile.
This method sometimes raises problems, though: certain svn versions are
broken in some respect, or the very few patches cannot be applied. For
example, 3.13 does currently not work because of this.

On the list for GODI there is feature that would greatly help here:
improved support for multiple repositories. That way, there could be a
bleeding edge repo for select packages, which always installs the latest
(and most broken) version. The user could pick these packages one by
one. (This feature is already mostly implemented.)

Another helpful utility could be a fake package generator, which creates
an empty package just for fulfilling dependencies. (Basically you could
already do this with "godi_console ptool", and the only thing needed is
a wrapper calling it in the right way.)

Gerd

Re: [Caml-list] Some comments on recent discussions

[Martin DeMello]

Better Windows support would be very nice too. A friend recently had a
python app that he wanted to port to native code, and I offered to do
it for him in OCaml. The linux version was quick and easy to develop,
and we both believed that he could just install OCaml and the required
libraries on windows and have easy cross-platform support with little
effort. He spent two days trying to get GODI and Batteries working,
and finally gave up; it was eashobier for me to just rewrite the bits
I was using directly in my code and not have dependencies. For a
larger project, it really wouldn't have been feasible not to be able
to rely on GODI, and (since my main area of interest is end-user
native apps) this has made me wary of using OCaml for anything other
than apps for my own use, or apps that I am very sure will only be
used under linux.

martin

On Tue, Dec 6, 2011 at 7:24 AM, Jonathan Protzenko
<jonathan.protzenko@gmail.com> wrote:
> Dear OCaml hackers,
>
> I'm very uneasy about the current opinions that are voiced on the caml-list.
> I have good reasons to think I'm not the only one in that situation, so
> please allow me to raise a few concerns about some recent discussions.
>
> There's several subtopics in the "OCaml maintenance status / community fork"
> that I'd like to discuss.
>
> = Improving the community =
>
> I think the main point of the discussion is to improve "the community". If
> we really want to improve OCaml as a whole, then I think we can put our
> efforts on better areas than patching the compiler.
>
> == Package management system ==
>
> The thing that's most needed is, imho, a package manager that works.
> Oasis-db looked very promising as far as I could tell, but Sylvain doesn't
> have as much time as he used to do. Instead of hacking on our pet projects
> (which is, I admit, very rewarding), maybe someone could step up and make
> Oasis-db happen. We don't have a single, unified answer to "what should I
> install to easily hack with OCaml?". What made Python, Perl, Haskell
> successful is the package management systems. How much longer are we going
> to shy away from this issue? Sure, it's much more fun to hack on the
> compiler. Not as useful.
>
> == Leaving our own corner of the web ==
>
> The OCaml community likes to stay in its own corner of the web, in
> isolation. We live on obscure web sites: who knows about ocamlforge outside
> the OCaml community? Who knows about the caml hump? We could host our
> projects on Sourceforge or on GitHub. We could get recognition in the
> open-source world through our projects, we could be more social, we could
> boost the language stats on ohloh, we could attract more contributors (being
> a fervent user of GitHub, I must say I've attracted a significant amount of
> contributors that way ; being on an obscure forge, I'm certain it would've
> never happened). We stay away from that. Why? Because GitHub is not
> open-source. The whole point of git is that everyone, everywhere has a
> backup copy and that we don't care if GitHub falls down. Nevermind.
>
> GitHub has a fantastic integration between the bug tracker, the commit
> messages (git commit -m "Fix #486" closes bug 486 on the bug tracker), the
> source repositories. You can discuss patches in-place. You can interact in a
> very easy manner. You can do peer-review in a snap. GitHub is the only place
> that leverages the social nature of open-source collaboration! That's
> precisely what we're trying to achieve here. Are we going to throw all that
> goodness away? What kind of signal are we sending, when we're considering
> hosting our own instance of gitorious? A very simple one: "we like to stay
> in our own corner — don't come".
>
> There are valid points: GitHub doesn't have a maliing-list list system. Is
> that really an excuse? How hard would it be to setup a website that lists
> OCaml projects, provides them with a mailing-list, and points to their
> GitHub page?
>
> = What is this about ? =
>
> If it's about improving the general situation with OCaml and its community
> (the title of this thread contains the word "community"), then I believe
> hacking on the compiler is not the most effective way to achieve that goal.
> We're hackers. We like to hack on things. And we often fail to ask
> ourselves: is it really worth implementing? Submitting patches is easy.
> Submitting quality patches that do solve a real problem is harder. The ARM
> backend does need a cleanup, and the patch does solve a stringent issue.
> That may not be the case for all patches.
>
> There is indeed a problem w.r.t external contributions. I agree that the
> INRIA team could make it clearer what its stance on external contributions
> is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on
> github that everyone can fork, where we would merge really outstanding
> features, before submitting them to INRIA, as you described. I don't think
> it is such a good idea creating a real fork. Maybe some sort of integration
> platform on GitHub would be the right solution to the "patch review"
> problem.
>
> I'm not even sure what kind of patches you wish to see integrated. Can you
> clarify that?
>
> = Conclusion =
>
> This is indeed a long rant, but I'd like to see us being more practical and
> down-to-earth. I love OCaml. I think we can do better for the language.
>
> Kind regards,
>
> jonathan
>

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Hi Martin,

GODI is currently broken on Windows, and I would need to invest again a
few days to get at least the basics running again. This is a big problem
for me, because I've personally no direct advantage from this, and there
is also the question how you can keep such a very different port running
when you don't use it (i.e. errors will start accumulating again). At
least I'd need support from a skilled porter with direct interest in it.

Also, the usefulness is not totally clear to me. Actually, only those
GODI libraries will run painlessly that are either ocaml-only, and that
have been specially ported. So for any bigger real-world app you would
clearly run into big problems anyway, because it is almost sure that
there is a non-ported library in the dependency chain. It might be good
enough for education or programs not needing deep OS support, but it is
clearly limited.

Gerd

Am Montag, den 12.12.2011, 21:54 -0800 schrieb Martin DeMello:
> Better Windows support would be very nice too. A friend recently had a
> python app that he wanted to port to native code, and I offered to do
> it for him in OCaml. The linux version was quick and easy to develop,
> and we both believed that he could just install OCaml and the required
> libraries on windows and have easy cross-platform support with little
> effort. He spent two days trying to get GODI and Batteries working,
> and finally gave up; it was eashobier for me to just rewrite the bits
> I was using directly in my code and not have dependencies. For a
> larger project, it really wouldn't have been feasible not to be able
> to rely on GODI, and (since my main area of interest is end-user
> native apps) this has made me wary of using OCaml for anything other
> than apps for my own use, or apps that I am very sure will only be
> used under linux.
> 
> martin
> 
> On Tue, Dec 6, 2011 at 7:24 AM, Jonathan Protzenko
> <jonathan.protzenko@gmail.com> wrote:
> > Dear OCaml hackers,
> >
> > I'm very uneasy about the current opinions that are voiced on the caml-list.
> > I have good reasons to think I'm not the only one in that situation, so
> > please allow me to raise a few concerns about some recent discussions.
> >
> > There's several subtopics in the "OCaml maintenance status / community fork"
> > that I'd like to discuss.
> >
> > = Improving the community =
> >
> > I think the main point of the discussion is to improve "the community". If
> > we really want to improve OCaml as a whole, then I think we can put our
> > efforts on better areas than patching the compiler.
> >
> > == Package management system ==
> >
> > The thing that's most needed is, imho, a package manager that works.
> > Oasis-db looked very promising as far as I could tell, but Sylvain doesn't
> > have as much time as he used to do. Instead of hacking on our pet projects
> > (which is, I admit, very rewarding), maybe someone could step up and make
> > Oasis-db happen. We don't have a single, unified answer to "what should I
> > install to easily hack with OCaml?". What made Python, Perl, Haskell
> > successful is the package management systems. How much longer are we going
> > to shy away from this issue? Sure, it's much more fun to hack on the
> > compiler. Not as useful.
> >
> > == Leaving our own corner of the web ==
> >
> > The OCaml community likes to stay in its own corner of the web, in
> > isolation. We live on obscure web sites: who knows about ocamlforge outside
> > the OCaml community? Who knows about the caml hump? We could host our
> > projects on Sourceforge or on GitHub. We could get recognition in the
> > open-source world through our projects, we could be more social, we could
> > boost the language stats on ohloh, we could attract more contributors (being
> > a fervent user of GitHub, I must say I've attracted a significant amount of
> > contributors that way ; being on an obscure forge, I'm certain it would've
> > never happened). We stay away from that. Why? Because GitHub is not
> > open-source. The whole point of git is that everyone, everywhere has a
> > backup copy and that we don't care if GitHub falls down. Nevermind.
> >
> > GitHub has a fantastic integration between the bug tracker, the commit
> > messages (git commit -m "Fix #486" closes bug 486 on the bug tracker), the
> > source repositories. You can discuss patches in-place. You can interact in a
> > very easy manner. You can do peer-review in a snap. GitHub is the only place
> > that leverages the social nature of open-source collaboration! That's
> > precisely what we're trying to achieve here. Are we going to throw all that
> > goodness away? What kind of signal are we sending, when we're considering
> > hosting our own instance of gitorious? A very simple one: "we like to stay
> > in our own corner — don't come".
> >
> > There are valid points: GitHub doesn't have a maliing-list list system. Is
> > that really an excuse? How hard would it be to setup a website that lists
> > OCaml projects, provides them with a mailing-list, and points to their
> > GitHub page?
> >
> > = What is this about ? =
> >
> > If it's about improving the general situation with OCaml and its community
> > (the title of this thread contains the word "community"), then I believe
> > hacking on the compiler is not the most effective way to achieve that goal.
> > We're hackers. We like to hack on things. And we often fail to ask
> > ourselves: is it really worth implementing? Submitting patches is easy.
> > Submitting quality patches that do solve a real problem is harder. The ARM
> > backend does need a cleanup, and the patch does solve a stringent issue.
> > That may not be the case for all patches.
> >
> > There is indeed a problem w.r.t external contributions. I agree that the
> > INRIA team could make it clearer what its stance on external contributions
> > is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on
> > github that everyone can fork, where we would merge really outstanding
> > features, before submitting them to INRIA, as you described. I don't think
> > it is such a good idea creating a real fork. Maybe some sort of integration
> > platform on GitHub would be the right solution to the "patch review"
> > problem.
> >
> > I'm not even sure what kind of patches you wish to see integrated. Can you
> > clarify that?
> >
> > = Conclusion =
> >
> > This is indeed a long rant, but I'd like to see us being more practical and
> > down-to-earth. I love OCaml. I think we can do better for the language.
> >
> > Kind regards,
> >
> > jonathan
> >
> 
> 

Re: [Caml-list] Some comments on recent discussions

[Martin DeMello]

good points. an alternative would be a wiki page describing step by
step and in detail, how to set up an ocaml development environment on
windows, particularly how to get ocamlfind and manual package
installation working. my friend couldn't manage to get Batteries
working either, even after he gave up on GODI, and i didn't know
enough to help. it's a bit frustrating for me because i don't have or
use windows either, but if i develop an end user app i really want it
to be as cross-platform as possible.

martin

On Mon, Dec 12, 2011 at 11:15 PM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> Hi Martin,
>
> GODI is currently broken on Windows, and I would need to invest again a
> few days to get at least the basics running again. This is a big problem
> for me, because I've personally no direct advantage from this, and there
> is also the question how you can keep such a very different port running
> when you don't use it (i.e. errors will start accumulating again). At
> least I'd need support from a skilled porter with direct interest in it.
>
> Also, the usefulness is not totally clear to me. Actually, only those
> GODI libraries will run painlessly that are either ocaml-only, and that
> have been specially ported. So for any bigger real-world app you would
> clearly run into big problems anyway, because it is almost sure that
> there is a non-ported library in the dependency chain. It might be good
> enough for education or programs not needing deep OS support, but it is
> clearly limited.
>
> Gerd
>
> Am Montag, den 12.12.2011, 21:54 -0800 schrieb Martin DeMello:
>> Better Windows support would be very nice too. A friend recently had a
>> python app that he wanted to port to native code, and I offered to do
>> it for him in OCaml. The linux version was quick and easy to develop,
>> and we both believed that he could just install OCaml and the required
>> libraries on windows and have easy cross-platform support with little
>> effort. He spent two days trying to get GODI and Batteries working,
>> and finally gave up; it was eashobier for me to just rewrite the bits
>> I was using directly in my code and not have dependencies. For a
>> larger project, it really wouldn't have been feasible not to be able
>> to rely on GODI, and (since my main area of interest is end-user
>> native apps) this has made me wary of using OCaml for anything other
>> than apps for my own use, or apps that I am very sure will only be
>> used under linux.
>>
>> martin
>>
>> On Tue, Dec 6, 2011 at 7:24 AM, Jonathan Protzenko
>> <jonathan.protzenko@gmail.com> wrote:
>> > Dear OCaml hackers,
>> >
>> > I'm very uneasy about the current opinions that are voiced on the caml-list.
>> > I have good reasons to think I'm not the only one in that situation, so
>> > please allow me to raise a few concerns about some recent discussions.
>> >
>> > There's several subtopics in the "OCaml maintenance status / community fork"
>> > that I'd like to discuss.
>> >
>> > = Improving the community =
>> >
>> > I think the main point of the discussion is to improve "the community". If
>> > we really want to improve OCaml as a whole, then I think we can put our
>> > efforts on better areas than patching the compiler.
>> >
>> > == Package management system ==
>> >
>> > The thing that's most needed is, imho, a package manager that works.
>> > Oasis-db looked very promising as far as I could tell, but Sylvain doesn't
>> > have as much time as he used to do. Instead of hacking on our pet projects
>> > (which is, I admit, very rewarding), maybe someone could step up and make
>> > Oasis-db happen. We don't have a single, unified answer to "what should I
>> > install to easily hack with OCaml?". What made Python, Perl, Haskell
>> > successful is the package management systems. How much longer are we going
>> > to shy away from this issue? Sure, it's much more fun to hack on the
>> > compiler. Not as useful.
>> >
>> > == Leaving our own corner of the web ==
>> >
>> > The OCaml community likes to stay in its own corner of the web, in
>> > isolation. We live on obscure web sites: who knows about ocamlforge outside
>> > the OCaml community? Who knows about the caml hump? We could host our
>> > projects on Sourceforge or on GitHub. We could get recognition in the
>> > open-source world through our projects, we could be more social, we could
>> > boost the language stats on ohloh, we could attract more contributors (being
>> > a fervent user of GitHub, I must say I've attracted a significant amount of
>> > contributors that way ; being on an obscure forge, I'm certain it would've
>> > never happened). We stay away from that. Why? Because GitHub is not
>> > open-source. The whole point of git is that everyone, everywhere has a
>> > backup copy and that we don't care if GitHub falls down. Nevermind.
>> >
>> > GitHub has a fantastic integration between the bug tracker, the commit
>> > messages (git commit -m "Fix #486" closes bug 486 on the bug tracker), the
>> > source repositories. You can discuss patches in-place. You can interact in a
>> > very easy manner. You can do peer-review in a snap. GitHub is the only place
>> > that leverages the social nature of open-source collaboration! That's
>> > precisely what we're trying to achieve here. Are we going to throw all that
>> > goodness away? What kind of signal are we sending, when we're considering
>> > hosting our own instance of gitorious? A very simple one: "we like to stay
>> > in our own corner — don't come".
>> >
>> > There are valid points: GitHub doesn't have a maliing-list list system. Is
>> > that really an excuse? How hard would it be to setup a website that lists
>> > OCaml projects, provides them with a mailing-list, and points to their
>> > GitHub page?
>> >
>> > = What is this about ? =
>> >
>> > If it's about improving the general situation with OCaml and its community
>> > (the title of this thread contains the word "community"), then I believe
>> > hacking on the compiler is not the most effective way to achieve that goal.
>> > We're hackers. We like to hack on things. And we often fail to ask
>> > ourselves: is it really worth implementing? Submitting patches is easy.
>> > Submitting quality patches that do solve a real problem is harder. The ARM
>> > backend does need a cleanup, and the patch does solve a stringent issue.
>> > That may not be the case for all patches.
>> >
>> > There is indeed a problem w.r.t external contributions. I agree that the
>> > INRIA team could make it clearer what its stance on external contributions
>> > is. Maybe one solution would be to have a INRIA-endorsed ocaml-next on
>> > github that everyone can fork, where we would merge really outstanding
>> > features, before submitting them to INRIA, as you described. I don't think
>> > it is such a good idea creating a real fork. Maybe some sort of integration
>> > platform on GitHub would be the right solution to the "patch review"
>> > problem.
>> >
>> > I'm not even sure what kind of patches you wish to see integrated. Can you
>> > clarify that?
>> >
>> > = Conclusion =
>> >
>> > This is indeed a long rant, but I'd like to see us being more practical and
>> > down-to-earth. I love OCaml. I think we can do better for the language.
>> >
>> > Kind regards,
>> >
>> > jonathan
>> >
>>
>>
>
>

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/13/2011 09:21 AM, Martin DeMello wrote:
> it's a bit frustrating for me because i don't have or
> use windows either, but if i develop an end user app i really want it
> to be as cross-platform as possible.

This attitude partially explains why support for OCaml under Windows 
lacks behind: people want it to work, because they somehow have to 
produce applications running under Windows, but they really don't like 
this OS and certainly don't want to invest time in learning its gory 
details in order to improve the situation with OCaml.  I don't blame 
anyone here, and I'd probably avoid developing under Windows myself if 
this was not mandatory for our business.  From what I hear, this is also 
the case for other industrial users of OCaml who needs Windows support. 
(And also for large projects like Coq, etc.)

There are a few talented OCaml enthusiasts who know quite a lot about 
Windows and have put some energy in improving OCaml for this OS in the 
past.  Thanks to them!

As Xavier said, it would be great to find someone who'd like to join the 
core dev team in order to improve support for Windows. Anyone interested?

But in order to get really good support in the long term, which includes
community tools (packaging, porting libraries, support for Windows API 
and .Net, documentation, etc), I think we need to find a way to 
"bootstrap" a larger community of OCaml hobbyists, who consider Windows 
as their main platform.  (It might be the case that "native Windows 
users" are culturally less inclined to participate to an open source 
project, but I don't believe this is the primary explanation for the 
lack of community work for Windows. We simply need more people on board.)

Good support for OCaml under Windows would benefits not only to Windows 
users, as it might simply attract a lot more people to OCaml and it 
would probably make the life easier to those who are "forced" to produce 
Windows applications.  So this questions should be of interest to the 
community as a whole.

Do you guys have ideas on how to bootstrap a larger community of 
OCaml/Windows hobbyists?


Alain

Re: [Caml-list] Some comments on recent discussions

[Gaius Hammond]

I suspect that all the OCaml-on-Windows enthusiasts find their needs met by F#. Maybe interoperability between OCaml and F# is the way to go on Windows. 


Gaius



------------------

-----Original Message-----
From: Alain Frisch <alain@frisch.fr>
Date: Tue, 13 Dec 2011 09:51:07 
To: Martin DeMello<martindemello@gmail.com>
Cc: Gerd Stolpmann<info@gerd-stolpmann.de>; Jonathan Protzenko<jonathan.protzenko@gmail.com>; <caml-list@inria.fr>
Subject: Re: [Caml-list] Some comments on recent discussions

On 12/13/2011 09:21 AM, Martin DeMello wrote:
> it's a bit frustrating for me because i don't have or
> use windows either, but if i develop an end user app i really want it
> to be as cross-platform as possible.

This attitude partially explains why support for OCaml under Windows 
lacks behind: people want it to work, because they somehow have to 
produce applications running under Windows, but they really don't like 
this OS and certainly don't want to invest time in learning its gory 
details in order to improve the situation with OCaml.  I don't blame 
anyone here, and I'd probably avoid developing under Windows myself if 
this was not mandatory for our business.  From what I hear, this is also 
the case for other industrial users of OCaml who needs Windows support. 
(And also for large projects like Coq, etc.)

There are a few talented OCaml enthusiasts who know quite a lot about 
Windows and have put some energy in improving OCaml for this OS in the 
past.  Thanks to them!

As Xavier said, it would be great to find someone who'd like to join the 
core dev team in order to improve support for Windows. Anyone interested?

But in order to get really good support in the long term, which includes
community tools (packaging, porting libraries, support for Windows API 
and .Net, documentation, etc), I think we need to find a way to 
"bootstrap" a larger community of OCaml hobbyists, who consider Windows 
as their main platform.  (It might be the case that "native Windows 
users" are culturally less inclined to participate to an open source 
project, but I don't believe this is the primary explanation for the 
lack of community work for Windows. We simply need more people on board.)

Good support for OCaml under Windows would benefits not only to Windows 
users, as it might simply attract a lot more people to OCaml and it 
would probably make the life easier to those who are "forced" to produce 
Windows applications.  So this questions should be of interest to the 
community as a whole.

Do you guys have ideas on how to bootstrap a larger community of 
OCaml/Windows hobbyists?


Alain

-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Some comments on recent discussions

[Martin DeMello]

On Tue, Dec 13, 2011 at 12:51 AM, Alain Frisch <alain@frisch.fr> wrote:
>
> But in order to get really good support in the long term, which includes
> community tools (packaging, porting libraries, support for Windows API and
> .Net, documentation, etc), I think we need to find a way to "bootstrap" a
> larger community of OCaml hobbyists, who consider Windows as their main
> platform.  (It might be the case that "native Windows users" are culturally
> less inclined to participate to an open source project, but I don't believe
> this is the primary explanation for the lack of community work for Windows.
> We simply need more people on board.)

ruby had the same problem of being heavily unix-centric for a long
time. i think what tipped it over was first a small handful of really
dedicated people putting in the hard work to make a one-click
installer and ensure critical libraries worked, followed by the
web-dev community at large deciding ruby was a really good language to
get stuff done in and thus attracting a flood of people on windows who
found that there was at least a good installer, some decent
development environments and IDEs, and a helpful community to
encourage them to stay and work out any teething pains they might
have. if ocaml could provide windows users some compelling reason to
use over other languages that already have better windows integration,
it might take off.

i personally see the big advantage of ocaml is being able to write
native apps in a powerful and expressive language, but it seems
interest in "native" is declining rather than growing over time.
(quite frankly, i'd be happy to see any of ocaml, haskell or chicken
scheme get the sort of community support and enthusiasm that c++
currently has as a language for writing cross-platform desktop apps,
but it doesn't seem likely to happen any time soon.)

another big draw would be a popular open source project that is easy
to write small ocaml extensions for, to encourage people to get their
toes wet. something like a plugin-oriented irc bot, for instance,
would really play to ocaml's strengths, and might have gained a decent
amount of mindshare if it was around when eggdrop was (i got the sense
that a lot of people who didn't particularly like or even really
master tcl nonetheless picked up enough of it to hack on eggdrop
plugins and extensions). as it stands, it's not even just a windows
problem - i see very little, in the way of either tutorials or open
source projects, to engage the casual hobbyist.

martin

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 13/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> As Xavier said, it would be great to find someone who'd like to join the
> core dev team in order to improve support for Windows. Anyone interested?

In my experience, OCaml is working mostly fine on Windows. I can see
some issues but nothing huge. Do you have some examples? I guess most
of the work would be to move forward instead of being stuck in the
current situation.

Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

> I suspect that all the OCaml-on-Windows enthusiasts find their needs met
> by F#. Maybe interoperability between OCaml and F# is the way to go on
> Windows.

f# is not compatible enough to do this (e.g. missing objects and
polymorphic variants). I was already thinking a bit about this, e.g.
whether it would make sense to port Ocamlnet to f#. As it is already
ported to win32 in general, this should not be too difficult regarding the
OS-level functionality, but the said language incompatibilities make it
essentially impossible.

Gerd

>
> Gaius
>
>
>
> ------------------
>
> -----Original Message-----
> From: Alain Frisch <alain@frisch.fr>
> Date: Tue, 13 Dec 2011 09:51:07
> To: Martin DeMello<martindemello@gmail.com>
> Cc: Gerd Stolpmann<info@gerd-stolpmann.de>; Jonathan
> Protzenko<jonathan.protzenko@gmail.com>; <caml-list@inria.fr>
> Subject: Re: [Caml-list] Some comments on recent discussions
>
> On 12/13/2011 09:21 AM, Martin DeMello wrote:
>> it's a bit frustrating for me because i don't have or
>> use windows either, but if i develop an end user app i really want it
>> to be as cross-platform as possible.
>
> This attitude partially explains why support for OCaml under Windows
> lacks behind: people want it to work, because they somehow have to
> produce applications running under Windows, but they really don't like
> this OS and certainly don't want to invest time in learning its gory
> details in order to improve the situation with OCaml.  I don't blame
> anyone here, and I'd probably avoid developing under Windows myself if
> this was not mandatory for our business.  From what I hear, this is also
> the case for other industrial users of OCaml who needs Windows support.
> (And also for large projects like Coq, etc.)
>
> There are a few talented OCaml enthusiasts who know quite a lot about
> Windows and have put some energy in improving OCaml for this OS in the
> past.  Thanks to them!
>
> As Xavier said, it would be great to find someone who'd like to join the
> core dev team in order to improve support for Windows. Anyone interested?
>
> But in order to get really good support in the long term, which includes
> community tools (packaging, porting libraries, support for Windows API
> and .Net, documentation, etc), I think we need to find a way to
> "bootstrap" a larger community of OCaml hobbyists, who consider Windows
> as their main platform.  (It might be the case that "native Windows
> users" are culturally less inclined to participate to an open source
> project, but I don't believe this is the primary explanation for the
> lack of community work for Windows. We simply need more people on board.)
>
> Good support for OCaml under Windows would benefits not only to Windows
> users, as it might simply attract a lot more people to OCaml and it
> would probably make the life easier to those who are "forced" to produce
> Windows applications.  So this questions should be of interest to the
> community as a whole.
>
> Do you guys have ideas on how to bootstrap a larger community of
> OCaml/Windows hobbyists?
>
>
> Alain
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>


-- 
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.

Re: [Caml-list] Some comments on recent discussions

[oliver]

On Sat, Dec 10, 2011 at 05:32:45PM -0300, Andrei Formiga wrote:
[...]
> Regarding documentation, this is a problem in many fronts, beginning
> with the book situation. Practical OCaml was a good idea, badly
> executed. And Jason Hicks' fine book
[...]

Fine book, but the author's name was Jason Hickey.

The last (?) version from 2008 looks a littlebid disturbed,
regarding the column titles.

In this book it's mentioned the following:
  "This book has been submitted for publication by Cambridge University Press.
  This draft may be used until the time the book appears in print."

If the book will not be published, maybe his book might be polished
and provided freely (and might be included into OS distributions?)
Payment for Jason Hickey could be done via donations, so that
he gets something back for his work.

Ciao,
   Oliver

RE: [Caml-list] Some comments on recent discussions

[Jon Harrop]

Adrien wrote:
> On 13/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> > As Xavier said, it would be great to find someone who'd like to join
> > the core dev team in order to improve support for Windows. Anyone
> interested?
> 
> In my experience, OCaml is working mostly fine on Windows. I can see some
> issues but nothing huge. Do you have some examples?

Someone recently posted a story about trying to install OCaml under Windows.
It echoed my own experiences.

Over the past few years we've gone from depending entirely upon Linux and
OCaml to not using it at all. When my Linux box blew up I thought we were in
real trouble but it was actually much easier to get everything we need up
and running under Windows using F# than it had been using OCaml.

The only project I miss from my OCaml days is HLVM. I can still hack on it
when I travel but I need my netbook running Windows so I want it running
under Windows. Due to the difficulty of getting OCaml working under Windows,
I'll probably just port HLVM to F#...

Cheers,
Jon.

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/13/2011 10:15 AM, Gaius Hammond wrote:
> I suspect that all the OCaml-on-Windows enthusiasts find their needs met by F#. Maybe interoperability between OCaml and F# is the way to go on Windows.

Do you mean source-level compatibility between the two languages?  I'm 
afraid they are too different, and limiting oneself to their 
intersection is not realistic for a large project (and you'd loose many 
benefits of each language).

For a bridge between the two languages, it would not be very different 
from a generic bridge between OCaml and .Net (similar to CSML), with the 
same major issue of having to deal with two separate GCs and references 
between them, maybe just with a better structural treatment for sum 
types.  Not very exciting, and to make it usable, one would also need to 
address existing issues with OCaml under Windows anyway.
Also, I don't think that people really want to use both languages in the 
same project.


Maybe you mean something else with interoperability?


Alain

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/13/2011 10:53 AM, Adrien wrote:
> On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
>> As Xavier said, it would be great to find someone who'd like to join the
>> core dev team in order to improve support for Windows. Anyone interested?
>
> In my experience, OCaml is working mostly fine on Windows. I can see
> some issues but nothing huge. Do you have some examples?

It is very good to hear about some successful experiences with OCaml 
under Windows!

Needless to say, but at LexiFi we are also very happy with OCaml under 
Windows.


That said, the situation probably needs to be improved in order to 
attract a larger audience. Many users complain about not being able to 
install and use OCaml under Windows in reasonable amount of time.  And 
the binary packages for Windows tend to lack behind official releases of 
OCaml.

As a concrete problem, until a few days ago, the mingw port could not be 
used with recent versions of Cygwin without some small hacks (like 
copying manually /bin/gcc-3.exe into gcc.exe, and passing more 
directories to flexlink).  No big deal, but it can discourage beginners.

A more serious issue is the lack of support for ocamlfind, GODI, and 
many libraries around for Windows.  Also, ocamlbuild does not play very 
nicely with Windows. A related point: the assumption is generally made 
that OCaml developpers under Windows need to have a running Cygwin 
installation. This is a huge barrier to entry. It would take some time 
to address this, but there is really no reason why ocamlbuild, for 
instance, should rely on an external Unix-like shell
(I believe the only reason today is to rely on bash for quoting 
arguments!).  And it is not difficult to adapt the build system for most 
libraries to avoid any dependency on Unix-like tools (using either 
ocamlbuild or omake). It just takes time to do so (and to maintain the 
result).

For the native compiler, we need an external toolchain, but this is not 
a huge issue.  With some little amount of work, one could support a 
standalone msys/mingw (as opposed to mingw compilers packaged in 
Cygwin), and it would be interesting to come up with a minimal mingw 
distribution (only with a C compiler, assembler, etc, as required by 
ocamlopt) that could be packaged together with OCaml. On the MSVC side, 
everything needed for the MSVC port (C compiler, linker, assembler, 
supporting headers and libraries) is found in a single free download 
from Microsoft.

I can also mention that with some work, one could come up with a 
standalone version of ocamlopt that does not require any external tool 
to produce .cmxs plugins  (we have done that at LexiFi, by replacing the 
assembler code emitter with a direct binary code generator; and by 
extending flexdll to produce dlls without an external linker).  Getting 
rid of the external toolchain to produce standalone programs is more 
difficult: to create the .exe, one needs some libraries and object 
files; a solution could be to do the same as for bytecode, that is, 
having a generic driver which loads user code concatenated to it. But 
being able to generate .cmxs without any external tool already make it 
possible to distribute OCaml native applications (packaged with 
ocamlopt) that the users can extend with OCaml plugins.


 > I guess most
> of the work would be to move forward instead of being stuck in the
> current situation.

Can you elaborate?  What are the most important issues in the current 
situation?


Alain

Re: [Caml-list] Some comments on recent discussions

[Jonathan Protzenko]

On 12/14/2011 07:03 AM, Alain Frisch wrote:
> On 12/13/2011 10:53 AM, Adrien wrote:
>> On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
>>> As Xavier said, it would be great to find someone who'd like to join 
>>> the
>>> core dev team in order to improve support for Windows. Anyone 
>>> interested?
>>
>> In my experience, OCaml is working mostly fine on Windows. I can see
>> some issues but nothing huge. Do you have some examples?
>
> It is very good to hear about some successful experiences with OCaml 
> under Windows!
>
> Needless to say, but at LexiFi we are also very happy with OCaml under 
> Windows.
>
>
> That said, the situation probably needs to be improved in order to 
> attract a larger audience. Many users complain about not being able to 
> install and use OCaml under Windows in reasonable amount of time.  And 
> the binary packages for Windows tend to lack behind official releases 
> of OCaml.
>
> As a concrete problem, until a few days ago, the mingw port could not 
> be used with recent versions of Cygwin without some small hacks (like 
> copying manually /bin/gcc-3.exe into gcc.exe, and passing more 
> directories to flexlink).  No big deal, but it can discourage beginners.
>
> A more serious issue is the lack of support for ocamlfind, GODI, and 
> many libraries around for Windows.  Also, ocamlbuild does not play 
> very nicely with Windows. A related point: the assumption is generally 
> made that OCaml developpers under Windows need to have a running 
> Cygwin installation. This is a huge barrier to entry. It would take 
> some time to address this, but there is really no reason why 
> ocamlbuild, for instance, should rely on an external Unix-like shell
> (I believe the only reason today is to rely on bash for quoting 
> arguments!).  And it is not difficult to adapt the build system for 
> most libraries to avoid any dependency on Unix-like tools (using 
> either ocamlbuild or omake). It just takes time to do so (and to 
> maintain the result).
>
> For the native compiler, we need an external toolchain, but this is 
> not a huge issue.  With some little amount of work, one could support 
> a standalone msys/mingw (as opposed to mingw compilers packaged in Cygwin)
This is precisely what http://protz.github.com/ocaml-installer/ 
provides. Is that not what you're describing here?
> and it would be interesting to come up with a minimal mingw 
> distribution (only with a C compiler, assembler, etc, as required by 
> ocamlopt) that could be packaged together with OCaml.
Looks a little bit more involved but not un-feasible. Would you be 
interested in helping me maintain such a port? ;-)

Cheers,

jonathan

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/14/2011 10:34 AM, Jonathan Protzenko wrote:
>> For the native compiler, we need an external toolchain, but this is
>> not a huge issue. With some little amount of work, one could support a
>> standalone msys/mingw (as opposed to mingw compilers packaged in Cygwin)
> This is precisely what http://protz.github.com/ocaml-installer/
> provides. Is that not what you're describing here?

Yes, I guess.  Is has been known for some time that the mingw port could 
be made to work with a standalone mingw compiler at little cost, but the 
"officially" supported mingw port required Cygwin, and flexdll needs to 
be adapted a little bit.  Providing long-term support for this new setup 
will take some resource (yet another Windows port!).

Alternatively, one could decide that the officially supported "mingw 
port" is based on a standalone mingw (or mingw-w64); Cygwin packagers 
could always create OCaml packages for the mingw compilers shipped with 
Cygwin.

This is a big move, which will probably make some people unhappy.

>> and it would be interesting to come up with a minimal mingw
>> distribution (only with a C compiler, assembler, etc, as required by
>> ocamlopt) that could be packaged together with OCaml.
> Looks a little bit more involved but not un-feasible. Would you be
> interested in helping me maintain such a port? ;-)

Yes, I can help solving some specific problems (e.g. with flexdll); but 
probably not for long-term maintenance.

-- Alain

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Mittwoch, den 14.12.2011, 07:03 +0100 schrieb Alain Frisch:
> On 12/13/2011 10:53 AM, Adrien wrote:
> > On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
> >> As Xavier said, it would be great to find someone who'd like to join the
> >> core dev team in order to improve support for Windows. Anyone interested?
> >
> > In my experience, OCaml is working mostly fine on Windows. I can see
> > some issues but nothing huge. Do you have some examples?
> 
> It is very good to hear about some successful experiences with OCaml 
> under Windows!
> 
> Needless to say, but at LexiFi we are also very happy with OCaml under 
> Windows.
> 
> 
> That said, the situation probably needs to be improved in order to 
> attract a larger audience. Many users complain about not being able to 
> install and use OCaml under Windows in reasonable amount of time.  And 
> the binary packages for Windows tend to lack behind official releases of 
> OCaml.
> 
> As a concrete problem, until a few days ago, the mingw port could not be 
> used with recent versions of Cygwin without some small hacks (like 
> copying manually /bin/gcc-3.exe into gcc.exe, and passing more 
> directories to flexlink).  No big deal, but it can discourage beginners.
> 
> A more serious issue is the lack of support for ocamlfind, GODI, and 
> many libraries around for Windows.  Also, ocamlbuild does not play very 
> nicely with Windows. A related point: the assumption is generally made 
> that OCaml developpers under Windows need to have a running Cygwin 
> installation. This is a huge barrier to entry. It would take some time 
> to address this, but there is really no reason why ocamlbuild, for 
> instance, should rely on an external Unix-like shell
> (I believe the only reason today is to rely on bash for quoting 
> arguments!).  And it is not difficult to adapt the build system for most 
> libraries to avoid any dependency on Unix-like tools (using either 
> ocamlbuild or omake). It just takes time to do so (and to maintain the 
> result).

I don't think you will be able to convince everybody - at this point the
issue becomes political in some sense: Do we want to give up our Unix
habits just to support an OS we (often enough) do not like, and would
only cover to get more love from the world?

There could be an alternative: The "busybox approach". We could develop
a toolkit that covers all the Unix commands we need for the existing
build scripts. It would include easy things like cp, mv etc., but also a
classic "make" (medium difficulty, note that it could reuse the
godi_make code), and especially a POSIX shell. The latter is a bit of
work, but not too much. I'd guess the overall effort takes not more than
1-2 weeks if done by somebody how knows the semantics of the tools very
well.

There are a number of advantages over Cygwin:
 - No danger of running into licensing problems
 - The Unix compatibility is only maintained for commands, but not on
   the system call level (eaiser to use, less surprises, fewer deps,...)
 - It would only be a small download, and easy to integrate into
   installers

Gerd

> For the native compiler, we need an external toolchain, but this is not 
> a huge issue.  With some little amount of work, one could support a 
> standalone msys/mingw (as opposed to mingw compilers packaged in 
> Cygwin), and it would be interesting to come up with a minimal mingw 
> distribution (only with a C compiler, assembler, etc, as required by 
> ocamlopt) that could be packaged together with OCaml. On the MSVC side, 
> everything needed for the MSVC port (C compiler, linker, assembler, 
> supporting headers and libraries) is found in a single free download 
> from Microsoft.
> 
> I can also mention that with some work, one could come up with a 
> standalone version of ocamlopt that does not require any external tool 
> to produce .cmxs plugins  (we have done that at LexiFi, by replacing the 
> assembler code emitter with a direct binary code generator; and by 
> extending flexdll to produce dlls without an external linker).  Getting 
> rid of the external toolchain to produce standalone programs is more 
> difficult: to create the .exe, one needs some libraries and object 
> files; a solution could be to do the same as for bytecode, that is, 
> having a generic driver which loads user code concatenated to it. But 
> being able to generate .cmxs without any external tool already make it 
> possible to distribute OCaml native applications (packaged with 
> ocamlopt) that the users can extend with OCaml plugins.
> 
> 
>  > I guess most
> > of the work would be to move forward instead of being stuck in the
> > current situation.
> 
> Can you elaborate?  What are the most important issues in the current 
> situation?
> 
> 
> Alain
> 

Re: [Caml-list] Some comments on recent discussions

[Jonathan Protzenko]

My feeling is that the core issue lies in the fact that we want two 
different styles: the Unix environment, and the Windows way.
- The first one, imho, currently very well served by the cygwin 
environment + official ocaml package for cygwin.
- The second one would be best served by an installer that bundles, as 
Alain said, ocaml binaries, flexlink binaries, and enough from 
mingw/msys so that native compilation works (without providing the 
entire environment, though).

The latter approach doesn't seem to be too hard, as the installer I 
built earlier provides most of it (although you're required to install 
mingw/msys by yourself right now).

Alain, others, how does that sound? We're somehow not talking about the 
cygwin + mingw64 combo that you enabled earlier on trunk, but as long as 
it's the "official way to compile", we can assume users who do want this 
are ready to take the matter into their own hands and compile OCaml if 
they want this very specific combo. The same goes for MSVC builds.

On 12/14/2011 01:52 PM, Gerd Stolpmann wrote:
> There could be an alternative: The "busybox approach". We could develop
> a toolkit that covers all the Unix commands we need for the existing
> build scripts.
I don't think we have the manpower available here to re-build an entire 
toolkit. Besides, I think that's the whole point of msys.

Cheers,

jonathan

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> On 12/13/2011 10:53 AM, Adrien wrote:
>> On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
>>> As Xavier said, it would be great to find someone who'd like to join the
>>> core dev team in order to improve support for Windows. Anyone interested?
>>
>> In my experience, OCaml is working mostly fine on Windows. I can see
>> some issues but nothing huge. Do you have some examples?
>
> It is very good to hear about some successful experiences with OCaml
> under Windows!
>
> Needless to say, but at LexiFi we are also very happy with OCaml under
> Windows.
>
>
> That said, the situation probably needs to be improved in order to
> attract a larger audience. Many users complain about not being able to
> install and use OCaml under Windows in reasonable amount of time.  And
> the binary packages for Windows tend to lack behind official releases of
> OCaml.

As far as I'm concerned, I managed to do it in a few hours last summer (less
than a morning) but: I'm used to digging in the system (cygwin, msys,
slackware) and packaging (godi, slackware, yypkg), and I've been lucky to
have to use libraries that used oasis. That's quite a lot of conditions for
most cases but, still, it's usually not terribly difficult.

I'd also like to mention the #ocaml IRC channel of freenode: IRC is a good
communication medium for such things imho.

> As a concrete problem, until a few days ago, the mingw port could not be
> used with recent versions of Cygwin without some small hacks (like
> copying manually /bin/gcc-3.exe into gcc.exe, and passing more
> directories to flexlink).  No big deal, but it can discourage beginners.

Actually, I think that you should have used the "/etc/alternatives"
symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make this
FOO symlink point to the /usr/bin/BAR binary that you want.

I've never considered /etc/alternatives to be a good solution however (feels
like spaghetti code).

> A more serious issue is the lack of support for ocamlfind, GODI, and
> many libraries around for Windows.  Also, ocamlbuild does not play very
> nicely with Windows. A related point: the assumption is generally made
> that OCaml developpers under Windows need to have a running Cygwin
> installation. This is a huge barrier to entry. It would take some time
> to address this, but there is really no reason why ocamlbuild, for
> instance, should rely on an external Unix-like shell
> (I believe the only reason today is to rely on bash for quoting
> arguments!).  And it is not difficult to adapt the build system for most
> libraries to avoid any dependency on Unix-like tools (using either
> ocamlbuild or omake). It just takes time to do so (and to maintain the
> result).

Last time I had to setup an ocaml install of windows, I pondered trying to
remove the dependency on bash or at least make it sh. I think that apart
from that, it was possible to use ocamlbuild inside cmd.exe directly.

As for the build systems, I'd advise everyone to use OASIS instead of custom
systems: it's not perfect on windows but for cairo2 and archimedes, I think
I only had to change paths from backward-slashes to forward-slashes in
setup.data (or the other way round) (took 15 seconds).

> For the native compiler, we need an external toolchain, but this is not
> a huge issue.  With some little amount of work, one could support a
> standalone msys/mingw (as opposed to mingw compilers packaged in
> Cygwin), and it would be interesting to come up with a minimal mingw
> distribution (only with a C compiler, assembler, etc, as required by
> ocamlopt) that could be packaged together with OCaml. On the MSVC side,
> everything needed for the MSVC port (C compiler, linker, assembler,
> supporting headers and libraries) is found in a single free download
> from Microsoft.

I've never really liked bundles or SDKs. They tend to be big, incompatible
with others and almost impossible to upgrade.
That's the reason I've started yypkg and while it has been mostly dormant
for almost a year, I will be able to spend a notable amount of time on it
and on the packages for it in a few weeks.

That reminds me that the mingw-w64 team has created a tool named "gendef" to
enable the use of gcc-compiled libraries with msvc.

> I can also mention that with some work, one could come up with a
> standalone version of ocamlopt that does not require any external tool
> to produce .cmxs plugins  (we have done that at LexiFi, by replacing the
> assembler code emitter with a direct binary code generator; and by
> extending flexdll to produce dlls without an external linker).  Getting
> rid of the external toolchain to produce standalone programs is more
> difficult: to create the .exe, one needs some libraries and object
> files; a solution could be to do the same as for bytecode, that is,
> having a generic driver which loads user code concatenated to it. But
> being able to generate .cmxs without any external tool already make it
> possible to distribute OCaml native applications (packaged with
> ocamlopt) that the users can extend with OCaml plugins.

I don't think it would be possible to live without a C toolchain simply
because we use C libraries all the time. It would be useful it it were
easier than getting C libraries but a tool like yypkg (or anything else)
is a closer goal with broader benefits.

I'm quite interested in the ability to create .cmxs files without a C
compiler and can already picture me using it. I've also noticed Benedikt's
ocamlnat work. Would it be usable to script native-code applications?
Maybe with less requirements?

>  > I guess most
>> of the work would be to move forward instead of being stuck in the
>> current situation.
>
> Can you elaborate?  What are the most important issues in the current
> situation?

I haven't been completely clear: I think the current situation is mostly
fine but I fear that it doesn't evolve anymore and doesn't react to changes
on windows or doesn't get some improvements that would be unixy-only.

Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Gabriel Scherer]

[-- Attachment #1: Type: text/plain, Size: 7528 bytes --]

>
> As for the build systems, I'd advise everyone to use OASIS instead of
> custom
> systems: it's not perfect on windows but for cairo2 and archimedes, I think
> I only had to change paths from backward-slashes to forward-slashes in
> setup.data (or the other way round) (took 15 seconds).
>

A clarification: oasis is not in itself a build system; it provides a
common interface to build, configure and install packages, as well as
metadata (documentation, etc.), but it delegates building to real build
system; by default, it uses ocamlbuild, but it is very easy to plug just
any build system (make, omake, ocp-build...) using the "Custom" commands:

http://oasis.forge.ocamlcore.org/MANUAL.html#plugin-custom-doc-conf-test-install-build

In this case, of course, the underlying system can become an obstacle to
portability (to windows or for example BSD when you use gnuisms in your
build scripts).

On Wed, Dec 14, 2011 at 2:37 PM, Adrien <camaradetux@gmail.com> wrote:

> On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> > On 12/13/2011 10:53 AM, Adrien wrote:
> >> On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
> >>> As Xavier said, it would be great to find someone who'd like to join
> the
> >>> core dev team in order to improve support for Windows. Anyone
> interested?
> >>
> >> In my experience, OCaml is working mostly fine on Windows. I can see
> >> some issues but nothing huge. Do you have some examples?
> >
> > It is very good to hear about some successful experiences with OCaml
> > under Windows!
> >
> > Needless to say, but at LexiFi we are also very happy with OCaml under
> > Windows.
> >
> >
> > That said, the situation probably needs to be improved in order to
> > attract a larger audience. Many users complain about not being able to
> > install and use OCaml under Windows in reasonable amount of time.  And
> > the binary packages for Windows tend to lack behind official releases of
> > OCaml.
>
> As far as I'm concerned, I managed to do it in a few hours last summer
> (less
> than a morning) but: I'm used to digging in the system (cygwin, msys,
> slackware) and packaging (godi, slackware, yypkg), and I've been lucky to
> have to use libraries that used oasis. That's quite a lot of conditions for
> most cases but, still, it's usually not terribly difficult.
>
> I'd also like to mention the #ocaml IRC channel of freenode: IRC is a good
> communication medium for such things imho.
>
> > As a concrete problem, until a few days ago, the mingw port could not be
> > used with recent versions of Cygwin without some small hacks (like
> > copying manually /bin/gcc-3.exe into gcc.exe, and passing more
> > directories to flexlink).  No big deal, but it can discourage beginners.
>
> Actually, I think that you should have used the "/etc/alternatives"
> symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make
> this
> FOO symlink point to the /usr/bin/BAR binary that you want.
>
> I've never considered /etc/alternatives to be a good solution however
> (feels
> like spaghetti code).
>
> > A more serious issue is the lack of support for ocamlfind, GODI, and
> > many libraries around for Windows.  Also, ocamlbuild does not play very
> > nicely with Windows. A related point: the assumption is generally made
> > that OCaml developpers under Windows need to have a running Cygwin
> > installation. This is a huge barrier to entry. It would take some time
> > to address this, but there is really no reason why ocamlbuild, for
> > instance, should rely on an external Unix-like shell
> > (I believe the only reason today is to rely on bash for quoting
> > arguments!).  And it is not difficult to adapt the build system for most
> > libraries to avoid any dependency on Unix-like tools (using either
> > ocamlbuild or omake). It just takes time to do so (and to maintain the
> > result).
>
> Last time I had to setup an ocaml install of windows, I pondered trying to
> remove the dependency on bash or at least make it sh. I think that apart
> from that, it was possible to use ocamlbuild inside cmd.exe directly.
>
> As for the build systems, I'd advise everyone to use OASIS instead of
> custom
> systems: it's not perfect on windows but for cairo2 and archimedes, I think
> I only had to change paths from backward-slashes to forward-slashes in
> setup.data (or the other way round) (took 15 seconds).
>
> > For the native compiler, we need an external toolchain, but this is not
> > a huge issue.  With some little amount of work, one could support a
> > standalone msys/mingw (as opposed to mingw compilers packaged in
> > Cygwin), and it would be interesting to come up with a minimal mingw
> > distribution (only with a C compiler, assembler, etc, as required by
> > ocamlopt) that could be packaged together with OCaml. On the MSVC side,
> > everything needed for the MSVC port (C compiler, linker, assembler,
> > supporting headers and libraries) is found in a single free download
> > from Microsoft.
>
> I've never really liked bundles or SDKs. They tend to be big, incompatible
> with others and almost impossible to upgrade.
> That's the reason I've started yypkg and while it has been mostly dormant
> for almost a year, I will be able to spend a notable amount of time on it
> and on the packages for it in a few weeks.
>
> That reminds me that the mingw-w64 team has created a tool named "gendef"
> to
> enable the use of gcc-compiled libraries with msvc.
>
> > I can also mention that with some work, one could come up with a
> > standalone version of ocamlopt that does not require any external tool
> > to produce .cmxs plugins  (we have done that at LexiFi, by replacing the
> > assembler code emitter with a direct binary code generator; and by
> > extending flexdll to produce dlls without an external linker).  Getting
> > rid of the external toolchain to produce standalone programs is more
> > difficult: to create the .exe, one needs some libraries and object
> > files; a solution could be to do the same as for bytecode, that is,
> > having a generic driver which loads user code concatenated to it. But
> > being able to generate .cmxs without any external tool already make it
> > possible to distribute OCaml native applications (packaged with
> > ocamlopt) that the users can extend with OCaml plugins.
>
> I don't think it would be possible to live without a C toolchain simply
> because we use C libraries all the time. It would be useful it it were
> easier than getting C libraries but a tool like yypkg (or anything else)
> is a closer goal with broader benefits.
>
> I'm quite interested in the ability to create .cmxs files without a C
> compiler and can already picture me using it. I've also noticed Benedikt's
> ocamlnat work. Would it be usable to script native-code applications?
> Maybe with less requirements?
>
> >  > I guess most
> >> of the work would be to move forward instead of being stuck in the
> >> current situation.
> >
> > Can you elaborate?  What are the most important issues in the current
> > situation?
>
> I haven't been completely clear: I think the current situation is mostly
> fine but I fear that it doesn't evolve anymore and doesn't react to changes
> on windows or doesn't get some improvements that would be unixy-only.
>
> Regards,
> Adrien Nader
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa-roc.inria.fr/wws/info/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>
>

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

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Mittwoch, den 14.12.2011, 14:37 +0100 schrieb Adrien:
> On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> > On 12/13/2011 10:53 AM, Adrien wrote:
> >> On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
> >>> As Xavier said, it would be great to find someone who'd like to join the
> >>> core dev team in order to improve support for Windows. Anyone interested?
> >>
> >> In my experience, OCaml is working mostly fine on Windows. I can see
> >> some issues but nothing huge. Do you have some examples?
> >
> > It is very good to hear about some successful experiences with OCaml
> > under Windows!
> >
> > Needless to say, but at LexiFi we are also very happy with OCaml under
> > Windows.
> >
> >
> > That said, the situation probably needs to be improved in order to
> > attract a larger audience. Many users complain about not being able to
> > install and use OCaml under Windows in reasonable amount of time.  And
> > the binary packages for Windows tend to lack behind official releases of
> > OCaml.
> 
> As far as I'm concerned, I managed to do it in a few hours last summer (less
> than a morning) but: I'm used to digging in the system (cygwin, msys,
> slackware) and packaging (godi, slackware, yypkg), and I've been lucky to
> have to use libraries that used oasis. That's quite a lot of conditions for
> most cases but, still, it's usually not terribly difficult.
> 
> I'd also like to mention the #ocaml IRC channel of freenode: IRC is a good
> communication medium for such things imho.
> 
> > As a concrete problem, until a few days ago, the mingw port could not be
> > used with recent versions of Cygwin without some small hacks (like
> > copying manually /bin/gcc-3.exe into gcc.exe, and passing more
> > directories to flexlink).  No big deal, but it can discourage beginners.
> 
> Actually, I think that you should have used the "/etc/alternatives"
> symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make this
> FOO symlink point to the /usr/bin/BAR binary that you want.

There are no (usable) symlinks in Windows. Cygwin includes an emulation,
but it is not understood by win32 programs, and hence this mechanism is
unavailable for ocamlc/opt and flexlink.

Gerd


>I've never considered /etc/alternatives to be a good solution however (feels
> like spaghetti code).
> 
> > A more serious issue is the lack of support for ocamlfind, GODI, and
> > many libraries around for Windows.  Also, ocamlbuild does not play very
> > nicely with Windows. A related point: the assumption is generally made
> > that OCaml developpers under Windows need to have a running Cygwin
> > installation. This is a huge barrier to entry. It would take some time
> > to address this, but there is really no reason why ocamlbuild, for
> > instance, should rely on an external Unix-like shell
> > (I believe the only reason today is to rely on bash for quoting
> > arguments!).  And it is not difficult to adapt the build system for most
> > libraries to avoid any dependency on Unix-like tools (using either
> > ocamlbuild or omake). It just takes time to do so (and to maintain the
> > result).
> 
> Last time I had to setup an ocaml install of windows, I pondered trying to
> remove the dependency on bash or at least make it sh. I think that apart
> from that, it was possible to use ocamlbuild inside cmd.exe directly.
> 
> As for the build systems, I'd advise everyone to use OASIS instead of custom
> systems: it's not perfect on windows but for cairo2 and archimedes, I think
> I only had to change paths from backward-slashes to forward-slashes in
> setup.data (or the other way round) (took 15 seconds).
> 
> > For the native compiler, we need an external toolchain, but this is not
> > a huge issue.  With some little amount of work, one could support a
> > standalone msys/mingw (as opposed to mingw compilers packaged in
> > Cygwin), and it would be interesting to come up with a minimal mingw
> > distribution (only with a C compiler, assembler, etc, as required by
> > ocamlopt) that could be packaged together with OCaml. On the MSVC side,
> > everything needed for the MSVC port (C compiler, linker, assembler,
> > supporting headers and libraries) is found in a single free download
> > from Microsoft.
> 
> I've never really liked bundles or SDKs. They tend to be big, incompatible
> with others and almost impossible to upgrade.
> That's the reason I've started yypkg and while it has been mostly dormant
> for almost a year, I will be able to spend a notable amount of time on it
> and on the packages for it in a few weeks.
> 
> That reminds me that the mingw-w64 team has created a tool named "gendef" to
> enable the use of gcc-compiled libraries with msvc.
> 
> > I can also mention that with some work, one could come up with a
> > standalone version of ocamlopt that does not require any external tool
> > to produce .cmxs plugins  (we have done that at LexiFi, by replacing the
> > assembler code emitter with a direct binary code generator; and by
> > extending flexdll to produce dlls without an external linker).  Getting
> > rid of the external toolchain to produce standalone programs is more
> > difficult: to create the .exe, one needs some libraries and object
> > files; a solution could be to do the same as for bytecode, that is,
> > having a generic driver which loads user code concatenated to it. But
> > being able to generate .cmxs without any external tool already make it
> > possible to distribute OCaml native applications (packaged with
> > ocamlopt) that the users can extend with OCaml plugins.
> 
> I don't think it would be possible to live without a C toolchain simply
> because we use C libraries all the time. It would be useful it it were
> easier than getting C libraries but a tool like yypkg (or anything else)
> is a closer goal with broader benefits.
> 
> I'm quite interested in the ability to create .cmxs files without a C
> compiler and can already picture me using it. I've also noticed Benedikt's
> ocamlnat work. Would it be usable to script native-code applications?
> Maybe with less requirements?
> 
> >  > I guess most
> >> of the work would be to move forward instead of being stuck in the
> >> current situation.
> >
> > Can you elaborate?  What are the most important issues in the current
> > situation?
> 
> I haven't been completely clear: I think the current situation is mostly
> fine but I fear that it doesn't evolve anymore and doesn't react to changes
> on windows or doesn't get some improvements that would be unixy-only.
> 
> Regards,
> Adrien Nader
> 

Re: [Caml-list] Some comments on recent discussions

[Gaius Hammond]

See the way Python does it (on Windows) with virtualenv

http://pypi.python.org/pypi/virtualenv/


Gaius


------------------

-----Original Message-----
From: Gerd Stolpmann <info@gerd-stolpmann.de>
Date: Wed, 14 Dec 2011 16:27:58 
To: Adrien<camaradetux@gmail.com>
Cc: Alain Frisch<alain@frisch.fr>; Jonathan Protzenko<jonathan.protzenko@gmail.com>; Martin DeMello<martindemello@gmail.com>; Gerd Stolpmann<info@gerd-stolpmann.de>; <caml-list@inria.fr>
Subject: Re: [Caml-list] Some comments on recent discussions

Am Mittwoch, den 14.12.2011, 14:37 +0100 schrieb Adrien:
> On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> > On 12/13/2011 10:53 AM, Adrien wrote:
> >> On 13/12/2011, Alain Frisch<alain@frisch.fr>  wrote:
> >>> As Xavier said, it would be great to find someone who'd like to join the
> >>> core dev team in order to improve support for Windows. Anyone interested?
> >>
> >> In my experience, OCaml is working mostly fine on Windows. I can see
> >> some issues but nothing huge. Do you have some examples?
> >
> > It is very good to hear about some successful experiences with OCaml
> > under Windows!
> >
> > Needless to say, but at LexiFi we are also very happy with OCaml under
> > Windows.
> >
> >
> > That said, the situation probably needs to be improved in order to
> > attract a larger audience. Many users complain about not being able to
> > install and use OCaml under Windows in reasonable amount of time.  And
> > the binary packages for Windows tend to lack behind official releases of
> > OCaml.
> 
> As far as I'm concerned, I managed to do it in a few hours last summer (less
> than a morning) but: I'm used to digging in the system (cygwin, msys,
> slackware) and packaging (godi, slackware, yypkg), and I've been lucky to
> have to use libraries that used oasis. That's quite a lot of conditions for
> most cases but, still, it's usually not terribly difficult.
> 
> I'd also like to mention the #ocaml IRC channel of freenode: IRC is a good
> communication medium for such things imho.
> 
> > As a concrete problem, until a few days ago, the mingw port could not be
> > used with recent versions of Cygwin without some small hacks (like
> > copying manually /bin/gcc-3.exe into gcc.exe, and passing more
> > directories to flexlink).  No big deal, but it can discourage beginners.
> 
> Actually, I think that you should have used the "/etc/alternatives"
> symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make this
> FOO symlink point to the /usr/bin/BAR binary that you want.

There are no (usable) symlinks in Windows. Cygwin includes an emulation,
but it is not understood by win32 programs, and hence this mechanism is
unavailable for ocamlc/opt and flexlink.

Gerd


>I've never considered /etc/alternatives to be a good solution however (feels
> like spaghetti code).
> 
> > A more serious issue is the lack of support for ocamlfind, GODI, and
> > many libraries around for Windows.  Also, ocamlbuild does not play very
> > nicely with Windows. A related point: the assumption is generally made
> > that OCaml developpers under Windows need to have a running Cygwin
> > installation. This is a huge barrier to entry. It would take some time
> > to address this, but there is really no reason why ocamlbuild, for
> > instance, should rely on an external Unix-like shell
> > (I believe the only reason today is to rely on bash for quoting
> > arguments!).  And it is not difficult to adapt the build system for most
> > libraries to avoid any dependency on Unix-like tools (using either
> > ocamlbuild or omake). It just takes time to do so (and to maintain the
> > result).
> 
> Last time I had to setup an ocaml install of windows, I pondered trying to
> remove the dependency on bash or at least make it sh. I think that apart
> from that, it was possible to use ocamlbuild inside cmd.exe directly.
> 
> As for the build systems, I'd advise everyone to use OASIS instead of custom
> systems: it's not perfect on windows but for cairo2 and archimedes, I think
> I only had to change paths from backward-slashes to forward-slashes in
> setup.data (or the other way round) (took 15 seconds).
> 
> > For the native compiler, we need an external toolchain, but this is not
> > a huge issue.  With some little amount of work, one could support a
> > standalone msys/mingw (as opposed to mingw compilers packaged in
> > Cygwin), and it would be interesting to come up with a minimal mingw
> > distribution (only with a C compiler, assembler, etc, as required by
> > ocamlopt) that could be packaged together with OCaml. On the MSVC side,
> > everything needed for the MSVC port (C compiler, linker, assembler,
> > supporting headers and libraries) is found in a single free download
> > from Microsoft.
> 
> I've never really liked bundles or SDKs. They tend to be big, incompatible
> with others and almost impossible to upgrade.
> That's the reason I've started yypkg and while it has been mostly dormant
> for almost a year, I will be able to spend a notable amount of time on it
> and on the packages for it in a few weeks.
> 
> That reminds me that the mingw-w64 team has created a tool named "gendef" to
> enable the use of gcc-compiled libraries with msvc.
> 
> > I can also mention that with some work, one could come up with a
> > standalone version of ocamlopt that does not require any external tool
> > to produce .cmxs plugins  (we have done that at LexiFi, by replacing the
> > assembler code emitter with a direct binary code generator; and by
> > extending flexdll to produce dlls without an external linker).  Getting
> > rid of the external toolchain to produce standalone programs is more
> > difficult: to create the .exe, one needs some libraries and object
> > files; a solution could be to do the same as for bytecode, that is,
> > having a generic driver which loads user code concatenated to it. But
> > being able to generate .cmxs without any external tool already make it
> > possible to distribute OCaml native applications (packaged with
> > ocamlopt) that the users can extend with OCaml plugins.
> 
> I don't think it would be possible to live without a C toolchain simply
> because we use C libraries all the time. It would be useful it it were
> easier than getting C libraries but a tool like yypkg (or anything else)
> is a closer goal with broader benefits.
> 
> I'm quite interested in the ability to create .cmxs files without a C
> compiler and can already picture me using it. I've also noticed Benedikt's
> ocamlnat work. Would it be usable to script native-code applications?
> Maybe with less requirements?
> 
> >  > I guess most
> >> of the work would be to move forward instead of being stuck in the
> >> current situation.
> >
> > Can you elaborate?  What are the most important issues in the current
> > situation?
> 
> I haven't been completely clear: I think the current situation is mostly
> fine but I fear that it doesn't evolve anymore and doesn't react to changes
> on windows or doesn't get some improvements that would be unixy-only.
> 
> Regards,
> Adrien Nader
> 



-- 
Caml-list mailing list.  Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 14/12/2011, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
> Am Mittwoch, den 14.12.2011, 14:37 +0100 schrieb Adrien:
>> On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
>> > As a concrete problem, until a few days ago, the mingw port could not be
>> > used with recent versions of Cygwin without some small hacks (like
>> > copying manually /bin/gcc-3.exe into gcc.exe, and passing more
>> > directories to flexlink).  No big deal, but it can discourage beginners.
>>
>> Actually, I think that you should have used the "/etc/alternatives"
>> symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make
>> this
>> FOO symlink point to the /usr/bin/BAR binary that you want.
>
> There are no (usable) symlinks in Windows. Cygwin includes an emulation,
> but it is not understood by win32 programs, and hence this mechanism is
> unavailable for ocamlc/opt and flexlink.

Hmmm, right. But if /usr/bin/gcc is already a symlink, ocaml wouldn't be
able to use it at all... I find it quite weird but I don't have a cygwin box
to test.

But windows actually has symlinks. Kind of. Starting with Vista and the
corresponding NTFS version. But by default you need to be an administrator
to use them, you can only create a limited number of symlink in a given
folder afaiu, some functions work on the symlink and some on the target
(stat()/lstat()). They have a number of limitations and last time I looked
at them, I found them to be mostly unusable because of their limitations.

They're one quite big issue I've had for packages on windows: if I
cross-compile a library from Linux, and make a tarball which has a number of
symlink in it. What to do when untarring on windows? Try to create symlinks?
Use hardlinks when possible? Copy the file's contents? Something else?

Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Fabrice Le Fessant]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]

A solution that I used is to patch OCaml to read a configuration file at
startup. This configuration file overrides what was put in the config at
compile time, so that you can change what C compiler/assembler/linker
you use at every execution. It was done in a first attempt to build a
cross-compiling compiler. Then, you can provide a simple tool that tests
the environment and generate the corresponding configuration file.

--Fabrice

On 12/14/2011 04:49 PM, Adrien wrote:
> On 14/12/2011, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
>> Am Mittwoch, den 14.12.2011, 14:37 +0100 schrieb Adrien:
>>> On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
>>>> As a concrete problem, until a few days ago, the mingw port could not be
>>>> used with recent versions of Cygwin without some small hacks (like
>>>> copying manually /bin/gcc-3.exe into gcc.exe, and passing more
>>>> directories to flexlink).  No big deal, but it can discourage beginners.
>>>
>>> Actually, I think that you should have used the "/etc/alternatives"
>>> symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make
>>> this
>>> FOO symlink point to the /usr/bin/BAR binary that you want.
>>
>> There are no (usable) symlinks in Windows. Cygwin includes an emulation,
>> but it is not understood by win32 programs, and hence this mechanism is
>> unavailable for ocamlc/opt and flexlink.
> 
> Hmmm, right. But if /usr/bin/gcc is already a symlink, ocaml wouldn't be
> able to use it at all... I find it quite weird but I don't have a cygwin box
> to test.
> 
> But windows actually has symlinks. Kind of. Starting with Vista and the
> corresponding NTFS version. But by default you need to be an administrator
> to use them, you can only create a limited number of symlink in a given
> folder afaiu, some functions work on the symlink and some on the target
> (stat()/lstat()). They have a number of limitations and last time I looked
> at them, I found them to be mostly unusable because of their limitations.
> 
> They're one quite big issue I've had for packages on windows: if I
> cross-compile a library from Linux, and make a tarball which has a number of
> symlink in it. What to do when untarring on windows? Try to create symlinks?
> Use hardlinks when possible? Copy the file's contents? Something else?
> 
> Regards,
> Adrien Nader
> 

[-- Attachment #2: fabrice_le_fessant.vcf --]
[-- Type: text/x-vcard, Size: 380 bytes --]

begin:vcard
fn:Fabrice LE FESSANT
n:LE FESSANT;Fabrice
org:INRIA Saclay -- Ile-de-France;P2P & OCaml
adr;quoted-printable:;;Parc Orsay Universit=C3=A9 ;Orsay CEDEX;;91893;France
email;internet:fabrice.le_fessant@inria.fr
title;quoted-printable:Charg=C3=A9 de Recherche
tel;work:+33 1 74 85 42 14
tel;fax:+33 1 74 85 42 49 
url:http://fabrice.lefessant.net/
version:2.1
end:vcard

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/14/2011 02:37 PM, Adrien wrote:
> Actually, I think that you should have used the "/etc/alternatives"
> symlinks: /usr/bin/gcc points to /etc/alternatives/FOO and you can make this
> FOO symlink point to the /usr/bin/BAR binary that you want.

The problem is that flexlink.exe (and ocamlopt.exe) are Win32 
executables. They cannot follow Cygwin symlinks.  Of course, I had 
/etc/gcc symlinked to gcc-3.exe through /etc/alternatives, but it did 
not work.

> I don't think it would be possible to live without a C toolchain simply
> because we use C libraries all the time.

It depends on who is "we". I can imagine that library developers still 
need a C toolchain but release binary packages that don't.

> I'm quite interested in the ability to create .cmxs files without a C
> compiler and can already picture me using it. I've also noticed Benedikt's
> ocamlnat work. Would it be usable to script native-code applications?
> Maybe with less requirements?

FWIW, LexiFi's application is distributed together with flexlink.exe and 
ocamlopt.exe, and it can recompile and dynamically load user-defined 
plugins without any other external tool.  (Our clients don't need to 
install anything else to write, compile and run native OCaml code.)

Benedikt's work on ocamlnat also includes a similar direct code 
generator as ours(to avoid the external assembler); I don't think it 
comes with a COFF file emitter, though.  But yes, ocamlnat can be used 
to script native-code applications.



Alain

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/14/2011 04:49 PM, Adrien wrote:
> Hmmm, right. But if /usr/bin/gcc is already a symlink, ocaml wouldn't be
> able to use it at all... I find it quite weird but I don't have a cygwin box
> to test.

Well, that's precisely the point: the natural way to use gcc 3 under 
Cygwin is through symlinks in order to have /usr/bin/gcc links to 
gcc-3.exe. But then ocamlopt and flexlink cannot see it.  A solution 
would have been to have them look directly for gcc-3.exe (and to fix the 
change of path for /lib/mingw), but we decided to use this opportunity 
to switch to gcc 4.

> But windows actually has symlinks. Kind of. Starting with Vista and the
> corresponding NTFS version. But by default you need to be an administrator
> to use them, you can only create a limited number of symlink in a given
> folder afaiu, some functions work on the symlink and some on the target
> (stat()/lstat()). They have a number of limitations and last time I looked
> at them, I found them to be mostly unusable because of their limitations.
>
> They're one quite big issue I've had for packages on windows: if I
> cross-compile a library from Linux, and make a tarball which has a number of
> symlink in it. What to do when untarring on windows? Try to create symlinks?
> Use hardlinks when possible? Copy the file's contents? Something else?

Even if Windows supports kinds of symlink internally, this is a rarely 
used/exposed features. I think it's a bad idea to rely on them for a 
packaging system (targeted to "native" Windows users). They would look 
"foreign" to users, and we should expect a lot of bad support from 
existing tools.


Alain

Re: [Caml-list] Some comments on recent discussions

[Aleksey Nogin]

On 14.12.2011 04:52, Gerd Stolpmann wrote:

> I don't think you will be able to convince everybody - at this point the
> issue becomes political in some sense: Do we want to give up our Unix
> habits just to support an OS we (often enough) do not like, and would
> only cover to get more love from the world?
> 
> There could be an alternative: The "busybox approach". We could develop
> a toolkit that covers all the Unix commands we need for the existing
> build scripts. It would include easy things like cp, mv etc., but also a
> classic "make" (medium difficulty, note that it could reuse the
> godi_make code), and especially a POSIX shell. The latter is a bit of
> work, but not too much. I'd guess the overall effort takes not more than
> 1-2 weeks if done by somebody how knows the semantics of the tools very
> well.
> 
> There are a number of advantages over Cygwin:
>  - No danger of running into licensing problems
>  - The Unix compatibility is only maintained for commands, but not on
>    the system call level (eaiser to use, less surprises, fewer deps,...)
>  - It would only be a small download, and easy to integrate into
>    installers

Note that to a degree, OMake already provides the ability to do
Unix-style things under Windows.

Aleksey

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin:
> On 14.12.2011 04:52, Gerd Stolpmann wrote:
> 
> > I don't think you will be able to convince everybody - at this point the
> > issue becomes political in some sense: Do we want to give up our Unix
> > habits just to support an OS we (often enough) do not like, and would
> > only cover to get more love from the world?
> > 
> > There could be an alternative: The "busybox approach". We could develop
> > a toolkit that covers all the Unix commands we need for the existing
> > build scripts. It would include easy things like cp, mv etc., but also a
> > classic "make" (medium difficulty, note that it could reuse the
> > godi_make code), and especially a POSIX shell. The latter is a bit of
> > work, but not too much. I'd guess the overall effort takes not more than
> > 1-2 weeks if done by somebody how knows the semantics of the tools very
> > well.
> > 
> > There are a number of advantages over Cygwin:
> >  - No danger of running into licensing problems
> >  - The Unix compatibility is only maintained for commands, but not on
> >    the system call level (eaiser to use, less surprises, fewer deps,...)
> >  - It would only be a small download, and easy to integrate into
> >    installers
> 
> Note that to a degree, OMake already provides the ability to do
> Unix-style things under Windows.

I know, and this makes me quite optimistic that it is not that hard to
develop standalone executables for the frequently used Unix utilities.

Gerd


> Aleksey
> 
> 

Re: [Caml-list] Some comments on recent discussions

[Dmitry Grebeniuk]

> Note that to a degree, OMake already provides the ability to do
> Unix-style things under Windows.

  I won't wish you ever hear the words I've said while porting
OMake on mingw.  If you want a polite response, please take
a look at
http://overbld.hg.sourceforge.net/hgweb/overbld/overbld/file/tip/src/omake
  -- "orig" directory is your sources, but other files are my
patches and other dirty hacks to make omake compile
and run.
  Your OMake is the most annoying piece of OCaml software
that pretends to "run under windows", that I've ever ported to
OCaml/mingw.
  Also note that your omake distibution contains compile-time
errors that every linux distributive should fix with its patches
(one of my patches is:
http://overbld.hg.sourceforge.net/hgweb/overbld/overbld/file/tip/src/omake/patch/390__sync
debian's patches are:
http://patch-tracker.debian.org/package/omake/0.9.8.5-3-8
).
  And you haven't released any fix to it, while some years
have passed.

  It's pity you are advertising such a software.

RE: [Caml-list] Some comments on recent discussions

[David Allsopp]

Gerd Stolpmann wrote:
> Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin:
> > On 14.12.2011 04:52, Gerd Stolpmann wrote:
> >
> > > I don't think you will be able to convince everybody - at this point
> > > the issue becomes political in some sense: Do we want to give up our
> > > Unix habits just to support an OS we (often enough) do not like, and
> > > would only cover to get more love from the world?
> > >
> > > There could be an alternative: The "busybox approach". We could
> > > develop a toolkit that covers all the Unix commands we need for the
> > > existing build scripts. It would include easy things like cp, mv
> > > etc., but also a classic "make" (medium difficulty, note that it
> > > could reuse the godi_make code), and especially a POSIX shell. The
> > > latter is a bit of work, but not too much. I'd guess the overall
> > > effort takes not more than
> > > 1-2 weeks if done by somebody how knows the semantics of the tools
> > > very well.
> > >
> > > There are a number of advantages over Cygwin:
> > >  - No danger of running into licensing problems
> > >  - The Unix compatibility is only maintained for commands, but not on
> > >    the system call level (eaiser to use, less surprises, fewer
> > > deps,...)
> > >  - It would only be a small download, and easy to integrate into
> > >    installers
> >
> > Note that to a degree, OMake already provides the ability to do
> > Unix-style things under Windows.
> 
> I know, and this makes me quite optimistic that it is not that hard to
> develop standalone executables for the frequently used Unix utilities.

Any particular reason why the GnuWin32 project doesn't already fulfil this requirement (http://gnuwin32.sourceforge.net/)?


David

Re: [Caml-list] Some comments on recent discussions

[Benedikt Meurer]

On Dec 14, 2011, at 17:55 , Alain Frisch wrote:

>> I'm quite interested in the ability to create .cmxs files without a C
>> compiler and can already picture me using it. I've also noticed Benedikt's
>> ocamlnat work. Would it be usable to script native-code applications?
>> Maybe with less requirements?
> 
> Benedikt's work on ocamlnat also includes a similar direct code generator as ours(to avoid the external assembler); I don't think it comes with a COFF file emitter, though.  But yes, ocamlnat can be used to script native-code applications.

ocamlnat does that already yes, although I doubt that it works on Windows out of the box (it did initially but I haven't tested for quite a while). We also did some prototype work on ELF and Mach-O emitters for ocamlopt earlier this year, which would remove the dependency on the toolchain assembler, but we found it easier to avoid the external stuff altogether and do everything in process (as implemented by ocamlnat now). Object Code emitters (ELF, Mach-O, PECOFF, etc.) would certainly be possible and with some restructuring in the compiler backend, they would even fit into the whole picture, and it would make life easier for OCaml cross-compilers and OCaml on Windows. But with the recent statements regarding the maintenance of the OCaml compiler toolchain and the fruitless discussion wrt. my initial proposal, I'm currently not willing to waste my time on this.

> Alain

Benedikt

Re: [Caml-list] Some comments on recent discussions

[Martin DeMello]

On Wed, Dec 14, 2011 at 4:52 AM, Gerd Stolpmann <info@gerd-stolpmann.de> wrote:
>
> There could be an alternative: The "busybox approach". We could develop
> a toolkit that covers all the Unix commands we need for the existing
> build scripts. It would include easy things like cp, mv etc., but also a
> classic "make" (medium difficulty, note that it could reuse the
> godi_make code), and especially a POSIX shell. The latter is a bit of
> work, but not too much. I'd guess the overall effort takes not more than
> 1-2 weeks if done by somebody how knows the semantics of the tools very
> well.

does mingw+msys not already do this? the last time i checked, it
shipped with rxvt, bash and bunch of natively compiled standard posix
utilities.

martin

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 15/12/2011, Martin DeMello <martindemello@gmail.com> wrote:
> On Wed, Dec 14, 2011 at 4:52 AM, Gerd Stolpmann <info@gerd-stolpmann.de>
> wrote:
>>
>> There could be an alternative: The "busybox approach". We could develop
>> a toolkit that covers all the Unix commands we need for the existing
>> build scripts. It would include easy things like cp, mv etc., but also a
>> classic "make" (medium difficulty, note that it could reuse the
>> godi_make code), and especially a POSIX shell. The latter is a bit of
>> work, but not too much. I'd guess the overall effort takes not more than
>> 1-2 weeks if done by somebody how knows the semantics of the tools very
>> well.
>
> does mingw+msys not already do this? the last time i checked, it
> shipped with rxvt, bash and bunch of natively compiled standard posix
> utilities.

It doesn't ship with much actually. sh.exe and a few things but it doesn't
even have coreutils by default iirc. The usual way to setup an environment
was to download every component from sourceforge.net, one by one and by
trial and error until you had everything.

Nowadays you can use mingw-get to download packages more easily. It's
endorsed (and created) by mingw.org. It doesn't support uninstallation
though and I find that many things on mingw.org are of dubious quality.

That being said, msys causes problems of its own. It's a bit between Cygwin
and Windows, with Cygwin already being between Windows and Unix. You quite
often end up with bastard mixes between unix and windows (mostly paths: I
once ended up writing a backward slash as \\\\\\\\\\\\\\\\ I think).

You typically don't know where you are with msys: it really blurs the line
between the unix/posix and the windows worlds.

Also, note that msys works like cygwin: you have a number of msys
applications which use some DLL. Unlike cygwin however, you're strongly
advised not ever remotely try to make your application an msys one.

Btw, msys has to be built with a gcc-2.9[56] fork since it uses a target
that has never been upstreamed.

It's smaller than cygwin but it's not really prettier unfortunately.


Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 14/12/2011, David Allsopp <dra-news@metastack.com> wrote:
> Gerd Stolpmann wrote:
>> Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin:
>> > On 14.12.2011 04:52, Gerd Stolpmann wrote:
>> >
>> > > I don't think you will be able to convince everybody - at this point
>> > > the issue becomes political in some sense: Do we want to give up our
>> > > Unix habits just to support an OS we (often enough) do not like, and
>> > > would only cover to get more love from the world?
>> > >
>> > > There could be an alternative: The "busybox approach". We could
>> > > develop a toolkit that covers all the Unix commands we need for the
>> > > existing build scripts. It would include easy things like cp, mv
>> > > etc., but also a classic "make" (medium difficulty, note that it
>> > > could reuse the godi_make code), and especially a POSIX shell. The
>> > > latter is a bit of work, but not too much. I'd guess the overall
>> > > effort takes not more than
>> > > 1-2 weeks if done by somebody how knows the semantics of the tools
>> > > very well.
>> > >
>> > > There are a number of advantages over Cygwin:
>> > >  - No danger of running into licensing problems
>> > >  - The Unix compatibility is only maintained for commands, but not on
>> > >    the system call level (eaiser to use, less surprises, fewer
>> > > deps,...)
>> > >  - It would only be a small download, and easy to integrate into
>> > >    installers
>> >
>> > Note that to a degree, OMake already provides the ability to do
>> > Unix-style things under Windows.
>>
>> I know, and this makes me quite optimistic that it is not that hard to
>> develop standalone executables for the frequently used Unix utilities.
>
> Any particular reason why the GnuWin32 project doesn't already fulfil this
> requirement (http://gnuwin32.sourceforge.net/)?

It's not maintained well and it's often quite dirty.

This is from the main page, "News" section:
> 7 June 2009: LibPng-1.2.37: library and tools for PNG images: new release

I'm stealing the following from slackware's changelog, starting mid-2010:

> Upgraded to libpng-1.2.44 and libpng-1.4.3.
> This fixes out-of-bounds memory write bugs that could lead to crashes
> or the execution of arbitrary code, and a memory leak bug which could
> lead to application crashes.
> For more information, see:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-1205
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-2249

> Upgraded to libpng-1.2.46 and libpng-1.4.8.
> Fixed uninitialized memory read in png_format_buffer()
> (Bug report by Frank Busse, related to CVE-2004-0421).
> For more information, see:
>   http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0421

As you can see, gnuwin32's libpng is more than outdated.


Maybe we could reuse it and provide our own updated packages?
Unfortunately, the foundations are quite bad since they rely on libgw32c:
http://gnuwin32.sourceforge.net/packages/libgw32c.htm

If you look at this page, you'll see that it provides a fork() function!
Except that the body of the function is as follows:
> int __fork () {
>   __set_errno (ENOSYS);
>   return -1;
> }

This is a typical example and many functions are not available. Think about
it: making Windows a UNIX. That's not a trivial task and the only complete
solution is cygwin. You can't have both a unix and no additional dependency
(cygwin or interix/sua). And you don't want to do that anyway because
Windows is not UNIX: typical issues are paths and their encoding:

  http://permalink.gmane.org/gmane.comp.windows.gnu.user/1197
  (I'm being told that Windows paths are not UTF-16 but UCB; I'm unable to
   explain more unfortunately)

Hopefully, you don't need to make applications and libraries believe they're
on a unix: most of the time, there is a windows port. For some things like
build systems (makefiles, autotools, or perl-based ones or...), it's more
difficult but you can quite simply cross-compile.

GnuWin32 and libgw32c are not completely worthless however: they can be used
for small systems (to bootstrap something bigger for instance).

Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> On 12/14/2011 02:37 PM, Adrien wrote:
>> I don't think it would be possible to live without a C toolchain simply
>> because we use C libraries all the time.
>
> It depends on who is "we". I can imagine that library developers still
> need a C toolchain but release binary packages that don't.

True. I tend to see the whole toolchain as a single element that you don't
split but it should be possible to only provide binutils.

>> I'm quite interested in the ability to create .cmxs files without a C
>> compiler and can already picture me using it. I've also noticed Benedikt's
>> ocamlnat work. Would it be usable to script native-code applications?
>> Maybe with less requirements?
>
> FWIW, LexiFi's application is distributed together with flexlink.exe and
> ocamlopt.exe, and it can recompile and dynamically load user-defined
> plugins without any other external tool.  (Our clients don't need to
> install anything else to write, compile and run native OCaml code.)
>
> Benedikt's work on ocamlnat also includes a similar direct code
> generator as ours(to avoid the external assembler); I don't think it
> comes with a COFF file emitter, though.  But yes, ocamlnat can be used
> to script native-code applications.

OK, thanks. As I've stated, I'm really interested in this ability. I see
them as complementary with ocamlnat making it possible to quickly do
one-time scripts and experimentations while .cmxs files would be used for
persistant plugins. I can't start using them right now but I think that I'll
try them in a few months.

Regards,
Adrien Nader

RE: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Mittwoch, den 14.12.2011, 19:41 +0000 schrieb David Allsopp:
> Gerd Stolpmann wrote:
> > Am Mittwoch, den 14.12.2011, 09:27 -0800 schrieb Aleksey Nogin:
> > > On 14.12.2011 04:52, Gerd Stolpmann wrote:
> > >
> > > > I don't think you will be able to convince everybody - at this point
> > > > the issue becomes political in some sense: Do we want to give up our
> > > > Unix habits just to support an OS we (often enough) do not like, and
> > > > would only cover to get more love from the world?
> > > >
> > > > There could be an alternative: The "busybox approach". We could
> > > > develop a toolkit that covers all the Unix commands we need for the
> > > > existing build scripts. It would include easy things like cp, mv
> > > > etc., but also a classic "make" (medium difficulty, note that it
> > > > could reuse the godi_make code), and especially a POSIX shell. The
> > > > latter is a bit of work, but not too much. I'd guess the overall
> > > > effort takes not more than
> > > > 1-2 weeks if done by somebody how knows the semantics of the tools
> > > > very well.
> > > >
> > > > There are a number of advantages over Cygwin:
> > > >  - No danger of running into licensing problems
> > > >  - The Unix compatibility is only maintained for commands, but not on
> > > >    the system call level (eaiser to use, less surprises, fewer
> > > > deps,...)
> > > >  - It would only be a small download, and easy to integrate into
> > > >    installers
> > >
> > > Note that to a degree, OMake already provides the ability to do
> > > Unix-style things under Windows.
> > 
> > I know, and this makes me quite optimistic that it is not that hard to
> > develop standalone executables for the frequently used Unix utilities.
> 
> Any particular reason why the GnuWin32 project doesn't already fulfil this requirement (http://gnuwin32.sourceforge.net/)?

Interesting collection, but it misses a shell.

Also, I'm unsure about several details. In particular, how the
command-line arguments are passed down to the started process. The win32
idea of command-line is a big mess, and you will continuously run into
problems if you just keep it. Cygwin works around by providing an
alternate path for passing the command-line down to the started process.
I fear we also would need such a mechanism. (The GnuWin32 docs do not
explain completely what they do, but it reads as if they just keep the
win32 conventions.)

Because of this, I'm still favoring a clean reimplementation, at least
of sh, make, and the frequently used file utilities. GnuWin32 might be
an interesting fallback source for complicated commands where we can
live with limitations (e.g. awk, which also sometimes appears in build
scripts, but would be a tremendous amount of work to reproduce).

Gerd
-- 
------------------------------------------------------------
Gerd Stolpmann, Darmstadt, Germany    gerd@gerd-stolpmann.de
Creator of GODI and camlcity.org.
Contact details:        http://www.camlcity.org/contact.html
Company homepage:       http://www.gerd-stolpmann.de
*** Searching for new projects! Need consulting for system
*** programming in Ocaml? Gerd Stolpmann can help you.
------------------------------------------------------------

Re: [Caml-list] Some comments on recent discussions

[Martin DeMello]

On Thu, Dec 15, 2011 at 2:29 AM, Adrien <camaradetux@gmail.com> wrote:
> On 14/12/2011, David Allsopp <dra-news@metastack.com> wrote:
>>
>> Any particular reason why the GnuWin32 project doesn't already fulfil this
>> requirement (http://gnuwin32.sourceforge.net/)?
>
> It's not maintained well and it's often quite dirty.

This seems better-maintained:

https://github.com/bmatzelle/gow/wiki

At the very least it would be a good starting point.

martin

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 15/12/2011, Martin DeMello <martindemello@gmail.com> wrote:
> On Thu, Dec 15, 2011 at 2:29 AM, Adrien <camaradetux@gmail.com> wrote:
>> On 14/12/2011, David Allsopp <dra-news@metastack.com> wrote:
>>>
>>> Any particular reason why the GnuWin32 project doesn't already fulfil
>>> this
>>> requirement (http://gnuwin32.sourceforge.net/)?
>>
>> It's not maintained well and it's often quite dirty.
>
> This seems better-maintained:
>
> https://github.com/bmatzelle/gow/wiki
>
> At the very least it would be a good starting point.

I had never heard of that one before and asked people about it. It turns out
it's a collection of binaries already available in other places. That makes
it both uninteresting and interesting.

It's annoying because it will have all the bugs the other have.

It's good because it saves work and you don't have to go hunt for various
binaries everywhere: you have them in a single place.

I think these are definitely fine for programs. Shell scripting shouldn't be
an issue. Libraries of projects like gnuwin32 are probably not as good
however. It shouldn't be an issue to bundle the programs if needed. :-)

Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Martin DeMello]

On Thu, Dec 15, 2011 at 12:47 PM, Adrien <camaradetux@gmail.com> wrote:
> On 15/12/2011, Martin DeMello <martindemello@gmail.com> wrote:
>>
>> This seems better-maintained:
>>
>> https://github.com/bmatzelle/gow/wiki
>>
>> At the very least it would be a good starting point.
>
> I had never heard of that one before and asked people about it. It turns out
> it's a collection of binaries already available in other places. That makes
> it both uninteresting and interesting.
>
> It's annoying because it will have all the bugs the other have.
>
> It's good because it saves work and you don't have to go hunt for various
> binaries everywhere: you have them in a single place.
>
> I think these are definitely fine for programs. Shell scripting shouldn't be
> an issue. Libraries of projects like gnuwin32 are probably not as good
> however. It shouldn't be an issue to bundle the programs if needed. :-)

My mistake, I had the impression from the README that they were
maintaining and compiling all those utilities themselves. Also,
looking more closely at it, they use bash 2.03, so they clearly aren't
trying to keep current.

martin

Re: [Caml-list] Some comments on recent discussions

[Adrien]

On 14/12/2011, Alain Frisch <alain@frisch.fr> wrote:
> On 12/14/2011 04:49 PM, Adrien wrote:
>> But windows actually has symlinks. Kind of. Starting with Vista and the
>> corresponding NTFS version. But by default you need to be an administrator
>> to use them, you can only create a limited number of symlink in a given
>> folder afaiu, some functions work on the symlink and some on the target
>> (stat()/lstat()). They have a number of limitations and last time I looked
>> at them, I found them to be mostly unusable because of their limitations.
>>
>> They're one quite big issue I've had for packages on windows: if I
>> cross-compile a library from Linux, and make a tarball which has a number
>> of
>> symlink in it. What to do when untarring on windows? Try to create
>> symlinks?
>> Use hardlinks when possible? Copy the file's contents? Something else?
>
> Even if Windows supports kinds of symlink internally, this is a rarely
> used/exposed features. I think it's a bad idea to rely on them for a
> packaging system (targeted to "native" Windows users). They would look
> "foreign" to users, and we should expect a lot of bad support from
> existing tools.

After some discussion and pondering, I think that symlinks won't be stored
as-is in the package but will instead be created during some sort of
post-install hook (yypkg doesn't work that way but you get the idea). Then,
if the OS or FS doesn't handle symlinks in an acceptable way, I think the
following fallbacks could be used:
1- if symlink's target is a file in the symlink's folder: use a hardlink
2- if symlink's target is a file in another folder: cp the file
3- if symlink's target is a folder: try to use symlinks
4- if symlink's target is a folder and 3- is impossible, cp -r the folder

3- is based on the optimistic but realistic assumption that there aren't
many symlinks to folders in a given folder, therefore avoiding the limit of
31 symlinks in a given folder on windows.

I've used the following commands to find how many symlinks to directories I
had in a given folder (hope it's right) (on a full slackware):
find -P / -mount -type l -xtype d | xargs -L 1 -x dirname | sort |
uniq -c | sort -n

I got: /usr/man: 11, /etc: 9, /usr/doc/gimp-2.6.11: 8, /usr/include: 7,
/usr/X11R6: 7, /media: 7, /usr/lib64/X11: 6, /usr/lib64: 6, ..., /usr/doc:
5, /usr/ 5...

That shows the option 3- is quite likely to succeed. Also, note that
slackware adds some symlinks to do things the way it wants (it predates
Linux' standard fs hierachy ;-) ).

I'd be interested in any comments. Thanks.

Regards,
Adrien Nader

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/14/2011 06:36 PM, Gerd Stolpmann wrote:
> I know, and this makes me quite optimistic that it is not that hard to
> develop standalone executables for the frequently used Unix utilities.

It's amazing how a discussion about simplifying the life for Windows 
users ends up with "let's emulate Unix under Windows"!

A few points:

1. It would be useful to have a completely standalone binary 
distribution of ocaml (with ocamlopt) under Windows. This can be 
achieved either with little development efforts by extracting the 
minimal needed subset of an mingw toolchain (an assembler, a linker, 
some libraries and object files to link the main program); or with a 
little bit more effort, by avoiding the need for an external toolchain 
altogether.  I insist: most users of OCaml under Windows won't need a C 
compiler or Unix-like tools.

2. Binary packages for OCaml libraries could be simple .zip files to be 
extracted at a precise place (under the hierarchy created by the OCaml 
binary installer itself); or maybe even Windows installers.  If 
installing a library only amounts to clicking on a link in a web page 
and run the installer, it already makes the life of the casual user much 
easier. We don't necessarily need a full-blown packaging system, with 
dependency tracking, versioning, automatic download, etc.

3. Binary packages are not created by casual users. It's not crazy to 
require, at least in the short term, a decent Unix-like environment 
(which includes a C compiler) in order to compile the libraries and 
create the binary packages. It would be nice to adapt all the OCaml 
libraries around so that they don't rely on external Unix tools, but 
this is simply not going to happen.

4. A small group of volunteers could identify the most important OCaml 
libraries around, make sure they compile fine under Windows, submit 
patches upstream if the build system needs to be adapted, and produce 
binary packages for these libraries.

5. What is important now is not to provide the ultimate package 
management system for OCaml under Windows.  We should focus instead on 
lowering the barrier for casual users, addressing justified complaints 
from beginners, making it easy to use OCaml for simple native projects 
under Windows or for porting OCaml applications developed initially for 
Unix.  My hope is that this will be enough to attract more "native" 
Windows users into OCaml, and then we (or they) can start thinking about 
more ambitious goals.



-- Alain

Re: [Caml-list] Some comments on recent discussions

[Jonathan Protzenko]

On Fri 16 Dec 2011 01:39:19 PM CET, Alain Frisch wrote:
>
> A few points:
>
> 1. It would be useful to have a completely standalone binary 
> distribution of ocaml (with ocamlopt) under Windows. This can be 
> achieved either with little development efforts by extracting the 
> minimal needed subset of an mingw toolchain (an assembler, a linker, 
> some libraries and object files to link the main program); or with a 
> little bit more effort, by avoiding the need for an external toolchain 
> altogether. I insist: most users of OCaml under Windows won't need a C 
> compiler or Unix-like tools.
I'm considering doing that with the next version of my ocaml installer, 
because this has been raised quite a few times on this list already.
>
> 2. Binary packages for OCaml libraries could be simple .zip files to 
> be extracted at a precise place (under the hierarchy created by the 
> OCaml binary installer itself); or maybe even Windows installers. If 
> installing a library only amounts to clicking on a link in a web page 
> and run the installer, it already makes the life of the casual user 
> much easier. We don't necessarily need a full-blown packaging system, 
> with dependency tracking, versioning, automatic download, etc.
Sure. I've discussed including findlib in the installer for windows [1] 
so that people can easily install third-party libraries and have them 
recognized.

Cheers,

jonathan

[1] https://github.com/protz/ocaml-installer/issues/4
>
>
> -- Alain
>

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Freitag, den 16.12.2011, 13:39 +0100 schrieb Alain Frisch:
> On 12/14/2011 06:36 PM, Gerd Stolpmann wrote:
> > I know, and this makes me quite optimistic that it is not that hard to
> > develop standalone executables for the frequently used Unix utilities.
> 
> It's amazing how a discussion about simplifying the life for Windows 
> users ends up with "let's emulate Unix under Windows"!

Simple answer: There is a bootstrap problem: The existing Ocaml users
are almost Unix-only. They do not care about Windows. In order to
establish "Windows-typical problem solving" you need definitely more
Windows users, but they will only come if you have a Windows-typical way
of distribution.

My thinking is that you can break this circle only if you go forward and
try to make as many Unix-style solutions available under Windows as
possible. Once there is a Windows community you can address it
differently, but for the time being I don't see a good alternative.

By the way, your plan includes Unix emulation, too, under point 3. It's
only more hidden.

Gerd


> 
> A few points:
> 
> 1. It would be useful to have a completely standalone binary 
> distribution of ocaml (with ocamlopt) under Windows. This can be 
> achieved either with little development efforts by extracting the 
> minimal needed subset of an mingw toolchain (an assembler, a linker, 
> some libraries and object files to link the main program); or with a 
> little bit more effort, by avoiding the need for an external toolchain 
> altogether.  I insist: most users of OCaml under Windows won't need a C 
> compiler or Unix-like tools.
> 
> 2. Binary packages for OCaml libraries could be simple .zip files to be 
> extracted at a precise place (under the hierarchy created by the OCaml 
> binary installer itself); or maybe even Windows installers.  If 
> installing a library only amounts to clicking on a link in a web page 
> and run the installer, it already makes the life of the casual user much 
> easier. We don't necessarily need a full-blown packaging system, with 
> dependency tracking, versioning, automatic download, etc.
> 
> 3. Binary packages are not created by casual users. It's not crazy to 
> require, at least in the short term, a decent Unix-like environment 
> (which includes a C compiler) in order to compile the libraries and 
> create the binary packages. It would be nice to adapt all the OCaml 
> libraries around so that they don't rely on external Unix tools, but 
> this is simply not going to happen.
> 
> 4. A small group of volunteers could identify the most important OCaml 
> libraries around, make sure they compile fine under Windows, submit 
> patches upstream if the build system needs to be adapted, and produce 
> binary packages for these libraries.
> 
> 5. What is important now is not to provide the ultimate package 
> management system for OCaml under Windows.  We should focus instead on 
> lowering the barrier for casual users, addressing justified complaints 
> from beginners, making it easy to use OCaml for simple native projects 
> under Windows or for porting OCaml applications developed initially for 
> Unix.  My hope is that this will be enough to attract more "native" 
> Windows users into OCaml, and then we (or they) can start thinking about 
> more ambitious goals.
> 
> 
> 
> -- Alain
> 

Re: [Caml-list] Some comments on recent discussions

[Stéphane Glondu]

Le 16/12/2011 13:39, Alain Frisch a écrit :
> 3. Binary packages are not created by casual users. It's not crazy to
> require, at least in the short term, a decent Unix-like environment
> (which includes a C compiler) in order to compile the libraries and
> create the binary packages. It would be nice to adapt all the OCaml
> libraries around so that they don't rely on external Unix tools, but
> this is simply not going to happen.

Binary packages could be cross-compiled. This is what has been done for
Coq dependencies [1]. Our goal while doing this was just to produce a
working Windows version of Coq, but maybe the idea could be extended to
provide a full development environment as envisioned in your point 1
(self-contained OCaml toolchain, with no C compiler). The "decent
Unix-like" environment you mention would then be an actual existing
(foreign) one.

Cross-compiling raises the issue of testing of binary packages. But if
we can get a working (and reasonably maintainable) OCaml toolchain on
Windows, pure OCaml test-suites could be used to test them natively.

I don't know about others, but the cross-compiling way would be my best
choice: I don't really care about Windows itself, but I do care about
Windows users of my software :-)

[1] http://ocaml.debian.net/mingw32/


Cheers,

-- 
Stéphane

Re: [Caml-list] Some comments on recent discussions

[Alain Frisch]

On 12/16/2011 02:14 PM, Gerd Stolpmann wrote:
> Simple answer: There is a bootstrap problem: The existing Ocaml users
> are almost Unix-only. They do not care about Windows. In order to
> establish "Windows-typical problem solving" you need definitely more
> Windows users, but they will only come if you have a Windows-typical way
> of distribution.
>
> My thinking is that you can break this circle only if you go forward and
> try to make as many Unix-style solutions available under Windows as
> possible.

Honestly, I think this is the wrong approach.  The Windows-style of 
packaging (i.e. lack of packaging system) is very simple to implement: 
just ship zip files or Windows installers. It's less comfortable than 
powerful package systems as we're used to in the Unix world, but it is 
not an issue for Windows users.

> By the way, your plan includes Unix emulation, too, under point 3. It's
> only more hidden.

Yes, but Unix emulation exists and works not too badly. You can use 
Cygwin, or msys, etc.  I can see two reasons for reimplementing 
Unix-like tools, and none of them are good:

  - We want to control everything in order to have better options for
    creating nice packages for OCaml related stuff. This is a bad reason,
    because Windows users except binary package anyway, so the external
    tools needed during the build process don't have to be redistributed.
    The only external tools which are currently mandatory to use ocaml
    are an assembler and a linker, and some native libraries. Not
    a Unix shell, a "find" or a "ls" command.

  - Existing solutions are not build on strong technical foundations,
    and one thinks one can do better. Ok, but this has nothing to do
    with OCaml; this will necessarily represent a huge amount of
    work; and I don't see why people who don't really care about Windows
    would do a better job in a few months than people who've spent years
    of work on cygwin/msys/etc.


Can you explain what's wrong with my approach:

   * OCaml users have access to binary packages which can be trivially
     installed (zip files or installers) and are self-contained.

   * People in charge of creating these packages use existing Unix-like
     environment (cygwin/msys/...); and progressively, they
     publish "best practices" for the whole community in order to
     simplify their job (e.g. try to rely on ocamlbuild or omake instead
     of Makefiles; avoid relying on symbolic links; etc).



Alain

Re: [Caml-list] Some comments on recent discussions

[Gerd Stolpmann]

Am Freitag, den 16.12.2011, 15:11 +0100 schrieb Alain Frisch:
> On 12/16/2011 02:14 PM, Gerd Stolpmann wrote:
> > Simple answer: There is a bootstrap problem: The existing Ocaml users
> > are almost Unix-only. They do not care about Windows. In order to
> > establish "Windows-typical problem solving" you need definitely more
> > Windows users, but they will only come if you have a Windows-typical way
> > of distribution.
> >
> > My thinking is that you can break this circle only if you go forward and
> > try to make as many Unix-style solutions available under Windows as
> > possible.
> 
> Honestly, I think this is the wrong approach.  The Windows-style of 
> packaging (i.e. lack of packaging system) is very simple to implement: 
> just ship zip files or Windows installers. It's less comfortable than 
> powerful package systems as we're used to in the Unix world, but it is 
> not an issue for Windows users.
> 
> > By the way, your plan includes Unix emulation, too, under point 3. It's
> > only more hidden.
> 
> Yes, but Unix emulation exists and works not too badly. You can use 
> Cygwin, or msys, etc.  I can see two reasons for reimplementing 
> Unix-like tools, and none of them are good:
> 
>   - We want to control everything in order to have better options for
>     creating nice packages for OCaml related stuff. This is a bad reason,
>     because Windows users except binary package anyway, so the external
>     tools needed during the build process don't have to be redistributed.
>     The only external tools which are currently mandatory to use ocaml
>     are an assembler and a linker, and some native libraries. Not
>     a Unix shell, a "find" or a "ls" command.
> 
>   - Existing solutions are not build on strong technical foundations,
>     and one thinks one can do better. Ok, but this has nothing to do
>     with OCaml; this will necessarily represent a huge amount of
>     work; and I don't see why people who don't really care about Windows
>     would do a better job in a few months than people who've spent years
>     of work on cygwin/msys/etc.
> 
> 
> Can you explain what's wrong with my approach:
> 
>    * OCaml users have access to binary packages which can be trivially
>      installed (zip files or installers) and are self-contained.

I have no problem with that.

>    * People in charge of creating these packages use existing Unix-like
>      environment (cygwin/msys/...); and progressively, they
>      publish "best practices" for the whole community in order to
>      simplify their job (e.g. try to rely on ocamlbuild or omake instead
>      of Makefiles; avoid relying on symbolic links; etc).

That's the part where I doubt it will happen. How do you find such
people? The job description does not sound very attractive, and
honestly, if I don't have any (or only limited) interest on my own in
this, I'd do this type of work only for money (because it's frustrating,
and Windows users are not really known to be grateful for getting
something for free).

Hence, my idea of reusing as much Unix scripting as possible. It's
finally easier.

Btw, a lot of infrastructure already exists: GODI for mingw, only that
it is broken now, and would need a few days of fixing everything.
Because GODI includes a binary package concept, you could easily extract
the built libraries, and distribute them in a zip-style format.
Currently you need the mingw toolchain for using the compilers, but as
you pointed out, this could be improved.

You may ask why GODI is broken for mingw. Well, see above. The job is
unattractive, too time-consuming, and I lost all interest in it. It's
better done by somebody who needs that for his/her own work.

Gerd

> 
> 
> 
> Alain
> 

Re: [Caml-list] Some comments on recent discussions

[Edgar Friendly]

On 12/16/2011 07:39 AM, Alain Frisch wrote:
> We don't necessarily need a full-blown packaging system, with dependency
> tracking, versioning, automatic download, etc.

At first, maybe.  In the long run, any friction in the system of 
inter-package dependencies grinds away at the composability of OCaml 
packages from different authors into a single solution.  This is the 
reason I support oasis and wrote odb, and this is the reason that 
everyone out there has their own stdlib.  Barriers to having package 
dependencies hinder the reuse of other people's code except in 
simplistic copy-and-paste of source code fashion.

This seems to be something that the haskell community has gotten 
right[1].  Whenever I run into a haskell package, it's common for it to 
have 5 or more dependencies on other packages, and those packages to 
have deps on others, etc.  And this *isn't* a problem for them.  I 
surmise that the haskell community has "greased" the process of 
dependencies sufficiently so that there is almost no friction in 
external dependencies.

In our community, external dependencies are painful - the existence of 
even one external dependency in batteries has been problematic for our 
users[2].  Furthermore, many people avoid using batteries because they 
don't want external dependencies for their own project.  Why?  Because 
dependencies are a pain.

To a great extent, we're stuck doing manual dependency resolution not 
just inside a project (mostly solved by ocamlbuild), but also between 
projects (mostly solved by findlib).  And because of the friction here, 
we're stuck in a community of tiny dependency trees and lots of 
re-inventing the wheel.

What's the next step?  Contribute to oasis with patches?  Oasis-ify your 
code and upload to oasis-db?  Fix GODI/mingw?  Build a proper dependency 
analysis system that can determine package dependencies from special 
comments in source files and compile them correctly *without* separating 
that metadata from the source file?  Something else?

Find your own pain-point in the current system and *fix* it.  Maybe a 
simple, crude, just barely good enough fix.  But share that fix with the 
community, and we all benefit, and can push forward a campaign to remove 
the pain of external dependencies from OCaml.

E.

[1] I'm speaking as an observer only, having no real experience with haskell
[2] Batteries has removed its last required external dependency as of 
2.0beta, but it has had internal a package that should be an external 
dep since before 1.0, so is still imperfect.