[Caml-list] Why don't you use batteries?

[Edgar Friendly]

It seems like batteries' adoption isn't quite as thorough as expected.
We in the batteries devel team would love to know why you don't use
batteries. Here's some of our guesses:

1) I *do* use batteries
2) It's not 1.0 yet, I'll try it then
3) It makes my executables too big
4) It's too hard to install (dependencies, godi failures)
5) It's difficult to compile against
6) It doesn't work on my platform
7) It uses camlp4
8) Other (please explain)

Respond in public if appropriate, respond directly to me if you want.
Now's a good time to think about where batteries is going and how it's
getting there.

E

_______________________________________________
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

[Rakotomandimby Mihamina]

09/03/2009 04:05 PM, Edgar Friendly::

> It seems like batteries' adoption isn't quite as thorough as expected.

From the end user point of view, things that might help in usage are:
- package availability
- "For Dummy" Documentation + examples.

I hate to say that, but something like this:
http://www.php.net/manual/en/function.strip-tags.php
Is "clear" for many discovering users.

With such a documentation, you are going to see many beginners
using it, have questions traffic about it, and slowly
go to the adoption of Batteries by "everyone".

--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34

[Alan Schmitt]

On Thu, Sep 3, 2009 at 3:05 PM, Edgar Friendly <thele...@gmail.com> wrote:

> 4) It's too hard to install (dependencies, godi failures)
>

I installed it once (using godi), but when I tried to migrate to a newer
version of ocaml, compilation fails. (It tells me it's already installed,
but it seems that godi believes it's not.) I have not taken the time to look
under the hood to find out what is wrong.

Alan

[kattla]

Hi,

> 3) It makes my executables too big

(Assuming this [0] is still true)

For me this is the biggest reason for not using batteries. I don't
really have a need for small executables right now, but I would like
to at least know that this issue will be resolved before I adopt
batteries.

[0] http://caml.inria.fr/pub/ml-archives/caml-list/2008/11/24509ad16aae6d1cc2e15f532e0007eb.en.html

[Vincent Aravantinos]

Edgar,

Le 3 sept. 09 � 15:05, Edgar Friendly a �crit :

> 2) It's not 1.0 yet, I'll try it then

Overall impression that it is still a bit messy:
- doc has broken links
- interfaces lack homogeneity e.g. Hashtbl.mem takes the container
first whereas Set.mem takes it second.
In contrast I love the way Jane Street Core handles this: having a
clear rule for all modules and using labels extensively.
- when I gave it a try there were still compilation problems under OSX
(so a bit of 4.) but it now seems to work.

I am watching batteries regularly to see how things evolve.

--
Vincent Aravantinos
PhD Student - LIG - CAPP Team
Grenoble, France
+33.6.11.23.34.72
vincent.a...@imag.fr
http://membres-lig.imag.fr/aravantinos/

[Dario Teixeira]

Hi,

> It seems like batteries' adoption isn't quite as thorough as expected.
> We in the batteries devel team would love to know why you don't use
> batteries.� Here's some of our guesses:

Batteries is a great project, and you guys shouldn't feel discouraged
if it doesn't take over the world overnight. There's unfamiliarity and
inertia to overcome, and that takes time. Personally, I've installed
Batteries and played with it, but I'm not using it (yet) on my projects.
Going back to your list, here's why:

> 2) It's not 1.0 yet, I'll try it then

That's indeed a factor.

> 3) It makes my executables too big

This used to be a bigger problem. Previous versions of Batteries would
pack everything into a module, disabling the linker's ability to link
only effectively used code. Thankfully newer versions are going towards
a flatter hierarchy.

> 4) It's too hard to install (dependencies, godi failures)

Never ran into this problem.

> 5) It's difficult to compile against

Not an issue.

> 6) It doesn't work on my platform

Not an issue.

> 7) It uses camlp4

Not an issue for me. There's this thing called a "build system" that
should handle all that transparently, so I couldn't care less if it
required carrier pigeons to compile my programs. But yes, I admit
it may be an issue for more constrained platforms.

> 8) Other (please explain)

a) Lack of exposure to the advantages of Batteries. It borrows lots of
cool ideas from Haskell, but that may not be immediately apparent.
You guys should take advantage of the Ocaml Planet to run a publicity
campaign: you can make a number of tutorial posts showing the "old"
way versus the Batteries way. There's more to Batteries than just
a collection of APIs, and that message may not be getting through.

b) I'm already using Extlib extensively, and that reduces the advantage
for Batteries. (Same way the Minitel slowed down Internet adoption
in France in the mid-nineties?)

Best regards,
Dario Teixeira

[Ashish Agarwal]

I have been planning to start using Batteries for several months, but here
are some reasons I have not yet:

- It did not compile under godi, but I haven't tried in a while.

- The migration will require changes across our code base. It's hard to set
aside the time for such an undertaking.

- Core language features are altered. For example, the Batteries way is to
use input's instead of in_channel's. Documentation explaining such changes
would help. The API documentation is excellent, but what is missing is a
book on "An Introduction to OCaml with Batteries". Perhaps a well planned
wiki would help get this started.

- Some assurance that Batteries really will become the de facto standard
would also help.

Having said that, I'm switching to Batteries soon. Thanks for all the hard
work!

[Tom Hutchinson]

> 8) Other (please explain)
It's not part of the standard distribution.

Using it in an open source project adds a lot of dependencies. I
understand that the Batteries team doesn't decide what gets included
in OCaml. Still, many projects are very hesitant to add extra
dependencies (even if batteries was entirely self-contained).

I imagine there are a fair number of people who take parts bits and
pieces out of the batteries sources and use those in their projects.

Tom Hutchinson

[Richard Jones]

On Thu, Sep 03, 2009 at 09:05:08AM -0400, Edgar Friendly wrote:
> 6) It doesn't work on my platform

Last time I tried, I couldn't get it to compile.

However it is on my to-do list to look again and try to package it for
Fedora.

Rich.

--
Richard Jones
Red Hat

[Jake Donham]

On Thu, Sep 3, 2009 at 6:05 AM, Edgar Friendly <thele...@gmail.com> wrote:

> 8) Other (please explain)
>

Please take this with the caveat that I have little experience with
Batteries, but my impression (from following batteries-devel) is that it
changes OCaml significantly with Camlp4 extensions, and that it is not
possible to use Batteries without the language changes. If I am wrong on
these points I would be glad to know it.

I think it is important for adoption of any new thing to give people a
low-cost way to get started, and an incremental path towards using it fully
and depending upon it. My impression is that with Batteries you must take or
leave the whole thing.

A full-featured de facto standard library for OCaml is a great idea, but it
must be a *library*; you must be able to use only the parts you want to use.

