Caml Weekly News Previous week Up Next week

Hello

Here is the latest Caml Weekly News, for the week of 20 to 27 September, 2005.

  1. Ocaml Win64 build?
  2. Unix module API: nonblocking connect's errors retrieving
  3. Ocaml C interface - Usage of custom blocks
  4. Cameleon2 available as alpha
  5. OCamlFuse beta release
  6. ocaml-glpk : LP library
  7. Xcode plugin for OCaml

Ocaml Win64 build?

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30557

Someone asked and Xavier Leroy answered:
[ The question was asked on caml-list a while ago, and I forgot to
reply there, so this is Cc: to caml-list ]

> Do you have any plans to release Ocaml in an x86_64 bit version for Windows?
> Or a 32-bit version that can also generate 64-bit binaries? In fact,
> this would be preferable to having a 64-bit version that cannot
> generate 32-bit binaries.

This is on my "to do" list.  This port will generate 64-bit binaries
only, but of course the 32-bit Windows port will still be there for
those who need to generate 32-bit binaries.

At this point, the main difficulty in this port is to set up a Win64
development machine.  There are no Win64 machines in my vicinity, and
given the way purchase orders work at INRIA, it's unlikely there will
be one before March 2006.

Also, I could use recommendations and experience return about 64-bit
Windows development tools.  What does Microsoft provides, preferably
for free?  (What is needed: a C compiler, a linker, an assembler, and
import libraries for standard Windows DLLs.)  Where is the reference
manual for the assembler syntax?  (As usual, I couldn't find any
complete description in MSDN.)  Any hints on when x86-64
versions of Mingw and Cygwin will be available?

Feel free to reply privately, as this isn't very topical for caml-list.
    

Unix module API: nonblocking connect's errors retrieving

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30559

Vsevolod Fedorov asked and Markus Mottl answered:
> I have the following problem when using Unix module:
> 
> I issuing 'connect' for nonblocked-mode socket.
> This can raise EINPROGRESS error meaning connect is not yet complete.
> Then (as I taught by manuals) I use 'select' method and then 'getsockopt_int
> sock SO_ERROR' to retreive connect results.
> The problem is: 'getsockopt_int' returns 'int' while I need Unix.error type.
> I can't map int to error in good way.

I have also run into this same problem a while ago.

> Of couse, I can use some workarounds (and I had to use one), but they all are
> not look good.
> 
> May be is it the time to extend Unix module API?
> For example, add function like 'getsockopt_error' or 'int_to_error'?

There is already a C-function for handling that case in the
OCaml-runtime (unix_error).  You only need to write a C-wrapper that
converts the arguments to this function appropriately, and define an
"external"-function in OCaml.  Then you can raise the corresponding
Unix_error-exceptions by passing the error code and other arguments
(i.e. name of associated Unix-call and arguments).

But I agree, it would be a very good idea to expose this function in
the standard Unix-module (hint, hint!)...
    

Ocaml C interface - Usage of custom blocks

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30556

Dominik Brugger asked and Lukasz Stafiniak answered:
> Is there a "best practice" for returning C data to OCaml 
> which was allocated by malloc?

My bet is on custom blocks.

> One way to do this is given by the curses library example
> in the OCaml reference manual in section 18.6:
> 
> value curses_initscr(value unit)
> {
>   CAMLparam1 (unit);
>   CAMLreturn ((value) initscr());  /* OK to coerce directly from WINDOW * to
>                               value since that's a block created by malloc() */
> }
> 
> But section 18.2.3 of the manual points out, that it is potentially
> dangerous to free C data, as it might be reclaimed by the OCaml GC.

No. It is dangerous to free C data, because you might still use them
on the OCaml side. GC will not reclaim "malloc pointers".

> So what happens if the data is never explicitly freed? Does the OCaml heap
> space grow until there is no more memory available to the C part of the
> OCaml program?

The data (allocated by malloc) is not on OCaml heap. You have memory
leak on the C side.
 
> In my opinion the only way to avoid these problems is the usage of
> OCaml custom blocks.

