Here's the update from the trenches: I'm about 75% done porting Camelia code to Qt4, the editor-related parts took longer than anticipated since a lot of code had to change due to the arguably better way that Qt4 handles text editing. The code shrinks quite a bit in the process (20% or so, per the line counts), so that's hopefully good ;) The debugging will surely take quite some time.
I'm in the process of getting admin rights to the sourceforge project and setting up an SVN repository for the code.
The upcoming version will be 2.0, and I hope to add some features to it before it's final. I'm sure of Ocamlbuild support. Any other features that people would like?
I'll keep you guys posted, this is obviously a "slightly"* larger project than initially anticipated, but the codebase is OK to work with, and it'll have way more features than anything done from scratch in a weekend would ;)
My plan is to have the final 2.0 release support all OCaml builds out of the box on Windows (MSVC, MinGW and Cygwin), although I will put 3.11.0 as the minimum supported version of OCaml due to debugger and other woes. Linux and OSX will also be supported; Linux-wise I can only test on FC9, but bug reports will be welcome of course.
Cheers, Kuba
* - "slightly" in the log scale, so just one order of magnitude is "not much" ;)
A notion of projects would be nice, which would give the ability to save/load multiple files.
And "slight" thanks for your work, David :)
On Fri, 2008-10-17 at 09:55 -0400, Kuba Ober wrote: > The upcoming version will be 2.0, and I hope to add some features > to it before it's final. I'm sure of Ocamlbuild support. > Any other features that people would like? > * - "slightly" in the log scale, so just one order of magnitude > is "not much" ;)
On 17-10-2008, Kuba Ober <k...@mareimbrium.org> wrote:
> I'm in the process of getting admin rights to the sourceforge > project and setting up an SVN repository for the code.
What about migrating it to forge.ocamlcore.org ?
It seems to be a project 100% related to OCaml, so I think you will get more visibility to the OCaml community being hosted along other OCaml projects ?
Since I am slightly responsible for getting you into this exercise, I volunteer to test the code on Ubuntu 7.04, Intel and AMD64 architectures. Let me know when you want something done.
> In the meantime, is there a public source control with the current version > or a tarball? (I'd just like to take a look at the code, not necessarily > run it).
SVN is in the usual sourceforge.net location. The original 1.1 release from a couple years ago is tagged, and I'm chopping away at it in the trunk.
> A notion of projects would be nice, which would give the ability to > save/load multiple files.
At first, I will add "Save all" to the menu (if not already there), so that all modified documents will be saved with a single action.
As for real project support, there will be a parser/generator for ocamlbuild files, although I have never played with ocamlbuild before so I have to see first how to go about it.
I know that the indenter support will be gone at least for the alpha version, as the indenter needs a revamp -- the QSyntaxHighlighter machinery can be (ab)used to modify the text in-place, and will most likely host all of the indenter. Right now, indenter has a big bunch of regexps and is a bit hard on the eyes. What I will do instead is to tokenize each line and work off the token stream; I expect this will cut the code size a lot.
The syntax highlighter has a notion of state for each line, and the state of preceding line, and is automatically invoked by Qt whenever the lines change. I have to check, but I think it is also invoked when the state of the preceding line changes. So it's fairly easy to work with.
Anyway, the plan is not to drop features, so the final release will have a hopefully nice indenter and whatnot.
Also note that I'm submitting everything to SVN pretty much as I go, and I try to keep the code compileable, so if anyone feels like contributing, let me know. It may be easier to work on it once it all gets to compile, which is still one file away and I will of course brag once it hits the "it compiles and pretends to run" mark.
I'm not sure that parsing ocamlbuild file is the right thing to do. For a simple OCaml project (which would probably mean most Camelia projects), there are no OCamlBuild files at all.
Mmmhhh.... there's .itarget (i.e. a list of files you wish generated after compilation), but that's about it. And, again, most projects don't have any.
On Mon, 2008-10-20 at 09:01 -0400, Kuba Ober wrote: > On Friday 17 October 2008, David Teller wrote: > > A notion of projects would be nice, which would give the ability to > > save/load multiple files.
> At first, I will add "Save all" to the menu (if not already there), so > that all modified documents will be saved with a single action.
> As for real project support, there will be a parser/generator for ocamlbuild > files, although I have never played with ocamlbuild before so I have to see > first how to go about it.
> I'm not sure that parsing ocamlbuild file is the right thing to do. For > a simple OCaml project (which would probably mean most Camelia > projects), there are no OCamlBuild files at all.
> Mmmhhh.... there's .itarget (i.e. a list of files you wish generated > after compilation), but that's about it. And, again, most projects don't > have any.
OK, so I'll focuse on .itarget instead, since that's the thing that the debugger has to cooperate with to decide what executable to run and debug.
>> I'm not sure that parsing ocamlbuild file is the right thing to do. For >> a simple OCaml project (which would probably mean most Camelia >> projects), there are no OCamlBuild files at all.
>> Mmmhhh.... there's .itarget (i.e. a list of files you wish generated >> after compilation), but that's about it. And, again, most projects don't >> have any.
> OK, so I'll focuse on .itarget instead, since that's the thing that the > debugger has to cooperate with to decide what executable to run and debug.
Err... I'm not sure .itarget is what you want. It's close of what you want, sure, but you may have several .itarget for the same project, things like that.
A typical project may have: * some source files (.ml .mli .mly .mll); * several main targets (.byte .native .mllib .mlpack), that may or may not be put together in one or several .itarget; * a documentation (.odocl); * some special rules (_tags myocamlbuild.ml), like some libraries to use; * a configure script. This is not, IMO, easily relatable to the project itself, which is simply a list of files...
Given a list of files, an IDE can guess interesting targets such as: * .docdir/index.html for each .odocl; * .cma .cmxa for each .mllib; * .cmo for each .mlpack. But potentially every file can generate several interesting targets. For instance, from the file x.mlpack, one can generate x.cmo, x.cmx, x.cma, x.cmxa, x.mli, or even x.docdir/index.html.
IMO, simply allowing to view the whole contents of a directory is enough, especially thanks to the fact that ocamlbuild does not pollute your source directory.
> I thought of reading through the code and maybe contributing, but the fact > that it's all in C++ is holding me back a bit. Still, I'm going to take a > look once I have time. > Actually, porting the code to pure OCaml might prove the most interesting > task to me. I wonder what is the state of QT4 bindings, though: you > mentioned they were incomplete or non-nexistant, so is it possible to > overcome this without writing the whole QT4 bindings package? It also might > be a bit early to start porting, but then, if I start now, by the time I'd > have anything basic, you would probably complete most of the features > (considering that I have little practical experience with OCaml and no > experience with QT).
PyQt may be a good thing to look at, but I don't know how easy it would be to port PyQt to OCaml. The only language I found it easy to bind to almost any binary API is Lisp, since it can actually execute nontrivial programs at compilation time.
I guess the starting point would be to look at Qt's C++ API and design an API for Qt in OCaml, and only then try to bridge the gap.
> Kuba Ober a écrit : > >> I'm not sure that parsing ocamlbuild file is the right thing to do. For > >> a simple OCaml project (which would probably mean most Camelia > >> projects), there are no OCamlBuild files at all.
> >> Mmmhhh.... there's .itarget (i.e. a list of files you wish generated > >> after compilation), but that's about it. And, again, most projects don't > >> have any.
> > OK, so I'll focuse on .itarget instead, since that's the thing that the > > debugger has to cooperate with to decide what executable to run and > > debug.
> Err... I'm not sure .itarget is what you want. It's close of what you > want, sure, but you may have several .itarget for the same project, > things like that.
> A typical project may have: > * some source files (.ml .mli .mly .mll); > * several main targets (.byte .native .mllib .mlpack), that may or > may not be put together in one or several .itarget; > * a documentation (.odocl); > * some special rules (_tags myocamlbuild.ml), like some libraries to > use; * a configure script. > This is not, IMO, easily relatable to the project itself, which is > simply a list of files...
> Given a list of files, an IDE can guess interesting targets such as: > * .docdir/index.html for each .odocl; > * .cma .cmxa for each .mllib; > * .cmo for each .mlpack. > But potentially every file can generate several interesting targets. For > instance, from the file x.mlpack, one can generate x.cmo, x.cmx, x.cma, > x.cmxa, x.mli, or even x.docdir/index.html.
> IMO, simply allowing to view the whole contents of a directory is > enough, especially thanks to the fact that ocamlbuild does not pollute > your source directory.
That works for me. In future I can implement functionality similar to Visual Studio's .vcproj files, where you can basically hand-tune the build process, all without leaving the IDE. I have had a go at writing a proof-of-concept stand-alone "executor" or "builder" for .vcproj files, and it's not only doable, but the concept should be easy to duplicate and is relatively user-friendly - certainly better than dealing with Makefiles directly, and better than dealing with qmake's .pro files too.
> That works for me. > In future I can implement functionality similar to Visual Studio's .vcproj > files, where you can basically hand-tune the build process, all without > leaving the IDE. I have had a go at writing a proof-of-concept stand-alone > "executor" or "builder" for .vcproj files, and it's not only doable, but > the concept should be easy to duplicate and is relatively user-friendly - > certainly better than dealing with Makefiles directly, and better than > dealing with qmake's .pro files too.
I do not know .vcproj files, but if you invent some syntax to describe projects, it would be great if you could do it in cooperation with some maintainer of Ocamlbuild. This is the kind of file that could be used by both by an editor and by Ocamlbuild :)
|