Jake

[Hezekiah M. Carty]

(I do not want to derail this thread, just make a small clarification below)

On Thu, Sep 3, 2009 at 11:49 AM, Jake Donham<ja...@donham.org> wrote:
> On Thu, Sep 3, 2009 at 6:05 AM, Edgar Friendly <thele...@gmail.com> wrote:
>>
>> 8) Other (please explain)
>
> Please take this with the caveat that I have little experience with
> Batteries, but my impression (from following batteries-devel) is that it
> changes OCaml significantly with Camlp4 extensions, and that it is not
> possible to use Batteries without the language changes. If I am wrong on
> these points I would be glad to know it.

This is, I think, a common and unfortunate misunderstanding with
Batteries. In its current state (and likely in all future
iterations), camlp4 extensions/syntax changes are _not_ required to
use Batteries with your OCaml code. If you simply link with Batteries
(ex. "-package batteries" using ocamlfind) then there will be no
changes to the syntax.

There are simple mechanisms to make use of the syntax extensions
provided by Batteries, but they are not required for Batteries to work

> I think it is important for adoption of any new thing to give people a
> low-cost way to get started, and an incremental path towards using it fully
> and depending upon it. My impression is that with Batteries you must take or
> leave the whole thing.
>
> A full-featured de facto standard library for OCaml is a great idea, but it
> must be a *library*; you must be able to use only the parts you want to use.

The easiest way to use Batteries is to take or leave the whole thing,
but it is not the only way. Hopefully some more documentation,
particularly in the form of tutorials for folks new to OCaml as well
as Batteries, will help clarify what Batteries _always_ provides and
what it _can_ provide when desired.

Hope this helps,

Hez

--
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

[Jean-Christophe Filliâtre]

> 8) Other (please explain)

I like writing my own libraries when I need some.

(But don't misread me: I don't see myself as a concurrent to Batteries,
and I think you guys are doing a great job.)

--
Jean-Christophe

[Alp Mestan]

On Thu, Sep 3, 2009 at 5:00 PM, Ashish Agarwal <agarw...@gmail.com>wrote:

> - Core language features are altered. For example, the Batteries way is to
> use input's instead of in_channel's. Documentation explaining such changes
> would help. The API documentation is excellent, but what is missing is a
> book on "An Introduction to OCaml with Batteries". Perhaps a well planned
> wiki would help get this started.
>

There's a French version : http://fr.wikibooks.org/wiki/Objective_Caml
for which a translation had been started :
http://en.wikibooks.org/wiki/Objective_Caml but it isn't up-to-date at all,
nor finished.

Still, the missing thing is time...

--
Alp Mestan
http://blog.mestan.fr/
http://alp.developpez.com/

[Sylvain Le Gall]

On 03-09-2009, Edgar Friendly <thele...@gmail.com> wrote:
> It seems like batteries' adoption isn't quite as thorough as expected.
> We in the batteries devel team would love to know why you don't use
> batteries. Here's some of our guesses:
>
> 1) I *do* use batteries
> 2) It's not 1.0 yet, I'll try it then
> 3) It makes my executables too big
> 4) It's too hard to install (dependencies, godi failures)
> 5) It's difficult to compile against
> 6) It doesn't work on my platform
> 7) It uses camlp4
> 8) Other (please explain)
>

I hope to use Batteries, when I will have enough time to learn it ! I
think it is a great thing to have it.

Regards,
Sylvain Le Gall

[Ashish Agarwal]

Great! I did not know this book was going to employ Batteries. That is a
great step towards making Batteries the standard library.

[Jon Harrop]

On Thursday 03 September 2009 15:35:20 Dario Teixeira wrote:
> a) Lack of exposure to the advantages of Batteries. It borrows lots of
> cool ideas from Haskell, but that may not be immediately apparent.

Can you elaborate on this?

> You guys should take advantage of the Ocaml Planet to run a publicity
> campaign: you can make a number of tutorial posts showing the "old"
> way versus the Batteries way. There's more to Batteries than just
> a collection of APIs, and that message may not be getting through.

I would very much like to learn batteries and write OCaml Journal articles
about it. The main reason I have not is not just that it has not reached 1.0
yet but that it is not a mere "apt-get install" away for most users.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

[Philippe Wang]

I am not sure my answer is relevant, but here it is :

The ratio
(time needed to install&learn&use it) / (time saved)
has to be interesting (close to zero).

For me, at the moment, this ratio is close to infinite.

However, I do hope to use it someday.

Cheers,

Philippe

[Hugo Schmitt]

Hi

I installed the Haskell Platform because there was a binary for win32, and
didn't installed Ocaml Batteries for the same reason: "You may download the
source tarball from the Forge [1], read the on-line API documentation [2] or
the extended release notes [3]."

Cheers,
Hugo

[Mike Lin]

2009/9/3 Jean-Christophe Filli�tre <Jean-Christo...@lri.fr>

>
> > 8) Other (please explain)
>
> I like writing my own libraries when I need some.
>

Ditto,
Due to the sparsity of OCaml's standard library, many long term users
probably have their own library to do all sorts of little things they need,
and substantial amounts of code written around it. :-(

[Erik de Castro Lopo]

Edgar Friendly wrote:

> 8) Other (please explain)

I can not yet "apt-get install" it.

The main systems where it batteries would be useful for me is on
production code for Ubuntu 6.06 (legacy) and 8.04. I do have a laptop
running 9.04 and will probably upgrade that to 9.10 in the near future.

If batteries is available for 9.10 and I like it enough I will probably
grab the 9.10 source package and backport it to 6.06 and 8.04 and then
push it into our personalised Ubuntu package repository.

The reliance Debian packages is do to our automation and QQ processes.
All software that ends up on our kiosk-like devices start up as source
code in subversion (not my first choice). We than have an autobuilder
that pulls stuff out of SVN, builds the packages and sticks it in our
own development repository. QA pulls built packages out of the devel
repository and if they pass QA , push them to our production repository
where they are pulled onto our kiosks (should be 1000 of these round
the world by about March next year) in an automatic upgrade procedure.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

[Erik de Castro Lopo]

Mike Lin wrote:

