[Caml-list] New Ocaml Plug-in for NetBeans
adonis28850
Im developing a Ocaml Plug-in for NetBeans, it has just started , i get
support for .ml files and a very simple syntax highlighting, if some one is
interested contact with me.thanks
--
View this message in context: http://www.nabble.com/New-Ocaml-Plug-in-for-NetBeans-tp18587175p18587175.html
Sent from the Caml Discuss2 mailing list archive at Nabble.com.
_______________________________________________
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
adonis28850
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!
--
View this message in context: http://www.nabble.com/New-Ocaml-Plug-in-for-NetBeans-tp18587175p18606458.html
Jon Harrop
> 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?
This has long since seemed like an obvious idea to me but everyone continues
to battle on with tools like Emacs and Eclipse that are (IMHO) horrendous.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
Erik de Castro Lopo
> 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?
Most people who actually code in Ocaml do so using the best IDE on
the planet, Unix. For those people an IDE is a step backwards and
hence they have no interest in writing one.
So I have an idea; why don't *you* write a cross platform IDE and if
it really is better than Unix then people would use it.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"It is capitalist America that produced the modern independent woman.
Never in history have women had more freedom of choice in regard to
dress, behavior, career, and sexual orientation."
-- Camille Paglia
Jon Harrop
> Jon Harrop wrote:
> > 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?
>
> Most people who actually code in Ocaml do so using the best IDE on
> the planet, Unix. For those people an IDE is a step backwards and
> hence they have no interest in writing one.
Graphical throwback of documentation is invaluable for interactive API
exploration, particularly in the context of GUI programming (I currently
trawl through ocamlbrowser's useful but very basic interface). A GUI to
browse and visualize performance profiles is useful (I currently browse
gprof's output as plain text files using KWrite). A GUI to visualize
dependencies is useful (I currently lookup the use of "dot" every time I need
it and the PostScript output is typically mangled by GhostScript).
> So I have an idea; why don't *you* write a cross platform IDE and if
> it really is better than Unix then people would use it.
I shall see if it is feasible to develop such an application within an OCaml
Journal article or two. I think it would be both very useful and a very
instructive educational exercise combining several of OCaml's strengths.
However, the resulting program would most likely be difficult to distribute
due to licensing issues (e.g. if you want to reuse OCaml's typechecker or
top-level) and could not be a viable commercial product due to the
limitations of OCaml itself.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
h...@inescporto.pt
> 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!
>
> 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.
> This has long since seemed like an obvious idea to me but everyone continues
> to battle on with tools like Emacs and Eclipse that are (IMHO) horrendous.
>
Hmmm... if I recall correctly you mentioned one of the advantages of
using F# is its IDE (Visual Studio?). In fact code-completion seemed to
be one of the functionalities you pointed out as useful. Well, OcaIDE
has this. And much more. I figure if you believe a full blown IDE for
F# is advantageous, then it should also stand for Eclipse, Netbeans,
or any other IDE.
Mind you, I assume your "horrendous" may also have something to do with
the plug-ins quality. I believe OcalIDE is quite usable at this point in
time. So.. try it out. Join the forum and give you feedback.
BTW, I am harping on this issue because I truly believe that a good IDE
is an excellent medium for promoting the use of Ocaml.
Rgrds,
HF.
h...@inescporto.pt
Jon Harrop wrote:
> On Saturday 26 July 2008 01:24:02 Erik de Castro Lopo wrote:
>> Jon Harrop wrote:
>>> 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?
>> Most people who actually code in Ocaml do so using the best IDE on
>> the planet, Unix. For those people an IDE is a step backwards and
>> hence they have no interest in writing one.
>
I am sceptical of comments such as those of Erik's (no disrespect
intended here). I suspect these people either have not tried using
an IDE or simply haven't made the effort to learn to use the IDE and
take full advantage of it. Which is surprising since mastering Ocaml
requires much effort, and all here seem to agree that the added
productivity of using Ocaml is worth it ;-). In fact mastering
emacs, vi, etc. with all those "modes" also requires a lot of
work. Why should the use of an IDE be any different?
> Graphical throwback of documentation is invaluable for interactive API
> exploration, particularly in the context of GUI programming (I currently
> trawl through ocamlbrowser's useful but very basic interface). A GUI to
> browse and visualize performance profiles is useful (I currently browse
> gprof's output as plain text files using KWrite). A GUI to visualize
> dependencies is useful (I currently lookup the use of "dot" every time I need
> it and the PostScript output is typically mangled by GhostScript).
>
>> So I have an idea; why don't *you* write a cross platform IDE and if
>> it really is better than Unix then people would use it.
>
> I shall see if it is feasible to develop such an application within an OCaml
> Journal article or two. I think it would be both very useful and a very
> instructive educational exercise combining several of OCaml's strengths.
Jon, I would really be interested if you could report back on your
experiences.
>
> However, the resulting program would most likely be difficult to distribute
> due to licensing issues (e.g. if you want to reuse OCaml's typechecker or
> top-level) and could not be a viable commercial product due to the
> limitations of OCaml itself.
>
I am not sure how it was done in OcalIDE but we have full function
signatures (we need only hover above the function). I guess if parsing
is done via another tool this would not be a problem. Could ask
the OcalIDE folks how its done.
Rgrds,
H.F
Richard Jones
> 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?
I'm sure you know why, but because (a) it's a huge amount of work and
(b) the sort of people who can do the work already use emacs so they
don't need it.
It'd be better to concentrate on OCaml for Eclipse (& other IDEs).
OCaml has the parts already to make an excellent Eclipse plugin -- eg.
camlp4, ocamldoc, cmigrep and '-dtypes/.annot'. If Eclipse itself has
specific problems, then fix those.
Red Hat have done a bit of work packaging and fixing the OCaml Eclipse
plugin and we'll have something to release soon(~ish).
Rich.
--
Richard Jones
Red Hat
h...@inescporto.pt
Richard Jones wrote:
> On Sat, Jul 26, 2008 at 12:56:26AM +0100, 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?
>
> I'm sure you know why, but because (a) it's a huge amount of work and
> (b) the sort of people who can do the work already use emacs so they
> don't need it.
>
> It'd be better to concentrate on OCaml for Eclipse (& other IDEs).
> OCaml has the parts already to make an excellent Eclipse plugin -- eg.
> camlp4, ocamldoc, cmigrep and '-dtypes/.annot'. If Eclipse itself has
> specific problems, then fix those.
>
> Red Hat have done a bit of work packaging and fixing the OCaml Eclipse
> plugin and we'll have something to release soon(~ish).
>
Just curious: when you say "fixing" do you mean changing the actual
code? If so, are these contributed back to the community or do I
have to change to Fedora to get them ? 8-).
Thanks,
HF.
> Rich.
Richard Jones
> In fact mastering emacs, vi, etc. with all those "modes" also
> requires a lot of work.
You miss the point that most Unix programmers already know emacs or vi
intimately. I use emacs constantly -- even for writing this very
email, and I have been using emacs for nearly 20 years. No
"mastering" is needed.
I've used IDEs a bit, but never particularly saw the point. They seem
to just obscure the workings of the build process, and break the
editor, for no tangible gain. Emacs can already print the type of an
expression when you hover over it, and can autocomplete symbols. I've
to find an IDE that can edit email.
There are many problems with the Unix build process -- eg. the horrors
of autoconf/automake/libtool, and possibly better integration with
packaging. Lack of an all-in-one graphical tool is not exactly high
on anyone's list.
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Richard Jones
> Just curious: when you say "fixing" do you mean changing the actual
> code? If so, are these contributed back to the community or do I
> have to change to Fedora to get them ? 8-).
Any changes we made are *always* contributed back to the community.
In fact it's a Fedora policy:
http://fedoraproject.org/wiki/PackageMaintainers/WhyUpstream
http://fedoraproject.org/wiki/Objectives
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Erik de Castro Lopo
> I am sceptical of comments such as those of Erik's (no disrespect
> intended here).
No offence taken.
> I suspect these people either have not tried using
> an IDE or simply haven't made the effort to learn to use the IDE and
> take full advantage of it.
As little as a 18 months ago I spend about 6 months maintaining
100k lines of mixed C++ and C# code using Visual Studio 2005,
the IDE all the IDE fans rave about. It found the Visual Studio
experience amazingly underwhelming; beyond tedious. The GUI hid
details from me that I thought I needed to know and got in my
way when I thought it should stay out of it.
More recently I spend a couple of months using the Adobe Flash
GUI development tools. Again I found this a woefully tedious
exercise and wished for command line tools to replace the stupid
and annoying GUI. The GUI thought it knew how I wanted to format
my Actionscript code better than I did.
The funny thing is that my preferences for command line tools was
something I developed after my first exposure to an IDE. My first
serios coding was done on Borland's Turbo Pascal and Turbo C IDEs
back in the late 1980s.
In the late 1990s I did a lot of FPGA development using the Xilinx
development tools. It was the inadequacy of these tools which forced
me back to Make because my Makefile understood the build process
I wanted to achieve better than than the Xilinx tools. Later on
in my FPGA design career I would do schematic entry of FPGA designs,
export a Xilinx XNF netlist, convert the XNY netlist to VHDL using
a utility I wrote and then run that VHDL through a simulator.
This was actually a pivotal event for me because I was able to do
better work by breaking free of the IDE which limited what I could
do.
IDEs still limit what I can do. How many IDEs allow for meta
programming; source code compiling to programs which generate
code which gets compiled to create the final program?
How many IDEs cater for more than one language? The thing is I use
lots of lanaguages. At work I work on a number of projects, some
in C, some in C++ and some in Ocaml. Doing it my way, with Linux
as my IDE, means that apart from the compilers, everything else is
the same. Same editor and same build system (make possibly augmented
with the autotools).
How many people who use multiple languages are willing to learn a
different IDE for each language? Eclipse is not the answer either
because however good it might be for Java its not very good for
other langauges.
> Which is surprising since mastering Ocaml
> requires much effort, and all here seem to agree that the added
> productivity of using Ocaml is worth it ;-).
The same can be said for the Unix IDE, but the UNIX IDE is 100
times more flexible and more capable than any other IDE in
existance. I know Make well enough to whip up a complex make
file in minutes. I am also intimately familair with the automake/
autoconf/libtool set. Since these tools are so flexible they
adapt to my requirements and never force me to work the way they
are designed.
> In fact mastering
> emacs, vi, etc. with all those "modes" also requires a lot of
> work.
I don't like emacs and vi. My editor of choice for the last 13
years has been nedit (Nirvana Editor) which has syntax highlighting
for dozens of languages (and it easy to add new ones or modify
existing ones), regex search/replace and macros. Its configurable
so over the years I have bent it into the shape I want. The same
goes for my Unix shell.
> Why should the use of an IDE be any different?
Unix is my IDE and I am reasonably certain that I can do more
with my IDE than you can do with yours :-). By more, I mean
more languages, more meta programming, more custom build
options with more languages.
I suspect that a lot of the people who think Ocaml needs an IDE
are people whose primay development platform is windows.
Erik
PS : Here's a nickle kid. Go and buy yourself a real computer :-).
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"The earth is degenerating these days. Bribery and corruption abound.
Children no longer mind parents ...and it is evident that the end of
the world is approaching fast." -- Assyrian Tablet Engraved in 2800 B.C.
Jon Harrop
> The same can be said for the Unix IDE, but the UNIX IDE is 100
> times more flexible and more capable than any other IDE in
> existance.
Yet we cannot even get basic documentation about potential completions from
any Unix development environment for OCaml.
> I know Make well enough to whip up a complex make file in minutes.
Yet Make is not expressive enough so we have OMake, OCamlBuild...
> I am also intimately familair with the automake/
> autoconf/libtool set. Since these tools are so flexible they
> adapt to my requirements and never force me to work the way they
> are designed.
That's great but it is the writing of OCaml code that is unnecessarily
cumbersome, not the building of it.
> > In fact mastering
> > emacs, vi, etc. with all those "modes" also requires a lot of
> > work.
>
> I don't like emacs and vi. My editor of choice for the last 13
> years has been nedit (Nirvana Editor) which has syntax highlighting
> for dozens of languages (and it easy to add new ones or modify
> existing ones), regex search/replace and macros. Its configurable
> so over the years I have bent it into the shape I want. The same
> goes for my Unix shell.
I assume nedit does not even have basic type throwback, let alone
documentation throwback?
> I suspect that a lot of the people who think Ocaml needs an IDE
> are people whose primay development platform is windows.
Diversifying to Windows has certainly shown me just how far behind Unix is in
terms of usability, productivity and modern computing environments like GUIs.
Here is an example: programming the GUI Sudoku solvers in OCaml and F# for the
OCaml and F#.NET Journal articles. I had years of experience with OCaml but
little experience of LablGTK2 (I did not know its API at all). I had little
experience with F# and none with Windows Forms. Yet I wrote the F#
implementation 10x faster because the Visual Studio mode makes it trivial to
explore unfamiliar APIs with complete graphical throwback of documentation.
In contrast, developing the OCaml required me to use "grep" to search the
LablGTK2 source code distribution from the command line and ocamlbrowser to
find definitions (but there is no way to jump to related definitions and no
way to jump back to previous definitions). That is unbelievably tedious in
comparison.
Provided you only want to write programs that manipulate text and maybe do
some custom OpenGL, OCaml is awesome. But if you want to write even the most
mundane GUI application, OCaml is a world of pain compared to the
alternatives. This could be solved by a decent graphical development
environment.
Mathematica has by far the best GUI I have ever seen. I think it would be
fantastic to have such an interface available for OCaml but, as I say, the
front-end requires tight bindings to the compiler and top-level which is not
easy with OCaml.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
h...@inescporto.pt
Hope not to take this too much further...
Erik de Castro Lopo wrote:
Ok, I assumed too much then. My apologies.
Two comments though:
a) Don't expect an IDE to provide all of the underlying functionality.
Its just not feasible. I don't expect it.
b) I am *not* saying that IDEs don't have limitations. I am defending
the point of view that a good IDE will *promote* Ocaml's *adoption*
(ease of use for newbies, facilitates giving classes to students,
allows quick prototyping by *non-experts*, etc...)
> IDEs still limit what I can do. How many IDEs allow for meta
> programming; source code compiling to programs which generate
> code which gets compiled to create the final program?
>
You mean create several projects, make a dependency to ensure
they are compiled correctly and in order and then call one of
those compiled applications to generate code? Hmm... I think
just the last part may be missing in the IDE I use.
> How many IDEs cater for more than one language? The thing is I use
> lots of lanaguages. At work I work on a number of projects, some
> in C, some in C++ and some in Ocaml. Doing it my way, with Linux
> as my IDE, means that apart from the compilers, everything else is
> the same. Same editor and same build system (make possibly augmented
> with the autotools).
>
Ok, this is not a rebuttal but... we all know C, C++, Ocaml, Haskell,
Ruby, etc, are supported in Eclipse. Granted support is not
perfect, but you can work quite comfortably.
> How many people who use multiple languages are willing to learn a
> different IDE for each language? Eclipse is not the answer either
> because however good it might be for Java its not very good for
> other langauges.
>
You don't. See above.
>> Which is surprising since mastering Ocaml
>> requires much effort, and all here seem to agree that the added
>> productivity of using Ocaml is worth it ;-).
>
> The same can be said for the Unix IDE, but the UNIX IDE is 100
> times more flexible and more capable than any other IDE in
> existance. I know Make well enough to whip up a complex make
> file in minutes. I am also intimately familair with the automake/
> autoconf/libtool set. Since these tools are so flexible they
> adapt to my requirements and never force me to work the way they
> are designed.
>
What I say here also goes for Richard. I am aware that a lot of time
has gone into learning these tools (20 years!). I am just saying that to
use IDEs also requires effort. Of course whether this is advantageous or
not is up to you. For the newbies, students and even those that hack
as a hobby, I believe it certainly is. This is what I defend.
>> In fact mastering
>> emacs, vi, etc. with all those "modes" also requires a lot of
>> work.
>
> I don't like emacs and vi. My editor of choice for the last 13
> years has been nedit (Nirvana Editor) which has syntax highlighting
> for dozens of languages (and it easy to add new ones or modify
> existing ones), regex search/replace and macros. Its configurable
> so over the years I have bent it into the shape I want. The same
> goes for my Unix shell.
>
Ok. But most IDE editor also offer most (all?) of those capabilities,
correct? Anyway, this is not the issue.
>> Why should the use of an IDE be any different?
>
> Unix is my IDE and I am reasonably certain that I can do more
> with my IDE than you can do with yours :-). By more, I mean
> more languages, more meta programming, more custom build
> options with more languages.
>
Granted. But I am defending lowering the barrier for Ocaml use.
Not for solving every conceivable problem that comes your way.
Remember: use the right tool to solve the problem.
> I suspect that a lot of the people who think Ocaml needs an IDE
> are people whose primay development platform is windows.
>
Ubuntu, before that Gentoo, before that Fedora, before that Red-hat.
Ok so before that windows NT, VMS, windows 98, windows 95,
windows 3.1 (I think), and ms-dos. So yes, I used windows quite a bit
;-).
On a final note: I believe that much of the resistance to use IDEs
also comes the following simple facts:
a) A lot of effort has gone into learning the tools used. No one wants
to throw away all they have invested in that.
b) Use of an IDE may also signify "lock-in".
But please note: I didn't say use only the IDE. That's not possible. We
all know that. Again, I am only defending the idea that IDEs are
excellent to facilitate the use of Ocaml.
Regards,
Hugo
> Erik
>
> PS : Here's a nickle kid. Go and buy yourself a real computer :-).
Erik de Castro Lopo
> On Saturday 26 July 2008 11:03:12 Erik de Castro Lopo wrote:
> > The same can be said for the Unix IDE, but the UNIX IDE is 100
> > times more flexible and more capable than any other IDE in
> > existance.
>
> Yet we cannot even get basic documentation about potential completions from
> any Unix development environment for OCaml.
Completions annoyed me immensely in visual studio and the Adobe's
products.
> > I know Make well enough to whip up a complex make file in minutes.
>
> Yet Make is not expressive enough so we have OMake, OCamlBuild.
I find Make expressive enough. I don't use these others.
> I assume nedit does not even have basic type throwback, let alone
> documentation throwback?
There are ways of getting this to work with nedit but I never
bothered because I don't like it.
If I need documentation I read the mli files. With bash command
line completion in an xterm I can find the one I want in a second
and I keep it open in a nedit window and then alt-tab between the
window I'm editing and the mli file I'm reading. Sometimes I stick
the two side by side.
> Diversifying to Windows has certainly shown me just how far behind Unix is in
> terms of usability, productivity and modern computing environments like GUIs.
You sound like someone who never mastered Unix, someone who never
realised that each user needs to mould Unix to their needs rather
than accepting what Unix provides as a default.
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"PHP is a minor evil perpetrated and created by incompetent amateurs, whereas
Perl is a great and insidious evil perpetrated by skilled but perverted
professionals." -- Jon Ribbens
Richard Jones
> Yet Make is not expressive enough so we have OMake, OCamlBuild...
Make is perfectly expressive enough.
When you start an OCaml project, you certainly need to know a bunch of
stuff to write the autoconf/make framework, and it's not very well
documented. Almost everyone starts from an existing project -- I
suggest starting from here[1]. IDEs let you start a project much more
easily because they write the boilerplate.
Ah but here's the problem: the boilerplate is meaningful, and sooner
or later you'll need to change it (eg. your project has some complex
code generation or you want to script some automated tests). Now your
IDE is getting in the way, your beginner has to face all that "stuff"
which was hidden behind the scenes, and (in one IDE I used) you
couldn't edit the boilerplate at all!
Not to mention serious real world problems like collaborating with
people who don't want to use the IDE, version control, cross-
compiling, applying patches, making tarballs & RPMs, uploading to your
website, feeding patches back upstream, integration with l10n tools,
etc. Most of which are way beyond what IDEs offer.
If you think the good people who develop libvirt could do it using an
IDE, you really don't understand the scope of the problem:
http://git.et.redhat.com/?p=libvirt.git;a=tree
http://git.et.redhat.com/?p=libvirt.git;a=blob;f=configure.in;h=8e04f14131cf68de6eee6eadd05c5704ea8a5d41;hb=HEAD
http://git.et.redhat.com/?p=libvirt.git;a=blob;f=Makefile.am;h=b5082d6a7eaf7c746c3e52d61f6eb952df79db42;hb=HEAD
Rich.
[1] http://hg.et.redhat.com/virt/applications/virt-top--devel click 'manifest'
--
Richard Jones
Red Hat
_______________________________________________
Erik de Castro Lopo
> You mean create several projects, make a dependency to ensure
> they are compiled correctly and in order and then call one of
> those compiled applications to generate code?
Yes, thats the way it would be done in VS. The way I work its
all in what I would consider a single project.
> Hmm... I think
> just the last part may be missing in the IDE I use.
I find this last part quite common for things like ocamllex/
ocamlyacc and Flex/Bison for C or C++.
> Ok, this is not a rebuttal but... we all know C, C++, Ocaml, Haskell,
> Ruby, etc, are supported in Eclipse. Granted support is not
> perfect, but you can work quite comfortably.
Personally I find Eclipse appalling. It takes forever to start
up and runs slow as a dog. It might support Java reasonably well
but I find its support for C rather poor. I haven't tried it
with other laguages.
I didn't mention having tried Eclipse before because I really
only used it for a couple of hours.
> What I say here also goes for Richard. I am aware that a lot of time
> has gone into learning these tools (20 years!). I am just saying that to
> use IDEs also requires effort.
I spent 35+ hours/week for 6 months on VS2005. Is that not enough
time to learn it?
> Ok. But most IDE editor also offer most (all?) of those capabilities,
> correct? Anyway, this is not the issue.
But the Adobe IDE was definitely different to the VS2005 one I
was using a couple of months earlier. What I really wanted was
to be using my editor, with my personalised syntax highlighting
pattern and my macros.
> Granted. But I am defending lowering the barrier for Ocaml use.
If you are advocating IDE use for the purposes of making Ocaml
easier for newcomers then you are in a bit of a bind. The
people who need the IDE are the newcomers who are not capable
of writing one and the ones with sufficient experience to write
an Ocaml IDE are happy with what they have and are therefore
not interested in writing one (with the possible exception of
Jon Harrop).
Erik
--
-----------------------------------------------------------------
Erik de Castro Lopo
-----------------------------------------------------------------
"The X-files is too optimistic. The truth is not out there."
-- Anthony Ord
Romain Beauxis
> > 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?
> However, the resulting program would most likely be difficult to distribute
> due to licensing issues (e.g. if you want to reuse OCaml's typechecker or
> top-level) and could not be a viable commercial product due to the
> limitations of OCaml itself.
It's amazing how you criticize the lack of this or that in the community, but
are reluctant to help it.
I guess the IDE you mentioned at first place would have been a non-commercial
software under some sort of open source license, so why this limitation when
you *may* contribute.. ?
Romain
--
How can a man
Discover a land
That already populated with Indians?
h...@inescporto.pt
Erik de Castro Lopo wrote:
>
>
>> What I say here also goes for Richard. I am aware that a lot of time
>> has gone into learning these tools (20 years!). I am just saying that to
>> use IDEs also requires effort.
>
> I spent 35+ hours/week for 6 months on VS2005. Is that not enough
> time to learn it?
>
I guess it is.
>> Granted. But I am defending lowering the barrier for Ocaml use.
>
> If you are advocating IDE use for the purposes of making Ocaml
> easier for newcomers then you are in a bit of a bind. The
> people who need the IDE are the newcomers who are not capable
> of writing one and the ones with sufficient experience to write
> an Ocaml IDE are happy with what they have and are therefore
> not interested in writing one
Exactly! This is the reason why I sent the e-mail to this list in the
first place. No IDE will be useful unless seasoned users are prepared to
contribute to it.
> (with the possible exception of
> Jon Harrop).
>
Because he also thinks that such IDEs makes his life easier.
I guess if the IDE was written in OCaml he would be an active
contributor. :-)
Jon Harrop
> Jon Harrop wrote:
> > Yet Make is not expressive enough so we have OMake, OCamlBuild.
>
> I find Make expressive enough. I don't use these others.
The others are particularly useful when you have multiple stages of
compilation that introduce new dependencies at compile time.
> > I assume nedit does not even have basic type throwback, let alone
> > documentation throwback?
>
> There are ways of getting this to work with nedit but I never
> bothered because I don't like it.
I find type throwback in Emacs invaluable and I miss documentation throwback
enormously.
> If I need documentation I read the mli files. With bash command
> line completion in an xterm I can find the one I want in a second
> and I keep it open in a nedit window and then alt-tab between the
> window I'm editing and the mli file I'm reading. Sometimes I stick
> the two side by side.
That is exactly what I do when writing OCaml at the moment and I find that it
leaves a lot to be desired.
For example, I cannot even jump to the definition of an identifier reliably. I
can look at the identifier and guess where it came from, potentially having
to manually trawl through directories of source files exactly as you
describe, hoping to find the correct location from many identifiers with the
same name. But it would be much easier if I could simply jump directly to the
location of the definition and then jump back. That could be done from plain
text editors.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
Jon Harrop
> > Ruby, etc, are supported in Eclipse. Granted support is not
> > perfect, but you can work quite comfortably.
>
> Personally I find Eclipse appalling. It takes forever to start
> up and runs slow as a dog.
Agreed. That is precisely why I think it is a bad idea to build upon Eclipse.
However that is not an inherent property of an IDE. Surely one written in
OCaml as I described could be extremely fast?
> It might support Java reasonably well
> but I find its support for C rather poor. I haven't tried it
> with other laguages.
The Scala plugin for Eclipse is also almost unusable. AFAIK, Haskell has
uniformly poor support in this respect as well. F# is the best of the
functional languages but still leaves a lot to be desired, IMHO.
> > What I say here also goes for Richard. I am aware that a lot of time
> > has gone into learning these tools (20 years!). I am just saying that to
> > use IDEs also requires effort.
>
> I spent 35+ hours/week for 6 months on VS2005. Is that not enough
> time to learn it?
Have you used the F# mode in Visual Studio?
> > Ok. But most IDE editor also offer most (all?) of those capabilities,
> > correct? Anyway, this is not the issue.
>
> But the Adobe IDE was definitely different to the VS2005 one I
> was using a couple of months earlier. What I really wanted was
> to be using my editor, with my personalised syntax highlighting
> pattern and my macros.
>
> > Granted. But I am defending lowering the barrier for Ocaml use.
>
> If you are advocating IDE use for the purposes of making Ocaml
> easier for newcomers then you are in a bit of a bind. The
> people who need the IDE are the newcomers who are not capable
> of writing one and the ones with sufficient experience to write
> an Ocaml IDE are happy with what they have and are therefore
> not interested in writing one (with the possible exception of
> Jon Harrop).
Actually, many OCaml programmers gave the F# team positive feedback over their
Visual Studio mode precisely because it makes experienced users so much more
productive.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
Jon Harrop
> Ah but here's the problem: the boilerplate is meaningful, and sooner
> or later you'll need to change it (eg. your project has some complex
> code generation or you want to script some automated tests). Now your
> IDE is getting in the way, your beginner has to face all that "stuff"
> which was hidden behind the scenes, and (in one IDE I used) you
> couldn't edit the boilerplate at all!
Yes. So it would be a good idea to make the IDE as uninvasive as possible.
Presumably it could even interact with findlib in order to let you choose
library dependencies graphically.
> Not to mention serious real world problems like collaborating with
> people who don't want to use the IDE, version control, cross-
> compiling, applying patches, making tarballs & RPMs, uploading to your
> website, feeding patches back upstream, integration with l10n tools,
> etc. Most of which are way beyond what IDEs offer.
Sure. So you continue to do all of those things conventionally. If you really
wanted you could augment an IDE with functionality to upload to your website
etc. but I'm not sure that would be particularly beneficial. My main interest
was better source navigation.
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
adonis28850
hey! this thread its animated!!! i think its possitive to think about
develop an exclusive Ocaml IDE, why??:
- novice people on ocaml will found all easier. -> so more novice people
will be interested in ocamle -> so more ocaml developers become active ->
ocaml community will grow up!
The intention of developing a NeTBeans plug-in is provide pupils of my
univesity a friendlier interface, 2 years ago myself cursed the subject
where ocaml was used, and i found difficult learn a new paradigm,
and if we add to this that in labs teacher say , "ei! you have Caml
installed, start programming!"...
I think this plug-in could be a starting point for future more friendly
interfaces for developing, so why not??
of course at this point, the plug-in its very simple, syntax highlighting,
auto completion of code, and link with external compiler,but...this is only
the beginning....
--
View this message in context: http://www.nabble.com/New-Ocaml-Plug-in-for-NetBeans-tp18587175p18669529.html
Florian Hars
> I've to find an IDE that can edit email.
Be careful what you wish for:
http://eclipsemail.org/wiki/index.php/Welcome_to_Eclipsemail
- Florian
Pal-Kristian Engstad
> I'm sure you know why, but because (a) it's a huge amount of work and
> (b) the sort of people who can do the work already use emacs so they
> don't need it.
>
environment and I must confess that I was quite impressed. It is
actually really neat. Instead of the usual edit, M-x compile, M-x
next-error cycle, the code is compiled in the background creating
"squigglies" under code that has errors. Using this and the
Intelli-sense completion features is very nice and I wish we could have
the equivalent under Emacs. (Of course, though those features still
won't detract me from my everyday daily use of Emacs.) Perhaps some
OCaml/Emacs hackers could work together on a system where emacs and the
ocaml communicates better?
Thanks,
PKE.
--
Pål-Kristian Engstad (eng...@naughtydog.com),
Lead Graphics & Engine Programmer,
Naughty Dog, Inc., 1601 Cloverfield Blvd, 6000 North,
Santa Monica, CA 90404, USA. Ph.: (310) 633-9112.
"Most of us would do well to remember that there is a reason Carmack
is Carmack, and we are not Carmack.",
Jonathan Blow, 2/1/2006, GD Algo Mailing List
Jon Harrop
> Richard Jones wrote:
> > I'm sure you know why, but because (a) it's a huge amount of work and
> > (b) the sort of people who can do the work already use emacs so they
> > don't need it.
>
> Actually, as a regular Emacs hacker myself, I checked out .NET's F#
> environment and I must confess that I was quite impressed. It is
> actually really neat. Instead of the usual edit, M-x compile, M-x
> next-error cycle, the code is compiled in the background creating
> "squigglies" under code that has errors. Using this and the
> Intelli-sense completion features is very nice and I wish we could have
> the equivalent under Emacs. (Of course, though those features still
> won't detract me from my everyday daily use of Emacs.) Perhaps some
> OCaml/Emacs hackers could work together on a system where emacs and the
> ocaml communicates better?
Indeed.
On a related note: what would people recommend as a good OCaml source code
editor under Linux for someone who finds Emacs too archaic and Eclipse too
slow?
Are there any other editors with type throwback (and maybe even error
throwback)?
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
rvanmelle
certainly has some appeal.
One of our developers in particular has invested a lot of time in our
emacs environment and has the same "squigglies" feature that was
described in the F# environment. I believe it is an adaption of "fly-
make" mode for emacs which continually runs the OCAML compiler as
edits are made and highlights both errors and warnings in the code.
It is actually pretty nifty.
I'm not even totally up-to-speed on all the other features that we
have since I am more of a vanilla emacs user.
- Reid
On Jul 28, 1:26 pm, Pal-Kristian Engstad <pal_engs...@naughtydog.com>
wrote:
> Richard Jones wrote:
> > I'm sure you know why, but because (a) it's a huge amount of work and
> > (b) the sort of people who can do the work already use emacs so they
> > don't need it.
>
> Actually, as a regular Emacs hacker myself, I checked out .NET's F#
> environment and I must confess that I was quite impressed. It is
> actually really neat. Instead of the usual edit, M-x compile, M-x
> next-error cycle, the code is compiled in the background creating
> "squigglies" under code that has errors. Using this and the
> Intelli-sense completion features is very nice and I wish we could have
> the equivalent under Emacs. (Of course, though those features still
> won't detract me from my everyday daily use of Emacs.) Perhaps some
> OCaml/Emacs hackers could work together on a system where emacs and the
> ocaml communicates better?
>
> Thanks,
>
> PKE.
>
> --
> Pål-Kristian Engstad (engs...@naughtydog.com),
Damien Doligez
On 2008-07-26, at 17:22, Jon Harrop wrote:
> For example, I cannot even jump to the definition of an identifier
> reliably.
OCaml 3.11 has extended .annot files that will allow external tools
to do that. Also, it tells you which function calls are tail calls
and which are normal calls.
-- Damien
Lukasz Stafiniak
>
> OCaml 3.11 has extended .annot files that will allow external tools
> to do that. Also, it tells you which function calls are tail calls
> and which are normal calls.
>
project participants following this? Would be nice to hear their
progress report :)
Jean-Christophe Filliâtre
> On Tue, Jul 29, 2008 at 4:16 PM, Damien Doligez <damien....@inria.fr> wrote:
>> OCaml 3.11 has extended .annot files that will allow external tools
>> to do that. Also, it tells you which function calls are tail calls
>> and which are normal calls.
>>
> Cool! Are the http://osp.janestcapital.com/files/ocamlwizard.pdf
> project participants following this? Would be nice to hear their
> progress report :)
They tried, indeed (I'm kind of helping in that projet, so I'm aware of
the progress). Unfortunately, even with the CVS version of Ocaml, the
annot files appear to lack some information. But the solution currently
followed by Ocamlwizard is along the lines of .annot files, and may even
rely on these files in future version of Ocaml.
--
Jean-Christophe
Maxence Guesdon
h...@inescporto.pt 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/
Richard Jones
> 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.
You've looked at cmigrep?
http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=560
Rich.
--
Richard Jones
Red Hat
_______________________________________________
Jon Harrop
> 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.
Intellisense-style completion would be incredibly productive, particularly in
the context of GUI programming but note that doing this for LablGTK2 would
require the system to have used type inference and type annotations on the
structurally-typed objects in the source code to determine the type of the
start of an expression in order to propose completions for it.
> 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)
I have found -dtypes to be very slow on large code bases and I assume this is
because it generates such huge dump files. Perhaps this could be optimized
somehow?
> [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
These are really exciting projects... :-)
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/products/?e
_______________________________________________
Maxence Guesdon
Richard Jones <ri...@annexia.org> wrote:
> On Wed, Aug 20, 2008 at 08:29:21AM +0200, Maxence Guesdon wrote:
> > 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.
>
> You've looked at cmigrep?
>
> http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=560
No. I just donwloaded it and indeed it could be used from chamo to provide
some more features in a flexible way.
Thanks !
Maxence
--
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/
_______________________________________________
Maxence Guesdon
Jon Harrop <j...@ffconsultancy.com> wrote:
> On Wednesday 20 August 2008 07:29:21 you wrote:
> > 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.
>
> Intellisense-style completion would be incredibly productive, particularly in
> the context of GUI programming but note that doing this for LablGTK2 would
> require the system to have used type inference and type annotations on the
> structurally-typed objects in the source code to determine the type of the
> start of an expression in order to propose completions for it.
Indeed. By the way, I'm not a big fan of completion, I prefer to use/train
my memory :-)
Maxence
--
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/
_______________________________________________
kirillkh
Sorry for a late reply. This line caught my attention:
- Chamo uses .annot files to display type information (Alt-t),
>
- Can Chamo infer and display type of an arbitrary expression in the source
code?
- Does it work for user-created types (which, supposedly, don't have .annot
files)?
- Is it tolerant to erroneous/incomplete code?
Thanks,
-Kirill
Maxence Guesdon
Chamo uses .annot files produced by the compiler when the -dtypes is
specified. If the expression has a type indicated in the .annot file, than
it is displayed, else no indication is displayed. If the source file has
been modified after the .annot file was created, then a message indicate
that the current .annot file is obsolete and must be updated by compiling
again. This is the same behaviour as under emacs.
Regards,
Nathaniel Gray
> On Saturday 26 July 2008 11:03:12 Erik de Castro Lopo wrote:
>>
>> I don't like emacs and vi. My editor of choice for the last 13
>> years has been nedit (Nirvana Editor) which has syntax highlighting
>> for dozens of languages (and it easy to add new ones or modify
>> existing ones), regex search/replace and macros. Its configurable
>> so over the years I have bent it into the shape I want. The same
>> goes for my Unix shell.
>
> I assume nedit does not even have basic type throwback, let alone
> documentation throwback?
As the guy who implemented one generic form of "throwback" for NEdit,
namely calltips, I can tell you that it certainly does support it and
I've used it extensively. It's an editor that is extremely flexible
without being *too* obscure, so you can get it to do just about
anything you want. I have been unable to find another editor that has
the same combination of power, flexibility, and ease-of-use, and I've
looked far and wide.
Having said that, I'm afraid NEdit development has sunk into a tar
pit. There is no effective leadership on the project and it's
inextricably tied to the Motif toolkit, which means very few new
developers will sign on. I've given up and switched to jEdit, which
has a similar spirit (platform-independent, language-independent,
flexible) but, being written in Java, a much higher bloat factor. But
hey, with 2GB of ram it doesn't feel so bad to give 150MB to my text
editor any more. I would *love* to have an alternative written in
OCaml, since my forays into the jEdit code have left me with
unpleasant feelings...
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
Nathaniel Gray
> On Wednesday 20 August 2008 07:29:21 you wrote:
>
>> 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)
>
> I have found -dtypes to be very slow on large code bases and I assume this is
> because it generates such huge dump files. Perhaps this could be optimized
> somehow?
Definitely. .annot files are incredibly bloated. Here's a snippet
from a .annot file I have on my hard drive:
"""
"ra_live.ml" 342 11092 11107 "ra_live.ml" 342 11092 11117
type(
Ra_type.code_class
)
"ra_live.ml" 343 11121 11139 "ra_live.ml" 343 11121 11147
type(
LiveSet.t
)
"ra_live.ml" 344 11148 11172 "ra_live.ml" 344 11148 11177
type(
Ra_type.label
)
"ra_live.ml" 344 11148 11163 "ra_live.ml" 344 11148 11177
type(
Ra_type.code_class
)
"""
See any opportunities for optimization? ;^)
In fact, gzip does a pretty fine job of optimizing .annot files. The
source file this .annot came from is 15K, the .annot file is 78K, and
gzipping it gets it down to 9K.
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________
Nathaniel Gray
<jonathand...@googlemail.com> wrote:
> On Monday 08 September 2008 00:31:47 Nathaniel Gray wrote:
>> In fact, gzip does a pretty fine job of optimizing .annot files. The
>> source file this .annot came from is 15K, the .annot file is 78K, and
>> gzipping it gets it down to 9K.
>
> token and writing out the mapping first will shrink such files enormously
> whilst still being easily dissected from any language. Moreover, the benefit
> is super-linear...
Sure, I had the same thought, but gzip already exists, doesn't require
approval from INRIA, and .gz is easily read in just about any language
(including OCaml). Once the .annot files are smaller than the source
files I'm completely willing to generate them all the time.
Jon Harrop
> Sure, I had the same thought, but gzip already exists, doesn't require
> approval from INRIA, and .gz is easily read in just about any language
> (including OCaml). Once the .annot files are smaller than the source
> files I'm completely willing to generate them all the time.
I think you will find that GZip is orders of magnitude less efficient that the
approach I suggested and too slow to be useful in this case.
For example, gzipping and unzipping the .annot files from the 4kLOC core of
Smoke takes 0.5s. So GZip is too slow for interactive use even on this tiny
code base.
--
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e
Nathaniel Gray
<jonathand...@googlemail.com> wrote:
> On Tuesday 09 September 2008 06:31:51 you wrote:
>> Sure, I had the same thought, but gzip already exists, doesn't require
>> approval from INRIA, and .gz is easily read in just about any language
>> (including OCaml). Once the .annot files are smaller than the source
>> files I'm completely willing to generate them all the time.
>
> I think you will find that GZip is orders of magnitude less efficient that the
> approach I suggested and too slow to be useful in this case.
>
> For example, gzipping and unzipping the .annot files from the 4kLOC core of
> Smoke takes 0.5s. So GZip is too slow for interactive use even on this tiny
> code base.
Why would you want to unzip more than one .annot file during
interactive use? If I query the type of some token foo in bar.ml I
only need to read from bar.annot.gz, not all the files in the project.
The biggest .annot file I have lying around is from a 40KB source
file. It's about 270KB before gzip, 30KB after. According to "time"
it takes 0.009 seconds to gunzip on my MacBook Pro. I'd say that's
plenty fast enough to be useful, even if your machine isn't quite as
snappy as mine.
I don't dispute that a more efficient encoding than gzip can be found,
but good luck convincing anybody at INRIA to work on it. ;^)
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________