Hello

Here is the latest Caml Weekly News, for the week of December 13 to 20, 2011.

1. Some comments on recent discussions
2. how could the community help with Oasis-DB; towards a CPAN for OCaml?
3. New experimental ARM backend
4. Don't forget the user
5. About the "mingw" port of OCaml
6. OCaml maintenance status / community fork (again)

Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00317.html

> 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
      

Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00332.html

> Edgar, It's excellent to know that you have some knowledge of Oasis-DB.
>
> I share the common assumption that this is one of the missing bricks
> of the OCaml ecosystem, and I hope the community at large can help
> with it. I asked Sylvain about it a few months ago, but he wasn't sure
> at that time what was the best way to help. With him now having less
> time available, I was afraid things could stall on that front.

Well things is now less stalled than before my new job. I have pushed a
couple of patches in oasis darcs repository and I am working to deliver
a oasis 0.2.1 sooner or later.

> Could you (or Sylvain) make a more precise picture of how exactly the
> community could help in the Oasis-DB effort?

See above.

>
> Is the priority to upload package (then maybe the warning on the
> webpage advising not to do it seriously should be changed), or are
> there other things we could help with, for example development
> aspects? 

You can upload packages to the server. They won't be lost. The main
point of the dev server DB is for the OCaml community to see if the
service is useful. I won't commit myself into delivering a long term
production server if nobody thinks it is useful.

Helping me to debug by uploading package to oasis-db has 4 "good" effects:
- you use oasis in you project and you can debug it/help me improve it
- you allow other projects to use your package to test oasis-db (e.g odb.ml)
- you increase the visibility of oasis-db and people gradually thinks it
  is a good solution
- it cheers me (ok seems like dumb, but that motivates)

Concerning the dev. aspect see above.

> Who/where should we ask for advice/help when we have issues?

Either you can create a bug in the BTS (or a feature request), send a
mail to 
oasis-devel AT lists.forge.ocamlcore.org,
 have a
chat on #ocaml IRC on freenode (more and more people are able to answer
your question on OASIS here) or send me an email. This should be the
last option because the discussion won't be public.

> It would really help, I think, if:
> - there was a list somewhere of things other people can contribute

Well there is:
http://oasis.forge.ocamlcore.org/contribute.html

> - you talked more about the progress of the effort (I discovered
> 'odb.ml' by absolute chance a few weeks ago, while I follow almost all
> OCaml-related information channels); if people don't know about your
> work, they won't contribute

odb.ml was started by thelema and it remains his project, I let him
communicate on that. But you can see on the home page of oasis-db a link
to odb.ml that directs to an explanation of what it is (Section
"Installing packages from OASIS-DB"). 

I think in general oasis probably needs a better press coverage... Will
try to improve this aspect.

So concerning other help:

For dvlpt:
- if you want to work on the core oasis or oasis-db, here is a short
  list of possible tasks:
    - bug/feature fixing for oasis v0.2.1:
      
https://forge.ocamlcore.org/tracker/index.php?group_id=54&atid=291&power_query=1&query_id=21&run
      
https://forge.ocamlcore.org/tracker/index.php?group_id=54&atid=294&power_query=1&query_id=23&run
    - other bug/feature fixing for oasis (browser and pick the one you
      want)
    - find a way to express C dependencies (pkg-config, .h files ?)
    - find a way to use syntax extension (Modules: Foo (syntax: camlp4o,
      camlp4.macro), Bar ?)
- if you want to work on external projects:
  - work on a oasis2rpm tools (like oasis2debian)
  - work on a oasis2godi tools (like oasis2debian and ~ GODIVA)
  - work on a oasis-db plugin that get the version of OCaml package
    available in Fedora, Arch Linux, Gentoo (it exists for GODI, Debian)

For communication:
- if you want to improve the designe of the current oasis-db/oasis
  website, I welcome your idea
- I need reviewer for the content of oasis.forge.ocamlcore.org and
  oasis.ocamlcore.org to spot obvious grammatical bugs/bad english
- if you are good at blogging, I need your help to write a series of
  articles how to use oasis in your ocaml project. The best is to tell
  your story about how you apply successfully oasis to your project or
  how it helps you.
      

> I tried to use Oasis on one of my projects. I got stuck at the very
> begining. I am on MacOS, there is no binary installer, and no
> instructions for MacOS users. It told me a bunch of dependencies were
> unsatisfied when I tried to compile. It would be useful to write a
> line or two about how to satisfy all the dependecies, for example:
> 
> "If you are compiling Oasis from source, it is easiest to satisfy all
> the dependencies by installing them via GODI" (if that's even true).
> 
> Even better: provide a binary installer for MacOS.