> Ditto,
> Due to the sparsity of OCaml's standard library, many long term users
> probably have their own library to do all sorts of little things they need,
> and substantial amounts of code written around it. :-(

Double ditto. I have quite a large amount of stuff sitting on top of
extlib/str/unix.

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________

[Edgar Friendly]

Erik de Castro Lopo wrote:
> Mike Lin wrote:
>
>> Ditto,
>> Due to the sparsity of OCaml's standard library, many long term users
>> probably have their own library to do all sorts of little things they need,
>> and substantial amounts of code written around it. :-(
>
> Double ditto. I have quite a large amount of stuff sitting on top of
> extlib/str/unix.
>
> Erik

Would you consider donating any of it to batteries?

E

[Erik de Castro Lopo]

Edgar Friendly wrote:

> Would you consider donating any of it to batteries?

When I finally get batteries (via apt-get) and find something
thats in my library, but not in batteries, I would be happy to
donate it :-).

Cheers,

Erik
--
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

_______________________________________________

[David MENTRE]

Hello Erik,

2009/9/4 Erik de Castro Lopo <mle+...@mega-nerd.com>:

> If batteries is available for 9.10

Batteries is available for 9.10:
http://packages.ubuntu.com/search?keywords=batteries

> and I like it enough I will probably
> grab the 9.10 source package and backport it to 6.06 and 8.04 and then
> push it into our personalised Ubuntu package repository.

Here is the official Debian package used in Ubuntu:
http://packages.qa.debian.org/o/ocaml-batteries.html

Yours,
d.

PS: List of OCaml packages in Debian and Ubuntu:
http://bentobako.org/ubuntu-ocaml-status/raw/compare-unstable-karmic.html

[Stefano Zacchiroli]

On Fri, Sep 04, 2009 at 01:08:32AM +0100, Jon Harrop wrote:
> I would very much like to learn batteries and write OCaml Journal
> articles about it. The main reason I have not is not just that it
> has not reached 1.0 yet but that it is not a mere "apt-get install"
> away for most users.

Uh? http://packages.debian.org/sid/libbatteries-ocaml-dev

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'� ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu � tous ceux que j'aime

[Stefano Zacchiroli]

On Fri, Sep 04, 2009 at 01:34:45PM +1000, Erik de Castro Lopo wrote:
> I can not yet "apt-get install" it.

Uh? I've released the Debian package close to the beginning of
Batteries development:
http://packages.debian.org/sid/libbatteries-ocaml-dev

Given that this is the second message in this direction, and given
that other distro (Fedora and Ubuntu mainly) use to announce
*packaging* initiative on this list. Do readers feel like we should do
the same for Debian?

I usually do that via blog posts that get syndicated on
http://planet.ocamlcore.org ; should I conclude from this feedback
that it's not enough?

Cheers.

--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
zack@{upsilon.cc,pps.jussieu.fr,debian.org} -<>- http://upsilon.cc/zack/
Dietro un grande uomo c'� ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...........| ..: |.... Je dis tu � tous ceux que j'aime

_______________________________________________

[Gaius Hammond]

On 4 Sep 2009, at 01:08, Jon Harrop wrote:

> I would very much like to learn batteries and write OCaml Journal
> articles
> about it. The main reason I have not is not just that it has not
> reached 1.0
> yet but that it is not a mere "apt-get install" away for most users.

This (for example) is what other language communities count as
"batteries included":

http://www.activestate.com/activepython/

No disrespect intended towards the Batteries guys, but if the goal is
to encourage widespread adoption, that's what to aim for.

Cheers,

G

[Stéphane Glondu]

Pierre Etchemaite a écrit :

>> I imagine there are a fair number of people who take parts bits and
>> pieces out of the batteries sources and use those in their projects.
>

> I've seen this in too many OCaml projects indeed, and that approach
> has its own problems too. Fixes and improvements do not flow from one
> copy of the code to the other, codes eventually diverge and using the
> "real" library becomes harder as time goes on... This is a maintainance
> nightmare. [...]

+1

> I think a broad availability (either installed by default or at least
> *very* easy to install) on all supported platforms should be a
> start. As I understand Batteries is getting there.

I would say it's software distributions' goal (GODI, Debian, etc.).

Cheers,

--
Stéphane

[Pierre Etchemaite]

Hi all,

Le Thu, 3 Sep 2009 17:50:21 +0200
Tom Hutchinson <Thomas.H...@sophia.inria.fr> a écrit:

> I imagine there are a fair number of people who take parts bits and
> pieces out of the batteries sources and use those in their projects.

I've seen this in too many OCaml projects indeed, and that approach

has its own problems too. Fixes and improvements do not flow from one
copy of the code to the other, codes eventually diverge and using the
"real" library becomes harder as time goes on... This is a maintainance
nightmare.

Solutions should be found for each reason (development, deployment,
performance,...) why OCaml libraries are not used like libraries, so
that the incitive to go cutting&pasting disappears; because in my
opinion it's terrible.

I think a broad availability (either installed by default or at least
*very* easy to install) on all supported platforms should be a
start. As I understand Batteries is getting there.

Best regards,
Pierre.

[Stéphane Glondu]

Jean-Christophe Filliâtre a écrit :

> I like writing my own libraries when I need some.

Unfortunately, many people do that.

The problem with this approach (from a FOSS point of view) is with
external contributors (who can fix bugs or develop features). A (big)
project using non-standard libraries for things that do have a standard
(imagine zlib and pcre in C) will attract less external contributors (it
would deter me from contributing and therefore using, at least).

Of course, things are easier with OCaml than with C, as you can "learn"
or discover the usage of a library being guided just by the compiler
error messages, but it become painful at some point.

I appreciate the Batteries initiative which IIUC aims at providing
standards (but I don't use it myself... yet). But I'd like to comment on:

> 3) It makes my executables too big

I wouldn't say this is a problem of Batteries, but a problem of OCaml's
lack of proper shared libraries.

--
Stéphane

[Vincent Aravantinos]

Le 4 sept. 09 � 11:32, St�phane Glondu a �crit :

>> I think a broad availability (either installed by default or at least
>> *very* easy to install) on all supported platforms should be a
>> start. As I understand Batteries is getting there.
>
> I would say it's software distributions' goal (GODI, Debian, etc.).

Installing a software distribution is a "one more step" in the install.
If you want to reach the widest audience it should be self contained.
A guy who wants to try batteries wants to try batteries
i.e. he doesn't want to waste his time in installing batteries.
An experienced guy will be ready to take this time but a beginner will
very easily get discouraged. And even the experienced guy will be
ready to take
this time on the condition that he is quite confident that this will
bring something to
him. From reading this thread it does not seem to be the case yet.

Anyway beginners are certainly *the* audience to reach since the
earlier you are addicted
the harder you are detoxified. Furthermore as shown by this thread,
many experienced
guys already have their own ways of doing things.

My opinion: at the moment, "wrapping" (install, doc, faq, quickstarts,
web site,
advertisement) should be a priority over new features.

--
Vincent Aravantinos
PhD Student - LIG - CAPP Team
Grenoble, France
+33.6.11.23.34.72
vincent.a...@imag.fr
http://membres-lig.imag.fr/aravantinos/

[Andrej Bauer]

I would use batteries and would recommend it to my students if there
were any chance they would succeed installing it. In other words,
batteries is too hard to install. This may not be so on Linux, but
what about Windows (99% of my students use Windows only)?

By the way, my experience with students trying to install software (on
WindowS) was that:

a) Java is easy to install but is useless by itself
b) Java + Textpad editor is hard to install because Java must be
installed before Textpad
c) Java + Eclipse is hard to install because Eclipse is scary
d) Ocaml is very hard to install for a number of reasons
e) Python is easy to install (assuming the use IDLE for editing)

