Here is the latest Caml Weekly News, for the week of December 13 to 20, 2011.
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00317.htmlDeep in this thread, Alain Frisch said and Jonathan Protzenko replied:
> 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  so that people can easily install third-party libraries and have them recognized. Cheers, jonathan  https://github.com/protz/ocaml-installer/issues/4
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00332.htmlDeep in this thread, Gabriel Scherer asked and Sylvain Le Gall replied:
> 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.Andrej Bauer said and Benedikt Meurer replied:
> 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 , the OASIS port is named "caml-oasis".  https://github.com/bmeurer/MacPorts
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00265.htmlDeep in this thread, Benedikt Meurer said:
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.Later on, Benedikt Meurer added:
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).Later on, Benedikt Meurer added:
I've updated the backend, and a new patch is available for testing at , you can also test it by cloning the ocaml-arm repository at , some documentation is available on the Wiki at . 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  https://github.com/downloads/bmeurer/ocaml-arm/ocaml-arm-3.12.1+20111218.diff.bz2  https://github.com/bmeurer/ocaml-arm  https://github.com/bmeurer/ocaml-arm/wiki
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00296.htmlAndrej Bauer said:
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...Jonathan Protzenko replied:
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.The thread moved on to talk about trying Ocaml in the browser. Andrej Bauer suggested and Hezekiah M. Carty added:
> 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Çagdas Bozman also replied:
Like Thomas and Fabrice said, I am currently working on a "Try it" web page. I am using Jérôme Vouillon's toplevel  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 .  http://ocsigen.org/js_of_ocaml/files/toplevel/index.html  https://github.com/cago/tryocaml
Archive: https://sympa-roc.inria.fr/wws/arc/caml-list/2011-12/msg00361.htmlAlain Frisch said and Romain Beauxis replied:
> 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.htmlContinuing this huge thread from last week, Alain Frisch said:
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)
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.