No subject
Tue Nov 10 01:19:43 PST 2009
xen-api at lists.xensource.com mailing list. In the future we plan to move
relevant content such as documentation, designs, roadmaps etc. onto the mai=
n
xen.org wiki.
Comments, criticism and contributions are welcome!
--
The XAPI toolstack team
[1] <http://xen.org>
[2] <http://www.citrix.com/English/ps2/products/feature.asp?contentID=3D168=
6939>
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
2) Ocal IDE: Vote for OcalIDE
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/6b099=
8fcce38e25f#>
------------------------------------------------------------------------
** Hugo Ferreira announced:
If you like OcaIDE, please vote for it to show your support:
<http://marketplace.eclipse.org/node/599>
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
3) compiling C library wrapper
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/5ace8=
ddf0af6701a#>
------------------------------------------------------------------------
** Aaron Bohannon asked and David Allsopp replied:
> I am quite confused by the whole process of compiling and installing
> wrappers for C libraries. It seems like I can get things to work OK
> without really knowing what I'm doing if everything is put and built
> in a single directory. The hard part seems to be putting the right
> files in the right places and getting the path arguments correct.
> Then things stop working, and I have to really understand what's going
> on, but the manual doesn't explain this part of the process in any
> detail.
Have a look at ocamlmklib in the manual - if it's available on your platfor=
m
then it nicely hides away a lot of this.
> Let's say I have a library "/opt/local/lib/libfoo.a" for which I want
> to build and use a (native-code) OCaml wrapper. Here are the steps as
> I understand them:
>
> 1) Write the file "foo_stubs.c" and compile it to get "foo_stubs.o".
>
> 2) Build the library "libfoo_stubs.a" by running
>
> ar rc libfoo_stubs.a foo_stubs.o
>
> 3) Copy "libfoo_stubs.a" to its permanent location, let's say,
> "/usr/local/lib/ocaml/stubs/libfoo_stubs.a".
>
> 4) Write "foo.mli" and use it to build "foo.cmi"
Steps 1-4 are fine.
> 5) Write "foo.ml" and use it to build "foo.cmxa" by running
>
> ocamlopt -a -o foo.cmxa foo.ml
> -ccopt -L/opt/local/lib -cclib -lfoo
> -ccopt -L/usr/local/lib/ocaml/stubs -cclib -lfoo_stubs
This command will also build foo.cmx, foo.a and foo.o
> 6) Copy "foo.cmi" and "foo.cmxa" to their permanent location, let's
> say "/usr/local/lib/ocaml/foo/"
You should also copy foo.a to this directory which should fix the problem.
foo.cmxa contains information required by OCaml but the actual code is in
foo.a (as it's been natively compiled). Similarly, .cmx files contain
information which ocamlopt needs but the actual code is in .o (or .obj)
files. For native code, it's a code idea to copy the .cmx files too as it
allows ocamlopt to do some inlining (I think that's right...)
> 7) Write my file "bar.ml" that needs to use the library, and compile
> it by running
>
> ocamlopt -I /usr/local/lib/ocaml/foo -o bar foo.cmxa bar.ml
This should now work without error.
=09
** Aaron Bohannon then said and Richard Jones replied:
> Ah! Yes, that's exactly the part I didn't understand and everything
> works fine now. Thank you!
>
> I can't say I completely understand the byte-code case, but I don't
> have an urgent need to.
>
> ocamlmklib seems fine, but if it's just a matter of saving keystrokes,
> "make" does a pretty good job of that (as long as I know what to tell
> "make" to do).
For the install step, use 'ocamlfind install'.
Grab the latest source tarball for one of our projects,
eg. libvirt-ocaml, to see how we do it:
<http://libvirt.org/sources/ocaml/>
or: <http://libguestfs.org/download/>
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
4) Camlight version 0.80
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/418b6=
809e94ea8bd#>
------------------------------------------------------------------------
** Fran=E7ois Boisson announced:
Depuis quelque temps je maintiens des paquets camllight pour debian et ubun=
tu.
Ces paquets se trouvent sur
deb <http://boisson.homeip.net/debian> lenny divers
(lenny peut =EAtre remplac=E9 par woody, sarge (version 0.75) ou etch)
deb <http://boisson.homeip.net/ubuntu> karmic divers
karmic peut =EAtre remplac=E9 par breezy, dapper edgy, feisty, gutsy, hardy=
,
intrepid, jaunty.
Ces paquets existent pour les architectures i386 et amd64 et vont des versi=
ons
0.75 =E0 0.80.
La version 0.80 existent pour etch, lenny, hardy, intrepid, jaunty et karmi=
c.
Les sources permettant de faire ces paquets (assez =ABcrades=BB, c'=E9tait =
un de mes
premiers paquets), se trouvent sur
deb-src <http://boisson.homeip.net/source/> ./
Par ailleurs, il y avait un bug dans la librairie graphique entrainant un
segfault sur une architecture 64 bits si on faisait
#open "graphics";;
open_graph "";;
(text_size "CAML");;
cela entrainait une erreur de segmentation..
L'origine =E9tait un transtypage sauvage du =E0 une d=E9calration manquante=
de la
fonction alloc_tuple. J'ai r=E9gl=E9 le probl=E8me et ai fait des paquets c=
orrig=E9s
pour lenny, karmic et hardy. (paquet camllight_0.80-1_amd64.deb).
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
5) MetaOcaml and high-performance
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/1b613=
030e6a9be54#>
------------------------------------------------------------------------
** Jon Harrop said and Oleg replied:
> I did some experiments with MetaOCaml. Firstly, it is x86 only and not x6=
4
> which means poor floating-point performance, many times slower than HLVM'=
s.
> The language itself is also very restrictive, e.g. you cannot generate
> pattern matches dynamically so you cannot leverage the pattern match
> compiler, which is a huge loss. In essence, effective use of MetaOCaml
> requires writing in continuation passing style which OCaml and, therefore=
,
> MetaOCaml do not handle well (closure invocations are slow in OCaml and C=
PS
> is not optimized back into anything sane). So I do not consider MetaOCaml=
to
> be a viable option for performance users.
A few clarifications seems to be in order. First of all, the original
poster asked about _offshoring_ with MetaOCaml. When the generated
code is run with offshoring, a C of Fortran file is created, which can
be compiled with your favorite compiler and dynamically linked back
into the running OCaml program. Alternatively, you can use the
generated C/Fortran code as it is, as a part of a C/Fortran project. We
did exactly the latter in our FFT project: we used MetaOCaml to create C
files for FFT kernels, and plugged the files into the FFTW benchmarking
framework, which is pure C. It worked as expected.
Because offshoring produces a portable C or Fortran code file, you can
use the code on 32 or 64-bit platform. The reason the native MetaOCaml
without offshoring does not work on amd64 is because at that time
OCaml didn't emit PIC code for amd64. So, dynamic linking was
impossible. That problem has long been fixed in later versions of
OCaml. Offshoring is a good way to get around it, thanks Jan Kybic.
Offshoring could just as well produce Verilog or LLVM code. Alas,
we didn't get around to exploring that idea.
Regarding continuation-passing style (CPS): if your code generatOR
needs let-insertion, then the generatOR _may_ need to be encoded in
CPS. The generatED code is _not_ in CPS; it is in the `conventional',
so-called `direct style'. Even if we assume that CPS code is
difficult to compile efficiently (which is not certain: in CPS, all
`important' function calls are tail-calls, and OCaml is very good with
tail-calls), that difficulty affects only the code generator rather
than the generated code. Most of the time it is the generated code
that is performance-critical.
One may say that writing the generator in CPS is a bother. I have
heard such objections. Please see our PEPM2009 paper about a way to
address it
<http://okmij.org/ftp/Computation/Generative.html#circle-shift>
and write generators in the conventional style. Please see the example
of writing a flexible Gaussian Elimination code, paying no penalty for
abstractions.
Fortunately, some people have considered MetaOCaml to be a viable
option for performance users and have reported good results. For
example,
Tuning MetaOCaml Programs for High Performance
Diploma Thesis of Tobias Langhammer.
<http://www.infosun.fmi.uni-passau.de/cl/arbeiten/Langhammer.pdf>
Here is a good quotation from the Introduction:
``This thesis proposes MetaOCaml for enriching the domain of high-performan=
ce
computing by multi-staged programming. MetaOCaml extends the OCaml
language.
...
Benchmarks for all presented implementations confirm that the
execution time can be reduced significantly by high-level
optimizations. Some MetaOCaml programs even run as fast as respective
C implementations. Furthermore, in situations where optimizations in
pure MetaOCaml are limited, computation hotspots can be explicitly or
implicitly exported to C. This combination of high-level and low-level
techniques allows optimizations which cannot be obtained in pure C
without enormous effort.''
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
6) Modules
Archive: <http://groups.google.com/group/fa.caml/browse_thread/thread/a8160=
6be6805729e#>
------------------------------------------------------------------------
** Wouter Swierstra asked and Pierre-Evariste Dagand replied:
> I've been learning OCaml, coming from a Haskell background.
> While I'm familiar with functional programming, I am occasionally puzzled=
by
> errors relating to the module system.
That's normal, everyone does, at some point. Especially when you start
having Parameterized Modules (called Functors in ML) all over the
place.
> I was wondering if there was a
> comprehensive overview/tutorial of OCaml's module system.
For a comprehensive source of information, there is the OCaml manual:
<http://caml.inria.fr/pub/docs/manual-ocaml/manual004.html>
For a tutorial on modules, I would recommend Chapter 14 of "Developing
Applications With Objective Caml":
<http://caml.inria.fr/pub/docs/oreilly-book/html/index.html>
=09
** blue storm then added:
I'd also add :
- the "formal" part of the manual (Part II) description of module
types : <http://caml.inria.fr/pub/docs/manual-ocaml/manual018.html> . In
particular the "Type specifications" section is quite informative
imho.
- the module-related chapter of the "UUU book" :
<http://caml.inria.fr/pub/docs/u3-ocaml/ocaml-modules.html>
If you're interested in theory, you can find an introduction to the ML
Module system theory in the Pierce's book "Advanced topic in Types and
Programming Languages" [1], and a some more advanced papers in the "A
Few Paper On Caml" section of this website :
<http://caml.inria.fr/about/papers.en.html>
[1] <http://books.google.com/books?id=3DA5ic1MPTvVsC&pg=3DPA293&dq=3Dpierce=
+module+ML#v=3Donepage&q=3Dpierce%20module%20ML&f=3Dfalse>
=09
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
7) Other Caml News
------------------------------------------------------------------------
** From the ocamlcore planet blog:
Thanks to Alp Mestan, we now include in the Caml Weekly News the links to t=
he
recent posts from the ocamlcore planet blog at <http://planet.ocamlcore.org=
/>.
Core Gems: Time:
<http://ocaml.janestcapital.com/?q=3Dnode/73>
Reflecting on One-Liners:
<http://alaska-kamtchatka.blogspot.com/2009/11/reflecting-on-one-liners.h=
tml>
Dyn alpha01:
<http://caml.inria.fr/cgi-bin/hump.cgi?contrib=3D714>
Xapi toolstack:
<http://caml.inria.fr/cgi-bin/hump.cgi?contrib=3D713>
The next server, please!:
<http://blog.camlcity.org/blog/ocamlnet3_ha.html>
ocamlbuild-plus:
<http://forge.ocamlcore.org/projects/ocamlbuildplus/>
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Old cwn
------------------------------------------------------------------------
If you happen to miss a CWN, you can send me a message
(alan.schmitt at polytechnique.org) and I'll mail it to you, or go take a look=
at
the archive (<http://alan.petitepomme.net/cwn/>) or the RSS feed of the
archives (<http://alan.petitepomme.net/cwn/cwn.rss>). If you also wish
to receive it every week by mail, you may subscribe online at
<http://lists.idyll.org/listinfo/caml-news-weekly/> .
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
More information about the caml-news-weekly
mailing list