We switched to Pythong from Java a while ago. You can never
overestimate how important "trivialities" such as ease of installation
and natural-looking syntax (python's indentation) are to beginners.

Andrej

[Pascal Cuoq]

Edgar Friendly <thele...@gmail.com> wrote:

> Erik de Castro Lopo wrote:

>> Mike Lin wrote:
>>
>>> Ditto,
>>> Due to the sparsity of OCaml's standard library, many long term
>>> users
>>> probably have their own library to do all sorts of little things
>>> they need,
>>> and substantial amounts of code written around it. :-(
>>
>> Double ditto. I have quite a large amount of stuff sitting on top of
>> extlib/str/unix.
>>
>> Erik

> Would you consider donating any of it to batteries?

17) I don't want to use any library that will accept code from people
like me.

Grou^H^H^H^H Pascal

[Jean-Christophe Filliâtre]

>> I like writing my own libraries when I need some.
>
> Unfortunately, many people do that.

Why do you say "unfortunately"? What was important in my answer was not
the words "my own libraries" but the words "I like". And you cannot find
unfortunate that some people like programming :-)

(But, of course, if this is to recode an existing library without any
pleasure, I agree with you.)

--
Jean-Christophe

[Richard Jones]

On Fri, Sep 04, 2009 at 07:39:25AM +0100, Gaius Hammond wrote:
> On 4 Sep 2009, at 01:08, Jon Harrop wrote:
>
> >I would very much like to learn batteries and write OCaml Journal
> >articles
> >about it. The main reason I have not is not just that it has not
> >reached 1.0
> >yet but that it is not a mere "apt-get install" away for most users.
>
>
> This (for example) is what other language communities count as
> "batteries included":
>
> http://www.activestate.com/activepython/

Which brings us back to the argument when Batteries was orginally
proposed: For some reason, some users are unable to use 'apt-get', or
the corresponding clicky interfaces.

For those users, either they need to be taught how to use the clicky
interfaces, or, if they are on certain OSes which lack packaging
systems, one can provide a fat OCaml package with lots of libraries.

However this problem is completely orthogonal to the problem of
providing a core, consistent and standardized library.

Rich.

--
Richard Jones
Red Hat

[Richard Jones]

On Fri, Sep 04, 2009 at 12:26:45PM +0200, Andrej Bauer wrote:
> I would use batteries and would recommend it to my students if there
> were any chance they would succeed installing it. In other words,
> batteries is too hard to install. This may not be so on Linux, but
> what about Windows (99% of my students use Windows only)?

Give them a live CD.

There are various online projects where you can create live CDs with a
custom set of packages via a webpage.[1]

A live CD is actually better than relying on them trying to install
something under Windows, because you're guaranteeing a consistent
environment. And you can provide them with customized bits too (like
the coursework!)

If you provide the live CD as both a physical CD and a downloadable
ISO, they can even run it virtualized so they don't need to reboot.

Rich.

[1] Fedora's tool is command-line based: you can use
'appliance-creator' or 'livecd-creator'.

http://thincrust.org/ace-examples.html

--
Richard Jones
Red Hat

_______________________________________________

[Dario Teixeira]

Hi,

> I would use batteries and would recommend it to my students if there
> were any chance they would succeed installing it. In other words,
> batteries is too hard to install. This may not be so on Linux, but
> what about Windows (99% of my students use Windows only)?

This issue of Ocaml + Windows installation woes comes up all too often
on this list, and not just when Batteries are concerned.� It simply
boggles my mind that beginners will put themselves to such ordeals
when modern computing offers a much easier solution: if you really must
be running Windows as your main OS, then use a virtualisation solution
to run Ocaml inside a Linux guest!

Sure, your students may not be familiar with Linux, but you don't have
to be a "1337 Hax0r" to fire up a terminal and run "apt-get install".
Even if your students need a couple of hours of introduction to Linux,
that time will quickly be compensated by the ease of installing Ocaml
packages under Linux.� Moreover, and to be blunt, if your students are
not capable of making a tiny accommodation towards Linux, then trying
to teach them Ocaml seems as consequential as teaching pigs to sing.

In short, the "ease of installation" argument seems like a red herring
as far as beginners are concerned.

Best regards,
Dario Teixeira

[Hezekiah M. Carty]

On Fri, Sep 4, 2009 at 9:10 AM, Richard Jones<ri...@annexia.org> wrote:
> Give them a live CD.
>
> There are various online projects where you can create live CDs with a
> custom set of packages via a webpage.[1]
>
> A live CD is actually better than relying on them trying to install
> something under Windows, because you're guaranteeing a consistent
> environment.  And you can provide them with customized bits too (like
> the coursework!)
>
> If you provide the live CD as both a physical CD and a downloadable
> ISO, they can even run it virtualized so they don't need to reboot.

This may be a nice longer-term goal for Batteries and/or Community
OCaml. Providing a livecd or perhaps a ready-to-go virtual machine
image would make it much simpler for folks with problems (4) and (6)
to try out both OCaml and Batteries in a known-functional environment.

Hez

--
Hezekiah M. Carty
Graduate Research Assistant
University of Maryland
Department of Atmospheric and Oceanic Science

[Rakotomandimby Mihamina]

09/04/2009 01:26 PM, Andrej Bauer::

> By the way, my experience with students trying to install software (on
> WindowS) was that:
> a) Java is easy to install but is useless by itself
> b) Java + Textpad editor is hard to install because Java must be
> installed before Textpad
> c) Java + Eclipse is hard to install because Eclipse is scary
> d) Ocaml is very hard to install for a number of reasons
> e) Python is easy to install (assuming the use IDLE for editing)

http://packages.ubuntu.com/karmic/ocaml/ocaml-batteries-included
http://packages.ubuntu.com/karmic/emacs-snapshot

What else? :-P
I love Fridays...

--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34

[Gaius Hammond]

