Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
Re: [Caml-list] New Ocaml Plug-in for NetBeans
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2008-08-20 (06:23)
From: Maxence Guesdon <maxence.guesdon@i...>
Subject: Re: [Caml-list] New Ocaml Plug-in for NetBeans
On Sat, 26 Jul 2008 09:46:19 +0100 wrote:

> Jon Harrop wrote:
> > On Wednesday 23 July 2008 09:50:03 adonis28850 wrote:
> >> thanks Hugo, i know there's a Eclipse plug-in, but i would like to get it
> >> on NetBeans,so if someone could help i will thanks!
> >
> > If I might stick my oar in: why don't the OCaml community write an IDE for
> > OCaml in OCaml using Camlp4 for parsing with throwback and LablGTK for the
> > GUI?
> >
> Because writing one that is usable and complete requires a *lot* of
> effort. Maybe the authors of cameleon (
> could also comment on the amount of work and commitment that is
> required to build one of these things.


Indeed it's a lot of work and I wish I had more time to work on it.
Here are some comments about my experience developping Chamo[1].

It's important for me to be able to change the editor/IDE I use without
having to change the build process or the organisation of the source files.
It's kind of easy to force the developper to use some tools and the way to
use them, saying "If you use my wonderful editor, you have to put your code
here, use this tool and not this other, etc.". The hard part is to keep
flexibility and so to foresee what must be customizable by the user. And
this flexibility is required to be able to contribute on projects using
different organisations and build processes.

For this reason, I never developped a "project manager" in Cameleon,
because I did not want to put my includes and other flags (for example) in
a specific file and become "cameleon-dependent" (and so for the possible
contributors). So I keep on writing Makefiles.

(Chamo is part of Cameleon. Cameleon aimed at being an IDE, with
documentation browsing, version control, etc., and using Chamo as
default source code editor)

So my recent efforts were on Chamo, a source code editor, like emacs but
written in ocaml and using ocaml rather than elisp to write configuration
and extensions. Again, the difficulty is to foresee what the user will want
to change because in ocaml a function f cannot be *redefined*: it is
possible to define *another* function f, but functions using the first
definition will continue to use the first definition, not the new one. So
I added "commands" in Chamo, like shell commands. These are only names, and
the user can change the ocaml function associated to these names. This
allows the user to write the ocaml code which calls its favorite tools and
to for example bind this code to the keyboard shortcuts he wants (see
examples at [3]).

The GUI represents a big part of the work, even using an existing source
code editor widget (gtksourceview). There is a lot of information
to keep and display, a lot of things possibly happening. Moreover, as
soon as there is interaction with the user, error handling is required at
every line...

For ocaml-specific aspects:
- Chamo uses .annot files to display type information (Alt-t),
- ocamlbuild is supported,
- errors messages in compilation processes (ocamlbuild, make or any command)
are parsed and the cursor is positionned at the location of the error.

So I already use Chamo for my daily work (development, edition of text
files). What's missing now is access to more information like location of
definitions, completion and so on. I'm waiting for the result of
ocamlwizard[3] to see how to use these tools in Chamo to provide these
missing features.

Since these tools will surely need some information about compilation
flags, there are two solutions:
1. Add a way to indicate these flags to Chamo/Cameleon, but keep this way
flexible so that any user can import them from any other location
(makefile, etc.)
2. Use "dump" files to store the results of these tools and Makefile targets
to produce them (that the way ocamldoc is used in Cameleon for browsing




Maxence Guesdon                 
Service Expérimentation et Développements
INRIA Paris-Rocquencourt