[Caml-list] Camelia progress
Kuba Ober
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" ;)
_______________________________________________
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
David Teller
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" ;)
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act
brings liquidations.
Sylvain Le Gall
On 17-10-2008, Kuba Ober <ku...@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 ?
You could then just made a redirection from camelia home webpage to
OCamlCore forge.
Regards,
Sylvain Le Gall
Andrej Bauer
volunteer to test the code on Ubuntu 7.04, Intel and AMD64
architectures. Let me know when you want something done.
Best regards,
Andrej
Kuba Ober
> Hi,
>
> 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.
Browse it at: http://camelia.svn.sourceforge.net/
Checkout:
svn co https://camelia.svn.sourceforge.net/svnroot/camelia camelia
Cheers, Kuba
Kuba Ober
> 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.
Cheers, Kuba
Kuba Ober
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.
Cheers, Kuba
David Teller
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.
Cheers,
David
--
David Teller-Rajchenbach
Security of Distributed Systems
http://www.univ-orleans.fr/lifo/Members/David.Teller
Angry researcher: French Universities need reforms, but the LRU act brings liquidations.
_______________________________________________
Kuba Ober
> 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.
Romain Bardou
>> 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.
--
Romain Bardou
Kuba Ober
> 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
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.
Cheers, Kuba
Romain Bardou
> 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 :)
--
Romain Bardou