On 4 Sep 2009, at 15:38, Hezekiah M. Carty wrote:
>>
>> If you provide the live CD as both a physical CD and a downloadable
>> ISO, they can even run it virtualized so they don't need to reboot.
>
> This may be a nice longer-term goal for Batteries and/or Community
> OCaml. Providing a livecd or perhaps a ready-to-go virtual machine
> image would make it much simpler for folks with problems (4) and (6)
> to try out both OCaml and Batteries in a known-functional environment.

I don't think this is a realistic use case. I am interested in using
OCaml for real work; the way I "try" any language (or tool, or
library, etc) is to install it on my work machine and use it to tackle
a small but real problem. If I like what I see I take it further, then
eventually I will want to deploy it. A sandbox is nothing more than a
toy for freshmen (and freshmen who need spoonfeeding, at that).

I am after a language that has the rapid-development of Python or Tcl
but with type safety; OCaml is right now the best bet, but it is
*very* rough around the edges. The way you install ActivePython is you
download it and run the installer and a few minutes later you're ready
to go with everything you need. I'm just reading the release notes for
Batteries now and it starts, you will need <a big long list of
things>. Maybe I'm just spoilt by other language distributions, but I
think I am representative of the "OCaml-curious" programmer, and
that's not what "batteries included" implies to us.

I don't mean to single Batteries out here, it's definitely a step in
the right direction, and kudos to those that have put in the effort.
It's a general problem in the OCaml world. Compare Python's actively
developed cx_Oracle to OCaml's abandoned Oracaml. Or Python's
excellent Matplotlib to OCaml's frankly crude Plplot, I tried to draw
a graph with a legend today, very simple you might think, wait, Plplot
doesn't even do that! It would be a very hard sell to my colleagues
right now, regardless of the brilliance of type inference, pattern
matching, etc...

Cheers,

G

[Richard Jones]

I just built one successfully using this:

http://www.annexia.org/tmp/ocaml-f11.ks

and:

appliance-creator --name ocaml-f11 --config ocaml-f11.ks

You'll probably want to use livecd-creator instead.

qemu-kvm -snapshot -hda ocaml-f11-sda.raw -vnc :10 -m 512

(Root password is 'thincrust').

In the live CD case you give students either the ISO or bootable CD
(or ISO and they can burn a bootable CD). The more knowledgeable ones
can just boot the ISO directly in any VM.

Rich.

[Rakotomandimby Mihamina]

09/04/2009 09:37 PM, Gaius Hammond:

> I am after a language that has the rapid-development of Python or Tcl
> but with type safety; OCaml is right now the best bet, but it is *very*
> rough around the edges. The way you install ActivePython is you download
> it and run the installer and a few minutes later you're ready to go with
> everything you need. I'm just reading the release notes for Batteries
> now and it starts, you will need <a big long list of things>.

I must insist on the fact this is probably specific to some OS.
On debian and Ubuntu, adding one line to sources.list and issuing one
command line does the trick.
That is easy, espacially for those already using them.

--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34

_______________________________________________

[David Rajchenbach-Teller]

Yes, we need to work on the uninstallation in GODI.

Cheers,
David

On Thu, 2009-09-03 at 15:25 +0200, Alan Schmitt wrote:
>
> I installed it once (using godi), but when I tried to migrate to a
> newer version of ocaml, compilation fails. (It tells me it's already
> installed, but it seems that godi believes it's not.) I have not taken
> the time to look under the hood to find out what is wrong.
>
>
> Alan

[David Rajchenbach-Teller]

Unfortunately, it still is. I hope that the compiler will eventually be
fixed to avoid this kind of issue.

Cheers,
David

On Thu, 2009-09-03 at 16:10 +0200, kattla wrote:
> Hi,

>
> > 3) It makes my executables too big
>

> (Assuming this [0] is still true)
>
> For me this is the biggest reason for not using batteries. I don't
> really have a need for small executables right now, but I would like
> to at least know that this issue will be resolved before I adopt
> batteries.
>
>
> [0] http://caml.inria.fr/pub/ml-archives/caml-list/2008/11/24509ad16aae6d1cc2e15f532e0007eb.en.html

[David Allsopp]

Rakotomandimby Mihamina wrote:
> 09/04/2009 09:37 PM, Gaius Hammond:
> > I am after a language that has the rapid-development of Python or Tcl
> > but with type safety; OCaml is right now the best bet, but it is
> > *very* rough around the edges. The way you install ActivePython is you
> > download it and run the installer and a few minutes later you're ready
to go
> > with everything you need. I'm just reading the release notes for
Batteries
> > now and it starts, you will need <a big long list of things>.
>
> I must insist on the fact this is probably specific to some OS.
> On debian and Ubuntu, adding one line to sources.list and issuing one
> command line does the trick.
> That is easy, espacially for those already using them.

Using a very simple analysis from
http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
97.14%[1] of the computers in the world run an OS which does not have a
"Linux"-style package manager (very sad, but true). Therefore a one-click
installer should be a higher priority than supporting package managers *if*
you want wider adoption of the system at all. Many developers will be using
Windows whether they want to or not (or OS X - though I apologise if OS X
does in fact have a package manager; please subtract 4.59% the previous
number if it does) because they'll be in companies whose IT infrastructure
is Windows, even if they have a few *nix boxes in the machine room "for
those weird developers".

I'm not sure that one is allowed to redistribute the Microsoft C compilers
directly without a license, but packaging MSYS or the relevant parts of
Cygwin along with OCaml and Batteries would create an installer somewhere
between 150-300MB which compared to the 16GB of trial software I downloaded
from the Microsoft website the other day is not that bad. You could even
throw an editor in with it. Microsoft Installer is a command line compiler
which reads text files so it can be targeted from make just like anything
else and the script would pretty much only have to be written once and then
someone would occasionally have to use a Windows box just to build it (and
virtualisation means you can pretend that your Linux PC isn't even running
Windows really). It would also not be too much work to have an MSVC version
which simply explained that you must install the Windows SDK to get the C
compiler (but, just like OCaml's own binary win32 files, you'd still get
bytecode for nothing).

Personally, I compile everything from sources with OCaml - but when I
started out with it (as an undergraduate) I used the mingw installer from
the OCaml website and was up and running in a matter of minutes. If I'd had
multi-step instructions to deal with at that point, I'd have probably ended
up sticking with Moscow ML! My point is that the one-click installer at the
start of the process allowed me to get hooked and then later, when the
benefits were very clear, I was happy to go down the slightly more complex
route of doing it properly. So, for example, once our
batteries-single-click-installer-beginners realise that OCaml is cool and
they want to use other libraries and tools as well then they may well
realise that Cygwin isn't that hard to install and so therefore
GODI-on-Windows isn't really that scary and so they can get Batteries and
lots of other goodies using that instead of the megalithic installer.