I created MacPorts for OASIS and its dependencies some time ago, you can 
install them using my Portfile repository at [1], the OASIS port is named 
"caml-oasis".

[1] https://github.com/bmeurer/MacPorts
      

Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00265.html

You can grab my current patch for the new OCaml ARM backend at:

 http://ps.informatik.uni-siegen.de/~meurer/tmp/ocaml-arm-20111213.diff

Compared to the old backend, this one does the following:

- Support for both softfp and VFPv3-D16 (if present).
- Properly supports interworking with Thumb/Thumb-2 code (for both OCaml and 
C code!)
- Supports dynamic linking and large memory models.
- Optional support for position-independent code via -fPIC, disabled by 
default and not required for natdynlink.
- Can emit both ARM and Thumb-2 code (currently Thumb-2 is used for ARMv7+ 
and ARM is used for everything else), with avg. code size savings of 27% for 
Thumb-2 (quite close the optimal 30% advertised by ARM Ltd.). I may also add 
support to emit small functions using Thumb-1 (for pre-ARMv7 / armel) in the 
future to reduce code size.
- Supports both AAPCS (armel) as well as extended VFP calling conventions 
(armhf).
- Properly supports backtraces.
- Recognizes several special ARM instructions (=> reduced code size and 
latency).
- Does not rely on GCC internals, but uses the standard ARM EABI runtime.

Feel free to test the patch, but be aware that it is

(a) highly experimental, it's tested and verified to work with Debian armel 
on ARMv5T and Debian armhf on a Cortex-A8, but YMMV,
(b) it only supports ARMv4T+ using the armel ABI w/o VFPv3, Thumb, etc. or 
ARMv7+ using the armhf ABI w/ VFPv3, Thumb-2, etc., there's no way to choose 
i.e. armel ABI w/ VFPv3, I don't know whether there's anyone except Ubuntu 
using such configurations currently,
(c) incompatible with .cmx/.cmxa/.cmxs files generated by the old ARM 
backend, and
(d) it's still a bit rough around the edges, i.e. the generated code is 
usually better (shorter and runs faster), but there's still room for 
improvement (i.e. instruction selection and scheduling need some more love).

Comments and suggestions are welcome.
      

The port is not in a clean state yet. It's still a bit messy, and I'm going 
to separate various things first (i.e. select FPU / CPU independent of 
platform ABI, for example use VFPv3 with softfp EABI, etc. or use Thumb-2 on 
armel, etc.). I hope to get some more time to work on it during the week. You 
can follow the work at:

http://github.com/bmeurer/ocaml-arm

Testing and feedback is always welcome, of course.

Concerning your proposal to split the patch into multiple smaller patches:

(a) This would probably result in roughly two patches, the first one to fix 
the existing armel port, and the second one to add support for FPUs, armhf 
EABI, Thumb, Thumb-2, etc. (these depend on each other in various ways).
(b) It would be a lot of work for almost no benefit, because it is an almost 
completely new backend and not simply a set of bug fixes for the existing ARM 
backend, and must be treated this way. And even if I'd spend my days 
splitting up the patch, there's still that unresolved OCaml contributions 
issue (i.e. high probability of wasting my time because that patch set will 
just idle in Mantis).
      

I've updated the backend, and a new patch is available for testing at [1], 
you can also test it by cloning the ocaml-arm repository at [2], some 
documentation is available on the Wiki at [3].

The following new features are included:

- Support for both VFPv3-D16 and VFPv3(-D32), using ocamlopt switch -ffpu 
(armhf only).
- Support for architecture selection using -farch.
- Support for profiling using gprof.
- Code cleanups.
- Confirmed to work with Debian/armel on ARM9 / Cortex-A8 and Debian/armhf on 
Cortex-A8.

Testers and feedback welcome.

greets,
Benedikt

[1] 
https://github.com/downloads/bmeurer/ocaml-arm/ocaml-arm-3.12.1+20111218.diff.bz2
[2] https://github.com/bmeurer/ocaml-arm
[3] https://github.com/bmeurer/ocaml-arm/wiki
      

Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00296.html

Recent discussions on how to improve the Ocaml-on-windows situation
are very welcome, but I see a lot of tech-speak and little feeling for
the users, who care just about one thing: to have a click & install
distribution of Ocaml that actually works.