My too. The difficulty comes, when the data is also refered by other C
data structures. I've solved it by reference counters, decremented
explicitly on C side and by finalisation on OCaml side.
    
Damien Doligez then said:
Here is the official word from the OCaml team: custom blocks are
the way to go.
    

Cameleon2 available as alpha

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30571

Maxence Guesdon announced:
I'm glad to announce that a lot of development has been done on Cameleon2,
the lablgtk2 port of Cameleon. Well, it is more that a port, since almost
all the code was rewritten.

DBForge was completely rewritten and is not yet fully tested.

Report was rewritten too but remains compatible for binary files, that
is you have to convert your old report files to the new format with:
  report -obin -o foo.rep myfile.tep
  report2.x -ibin -o myfile.rep foo.rep

The Config_file library by Jean-Baptiste Rouquier is used and replace
the Options module.

Topcameleon, the graphical toplevel, is available if you have the compiled
sources of OCaml installed.

OCamlcvs, Configwin, Okey and the documentation browser are only ports to
Lablgtk2.

Zoggy is dead, now we use Glade and lablglade to generate GUI code.

Some utils modules are added.

At last, all Cameleon is based on commands and views as introduced in the
(small) documentation on the web site.

You can have a try, tests and comments are welcome. If you encounter
difficulties, please post on this list so that everybody can follow the
discussions.

The web site is here:
http://home.gna.org/cameleon/

Snapshots are made every night and available here:
http://download.gna.org/cameleon/

A caml-get plugin is available in caml-get:
  http://pauillac.inria.fr/~guesdon/camlget.en.html
It allows the configuration and browsing of your caml-get repositories,
and provides a menu-oriented interface to insert caml-get elements in your
source files.
    

OCamlFuse beta release

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30573

Vincenzo Ciancia announced:
OCamlFuse is an ocaml binding for FUSE (filesystem in userspace) enabling
you to write your own multithreaded, efficient userspace filesystems
using the OCaml programming language.

This release has been updated to the FUSE API version 2.2 (and above),
so it is ready for linux 2.6.14, which is going to include the
kernel-side part of FUSE in the official release.

Two important issues have been fixed:

- the library is correctly multithreaded (a single call cannot
  block the entire filesystem)

- the library does not copy memory buffers in read and write
  operations, thus achieving efficiency close to C.

The OCaml implementation of "fusexmp", the official example performing
a similar function to "mount -bind", is less than 100 lines long
including a simple in-memory extended attributes implementation, and
is I/O bound on my two years old laptop.

You can find more information, download the source code of this
release, check-out code from CVS, subscribe to the development
mailing list etc. at

http://sourceforge.net/projects/ocamlfuse

Fusexmp "looks stable", but testing is needed, as well as help with
installation and distribution and general advice about everything
related to ocamlfuse.

To learn more about FUSE, the great work on which ocamlfuse is based,
please visit

http://fuse.sourceforge.net
    

ocaml-glpk : LP library

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30574

Samuel Mimram announced:
I've made OCaml bindings for the GNU Linear Programming Kit (GLPK) which 
is a library for solving large-scale linear programming, mixed integer 
programming, and other related problems. It's released under the GPL 
(like GLPK itself) and is available here:

http://ocaml-glpk.sourceforge.net/

Comments, patches, etc are of course welcome.
    

Xcode plugin for OCaml

Archive: http://thread.gmane.org/gmane.comp.lang.caml.general/30576

Damien Bobillot announced:
I'm writing a plugin for integrating OCaml in Xcode. At this time,  
it's still a beta version but it now works on simple tasks like :
- syntax coloration
- creation of a native ocaml target, and adding .m files  or .cma  
static libraries to the target
- integration of ocamllex and ocamlyacc
- integration into the Xcode build system, error window...

You may download this plugin at : http://maxao.free.fr/xcode-ocaml-plugin/
    

Using folding to read the cwn in vim 6+

Here is a quick trick to help you read this CWN if you are viewing it using vim (version 6 or greater).

:set foldmethod=expr
:set foldexpr=getline(v:lnum)=~'^=\\{78}$'?'<1':1
zM

If you know of a better way, please let me know.


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