Also personally, when I come across a piece of software that offers a
live-CD or virtual appliance as a means of demonstration it makes me look
elsewhere as to me it implies that installation and maintenance is so
complicated that it's made the developers go to the trouble of building a
demo PC (albeit virtual!) just to guarantee that it works properly first
time... but that's probably "just me".

There's an old saying: "If you can't beat them, join them". Standing ranting
on a soap-box doesn't tend to achieve much...

In vain hope of not starting a flame war,

David (who, by the way, is a realist rather than a Microsoft-apologist)

[1] 4 s.f. seems a tad optimistic on an estimate like that - but rounding to
the more sensible 1 s.f. would mean 100% which might be considered as
over-egging my point ;o)

[ri...@happyleptic.org]

> 5) It's difficult to compile against

I tried to use it once but failed to find documentation
on how to use it with OCamlMakefile.

> 8) Other (please explain)

I'm still learning OCaml and I'm afraid that batteries, beeing both a library
and sort of replacement for OCaml (replace compiler, toplevel...), would
be too complex to comprehend.

[ri...@happyleptic.org]

> Using a very simple analysis from
> http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
> 97.14%[1] of the computers in the world run an OS which does not have a
> "Linux"-style package manager (very sad, but true).

With OCaml you can distribute native code programs, so the installation
problem is relevant only to programmers.

As only a very small portion of these "computers in the world" are used as
programming work-stations, we can't conclude much from this measure.
We'd rather have to know what share of computers used by programmers to write
software does not come with a decent package system. I guess this would be much
less impressive.

Also, OCaml is not the only system that's harder to install on windows
than on Unix : Haskell's Cabal have difficulties on windows also, for instance.
I bet something like ActivePython came _after_ python was already popular and
had many libraries that were easy to install on Linux only, and not the other
way around.

> In vain hope of not starting a flame war,

In other words, you would like to be read but not answered ?

[Gaius Hammond]

On 5 Sep 2009, at 10:44, David Allsopp wrote:

>
> Using a very simple analysis from
> http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
> 97.14%[1] of the computers in the world run an OS which does not
> have a
> "Linux"-style package manager (very sad, but true). Therefore a one-
> click
> installer should be a higher priority than supporting package
> managers *if*
> you want wider adoption of the system at all. Many developers will
> be using
> Windows whether they want to or not (or OS X - though I apologise if
> OS X
> does in fact have a package manager; please subtract 4.59% the
> previous
> number if it does) because they'll be in companies whose IT
> infrastructure
> is Windows, even if they have a few *nix boxes in the machine room
> "for
> those weird developers".

I do most of my development on Solaris, we operate a variety of OSs in
production including Solaris, various Linuxes, various Windows
versions. To deploy Python code, I say to the sysadmins, "can you drop
ActivePython on these boxes" and they do, it's a snap, and it all
works the same everywhere. That is a big factor in language adoption.
I think we can all agree that Perl and Java are horrible languages,
but they're ubiquitous because of this.

In my OCaml environment, Oracaml has to be built with SunStudio
(because it links against C++ code, Oracle's OCCI libraries, compiled
with SunStudio). Plplot has to be built with GCC. Pcre doesn't work
with the Pcre library package from Blastwave (this is a repository of
Solaris software a la GODI), you have to compile the C from source and
forego the benefits of package management. Plplot isn't happy with
OCaml 3.08 and Oracaml isn't happy with 3.11 (tho' this is fixable,
it's a symptom of it being abandoned, do I dare rely on it for real
work?). I could go on...

For me the benefits of OCaml do outweigh these factors for my own use
- that is code written by me for my own and my team's use on the main
machine we share for our work. I can't even contemplate using OCaml to
be deployed elsewhere in the organization - I'd have to become nearly
a full time build engineer to support it!

> Also personally, when I come across a piece of software that offers a
> live-CD or virtual appliance as a means of demonstration it makes me
> look
> elsewhere as to me it implies that installation and maintenance is so
> complicated that it's made the developers go to the trouble of
> building a
> demo PC (albeit virtual!) just to guarantee that it works properly
> first
> time... but that's probably "just me".

No, you've hit the nail on the head here.

Cheers,

G

[Jon Harrop]

On Saturday 05 September 2009 10:44:58 David Allsopp wrote:

> Rakotomandimby Mihamina wrote:
> > I must insist on the fact this is probably specific to some OS.
> > On debian and Ubuntu, adding one line to sources.list and issuing one
> > command line does the trick.
> > That is easy, espacially for those already using them.
>
> Using a very simple analysis from
> http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
> 97.14%[1] of the computers in the world run an OS which does not have a
> "Linux"-style package manager (very sad, but true). Therefore a one-click
> installer should be a higher priority than supporting package managers *if*
> you want wider adoption of the system at all. Many developers will be using
> Windows whether they want to or not (or OS X - though I apologise if OS X
> does in fact have a package manager; please subtract 4.59% the previous
> number if it does) because they'll be in companies whose IT infrastructure
> is Windows, even if they have a few *nix boxes in the machine room "for
> those weird developers".

You're quoting statistics that cover secretaries, housewives and teenage
gamers and trying to apply them to OCaml programmers. Windows' market share
among technical users and programmers is significantly smaller and among
OCaml programmers is smaller still.

For example, if you look at sales of technical software like ours or
Mathematica, Windows has only ~60% market share.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

[Jon Harrop]

On Saturday 05 September 2009 11:22:30 ri...@happyleptic.org wrote:
> > Using a very simple analysis from
> > http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
> > 97.14%[1] of the computers in the world run an OS which does not have a
> > "Linux"-style package manager (very sad, but true).
>
> With OCaml you can distribute native code programs, so the installation
> problem is relevant only to programmers.

Don't bank on it. We shipped a product called Presenta a few years ago that
was written in OCaml and distributed as a native code executable for Linux.
It was a complete disaster with 80% of users experiencing random segfaults
and we canned the product and will never try to distribute compiled OCaml
programs again.

Linux is basically a complete disaster in this regard because it offers so
little binary compatibility between distros. Building upon a decent VM solves
this problem and many others, of course, but Linux has none.

--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

_______________________________________________

[Rakotomandimby Mihamina]

09/05/2009 03:03 PM, Jon Harrop::

>>> Using a very simple analysis from
>>> http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
>>> 97.14%[1] of the computers in the world run an OS which does not have a
>>> "Linux"-style package manager (very sad, but true).
>> With OCaml you can distribute native code programs, so the installation
>> problem is relevant only to programmers.
> Don't bank on it. We shipped a product called Presenta a few years ago that
> was written in OCaml and distributed as a native code executable for Linux.