Keep this in mind: 90% of potential Ocaml users are on Windows, and
they never heard of Mingw or Cygwin, and they never used a command
prompt.

It doesn't matter if the distribution is incomplete. It doesn't matter
what is under the hood. It doesn't matter what "the expert" thinks
about it, much less so what Linux people think about it (I am typing
this on a Linux box). Someone just needs to do it, and Jonathan
Protzenko seems an obvious candidate. Jonathan, if you have the time
to modify your distribution so that it become self-contained, i.e., it
contains mingw + ocaml (does _not_ separately install mingw, it just
sticks it under ocaml and then ocaml uses that, independently of
whether there already is a mingw on the system), I am sure that will
be received very positively by many people, even though "the experts"
will spit on it, and will point out that this is not The Right Way,
etc. Just do it.

Once we have such a thing, it can be optimized to our hearts content:
strip down mingw, check if mingw is already there, add support for
flexdll, etc.

The said fact is that I would _love_ to teach Ocaml to my students,
but I can't because installing Ocaml is too hard. Just give me
_anything_ that actually works. Otherwise I will keep teaching
"functional programming" with Mathematica...
      

I would gladly welcome any patch for my ocaml-installer that allows one to
build the self-contained environment you describe. Some people seem to have
volunteered to help out; let them be assured that I will gladly review any
patch they send.

I'm just afraid it's a big task to do so, which is why I haven't tackled this
earlier (I could easily see myself spending the whole week on it).

There's also http://caml.inria.fr/mantis/view.php?id=0005392 that could be
improved with the ocaml installer. Any patches for that are welcome, too.

Just for reference, the project lives on github
https://github.com/protz/ocaml-installer.
      

> Here it is:
>
> http://ocsigen.org/js_of_ocaml/files/toplevel/index.html

Another using the Cadmium (http://cadmium.x9c.fr/):

http://ocamljava.x9c.fr/toplevel/toplevel.html
      

Like Thomas and Fabrice said, I am currently working on a "Try it" web
page. I am using Jérôme Vouillon's toplevel [1] and try to make it more
user friendly with pretty CSS :-)
The main goal is to let new users and beginners to try OCaml without
installing anything and with some exercises/lessons/tutorials.

I have a git repository on [2].

[1] http://ocsigen.org/js_of_ocaml/files/toplevel/index.html
[2] https://github.com/cago/tryocaml
      

Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00361.html

> The mingw port of OCaml was not in a good shape, because of changes in
> Cygwin:
>
>  - We used to rely on the normal Cygwin gcc compiler, using the
>    -mno-cygwin flag. This is no longer available for recent versions
>    of gcc shipped in Cygwin. There is still a gcc-3.exe, but it
>    is not clear whether it will be supported in the future.
>
>  - There are now two modern versions of gcc, available in cygwin,
>    which supports compiling in "mingw" mode (32-bit mode):
>
>      * A packaged version of the compiler from the MinGW.org project:
>        i686-pc-mingw32-gcc.exe
>
>      * A packaged version of the compiler from the mingw-w64 project:
>        i686-w64-mingw32-gcc
>
>
> Future versions of the OCaml mingw port should be based on one of these two
> versions.  I'd be interested to hear if anyone in the community has any
> advice on which one to choose.  Feel free to comment on this list, or on the
> bug tracker:
>
>   http://caml.inria.fr/mantis/view.php?id=5179
>
> Currently, flexdll (version 0.27) and OCaml (SVN trunk version) have been
> adapted to work with the mingw-w64 version (32-bit only, for now), but if
> there are arguments in favor of the other one, it should not be difficult to
> switch (supporting both is not technically difficult, but it might create
> useless confusion).

For what it's worth, the OCaml cross-compiler in debian
(http://packages.debian.org/mingw-ocaml) has been switched to
i686-w64-.. after a request from the guys maintaining mingw in debian
(see: http://bugs.debian.org/624533).
      

Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00363.html

Jonathan Protzenko has started to write down some guidelines how to contribute
most effectively to OCaml. These ideas are being discussed, and should be
published soon.

For a big project like the one you mention (a complete rewrite of OCaml's
build system), it is always a good idea to contact the development team first
with a detailed proposal and wait for some feedback before doing the heavy
work. Contacting the development team can be done either via the bug tracker
or by email (caml AT inria.fr)
      

Old cwn

If you happen to miss a CWN, you can send me a message and I'll mail it to you, or go take a look at the archive or the RSS feed of the archives.

If you also wish to receive it every week by mail, you may subscribe online.

Alan Schmitt