On Sat, 26 Jul 2008 09:46:19 +0100 [EMAIL PROTECTED] 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 (http://home.gna.org/cameleon/) > could also comment on the amount of work and commitment that is > required to build one of these things.
Hello, 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 documentation) Regards, Maxence [1] http://home.gna.org/cameleon/chamo.en.html [2] http://home.gna.org/cameleon/snippets.en.html [3] http://osp.janestcapital.com/files/ocamlwizard.pdf -- Maxence Guesdon http://yquem.inria.fr/~guesdon/ Service Expérimentation et Développements https://devel.inria.fr/rocq/ INRIA Paris-Rocquencourt http://www.inria.fr/rocquencourt/ _______________________________________________ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