> [...]

> Linux is basically a complete disaster in this regard because it offers so
> little binary compatibility between distros.

The same with Windows. Some executables are version-sticky.

<my really personnal opinion>
But if you really wanted to distribute for Linux, the least action is
to provide:
- a specfile for rpm packagin
- a debian/ directory for debian likes
That way, you'll get it right.
</p>

For example http://dev.coova.org/svn/coova-chilli/ has.
I think it's a good effort made.

--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34

_______________________________________________

[Richard Jones]

On Sat, Sep 05, 2009 at 10:44:58AM +0100, David Allsopp wrote:
> I'm not sure that one is allowed to redistribute the Microsoft C compilers
> directly without a license, but packaging MSYS or the relevant parts of
> Cygwin along with OCaml and Batteries would create an installer somewhere
> between 150-300MB which compared to the 16GB of trial software I downloaded
> from the Microsoft website the other day is not that bad. You could even
> throw an editor in with it. Microsoft Installer is a command line compiler
> which reads text files so it can be targeted from make just like anything
> else and the script would pretty much only have to be written once and then
> someone would occasionally have to use a Windows box just to build it (and
> virtualisation means you can pretend that your Linux PC isn't even running
> Windows really). It would also not be too much work to have an MSVC version
> which simply explained that you must install the Windows SDK to get the C
> compiler (but, just like OCaml's own binary win32 files, you'd still get
> bytecode for nothing).

I don't think anyone's claiming it's not possible, just that no one
has actually done the work or offered to keep making up to date
releases.

It's a big project, but not big compared to other OCaml projects out
there, eg. Debian's OCaml project is far larger than is proposed for
an "Active OCaml" Windows installer. For comparison, I reckon on
spending about one day a month maintaining the Fedora OCaml packages.

You just need to find some people who are technically competent on
OCaml on Windows, yet haven't ditched Windows for Linux for some
reason.

Rich.

--
Richard Jones
Red Hat

_______________________________________________

[Jon Harrop]

On Saturday 05 September 2009 13:02:10 Richard Jones wrote:

> On Sat, Sep 05, 2009 at 01:03:28PM +0100, Jon Harrop wrote:
> > Linux is basically a complete disaster in this regard because it
> > offers so little binary compatibility between distros.
>

> You probably want to use a commercial Linux distribution. Red Hat (as
> an example) *guarantee* perfect binary compatibility for the 7 - 10
> year lifespan of a release of RHEL.

You mean sell only to RHEL users and not Linux users?

> > Building upon a decent VM solves this problem and many others, of
> > course, but Linux has none.
>

> Not sure what you mean by this. Linux was the first _PC_[1] OS to
> incorporate a hypervisor into the kernel (Xen or KVM depending on your
> interpretation of the words "hypervisor" and/or "incorporate").

I'm talking about user space VMs like the JVM and CLR and not OS kernel
hypervisors.

[dmitry grebeniuk]

2009/9/5 David Allsopp <dra-...@metastack.com>:

> I'm not sure that one is allowed to redistribute the Microsoft C compilers
> directly without a license, but packaging MSYS or the relevant parts of
> Cygwin along with OCaml and Batteries would create an installer somewhere
> between 150-300MB which compared to the 16GB of trial software I downloaded
> from the Microsoft website the other day is not that bad.

 That's what I'm doing for my local needs, approximately.  First of
all, I have an infrastructure to build so called "packages".  global
configure script (allows to choose installation prefix, library
paths), a lot of patches, platform-specific build scripts, some
dependency-stuff.  Patches allow me to hardcode paths in some places
(ugly, but it works).  I'm building it under platforms that are
interesting for me, for now it's only mingw/win32 and ubuntu, maybe
I'll build under freebsd later.  I'm enjoying the pleasure of patching
everything: for example, I made ocamlnet (fastcgi part) working on
mingw.  "Packages" are building and working both under mingw and
linux. (working as far as I have tested -- using "test" targets when
available, or using the library in my code).  The selection of
packages is incomplete, but that's the packages I'm using and its
dependencies: camltemplate camlzip camomile cryptokit deriving extlib
findlib json-static lablgtk2 lwt menhir objsize ocaml-bitstring
ocaml-sqlite3 ocaml-ssl ocamlgraph ocamlnet omake ounit pa_do
pa_safeuse pcre-ocaml sexplib type-conv ulex xmlm.  (there are no
batteries for now)

 Then, some revisions of my project become binary.  I'm making 4
zip-archives under windows: 1. base installation of mingw, msys,
tcl/tk, gtk+ in standard places (c:\mingw, etc), 2. archive that adds
unpacked .tar.gz with mingw C libraries, 3. archive that contains
compiled ocaml + findlib, 4. archive with other ocaml libraries.  So,
installing fresh ocaml and libraries under fresh win32 is just
unpacking 4 zip-archives in c:\ , and adding something like "call
c:\ocaml\set-vars.bat" or ". c:/ocaml/set-vars.sh" in build script.

 I don't distribute it mainly because of the following reasons.  1.
License questions for binary builds.  For my local needs I can do
whatever I want, until it doesn't leave my host and nobody sees it.
(so, guys, you haven't seen all what I've described before)  2. The
complexity of building the system from sources under windows: approx
17 files to download, some of them you install, others you unpack
(.tar.gz, .tar.bz2, not very comfortable for windows).  3. I don't
want to support cygwin (I'm even not installing it at all), and I
don't support msvc and win64 architectures (I don't need it for now).
 Maybe the reason#1 can be solved by building ocaml compiler without
my local patches and reading licenses carefully.

[Adrien]

You seem to have a pretty nice list of packages on windows^Wmingw. :)

Reason #1 could also be solved by publishing your patches and having
them merged upstream. ;-)

>From what you said, your patches won't be very clean and won't be
mergeable in their current state (hardcoding paths, I've been there
too) but they would at least show where the problems are and that's
maybe the biggest part of the work. Please share them if you can.

---

Adrien Nader

[Henry Lenzi]

(snip)

> Compare Python's actively developed
> cx_Oracle to OCaml's abandoned Oracaml. Or Python's excellent Matplotlib to
> OCaml's frankly crude  Plplot, I tried to draw a graph with a legend today,
> very simple you might think, wait, Plplot doesn't even do that! It would be
> a very hard sell to my colleagues right now, regardless of the brilliance of
> type inference, pattern matching, etc...
>

OCaml has much less people working on it.
Colleges churn out C++ and Java-trained people. Python is very close
to that. See how much less love Ruby gets because of its
Smalltalkishness.
OCaml needs more people. Where are the French, by the way? ;-)

Henry

[Rakotomandimby Mihamina]

09/06/2009 11:47 AM, Henry Lenzi:

> OCaml has much less people working on it.
> Colleges churn out C++ and Java-trained people. Python is very close
> to that.

May be, but not nough.
I remember Nuxeo switch to Java a while ago.

> See how much less love Ruby gets because of its
> Smalltalkishness.
> OCaml needs more people. Where are the French, by the way? ;-)

Coming soon... :-P

--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34

_______________________________________________

[Gaius Hammond]

On 6 Sep 2009, at 09:47, Henry Lenzi wrote:

> OCaml needs more people. Where are the French, by the way? ;-)

That's an interesting question. I have a friend who is an
astrophysicist at a French observatory. He and his colleagues use
FORTRAN and more recently Python (which hands off its heavy numeric
work to LAPACK and BLAS). OCaml is unheard of, yet it ought to be
perfect for them. I have another friend at a large French consulting
firm - they are all Java for new work, plus whatever legacy languages
they have to maintain, and they've never heard of OCaml. Same is true
in French investment banking. Which is all very strange, the French
are well known for championing home-grown ideas over whatever Les
Rosbifs are doing (esp. since OCaml is clearly the more elegant
language!).

Cheers,

G

[Philip]

maybe its the wrong question. what about:
how (ie in which projects, success-stories) do you use batteries?

Philip

On Thu, 2009-09-03 at 09:05 -0400, Edgar Friendly wrote:
> It seems like batteries' adoption isn't quite as thorough as expected.
> We in the batteries devel team would love to know why you don't use
> batteries. Here's some of our guesses:
>
> 1) I *do* use batteries
> 2) It's not 1.0 yet, I'll try it then

> 3) It makes my executables too big

> 4) It's too hard to install (dependencies, godi failures)

> 5) It's difficult to compile against

> 6) It doesn't work on my platform
> 7) It uses camlp4
> 8) Other (please explain)
>
> Respond in public if appropriate, respond directly to me if you want.
> Now's a good time to think about where batteries is going and how it's
> getting there.
>
> E

[Alan Schmitt]

On Sat, Sep 5, 2009 at 10:47 AM, David Rajchenbach-Teller <
David....@ens-lyon.org> wrote:

> Yes, we need to work on the uninstallation in GODI.

Do you have any suggestion to get me out of this state? (I can go and
manually erase something, but I don't know what.)

Alan

[David Rajchenbach-Teller]

I'd say

ocamlfind remove batteries
ocamlfind remove batteries_threads
ocamlfind remove batteries_nothreads

_______________________________________________

[Alan Schmitt]

On Sun, Sep 6, 2009 at 12:15 PM, David Rajchenbach-Teller <
David....@ens-lyon.org> wrote:

> I'd say
>
> ocamlfind remove batteries
> ocamlfind remove batteries_threads
> ocamlfind remove batteries_nothreads

Thanks, it worked. (I had to specify "-destdir" but ocamlfind was kind
enough to tell me to do it.)

Alan

[ri...@happyleptic.org]

> OCaml needs more people. Where are the French, by the way? ;-)

They are loading Ariane rockets with ADA :-)

[Olivier Schwander]

Le 06 Sep 2009 10:52, Gaius Hammond a �crit:

> That's an interesting question. I have a friend who is an astrophysicist
> at a French observatory. He and his colleagues use FORTRAN and more
> recently Python (which hands off its heavy numeric work to LAPACK and
> BLAS). OCaml is unheard of, yet it ought to be perfect for them.

I don't think the OCaml bindings for BLAS and LAPACK are close to the
power and the ease of use of Numpy and Scipy. They provide all the
facilities of Matlab with the power of a true programming language (even
if I don't like Python).

I would say there is a lot of of work to provide such a library with all
the syntactic sugar needed to use it confortably but I'm sure that it
would be really nice to have efficient and powerful matrix computation
in a safe language.

Cheers,

Olivier

[Florent Ouchet]

Richard Jones a �crit :
> Give them a live CD.
>
> There are various online projects where you can create live CDs with a
> custom set of packages via a webpage.[1]
>
> A live CD is actually better than relying on them trying to install
> something under Windows, because you're guaranteeing a consistent
> environment. And you can provide them with customized bits too (like
> the coursework!)

>
> If you provide the live CD as both a physical CD and a downloadable
> ISO, they can even run it virtualized so they don't need to reboot.
>

> Rich.
>

Hi all,

Yet an other Friday :)

IMO, all this discussion is implicitely correlated to the lack of easy
packaging for OCaml applications.

Many projects aim at developers and only developers (there are some
relevant quotes in this thread) but they forget that developers inherit
from advanced users who inherit from basic users. Sometimes (often)
developers do not want to waste their time on things that do not work
out-of-the-click-the-button. You should not forget that many Windows
developers are basic users and that software virtualization is still
rocket science. The release of VM appliances require users to have some
VM software on their system, not every developer has one yet.

The OCaml world is heavily based on the Unix/Linux community and the
Windows world is really different. Many OCaml projects used to release
source tarballs and only source tarballs. They rely on third-party
packagers to build precompiled things for binary Linux/Windows... etc...
That's definitively an approach that is not compatible with most
Windows' users. Basic users that want WinZip go to www.winzip.com (or
download.com) and not to www.my-packager.com/packages/winzip.

In the Windows world, you need a single installer that does everything
for you:
1) it should check the environment consistency;
2) it should silently install all required dependencies;
3) it should publish the project location in the registry
(configuration files should definitively be banned);

These 3 points have nested dependencies: the installer checks the
environment consistency (1) by listing the availability of all the
dependencies (3). If a dependency is missing (2), its package is
silently downloaded and silently installed ("setup.exe /silent" is quite
common). This nested installation checks for consistency and
dependencies etc...

For instance, the OCaml binary files for Windows that are available at
caml.inria.fr lack (2) and (3) (at least).

All this installation process is possible as soon as some kind of
unified OCaml packaging is available and as soon as most projects use it.
This unified OCaml packaging should not be limited to binary
distribution and we can imagine a silent compilation at user's side.
Furthermore, the historical Linux/Unix community will take benefit of
this simplified process which is something like a distributed godi where
each OCaml project provides compatible installation files.

My $0.02,

- Florent

[Rakotomandimby Mihamina]

09/03/2009 04:05 PM, Edgar Friendly:
> 8) Other (please explain)

Some hints (I just saw it in my INBOX, I dont agree nor disagree):
http://www.itworld.com/open-source/78643/how-attract-more-people-your-open-source-project

--
Architecte Informatique chez Blueline/Gulfsat:
Administration Systeme, Recherche & Developpement
+261 34 29 155 34

_______________________________________________