What does Jane Street use/want for an IDE? What about you?

What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

I have questions to the kind folks at Jane Street,
and others who use OCaml for commercial/non-research
development: what do you guys use for your development
environment? What would be the minimal set of functionality
that would make you happy for an IDE? What are killer features
you dream of?

I'm trying to come up with a longer time plan for Camelia --
this so far relegated, to the dismay of my wife and daughter
-- to prolonging my morning showers, so I may as well ask
around. None of those plans/feedback would have immediate
effect, but I wouldn't mind it simmering for a bit.

The reason I got into camelia is not only OCaml, but it
seems like a small and manageable enough IDE to base
other tools that I'm working on for various embedded
architectures. In the long run, for Windows platform
I will statically link it and literally have it be
a single executable, so that it can be trivially
shared, it would also make it easier to consume
by people on locked-down computers where software
installations are disallowed. Of course OCaml is another
deal here, but you have to start with something :)

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Mark Shinwell]

On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment?

vim in an xterm for me :)

> What are killer features you dream of?

Something along the lines of Jun Furuse's ocamlspotter work, with good
editor integration, is probably highest on my list at the moment.

Mark

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Thomas Gazagnaire]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

> What are killer features you dream of?

Clearly, the ability to click on a function to go to the place where it is
defined is the only reason why I switched from emacs to Eclipse ... And I
would be very happy to switch to a faster IDE because Eclipse is so slow on
big project.

Thomas

[-- Attachment #2: Type: text/html, Size: 399 bytes --]

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Andres Varon]

On Oct 20, 2008, at 9:37 AM, Mark Shinwell wrote:

> On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
>> I have questions to the kind folks at Jane Street,
>> and others who use OCaml for commercial/non-research
>> development: what do you guys use for your development
>> environment?
>
> vim in an xterm for me :)
>
>> What are killer features you dream of?
>
> Something along the lines of Jun Furuse's ocamlspotter work, with good
> editor integration, is probably highest on my list at the moment.

Being a vim user myself, good editor integration is also very  
important to me. My wish list has only one killer feature: smart  
autocompletion, that would really increase the productivity of new  
programmers and would make it easier to learn new modules.

Andres

>
>
> Mark
>
> _______________________________________________
> 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

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Martin Jambon]

Kuba Ober wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment? What would be the minimal set of functionality
> that would make you happy for an IDE? What are killer features
> you dream of?

I'm working for wink.com (people search engine) and speaking on my own
behalf.

I use 16 (4x4) virtual Fvwm desktops with free mouse movement between
them and a small map of the desktops in the lower-right corner (+
xosview). The majority of the population finds this disturbing, I'm not
really sure why. I hate clicking or typing to switch from a window to
another so I just move my arm in order to place the mouse cursor over
the right window in the right virtual desktop as shown on the map.
That's the feature I was dreaming of until I discovered its existence,
quite a long time ago.

There are no icons or toolbar. A left-click anywhere on the background
displays a menu with the applications I commonly use, and that's enough.

Here are graphical applications I use:
* standard 80x25 xterm for filesystem navigation, commands and remote
logins.
* 80xN emacs
* wider xterm for reading log files with less, grep, etc.
* ocamlbrowser
* web browser
* IM client
* email client

Build tools:
* omake for large OCaml projects (which represents now more than 95% of
my time)
* whatever-works for small or public projects

Compilation:
* from within emacs with tuareg-mode (C-c C-c) or from an (O)Makefile
(C-x C-e)
* middle-click on the error message or warning brings me directly to the
error location (killer feature)
* compiling now always with -dtypes; C-c C-t shows the type under the
cursor (killer feature; requires caml-mode installed if I remember
correctly)

Editor:
* emacs + tuareg-mode for OCaml
* still emacs for any other text format

Testing:
* ocaml toplevel within emacs (C-x C-e to evaluate a phrase in tuareg-mode)
* or ocaml toplevel + xterm + ledit
* programs are run from an xterm
* I'm close to totally ignorant about ocamldebug. Maybe a graphical
interface would help (is there any?).


All of this is the best combination for me because I chose it myself
from the largest choice available. I must say I don't understand the
meaning or the need for the I in IDE. What I use is accessible using a
single monitor, a keyboard and a mouse + a desk + paper and pen.
Technically it is integrated on my desk, I have full control over it, it
is safe, it does what I want and never does what I don't want.

Now I hope someone will react and tell me the benefits of "Integrated"
but so far it looks to me that the close interaction between the build
system, the file system and the text editor is taken care of nicely by
emacs+tuareg-mode.


> I'm trying to come up with a longer time plan for Camelia --
> this so far relegated, to the dismay of my wife and daughter
> -- to prolonging my morning showers, so I may as well ask
> around. None of those plans/feedback would have immediate
> effect, but I wouldn't mind it simmering for a bit.
> 
> The reason I got into camelia is not only OCaml, but it
> seems like a small and manageable enough IDE to base
> other tools that I'm working on for various embedded
> architectures. In the long run, for Windows platform
> I will statically link it and literally have it be
> a single executable, so that it can be trivially
> shared, it would also make it easier to consume
> by people on locked-down computers where software
> installations are disallowed. Of course OCaml is another
> deal here, but you have to start with something :)

I would already be unhappy and underproductive with KDE, so don't even
mention Windows and its single virtual desktop. (How do people manage
20+ windows without using several virtual desktops? I can't because I
need to switch between them all the time)

The great thing about an all-in-one-app solution is that it makes it
possible to get started quickly, which is great for teaching a
programming language to inexperienced students.

For a daily use it seems to me like a source of frustration and waste of
productivity.


Martin

-- 
http://mjambon.com/

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Robert Morelli]

Thomas Gazagnaire wrote:
> > What are killer features you dream of?
>  
> Clearly, the ability to click on a function to go to the place where 
> it is defined is the only reason why I switched from emacs to Eclipse 
> ... And I would be very happy to switch to a faster IDE because 
> Eclipse is so slow on big project.

The emacs tags system didn't work for you?

I'm surprised that's the only thing you found useful in Eclipse, 
considering how primitive Emacs is.

Which brings me to my suggestion ...

Part of the reason Emacs is still so limited after nearly 30 years of 
development is that it is largely based on
emacs lisp, a very poorly designed lisp dialect that makes large scale 
development very difficult and
unreliable. Emacs lisp has all of the flaws that make large scale, 
loosely organized, collaborative development
a disaster. It's in fact rather astonishing how little progress Emacs 
has made over the years and I think it's a
great case study in how dramatic an effect poor up front design choices 
can have on long term development.

Unfortunately, most of the foundational "unix-think" technologies I use 
suffer from the same fatal
flaw: very poor programming language design built on top of very poor 
underlying architecture. That's certainly
the case with Emacs (along with bash, TeX, X, and pretty much every 
other unix technology).

What Emacs lisp does wrong is virtually a checklist of bad programming 
language design. On the
other hand, these are all of the things languages like OCaml do right.

So, my dream would be for someone to build a text editor with the same 
basic philosophy as Emacs,
cloning a good bit of its core functionality, but built on a sound 
architecture, and capable of dealing with
the demands of modern complex software systems, like IDEs. Roughly 
speaking, Emacs built on top of
a "real" language like OCaml, and with the capabilities of modern gui 
systems, networks, work flows,
etc. in mind.

It would of course be a total waste of time to start writing the 5000th 
text editor that goes nowhere. But
I think this would be a very worthwhile project if it is built with the 
goal of overcoming the failures of
Emacs through sound technology, appropriate design, and a mind to 
extensibility. The goal of building a
text editor that could serve as an IDE for OCaml would be a very good 
challenge to keep these goals
tested from an early stage.

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[David Teller]

On Mon, 2008-10-20 at 09:45 -0600, Robert Morelli wrote:
> So, my dream would be for someone to build a text editor with the same 
> basic philosophy as Emacs,
> cloning a good bit of its core functionality, but built on a sound 
> architecture, and capable of dealing with
> the demands of modern complex software systems, like IDEs. Roughly 
> speaking, Emacs built on top of
> a "real" language like OCaml, and with the capabilities of modern gui 
> systems, networks, work flows,
> etc. in mind.

Just for the sake of bibliography, this reminds me of efuns [1] and
Chamo [2].

[1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
[2] http://home.gna.org/cameleon/ 

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. 

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Yitzhak Mandelbaum]

On Oct 20, 2008, at 11:56 AM, David Teller wrote:
>
> Just for the sake of bibliography, this reminds me of efuns [1] and
> Chamo [2].
>
> [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> [2] http://home.gna.org/cameleon/
>
> Cheers,
> David

Does anyone know the status of either of these projects? Are they  
still actively maintained?

Yitzhak

-----------------------------
Yitzhak Mandelbaum

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I have written smart autocompletion based on the toplevel in a mode I call 
SOLID.

  http://www.cc.gatech.edu/~pengzang/tools.html

I've never gotten around to announcing it because it takes time to polish up 
and write good doc... time that I haven't had of late.  However, I have been 
using it myself for a while and a handful of random people have emailed me 
about it and it works with them so, it may work for you.  Now seems as good a 
time as any to tell people about since I've held off for over a year saying 
anything..

Peng

On Monday 20 October 2008 10:33:28 am Andres Varon wrote:
> On Oct 20, 2008, at 9:37 AM, Mark Shinwell wrote:
> > On Mon, Oct 20, 2008 at 09:19:40AM -0400, Kuba Ober wrote:
> >> I have questions to the kind folks at Jane Street,
> >> and others who use OCaml for commercial/non-research
> >> development: what do you guys use for your development
> >> environment?
> >
> > vim in an xterm for me :)
> >
> >> What are killer features you dream of?
> >
> > Something along the lines of Jun Furuse's ocamlspotter work, with good
> > editor integration, is probably highest on my list at the moment.
>
> Being a vim user myself, good editor integration is also very
> important to me. My wish list has only one killer feature: smart
> autocompletion, that would really increase the productivity of new
> programmers and would make it easier to learn new modules.
>
> Andres
>
> > Mark
> >
> > _______________________________________________
> > 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
>
> _______________________________________________
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/OHhfIRcEFL/JewRAitYAKCkwkPaD3A/uf/N6NBM3QyShyz2egCeJsna
fqAFuuuiwCmcdDdGL8ahKG0=
=T7T8
-----END PGP SIGNATURE-----

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> I use 16 (4x4) virtual Fvwm desktops with free mouse movement between
> them and a small map of the desktops in the lower-right corner (+
> xosview). The majority of the population finds this disturbing, I'm not
> really sure why. I hate clicking or typing to switch from a window to
> another so I just move my arm in order to place the mouse cursor over
> the right window in the right virtual desktop as shown on the map.
> That's the feature I was dreaming of until I discovered its existence,
> quite a long time ago.
>
> There are no icons or toolbar. A left-click anywhere on the background
> displays a menu with the applications I commonly use, and that's enough.

I already thought that Camelia and similar apps should provide essentially
two UI modes: the standard, all-exposed "clutterface" typical of most
applications, and a "nakedface" where just as you say there's just the main
window (or two), even without decorations, and nothing more.

Camelia provides panes for debugger and toplevel, so those of course could be
held in a virtual space in the "nakedface" model.

Heck, as far as I can imagine it, it souldn't be that big of a deal to have
the virtual desktops implemented in Camelia itself: depending on which 
direction and how fast the mouse crosses/touches the window edge from
inside, it changes the viewport to a different window.

I had similar mode in mind for a PCB editing application I'm working on, so
I do actually find your ideas appealing and worthwhile. Especially that
it's relatively trivial to implement little goodies like that. I vehemently
hate window decorations on CAD programs: that's why I liked the old
school applications like Protel for DOS, AutoCad, most of the stand-alone CAD
workstations: they displayed things full-screen since screen real estate
was really expensive, and often had single-key shortcuts to swap the screen
with a textmode interface for options, command input etc.

> Build tools:
> * omake for large OCaml projects (which represents now more than 95% of
> my time)

Will check on omake, for sure.

Thanks for the suggestions, keep them coming. I guess I have to think of
"classic" and "naked" interface modes for Camelia, then.

Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Richard Jones]

On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
> What Emacs lisp does wrong is virtually a checklist of bad programming 
> language design. On the
> other hand, these are all of the things languages like OCaml do right.

It'd be interesting to hear[1] what exact features of elisp are
counterproductive for large-scale collaborative programming.

I've not looked very closely at elisp, but assumed the reason that
emacs remains "unconfigurable" for most users is because it's Lisp,
not because of the particular dialect of Lisp.  Most programmers look
at Lisp and run a mile, and I don't think an OCaml editor will fare
much better if that is the case.

FWIW microemacs[2] used a C-like language for configuration and
extension, and this language was almost laughably incapable of doing
the most basic things.  You'd think that a language designed for an
editor would, you know, be able to handle at least strings properly,
but the microemacs programming language couldn't even do that.
Nevertheless at the electronics laboratory where I started out,
electrical engineers (totally unused/untrained as programmers) wrote
huge macros and extensions in this horrible language.

Rich.

[1] Here or in a blog posting ...
[2] http://en.wikipedia.org/wiki/Microemacs

-- 
Richard Jones
Red Hat

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Monday 20 October 2008, you wrote:
> > What are killer features you dream of?
>
> Clearly, the ability to click on a function to go to the place where it is
> defined is the only reason why I switched from emacs to Eclipse

I think that Camelia can do that -- it already fetches type annotations from
OCaml to generate type tooltips for expressions, so probably fetching 
function definition locations is either already possible, or would require
a little bit of extra work. Goes onto my feature wishlist, and I will enter
it into Sourceforge's issue tracker for this project.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> It'd be interesting to hear[1] what exact features of elisp are
> counterproductive for large-scale collaborative programming.
>
> I've not looked very closely at elisp, but assumed the reason that
> emacs remains "unconfigurable" for most users is because it's Lisp,
> not because of the particular dialect of Lisp.  Most programmers look
> at Lisp and run a mile, and I don't think an OCaml editor will fare
> much better if that is the case.
>
> FWIW microemacs[2] used a C-like language for configuration and
> extension, and this language was almost laughably incapable of doing
> the most basic things.  You'd think that a language designed for an
> editor would, you know, be able to handle at least strings properly,
> but the microemacs programming language couldn't even do that.
> Nevertheless at the electronics laboratory where I started out,
> electrical engineers (totally unused/untrained as programmers) wrote
> huge macros and extensions in this horrible language.

I can understand that: Lisp does require wrapping your head around it.

Even its library deals with things and concepts that other languages
simply don't offer. Functions that do symbol interning/generation
or say destructuring-bind will elicit blank stares from most engineering
folk -- folk that otherwise may have no problem generating your everyday
C or Matlab code without even blinking. Lisp deals with programming at
a much more abstract level, IMHO -- you can of course write C-like
code in Lisp, but it just feels unnatural to do so, and rightly so.

While it may sound weird, your regular programming experience applies
only halfway to Lisp. The other, important half, you have to acquire
with use of the language. Switching from C or C++ to say Python is
easy, going to OCaml requires perhaps a book but is quite manageable
too, even Haskell IMHO is easier than Lisp! To learn Lisp the right
way you need basically two and a half books (two by Graham, and a
half of "Practical Common Lisp"), and some midnight oil ;) That's
been the case with me.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Maxence Guesdon]

On Mon, 20 Oct 2008 13:15:52 -0400
Yitzhak Mandelbaum <yitzhakm@CS.Princeton.EDU> wrote:

> On Oct 20, 2008, at 11:56 AM, David Teller wrote:
> >
> > Just for the sake of bibliography, this reminds me of efuns [1] and
> > Chamo [2].
> >
> > [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> > [2] http://home.gna.org/cameleon/
> >
> > Cheers,
> > David
> 
> Does anyone know the status of either of these projects? Are they  
> still actively maintained?

Hello,

I maintain and develop Chamo but I miss time to do more. I use Chamo as
editor for all text files now (including ocaml code of course).

Regards,

-- 
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/

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Robert Morelli]

Richard Jones wrote:
> On Mon, Oct 20, 2008 at 09:45:34AM -0600, Robert Morelli wrote:
>   
>> What Emacs lisp does wrong is virtually a checklist of bad programming 
>> language design. On the
>> other hand, these are all of the things languages like OCaml do right.
>>     
>
> It'd be interesting to hear[1] what exact features of elisp are
> counterproductive for large-scale collaborative programming.
>
> I've not looked very closely at elisp, but assumed the reason that
> emacs remains "unconfigurable" for most users is because it's Lisp,
> not because of the particular dialect of Lisp.  Most programmers look
> at Lisp and run a mile, and I don't think an OCaml editor will fare
> much better if that is the case.
>   

Because of its poor design, I lost the heart to try to program complex 
tasks in Emacs lisp quite
a while ago, so I don't have everything fresh in my mind. Perhaps Peng 
Zang who posted
in this thread about more recent work can comment on his experience. Let 
me point out that
Peng Zang's experience of withholding his code because it wasn't quite 
finished is very typical.
Unfortunately, Emacs lisp code is never really done. It's always in this 
not-sure-this-is-right
state, exactly the kind of murkiness that people who favor languages 
like OCaml hate.
I have done the same thing, withholding code. Ironically, it's probably 
often people with decent
programming standards who withhold their code, with the effect you can 
surely predict.

As far as the problem being a dislike of lisp, no. I'm more of a static 
typing kind of guy, but good
implementations of Scheme are certainly respectable languages. Emacs 
lisp falls far short of that.
For instance, it has no true higher order functions, and makes an 
artificial distinction between function
values and data values. For that matter, it has a somewhat wacky 
smattering of types for its data values,
with a lot of redundant parallel functionality that's always getting in 
the way. It uses dynamic rather
than lexical scoping. Emacs lisp has no structured datatypes like 
records (only lists, arrays, and such),
nor even good conventions for how to simulate them.  Scheme dialects 
generally implement record types
with macros using a familiar pattern.  Speaking of macros, emacs lisp 
uses an unsafe kind of macro in
distinction to Scheme's hygienic macros.  There's also no notion of 
namespace in emacs lisp, nor any
concept of modularization, nor of object.  Emacs lisp conflates 3 
distinct notions into the symbol "nil":
the empty list, the false boolean, and the symbol whose name is "nil." 
Emacs lisp programmers
seem to embrace this confusion with zeal, and this is one of the many 
reasons why it's tedious
to translate Emacs lisp code into a higher quality lisp dialect.

Emacs lisp is closer to Common Lisp than Scheme in appearance. In my 
opinion, Common Lisp is an overly
complex language, a bit like the C++ of the lisp world. The philosophy 
of Scheme, which attempts to
boil down the basic language features to the most fundamental but 
powerful building blocks, is a much
more satisfying approach. But while there's a lot of junk and complexity 
in Common Lisp, there's
also quite a lot of powerful features to compensate. Not even that is 
true of Emacs lisp.

In addition to language deficits like these, the standard libraries of 
built in functions in emacs lisp
are quirky, limited, somewhat haphazardly organized, and buggy. And it 
executes in a single threaded
environment, which doesn't play well with gui and network features.

Etc.

It is my opinion that Emacs is so poorly designed, and the existing base 
of Emacs lisp code is of
such low quality, that continuing to build on top of this foundation is 
doomed to produce the same
low quality of software at the same glacial pace as we've seen over the 
past 3 decades. My hope is
that people will in fact stop writing Emacs lisp and somehow, through 
some magic, a sizable community
can coalesce around a more intelligently designed editor platform. As 
always, the issue is the barrier
to entry in a world that's been dominated by two text editors since 
ancient times.

By the way, this message was written in Emacs, the editor I've been 
using for 25 years.

PS: Almost exactly the same pattern of poor quality and glacially slow 
development has plagued the TeX/LaTeX
world over the past few decades and I believe the issue is the same. If 
anything, the foundations of TeX are
even worse than of Emacs. That's another place where someone with an 
understanding of modern language
design could make an enormous contribution.

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 20 October 2008 07:02:46 pm Robert Morelli wrote:
> Because of its poor design, I lost the heart to try to program complex
> tasks in Emacs lisp quite
> a while ago, so I don't have everything fresh in my mind. Perhaps Peng
> Zang who posted
> in this thread about more recent work can comment on his experience. Let
> me point out that
> Peng Zang's experience of withholding his code because it wasn't quite
> finished is very typical.
> Unfortunately, Emacs lisp code is never really done. It's always in this
> not-sure-this-is-right
> state, exactly the kind of murkiness that people who favor languages
> like OCaml hate.
> I have done the same thing, withholding code. Ironically, it's probably
> often people with decent
> programming standards who withhold their code, with the effect you can
> surely predict.

Let me first say that I've never written anything large in elisp, so take my 
views with a grain of salt.

I think for small extensions (eg. SOLID) elisp is fine.  Certainly it's not 
the best language, but it's better than writing C or Java, more fun than 
python and more straightforward than haskell.  A couple things bother me 
about it which I'll explain in more detail later.  The overall point is that 
elisp as an editor extension language is satisfising.  My reason for not 
announcing my code is that I developed it to scratch my own itch.  Thus, as 
soon as it worked "well enough" I stopped working on it.  I've always meant 
to make it more robust, write down its assumptions and requirements and 
document it for the benefit of the community at large; however, as perhaps 
many of you have experienced, "things come up".  There's always a fire to put 
out, a paper deadline to meet, research to be done, etc...

As to lisp, well, I like the idea of lisp.  This includes dialects from scheme 
to sbcl to elisp.  The main issues that have irked me about elisp are the 
same ones that irk me about common lisp in general, eg. dual namespace (one 
for functions and one for values).  This was a stupid idea and it's 
irritating.  Lack of a good standard library is another complaint that I 
have.  But what can you do?  Elisp is a CL dialect.  Elisp's main 
differenciating aspect is dynamic scoping.  While for general programming I 
think it is a bad idea, for a DSL aimed at extending an editor, I have found 
it to be fantastically useful.  There may be a safer way to do the things 
elisp lets you do.  If there is, I would love it.  Unfortunately though, I 
haven't found an editor that has it.  In the mean time, Emacs remains the #1 
most extensible, configurable, and flexible editor I know.

In summary, elisp is fine for small things... better than many in fact.  I 
might even go out on a limb and say for really small things, it's really 
great.  It's not a great language though, and it has plenty of room for 
improvement.

Peng




> As far as the problem being a dislike of lisp, no. I'm more of a static
> typing kind of guy, but good
> implementations of Scheme are certainly respectable languages. Emacs
> lisp falls far short of that.
> For instance, it has no true higher order functions, and makes an
> artificial distinction between function
> values and data values. For that matter, it has a somewhat wacky
> smattering of types for its data values,
> with a lot of redundant parallel functionality that's always getting in
> the way. It uses dynamic rather
> than lexical scoping. Emacs lisp has no structured datatypes like
> records (only lists, arrays, and such),
> nor even good conventions for how to simulate them.  Scheme dialects
> generally implement record types
> with macros using a familiar pattern.  Speaking of macros, emacs lisp
> uses an unsafe kind of macro in
> distinction to Scheme's hygienic macros.  There's also no notion of
> namespace in emacs lisp, nor any
> concept of modularization, nor of object.  Emacs lisp conflates 3
> distinct notions into the symbol "nil":
> the empty list, the false boolean, and the symbol whose name is "nil."
> Emacs lisp programmers
> seem to embrace this confusion with zeal, and this is one of the many
> reasons why it's tedious
> to translate Emacs lisp code into a higher quality lisp dialect.
>
> Emacs lisp is closer to Common Lisp than Scheme in appearance. In my
> opinion, Common Lisp is an overly
> complex language, a bit like the C++ of the lisp world. The philosophy
> of Scheme, which attempts to
> boil down the basic language features to the most fundamental but
> powerful building blocks, is a much
> more satisfying approach. But while there's a lot of junk and complexity
> in Common Lisp, there's
> also quite a lot of powerful features to compensate. Not even that is
> true of Emacs lisp.
>
> In addition to language deficits like these, the standard libraries of
> built in functions in emacs lisp
> are quirky, limited, somewhat haphazardly organized, and buggy. And it
> executes in a single threaded
> environment, which doesn't play well with gui and network features.
>
> Etc.
>
> It is my opinion that Emacs is so poorly designed, and the existing base
> of Emacs lisp code is of
> such low quality, that continuing to build on top of this foundation is
> doomed to produce the same
> low quality of software at the same glacial pace as we've seen over the
> past 3 decades. My hope is
> that people will in fact stop writing Emacs lisp and somehow, through
> some magic, a sizable community
> can coalesce around a more intelligently designed editor platform. As
> always, the issue is the barrier
> to entry in a world that's been dominated by two text editors since
> ancient times.
>
> By the way, this message was written in Emacs, the editor I've been
> using for 25 years.
>
> PS: Almost exactly the same pattern of poor quality and glacially slow
> development has plagued the TeX/LaTeX
> world over the past few decades and I believe the issue is the same. If
> anything, the foundations of TeX are
> even worse than of Emacs. That's another place where someone with an
> understanding of modern language
> design could make an enormous contribution.
>
>
> _______________________________________________
> 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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/TzdfIRcEFL/JewRAmL7AJ0Q1QkkfGaAlKh2/U6UW5m8qAackwCePLK3
neR4MfWIKfitc8xYnIeQtK4=
=9Jl2
-----END PGP SIGNATURE-----

tags (Was: [Caml-list] What does Jane Street use/want for an IDE? What about you?)

[Florian Hars]

Robert Morelli schrieb:
> The emacs tags system didn't work for you?

There is no way to produce tags files for emacs that does actually work, no?
exuberant-ctags doesn't support caml, otags is still on 3.09 and ocamltags
doesn't understand files in directories...

Am I missing something?

- Florian.

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jean-Marie Gaillourdet]

Hi,

and there is of course Yi[1], although it is written in Haskell.

[1] http://www.haskell.org/haskellwiki/Yi

Regards,
  Jean-Marie

David Teller wrote:
> Just for the sake of bibliography, this reminds me of efuns [1] and
> Chamo [2].
> 
> [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm
> [2] http://home.gna.org/cameleon/ 
> 
> Cheers,
>  David

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Dmitry Bely]

On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <ober.14@osu.edu> wrote:
> I have questions to the kind folks at Jane Street,
> and others who use OCaml for commercial/non-research
> development: what do you guys use for your development
> environment? What would be the minimal set of functionality
> that would make you happy for an IDE? What are killer features
> you dream of?

I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
It's Eclipse plugin so Windows is fully supported (including graphical
debugging). IMHO it's (almost) ready for commercial development. Many
features are very convenient: hyperlink jumps, code outline, type
tooltip on mouse hoovering, completion etc. Give it a try.

- Dmitry Bely

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Hugo Ferreira]

Dmitry Bely wrote:
> On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober <ober.14@osu.edu> wrote:
>> I have questions to the kind folks at Jane Street,
>> and others who use OCaml for commercial/non-research
>> development: what do you guys use for your development
>> environment? What would be the minimal set of functionality
>> that would make you happy for an IDE? What are killer features
>> you dream of?
> 
> I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
> It's Eclipse plugin so Windows is fully supported (including graphical
> debugging). IMHO it's (almost) ready for commercial development. Many
> features are very convenient: hyperlink jumps, code outline, type
> tooltip on mouse hoovering, completion etc. Give it a try.
> 

In other words, Dmitry's short list for Camelia is OcalIDE's feature's 
list ;-)

Seriously, give it a try. It's a good way to see how things could be
done.

Hugo F.

P.S: I am curious as to the distribution regarding IDE/editor use.

> - Dmitry Bely
> 
> _______________________________________________
> 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
> 

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Christian Stork]

(I know it's off-topic, but anyway...)

You should be happy to find out about Yi, an editor written in Haskell:
    
    http://www.haskell.org/haskellwiki/Yi

On Mon, Oct 20, 2008 at 05:02:46PM -0600, Robert Morelli wrote:
...
> PS: Almost exactly the same pattern of poor quality and glacially slow 
> development has plagued the TeX/LaTeX
> world over the past few decades and I believe the issue is the same. If 
> anything, the foundations of TeX are
> even worse than of Emacs. That's another place where someone with an 
> understanding of modern language
> design could make an enormous contribution.

I wholeheartetly agree and think of this each time I use TeX!

-- 
Chris Stork   <>  Support eff.org!  <>   http://www.ics.uci.edu/~cstork/
OpenPGP fingerprint:  B08B 602C C806 C492 D069  021E 41F3 8C8D 50F9 CA2F

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> > I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
> > It's Eclipse plugin so Windows is fully supported (including graphical
> > debugging). IMHO it's (almost) ready for commercial development. Many
> > features are very convenient: hyperlink jumps, code outline, type
> > tooltip on mouse hoovering, completion etc. Give it a try.
>
> In other words, Dmitry's short list for Camelia is OcalIDE's feature's
> list ;-)
>
> Seriously, give it a try. It's a good way to see how things could be
> done.

I will give it a try, prepare a feature list, and ask people to vote on
priorities. I will follow Joel Spolsky's feature selection process. This
will happen no earlier than 30 days from now, as getting Camelia into shape
is my first priority, extra features will come later.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Till Varoquaux]

I am answering as someone who works at jane street but not for jane
street (i.e. this is my personal point of view but I am a Jane street
employee).

First of all thank you for tackling the IDE problem. Anything that's
good for the Ocaml community is, by osmosis, good for companies
working with Ocaml even if it is indirectly.

There is a mix of Emacs,vim,texmate and other esoteric editors being
used here. We are all free to choose what we use but I think a lot of
us decide to cope with a steeper learning curve in order to gain more
flexibility (there's a big difference between hacking as your day job
and coding for a one term class). Dethroning emacs (or vim or ....)
might therefor be a bit of a challenge. That being said a fair amount
of advanced IDE features can be oloaded to external tools (in the
spirit of ocamlwizard). I would really love to see a user friendly IDE
interfacing with such a tool (with the heavy lifting done in an
external tool so that other editors could also benefit cheaply from
advanced features like refactoring).

We tend to work with really large code bases and cannot allow editors
we use to dictate the way we build and/or structure our tree. This
means that emacs/vim are currently closer to our needs than
eclipse/visual studio. This, however, might be very different for
student in an introduction to functional programming class. I thinks
both use cases exists and should be considered (maybe in different
IDE's) you may decide to cater to either or even both. Whatever you do
I know many of us will be following potential outcomes closely.

Till

On Tue, Oct 21, 2008 at 2:35 PM, Kuba Ober <ober.14@osu.edu> wrote:
>> > I really like OcaIDE (http://ocaml.eclipse.ortsa.com:8480/ocaide/).
>> > It's Eclipse plugin so Windows is fully supported (including graphical
>> > debugging). IMHO it's (almost) ready for commercial development. Many
>> > features are very convenient: hyperlink jumps, code outline, type
>> > tooltip on mouse hoovering, completion etc. Give it a try.
>>
>> In other words, Dmitry's short list for Camelia is OcalIDE's feature's
>> list ;-)
>>
>> Seriously, give it a try. It's a good way to see how things could be
>> done.
>
> I will give it a try, prepare a feature list, and ask people to vote on
> priorities. I will follow Joel Spolsky's feature selection process. This
> will happen no earlier than 30 days from now, as getting Camelia into shape
> is my first priority, extra features will come later.
>
> Cheers, Kuba
>
> _______________________________________________
> 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
>

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Philippe Strauss]

Hello,

I'm somewhat ashamed of myself, but I must confess: I'm one of those wimps using texmate! ;-)
I like the long time spent in front of it without my eyes being too tired (mostly due
to the good mac font antialiasing), the set of color scheme, support for ocaml.

What would make me switch: a way to highlight the error when compiling, highlighting
the line, a stronger highlight for the character range reported by the compiler, taking
in consideration the tab mode used (real tab, n spaces) to interpret the value returned
by the compiler.
the error message in an infobulle and a log area.

An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my computer).

An integrated small terminal window.

A mean to prevent you from the obscure error message about the very last char of the
file, that after (for a beginner) 10 minutes of nervous fight you end up discovering in
the first half of your file a missing syntax. I've been told emacs tuareg do that, maybe your
autoindent mode already do it.

Will test camelia 2.0 for sure.
Thanks.

-- 
Philippe Strauss
http://philou.ch

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> What would make me switch: a way to highlight the error when compiling,
> highlighting the line, a stronger highlight for the character range
> reported by the compiler, taking in consideration the tab mode used (real
> tab, n spaces) to interpret the value returned by the compiler.
> the error message in an infobulle and a log area.

That's actually nearly what Camelia has right now. Right now Camelia
insists on not dealing with tabs at all -- it converts them all to
spaces. This "feature" has to go obviously, and it's a few-liner to
convert between characters (which include tabs) and columns.
The editor widget in Qt has a good text document model, and
iteration/selections are implemented via a text cursor class.
It's very easy to have multiple, even overlapping selections -- they
are all handled by the editor code, pretty much transparently.

> An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my
> computer).

OK, I'm adding this to my feature list. I didn't even know ocamlbrowser
existed (never quite made it through the manual, I'm afraid).

> An integrated small terminal window.

It's there.

> A mean to prevent you from the obscure error message about the very last
> char of the file, that after (for a beginner) 10 minutes of nervous fight
> you end up discovering in the first half of your file a missing syntax.
> I've been told emacs tuareg do that, maybe your autoindent mode already do
> it.

I presume you're talking about missing closing elements (parentheses etc.).
Yes, they can be automatically highlighted.

> Will test camelia 2.0 for sure.

I will first release 1.90, which will be an alpha, then a few releases later
we'll have a beta, and then 2.0 ;)

I know for sure now that 1.90 release will be a single executable that can
be run from anywhere, which will make it more convenient to test.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[David Teller]

On Wed, 2008-10-22 at 08:42 -0400, Kuba Ober wrote:
> > An integrated ocamlbrowser (the standard TK tend to jiggle and hang on my
> > computer).
> 
> OK, I'm adding this to my feature list. I didn't even know ocamlbrowser
> existed (never quite made it through the manual, I'm afraid).

For information, we have the beginning of a ocamlbrowser replacement in
Batteries.

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. 

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[David Teller]

Le me be more specific: we're not working on a ocamlbrowser replacement.
We're just working on a on-line help system. In turn, this help system
could be useful for someone wishing to write a ocamlbrowser replacement.

Cheers,
 David

On Wed, 2008-10-22 at 23:56 +0200, David Teller wrote:
> For information, we have the beginning of a ocamlbrowser replacement in
> Batteries.
> 
> 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. 

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Peng Zang]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 21 October 2008 03:31:26 pm Till Varoquaux wrote:
> There is a mix of Emacs,vim,texmate and other esoteric editors being
> used here. We are all free to choose what we use but I think a lot of
> us decide to cope with a steeper learning curve in order to gain more
> flexibility (there's a big difference between hacking as your day job
> and coding for a one term class). Dethroning emacs (or vim or ....)
> might therefor be a bit of a challenge. That being said a fair amount
> of advanced IDE features can be oloaded to external tools (in the
> spirit of ocamlwizard). I would really love to see a user friendly IDE
> interfacing with such a tool (with the heavy lifting done in an
> external tool so that other editors could also benefit cheaply from
> advanced features like refactoring).
>
> We tend to work with really large code bases and cannot allow editors
> we use to dictate the way we build and/or structure our tree. This
> means that emacs/vim are currently closer to our needs than
> eclipse/visual studio. This, however, might be very different for

I agree.  There are many different use cases, different types of developers 
with different goals and styles.  Putting most of the heavy lifting into 
external tools so that can be integrated into any editor would be a great 
boon across the board.

Actually, how did ocamlwizard go?  I seemed to have missed the OSC results.  
The proposal looked promising..

Peng
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)

iD8DBQFI/8OvfIRcEFL/JewRAnFeAJsFLZs4EfEsW4o7VoFY0g1oNQijHgCbBK/Y
BOy2qu3Nomzng5bpJqT27is=
=3Cmt
-----END PGP SIGNATURE-----

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Hugo Ferreira]

Hello,

Kuba Ober wrote:
>> What would make me switch: a way to highlight the error when compiling,
>> highlighting the line, a stronger highlight for the character range
>> reported by the compiler, taking in consideration the tab mode used (real
>> tab, n spaces) to interpret the value returned by the compiler.
>> the error message in an infobulle and a log area.
> 
> That's actually nearly what Camelia has right now. Right now Camelia
> insists on not dealing with tabs at all -- it converts them all to
> spaces. This "feature" has to go obviously, and it's a few-liner to
> convert between characters (which include tabs) and columns.

What do you mean with this? Reason I ask is that in OcalIDE an option to
save files with spaces only, was added because it allows one to 
simultaneously edit files in various editors, each with its own tab
"length". If not, indenting is not maintained. I myself think that
avoiding tabs altogether is a good solution.

Regards,
Hugo F.

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Romain Bardou]

>> That's actually nearly what Camelia has right now. Right now Camelia
>> insists on not dealing with tabs at all -- it converts them all to
>> spaces. This "feature" has to go obviously, and it's a few-liner to
>> convert between characters (which include tabs) and columns.
> 
> What do you mean with this? Reason I ask is that in OcalIDE an option to
> save files with spaces only, was added because it allows one to 
> simultaneously edit files in various editors, each with its own tab
> "length". If not, indenting is not maintained. I myself think that
> avoiding tabs altogether is a good solution.

I agree.

Even without changing your editor, you can change the tab length.

Moreover, if the editor uses tabs and counts them as more than one 
character (default behavior of emacs) it won't be able to locate errors 
correctly.

Finally, when you use backspace to delete one space and suddenly it 
deletes eight of them because it was actually a tab, it's annoying 
because it's unpredictable.

Altogether, this means that if you edit a file and put tabs in it, it 
may work for you, but it may annoy the people you give your file to :p

-- 
Romain Bardou

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Thomas Gazagnaire]

[-- Attachment #1: Type: text/plain, Size: 1853 bytes --]

I would prefer to not have an editor which modify completely the file I am
working on (ie. automatically replace tab by spaces). When working on big
project, you cannot assume that everybody use spaces-based editor, and you
still want to minimize the diff size of your patches.

Thomas

2008/10/23 Romain Bardou <Romain.Bardou@lri.fr>

> That's actually nearly what Camelia has right now. Right now Camelia
>>> insists on not dealing with tabs at all -- it converts them all to
>>> spaces. This "feature" has to go obviously, and it's a few-liner to
>>> convert between characters (which include tabs) and columns.
>>>
>>
>> What do you mean with this? Reason I ask is that in OcalIDE an option to
>> save files with spaces only, was added because it allows one to
>> simultaneously edit files in various editors, each with its own tab
>> "length". If not, indenting is not maintained. I myself think that
>> avoiding tabs altogether is a good solution.
>>
>
> I agree.
>
> Even without changing your editor, you can change the tab length.
>
> Moreover, if the editor uses tabs and counts them as more than one
> character (default behavior of emacs) it won't be able to locate errors
> correctly.
>
> Finally, when you use backspace to delete one space and suddenly it deletes
> eight of them because it was actually a tab, it's annoying because it's
> unpredictable.
>
> Altogether, this means that if you edit a file and put tabs in it, it may
> work for you, but it may annoy the people you give your file to :p
>
> --
> Romain Bardou
>
>
> _______________________________________________
> 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
>

[-- Attachment #2: Type: text/html, Size: 2864 bytes --]

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Hugo Ferreira]

Thomas Gazagnaire wrote:
> I would prefer to not have an editor which modify completely the file I 
> am working on (ie. automatically replace tab by spaces). When working on 
> big project, you cannot assume that everybody use spaces-based editor, 
> and you still want to minimize the diff size of your patches.
>

That is the whole issue. If you work in a big project wherein everyone
can you use their own "tab length", maintaining consistent indentation
is difficult (if not impossible). As Romain Bardou pointed out, you
can even use the same editors with differing "tab length". Real messy.
And the bigger the project and the longer it needs maintenance the worse
it gets.

BTW, I believe all editors are "space based" :-)

HF.

> Thomas
> 
> 2008/10/23 Romain Bardou <Romain.Bardou@lri.fr 
> <mailto:Romain.Bardou@lri.fr>>
> 
>             That's actually nearly what Camelia has right now. Right now
>             Camelia
>             insists on not dealing with tabs at all -- it converts them
>             all to
>             spaces. This "feature" has to go obviously, and it's a
>             few-liner to
>             convert between characters (which include tabs) and columns.
> 
> 
>         What do you mean with this? Reason I ask is that in OcalIDE an
>         option to
>         save files with spaces only, was added because it allows one to
>         simultaneously edit files in various editors, each with its own tab
>         "length". If not, indenting is not maintained. I myself think that
>         avoiding tabs altogether is a good solution.
> 
> 
>     I agree.
> 
>     Even without changing your editor, you can change the tab length.
> 
>     Moreover, if the editor uses tabs and counts them as more than one
>     character (default behavior of emacs) it won't be able to locate
>     errors correctly.
> 
>     Finally, when you use backspace to delete one space and suddenly it
>     deletes eight of them because it was actually a tab, it's annoying
>     because it's unpredictable.
> 
>     Altogether, this means that if you edit a file and put tabs in it,
>     it may work for you, but it may annoy the people you give your file
>     to :p
> 
>     -- 
>     Romain Bardou
> 
> 
>     _______________________________________________
>     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
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> 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

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Vincent Hanquez]

On Thu, Oct 23, 2008 at 12:01:00PM +0100, Hugo Ferreira wrote:
> Thomas Gazagnaire wrote:
>> I would prefer to not have an editor which modify completely the file I 
>> am working on (ie. automatically replace tab by spaces). When working 
>> on big project, you cannot assume that everybody use spaces-based 
>> editor, and you still want to minimize the diff size of your patches.
>>
>
> That is the whole issue. If you work in a big project wherein everyone
> can you use their own "tab length", maintaining consistent indentation
> is difficult (if not impossible). As Romain Bardou pointed out, you
> can even use the same editors with differing "tab length". Real messy.

tab has no length. projects tab-indented (not talking about alignment here),
is the only consistant choice that permit everyone in this same project
to use any *representation* they want for their indentation (8 spaces, 2
spaces, 4 spaces, 11 spaces, ...) without making a mess.

-- 
Vincent

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Romain Bardou]

> tab has no length. projects tab-indented (not talking about alignment here),
> is the only consistant choice that permit everyone in this same project
> to use any *representation* they want for their indentation (8 spaces, 2
> spaces, 4 spaces, 11 spaces, ...) without making a mess.

Sure, this would work if you could force everyone to follow this 
convention AND that your indentations are always a multiple of the same 
number of spaces. Unfortunately, the later does not seem to hold for 
OCaml programs. For instance:

let x = List.map (fun z ->
                     very_long_stuff_blablablablablablablabla)

IMO this is ugly and I try to avoid this indentation style, but it is 
not always easy and it is the behavior of the Tuareg mode (OCaml mode 
for emacs), and I think the vim OCaml mode too.

-- 
Romain Bardou

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Dave Benjamin]

Romain Bardou wrote:
> let x = List.map (fun z ->
>                     very_long_stuff_blablablablablablablabla)

I tend to write this sort of thing as:

let x =
   List.map
     (fun z ->
        very_long_stuff_blablablablablablablabla)
     ...

which, as you may notice, still can't be done with tabs alone due to the 
extra space after the opening parenthesis. I'm curious what you all 
think of this coding style, which seems on one hand to be excessively... 
um, vertical? but it does seem to strike a balance between Tuareg's 
indentation rules and the problem of "running into the margin" too quickly.

BTW, If you keep the function on the first line, it's a bit more 
compact, but the indentation no longer tells the truth about the real 
hierarchy:

let x = List.map
   (fun z ->
      very_long_stuff_blablablablablablablabla)
   ...

This is why I tend to put the function on a line of its own as soon as 
things start to wrap.

Dave

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Wednesday 22 October 2008, you wrote:
> Thanks, I tried it and I love the simplicity vis-a-vis eclipse's
> baroqueness. But am I missing something?
> When I type in a line of caml followed by a CR the cursor lines up all
> the way to the left rather than indenting
> on the next line. Once I'm doing I can hit the indent button and all
> is well but I'm wondering if there is a way to
> get it to indent for me as I go along. (Otherwise the code looks funky
> as I write it.)

This is perhaps a bug in the code. I don't have time nor incentive
to fix the 1.2 code line, which uses Qt3 (and Qt3 portability classes in Qt4),
but it's there in the SVN repository and the world is free to send me patches
;).

I am aware of most of these problems and my primary goal is to eliminate
silliness and follow the principle of least astonishment.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> >> What would make me switch: a way to highlight the error when compiling,
> >> highlighting the line, a stronger highlight for the character range
> >> reported by the compiler, taking in consideration the tab mode used
> >> (real tab, n spaces) to interpret the value returned by the compiler.
> >> the error message in an infobulle and a log area.
> >
> > That's actually nearly what Camelia has right now. Right now Camelia
> > insists on not dealing with tabs at all -- it converts them all to
> > spaces. This "feature" has to go obviously, and it's a few-liner to
> > convert between characters (which include tabs) and columns.
>
> What do you mean with this? Reason I ask is that in OcalIDE an option to
> save files with spaces only, was added because it allows one to
> simultaneously edit files in various editors, each with its own tab
> "length". If not, indenting is not maintained. I myself think that
> avoiding tabs altogether is a good solution.

This is likely to erupt into a flamewar ;) I will leave it to the user to 
choose. I have no preference personally, and this is a matter of taste
and people get religious about it: so no point arguing either way.

I will support space-only mode, mixed space-tab mode, and also different
indent styles between expressions/statements and within them. Basically
whatever emacs/vi does, I will do as well, leaving it to the user to choose.

Depending on time constraints, the full gamut of choices may be relegated
to 2.1, but I have it all on my mind.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Thursday 23 October 2008, Vincent Hanquez wrote:
> On Thu, Oct 23, 2008 at 12:01:00PM +0100, Hugo Ferreira wrote:
> > Thomas Gazagnaire wrote:
> >> I would prefer to not have an editor which modify completely the file I
> >> am working on (ie. automatically replace tab by spaces). When working
> >> on big project, you cannot assume that everybody use spaces-based
> >> editor, and you still want to minimize the diff size of your patches.
> >
> > That is the whole issue. If you work in a big project wherein everyone
> > can you use their own "tab length", maintaining consistent indentation
> > is difficult (if not impossible). As Romain Bardou pointed out, you
> > can even use the same editors with differing "tab length". Real messy.
>
> tab has no length. projects tab-indented (not talking about alignment
> here), is the only consistant choice that permit everyone in this same
> project to use any *representation* they want for their indentation (8
> spaces, 2 spaces, 4 spaces, 11 spaces, ...) without making a mess.

Exactly, and that's why indentation in-between statements/expressions
can use tabs with arbitrary length, but indentation within statements/
expressions (split between lines) has to copy previous line's indentation
up to the starting column, and then use solely spaces. Same goes for 
indentation of comments that follow a non-blank line (can only use spaces).
There are several orthogonal issues here, all are well known, so please let's
not prolong this thread ;)

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[DooMeeR]

Another possibility is:

let x = List.map begin fun z ->
  very_blabla
end my_list in

It's quite compact, doesn't run into the margin, is consistent with 
tuareg, but might be less readable.

-- 
Romain Bardou

Dave Benjamin a écrit :
> Romain Bardou wrote:
>> let x = List.map (fun z ->
>>                     very_long_stuff_blablablablablablablabla)
>
> I tend to write this sort of thing as:
>
> let x =
>   List.map
>     (fun z ->
>        very_long_stuff_blablablablablablablabla)
>     ...
>
> which, as you may notice, still can't be done with tabs alone due to 
> the extra space after the opening parenthesis. I'm curious what you 
> all think of this coding style, which seems on one hand to be 
> excessively... um, vertical? but it does seem to strike a balance 
> between Tuareg's indentation rules and the problem of "running into 
> the margin" too quickly.
>
> BTW, If you keep the function on the first line, it's a bit more 
> compact, but the indentation no longer tells the truth about the real 
> hierarchy:
>
> let x = List.map
>   (fun z ->
>      very_long_stuff_blablablablablablablabla)
>   ...
>
> This is why I tend to put the function on a line of its own as soon as 
> things start to wrap.
>
> Dave
>
> _______________________________________________
> 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

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jacques Garrigue]

Using labels makes this kind of code more readable.

  open StdLabels

  let x = List.map my_list ~f:
    begin fun z ->
      very_blabla
    end in
  ...

Jacques Garrigue

From: DooMeeR <d@doomeer.com>

> Another possibility is:
> 
> let x = List.map begin fun z ->
>   very_blabla
> end my_list in
> 
> It's quite compact, doesn't run into the margin, is consistent with 
> tuareg, but might be less readable.
> 
> -- 
> Romain Bardou
> 
> Dave Benjamin a écrit :
> > Romain Bardou wrote:
> >> let x = List.map (fun z ->
> >>                     very_long_stuff_blablablablablablablabla)
> >
> > I tend to write this sort of thing as:
> >
> > let x =
> >   List.map
> >     (fun z ->
> >        very_long_stuff_blablablablablablablabla)
> >     ...
> >
> > which, as you may notice, still can't be done with tabs alone due to 
> > the extra space after the opening parenthesis. I'm curious what you 
> > all think of this coding style, which seems on one hand to be 
> > excessively... um, vertical? but it does seem to strike a balance 
> > between Tuareg's indentation rules and the problem of "running into 
> > the margin" too quickly.
> >
> > BTW, If you keep the function on the first line, it's a bit more 
> > compact, but the indentation no longer tells the truth about the real 
> > hierarchy:
> >
> > let x = List.map
> >   (fun z ->
> >      very_long_stuff_blablablablablablablabla)
> >   ...
> >
> > This is why I tend to put the function on a line of its own as soon as 
> > things start to wrap.
> >
> > Dave
> >
> > _______________________________________________
> > 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
> 
> _______________________________________________
> 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

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Martin Jambon]

DooMeeR wrote:
> Another possibility is:
> 
> let x = List.map begin fun z ->
>  very_blabla
> end my_list in
> 
> It's quite compact, doesn't run into the margin, is consistent with
> tuareg, but might be less readable.

Now I generally tend to use this:

let x =
  List.map (
    fun z ->
      very_blabla
      ...
  ) my_list
in
...

I find that the most significant barrier is of psychological nature.
This formatting of parentheses is unnatural in natural languages and in
mathematics.

Other than that, it's no different from curly braces as used in the
C-like syntaxes.

The additional 2 or 3 lines are generally negligible and introduce some
vertical spacing which improves readability.


Martin

-- 
http://mjambon.com/

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Daniel Bünzli]

Le 25 oct. 08 à 14:43, Martin Jambon a écrit :

> Now I generally tend to use this:
>
> let x =
>  List.map (
>    fun z ->
>      very_blabla
>      ...
>  ) my_list
> in

I think the best solution is to name your anonymous function, as the  
guidelines suggest [1].

Regards,

Daniel

[1]
http://caml.inria.fr/resources/doc/guides/guidelines.en.html
search for "Naming anonymous functions"

Indentation (was Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?)

[Martin Jambon]

Daniel Bünzli wrote:
> 
> Le 25 oct. 08 à 14:43, Martin Jambon a écrit :
> 
>> Now I generally tend to use this:
>>
>> let x =
>>  List.map (
>>    fun z ->
>>      very_blabla
>>      ...
>>  ) my_list
>> in
> 
> I think the best solution is to name your anonymous function, as the
> guidelines suggest [1].

It says: "Justification: Much clearer, in particular if the name given
to the function is meaningful."

I think that's true for typical functional code which follows some clear
logic or model.

In many cases it's not possible to give a meaningful name to such a
function and defining it out of the current block can make things
needlessly hard to follow.

I can think of 4 cases:

1. anonymous function that fits on one line
2. anonymous function that doesn't fit on one line (my original example)
3. named function defined locally using let-in
4. named function defined globally using let

I don't use (3) very much since:
* it still causes the outermost function definition to be very long and
hard to follow like (2),
* and it's okay to define a function globally (4) because there is no
serious risk of global namespace pollution, thanks to the module system.

I think (3) is most useful for defining named functions that depend on a
lot of locally-defined values. This creates a closure, which is often
acceptable performance-wise, instead of having to make each parameter of
the function explicit.

In performance-critical code or maybe imperative code in general, it
feels good to control when closures are created. In such cases, avoiding
local functions helps.


Martin

-- 
http://mjambon.com/

Re: Indentation (was Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?)

[Daniel Bünzli]

Le 26 oct. 08 à 01:08, Martin Jambon a écrit :

> In performance-critical code or maybe imperative code in general, it
> feels good to control when closures are created. In such cases,  
> avoiding
> local functions helps.

Just to be clear, naming your anonymous function locally (which is  
what is recommended) or not naming it doesn't make any performance  
difference AFAIK.

Daniel

Re: Indentation (was Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?)

[Martin Jambon]

Daniel Bünzli wrote:
> 
> Le 26 oct. 08 à 01:08, Martin Jambon a écrit :
> 
>> In performance-critical code or maybe imperative code in general, it
>> feels good to control when closures are created. In such cases, avoiding
>> local functions helps.
> 
> Just to be clear, naming your anonymous function locally (which is what
> is recommended) or not naming it doesn't make any performance difference
> AFAIK.

What I mean is that:


let f x y = x + y

let g x l =
  List.map (f x) l


is clearer than:


let g x l =
  let f y = x + y in
  List.map f l


in the sense that it is obvious that a closure is created in the first
case, while it is less visible in the second case.



Martin

-- 
http://mjambon.com/

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Monday 20 October 2008 14:19:40 Kuba Ober wrote:
> what do you guys use for your development environment?

I use Emacs but I hate it.

> What would be the minimal set of functionality that would make you happy for
> an IDE?

. Written in OCaml using OCaml's own lexer and parser to save effort and make 
it possible for others to help develop it without losing their hair.

. A proper GUI (where options can be set using the mouse).

. Mainstream key bindings, e.g. CTRL+S for save.

. Jump to definition.

. Graphical throwback of the type of the subexpression under the mouse pointer 
or in the current selection.

. Graphical throwback of the documentation related to what is under the mouse 
pointer.

. Graphical throwback of errors and, in the case of type errors, optional 
highlighting of previous unification points.

. Refactoring, e.g. changing the name of a definition in all occurrences.

. Autocompletion that handles structural types in LablGTK code and operators, 
i.e. when the user types "+" present options for int "+", float "+.", 
num "+/" and any other operators that begin with "+".

. Represent an OCaml project as a tree of modules that happen to have the 
first level stored as files.

. Performant enough to handle projects with hundreds of thousands of lines of 
code.

. Parallel so seven of my cores aren't idle while I'm waiting.

. The ability to hide the tail of +., +/ etc. operators to make numerical code 
more readable.

> What are killer features you dream of?

Only one: an interactive top-level where output is presented via graphical 
elements (e.g. a scene graph) and is no longer limited to just ASCII text. 
This would give OCaml the graphical capabilities of Mathematica's 
awesome "notebook" front-end.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Friday 31 October 2008, Jon Harrop wrote:
> On Monday 20 October 2008 14:19:40 Kuba Ober wrote:
> > what do you guys use for your development environment?
>
> I use Emacs but I hate it.
:)

> > What would be the minimal set of functionality that would make you happy
> > for an IDE?
>
> . Written in OCaml using OCaml's own lexer and parser to save effort and
> make it possible for others to help develop it without losing their hair.

That's perhaps possible in the longer run by linking some OCaml code in.
Right now Camelia has its own parser. I could port Camelia to OCaml if someone
would first develop Qt bindings for OCaml that would allow me to do in
OCaml what I'm doing in C++ so far ;)

That's an undertaking bigger than Camelia itself. I will not develop for
gtk-anything as lost feature parity with Qt right around the time when Qt 3
came around, IIRC. Qt 4 is leaps and bounds above anything gtk provides, in
terms of integrated functionality. This is not meant as a flamebait, I believe
it to be an accurate statement of fact. I wish I could use gtk since
it's easier to bind with, but I'd end up having to either reimplement parts of
Qt, or have to deal with lots of 3rd party libraries, each from a different
author who had a different API design mindset. Qt takes care of those
integration issues internally and provides a relatively self-consistent API
-- this saves a metric crapton of time (I use the darn thing).

> . A proper GUI (where options can be set using the mouse).

Check ;)

> . Mainstream key bindings, e.g. CTRL+S for save.

Check ;)

> . Jump to definition.

Easy to do -- goes on my to-do list.

> . Graphical throwback of the type of the subexpression under the mouse
> pointer or in the current selection.

Camelia does that.

> . Graphical throwback of the documentation related to what is under the
> mouse pointer.

Easy to do -- goes on my to-do list.

> . Graphical throwback of errors and, in the case of type errors, optional
> highlighting of previous unification points.

Camelia does that.

> . Refactoring, e.g. changing the name of a definition in all occurrences.

Perhaps in version 2.2 ;)

> . Autocompletion that handles structural types in LablGTK code and
> operators, i.e. when the user types "+" present options for int "+", float
> "+.", num "+/" and any other operators that begin with "+".

Version 2.2 ;)

> . Represent an OCaml project as a tree of modules that happen to have the
> first level stored as files.

Level 1 is easy to do, but what's on the second and deeper levels in your 
idea?

> . Performant enough to handle projects with hundreds of thousands of lines
> of code.

Shouldn't be a problem, perhaps as long as you don't put all the lines in one
file ;)

In the long run I may switch to using QCodeEdit from edyuk, which is 
supposedly better performing than QPlainTextEdit. This is just hearsay, and
anyway before I can switch editors I have to refactor a lot of code to move
OCaml-specific functionality out of the editor widget itself. Since I have
to do this refactoring whether I switch editors or not, just to make the
code saner, the editor change decision can wait without undue consequences
(or so I think).

> . Parallel so seven of my cores aren't idle while I'm waiting.

Everything is done in one thread right now, but over time it can be spread
out. Implementing this properly requires refectoring of the code first:
right now Camelia is in no shape to attempt that. After 2.0 release there will
be time to attack that.

> . The ability to hide the tail of +., +/ etc. operators to make numerical
> code more readable.

Easy to do, can go in for 2.0.

> > What are killer features you dream of?
>
> Only one: an interactive top-level where output is presented via graphical
> elements (e.g. a scene graph) and is no longer limited to just ASCII text.
> This would give OCaml the graphical capabilities of Mathematica's
> awesome "notebook" front-end.

How would you like that to work? Do you think about something like ddd, or
a different approach?

Processing toplevel output is an issue nicely orthogonal to editor and
knowledgebase, so this doesn't block on the major refactoring that has
to happen on the editor end.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> On Friday 31 October 2008, Jon Harrop wrote:
> > . Written in OCaml using OCaml's own lexer and parser to save effort and
> > make it possible for others to help develop it without losing their hair.
>
> That's perhaps possible in the longer run by linking some OCaml code in.
> Right now Camelia has its own parser.

You reimplemented the whole OCaml parser in C++? Does it handle Camlp4 syntax 
extensions?

> I could port Camelia to OCaml if 
> someone would first develop Qt bindings for OCaml that would allow me to do
> in OCaml what I'm doing in C++ so far ;)

That may already be possible if you go via more mainstream dynamic languages 
like Python. However, python-qt4-dev has fewer installs on Debian and Ubuntu 
than OCaml does, so you may well find that the Python bindings are inadequate 
as well.

> That's an undertaking bigger than Camelia itself. I will not develop for
> gtk-anything as lost feature parity with Qt right around the time when Qt 3
> came around, IIRC.

I can well believe that. Another option is to create a new GUI toolkit from 
scratch in OCaml.

> Qt 4 is leaps and bounds above anything gtk provides, in 
> terms of integrated functionality. This is not meant as a flamebait, I 
> believe it to be an accurate statement of fact.

And WPF is leaps and bounds above anything Qt 4 provides, in terms of 
functionality, integration and performance. Combined with the fact that using 
Qt4 from a decent language is very hard and basically completely pointless by 
design anyway, I think there is a strong argument for starting from scratch.

> I wish I could use gtk 
> since it's easier to bind with, but I'd end up having to either reimplement
> parts of Qt, or have to deal with lots of 3rd party libraries, each from a
> different author who had a different API design mindset. Qt takes care of
> those integration issues internally and provides a relatively
> self-consistent API -- this saves a metric crapton of time (I use the darn
> thing).

Swings and roundabouts. The metric crapton of time you save with Qt4's 
functionality is paid by having to use an awful language.

> > . Graphical throwback of the documentation related to what is under the
> > mouse pointer.
>
> Easy to do -- goes on my to-do list.

How would you implement it?

> > . Graphical throwback of errors and, in the case of type errors, optional
> > highlighting of previous unification points.
>
> Camelia does that.

Cool. AFAIK, OCaml does not export information about unification points. So 
how do you get hold of that data in Camelia?

> > . Refactoring, e.g. changing the name of a definition in all occurrences.
>
> Perhaps in version 2.2 ;)

Fair enough. That is not essential.

> > . Autocompletion that handles structural types in LablGTK code and
> > operators, i.e. when the user types "+" present options for int "+",
> > float "+.", num "+/" and any other operators that begin with "+".
>
> Version 2.2 ;)

I believe that kind of IDE support would allow a language like OCaml (i.e. 
without overloading) to handle arithmetic over many types gracefully.

> > . Represent an OCaml project as a tree of modules that happen to have the
> > first level stored as files.
>
> Level 1 is easy to do, but what's on the second and deeper levels in your
> idea?

The first level is defined by the filename and all subsequent levels are 
defined as nested modules within a file. I would not mind if the IDE 
abstracted away the concept of files completely: they have no place in modern 
programming IMHO.

> > . Performant enough to handle projects with hundreds of thousands of
> > lines of code.
>
> Shouldn't be a problem, perhaps as long as you don't put all the lines in
> one file ;)
>
> In the long run I may switch to using QCodeEdit from edyuk, which is
> supposedly better performing than QPlainTextEdit.

Until you get a significant user base I wouldn't worry about it.

> > . Parallel so seven of my cores aren't idle while I'm waiting.
>
> Everything is done in one thread right now, but over time it can be spread
> out. Implementing this properly requires refectoring of the code first:
> right now Camelia is in no shape to attempt that. After 2.0 release there
> will be time to attack that.

It is trivial if you can pull the sources of the OCaml compiler into your IDE 
and if OCaml has a parallel GC. ;-)

> > . The ability to hide the tail of +., +/ etc. operators to make numerical
> > code more readable.
>
> Easy to do, can go in for 2.0.

You need type throwback on operators as well, of course.

> > > What are killer features you dream of?
> >
> > Only one: an interactive top-level where output is presented via
> > graphical elements (e.g. a scene graph) and is no longer limited to just
> > ASCII text. This would give OCaml the graphical capabilities of
> > Mathematica's awesome "notebook" front-end.
>
> How would you like that to work?

It is a logical progression from building your own GUI toolkit. You represent 
graphics using scene graphs. Everything in an interactive session is 
converted into scene graphs for rendering.

So:

  val pretty_printer : Expr.t -> string

becomes:

  val pretty_printer : Expr.t -> Scene.t

and the resulting Scene.t is fed through a renderer like Smoke.

> Do you think about something like ddd, or a different approach?

Look at Mathematica (and not ddd) for inspiration.

> Processing toplevel output is an issue nicely orthogonal to editor and
> knowledgebase, so this doesn't block on the major refactoring that has
> to happen on the editor end.

Yes and no. I assume your editor is completely hard-wired from the ground up 
for editing plain text and maybe even unicode but is completely incapable of 
rendering arbitrary vector graphics. If so, it will need to be completely 
gutted.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Monday 03 November 2008, Jon Harrop wrote:
> On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> > On Friday 31 October 2008, Jon Harrop wrote:
> > > . Written in OCaml using OCaml's own lexer and parser to save effort
> > > and make it possible for others to help develop it without losing their
> > > hair.
> >
> > That's perhaps possible in the longer run by linking some OCaml code in.
> > Right now Camelia has its own parser.
>
> You reimplemented the whole OCaml parser in C++? Does it handle Camlp4
> syntax extensions?

It's only good enough for simple things, like looking up symbols and figuring 
out in which context does a symbol appear. Heavy lifting like type inference 
etc. is left to OCaml, and its type annotations are used extensively. Even
though I see no problem with having a real OCaml parser. Type inference
notwithstanding, of course.

> > I could port Camelia to OCaml if
> > someone would first develop Qt bindings for OCaml that would allow me to
> > do in OCaml what I'm doing in C++ so far ;)
>
> That may already be possible if you go via more mainstream dynamic
> languages like Python. However, python-qt4-dev has fewer installs on Debian
> and Ubuntu than OCaml does, so you may well find that the Python bindings
> are inadequate as well.

Python Qt bindings are pretty much feature-complete, but C++'s class system
maps perhaps better to Python/LISP than to OCaml?

> > That's an undertaking bigger than Camelia itself. I will not develop for
> > gtk-anything as lost feature parity with Qt right around the time when Qt
> > 3 came around, IIRC.
>
> I can well believe that. Another option is to create a new GUI toolkit from
> scratch in OCaml.

Since Camelia uses so much of Qt's functionality, this is a task on par with
reimplementing Qt. Good luck with that ;)

> > Qt 4 is leaps and bounds above anything gtk provides, in
> > terms of integrated functionality. This is not meant as a flamebait, I
> > believe it to be an accurate statement of fact.
>
> And WPF is leaps and bounds above anything Qt 4 provides, in terms of
> functionality, integration and performance. Combined with the fact that
> using Qt4 from a decent language is very hard and basically completely
> pointless by design anyway, I think there is a strong argument for starting
> from scratch.

WPF is just another thing, and it's not really portable in any decent sense
of the word. Camelia could be run on a 486 system with perhaps 64MB of memory
when compiled using Qt/Embedded. While one can question whether it's useful
or not, Qt has the benefit of targeting all major computing platforms out 
there.

Using Qt4 in a decent language will be easy once there is a C++ parser in said
decent language. I don't know if I mentioned it, but some time ago I did
a proof-of-concept of machine-translating QObject.cpp and friends to LISP and
it not only worked, but required no moc ;) So I'd say that as soon as there's
a good-enough C++ parser written in OCaml, and given availability of a basic
AI package (to implement a KB and searches), it should be perfectly doable to
translate Qt4 into human-readable, not-too-bad OCaml.

> > I wish I could use gtk
> > since it's easier to bind with, but I'd end up having to either
> > reimplement parts of Qt, or have to deal with lots of 3rd party
> > libraries, each from a different author who had a different API design
> > mindset. Qt takes care of those integration issues internally and
> > provides a relatively
> > self-consistent API -- this saves a metric crapton of time (I use the
> > darn thing).
>
> Swings and roundabouts. The metric crapton of time you save with Qt4's
> functionality is paid by having to use an awful language.

Let's not flame about it, but as a pure exercise I have implemented everything
(as in all presented algorithms/approacheds) for three "major" courses from
www.osu.edu (MATH707/727, CSE630 and CSE680), in LISP, OCaml and C++.
The code in each case has similar readability and uses similarly high-level
concepts. I'd say that if you think in OCaml or LISP and implement in C++,
you can still get pretty good code ;) Of course some LISP/OCaml-isms are
unavailable in C++, but then some other ones can be implemented with relative
cleanliness using available template metaprogramming.

> > > . Graphical throwback of the documentation related to what is under the
> > > mouse pointer.
> >
> > Easy to do -- goes on my to-do list.
>
> How would you implement it?

1. Everything has type annotations.
2. I know scope of symbols from my simple parser.

It's easy enough to look things up by name+context and type, right?

> > > . Graphical throwback of errors and, in the case of type errors,
> > > optional highlighting of previous unification points.
> >
> > Camelia does that.
>
> Cool. AFAIK, OCaml does not export information about unification points. So
> how do you get hold of that data in Camelia?

I was probably wrong about unification points. What are they?

> > > . Autocompletion that handles structural types in LablGTK code and
> > > operators, i.e. when the user types "+" present options for int "+",
> > > float "+.", num "+/" and any other operators that begin with "+".
> >
> > Version 2.2 ;)
>
> I believe that kind of IDE support would allow a language like OCaml (i.e.
> without overloading) to handle arithmetic over many types gracefully.

I agree.

> > > . Represent an OCaml project as a tree of modules that happen to have
> > > the first level stored as files.
> >
> > Level 1 is easy to do, but what's on the second and deeper levels in your
> > idea?
>
> The first level is defined by the filename and all subsequent levels are
> defined as nested modules within a file. I would not mind if the IDE
> abstracted away the concept of files completely: they have no place in
> modern programming IMHO.

OK, got it. Since I parse things already, I know all about modules so it
should be easy to do. I don't know if it'd be v2.0 or 2.1, though.

> > > . Performant enough to handle projects with hundreds of thousands of
> > > lines of code.
> >
> > Shouldn't be a problem, perhaps as long as you don't put all the lines in
> > one file ;)
> >
> > In the long run I may switch to using QCodeEdit from edyuk, which is
> > supposedly better performing than QPlainTextEdit.
>
> Until you get a significant user base I wouldn't worry about it.

That's what I was thinking, too.

> > > . Parallel so seven of my cores aren't idle while I'm waiting.
> >
> > Everything is done in one thread right now, but over time it can be
> > spread out. Implementing this properly requires refectoring of the code
> > first: right now Camelia is in no shape to attempt that. After 2.0
> > release there will be time to attack that.
>
> It is trivial if you can pull the sources of the OCaml compiler into your
> IDE and if OCaml has a parallel GC. ;-)

Doing even that requires a lot of refactoring. Camelia 1.1 had its OCaml-
awareness spread about everywhere, so before anything major happens I had
to get all language-specific stuff abstracted out anyway. I'm in the process
of doing that.

> > > . The ability to hide the tail of +., +/ etc. operators to make
> > > numerical code more readable.
> >
> > Easy to do, can go in for 2.0.
>
> You need type throwback on operators as well, of course.

> > > Only one: an interactive top-level where output is presented via
> > > graphical elements (e.g. a scene graph) and is no longer limited to
> > > just ASCII text. This would give OCaml the graphical capabilities of
> > > Mathematica's awesome "notebook" front-end.
> >
> > How would you like that to work?
>
> It is a logical progression from building your own GUI toolkit. You
> represent graphics using scene graphs. Everything in an interactive session
> is converted into scene graphs for rendering.
>
> So:
>
>   val pretty_printer : Expr.t -> string
>
> becomes:
>
>   val pretty_printer : Expr.t -> Scene.t
>
> and the resulting Scene.t is fed through a renderer like Smoke.

1. How exactly do you see the pretty_printer rendering things?
2. How easy it is to replace pretty_printer built into OCaml?

I presume that the running OCaml instance (toplevel) would
dump scene graphs, and then a separate OCaml instance would
take those and render them?

> Look at Mathematica (and not ddd) for inspiration.

We have it at school, so I'll give it a look.

> > Processing toplevel output is an issue nicely orthogonal to editor and
> > knowledgebase, so this doesn't block on the major refactoring that has
> > to happen on the editor end.
>
> Yes and no. I assume your editor is completely hard-wired from the ground
> up for editing plain text and maybe even unicode but is completely
> incapable of rendering arbitrary vector graphics. If so, it will need to be
> completely gutted.

Well, the thing about toplevel is that it's completely separate from the
actual source editor.

So I can actually replace toplevel at any time by simply substituting a 
different widget for it. The toplevel widget talks to a wrapper around the
real OCaml process, which would be re-used.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Tuesday 04 November 2008, Jon Harrop wrote:
> On Tuesday 04 November 2008 18:35:45 Kuba Ober wrote:
> > On Monday 03 November 2008, Jon Harrop wrote:
> > > On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> > > > I could port Camelia to OCaml if
> > > > someone would first develop Qt bindings for OCaml that would allow me
> > > > to do in OCaml what I'm doing in C++ so far ;)
> > >
> > > That may already be possible if you go via more mainstream dynamic
> > > languages like Python. However, python-qt4-dev has fewer installs on
> > > Debian and Ubuntu than OCaml does, so you may well find that the Python
> > > bindings are inadequate as well.
> >
> > Python Qt bindings are pretty much feature-complete, but C++'s class
> > system maps perhaps better to Python/LISP than to OCaml?
>
> You'll just be invoking autogenerated Python code using OCaml so OCaml's
> class system is only relevant if you want to do some fancy statically-typed
> shim. I'd forget about that and just focus on making the whole of Qt4
> available safely from OCaml in any form first. Even this is an unsolved
> problem in the OCaml world!

Python bindings for Qt extensively use Python's API. You'd need OCaml to
provide said API first.

> > Since Camelia uses so much of Qt's functionality, this is a task on par
> > with reimplementing Qt. Good luck with that ;)
>
> From Qt4's architecture diagram:
>
>  
> http://trolltech.com/images/template/product-architecture-diagram-collapsed
>
>   Core, GUI, database, scripting, network, OpenGL, XML, Multimedia, Font
> Engine and Webkit
>
> Of those, only core and GUI might be relevant here but the core lacks
> first-class functions for events and callbacks 

Maybe they are not first-class, but the way they've done it is via 
preprocessing using moc and things behave like they were first-class.

In Qt, if you have a user interface dialog box (a form) called MyForm
with an element named say ExitButton, you'd have this:

class MyForm : public QDialog {
Q_OBJECT
	Ui::MyForm ui;

	MyForm::MyForm(QWidget * parent) : QDialog(parent) {
	  ui.setupUi(this); // calls code autogenerated by UI compiler
        }

public slots:
        void on_ExitButton_clicked() {
           ui.ExitButton->hide()
        }
};

The code is hopefully easy to understand and as you can see you don't even
have to connect signals and slots manually if you don't want to. All the
magic happens behind the scenes. It's very easy to use.

> and the GUI is unable to 
> express integrated graphics (e.g. OpenGL layers).

You're talking like everyone was after integrated graphics. You are and
I understand your viewpoint, but say I'm not :)

> So the amount of Qt that is objectively beneficial is tiny and the cost of
> using it is very high.

I really doubt that.

> > > > Qt 4 is leaps and bounds above anything gtk provides, in
> > > > terms of integrated functionality. This is not meant as a flamebait,
> > > > I believe it to be an accurate statement of fact.
> > >
> > > And WPF is leaps and bounds above anything Qt 4 provides, in terms of
> > > functionality, integration and performance. Combined with the fact that
> > > using Qt4 from a decent language is very hard and basically completely
> > > pointless by design anyway, I think there is a strong argument for
> > > starting from scratch.
> >
> > WPF is just another thing, and it's not really portable in any decent
> > sense of the word.
>
> Sure. My point is that you're building on antique technology when you could
> be building modern technology instead.

With Qt there's a real chance of machine-translating the code to say LISP
or OCaml or what have you. With WPF, you're stuck with .Net and that's the end
of it.

> > Camelia could be run on a 486 system with perhaps 64MB of
> > memory when compiled using Qt/Embedded. While one can question whether
> > it's useful or not, Qt has the benefit of targeting all major computing
> > platforms out there.
>
> That sales hype for Qt is just a reflection of the fact that Qt was built
> on sand using a dying technology (C++). In practice, the world moved on to
> garbage collected virtual machines for GUI programming years ago. Qt was
> left behind and is desperately trying to catch up by migrating to the JVM
> but the JVM is now dying...

Qt has not migrated to JVM. Relevant Qt classes implement parent-child
ownership, implicit copy-on-write and reference counting, and are used
just like you would any random collection of things in a garbage-collected
language. You're also free to use a garbage collector with any C++ project,
this has nothing to do with Qt.

> > Using Qt4 in a decent language will be easy once there is a C++ parser in
> > said decent language.
>
> You'll be Greenspunning managed C++ from the .NET world. That's a fine idea
> if you regard Qt as useful legacy code but I don't see the point myself. Qt
> will always have a stone-age API and reimplementing managed C++ is a huge
> undertaking.

This is not about greenspunning anything. Most of Qt code is written in such 
way that the C++-isms are completely abstracted out at the level of core
classes such as QObject and collections (QList, QVector, etc). By translating
the use of basic Qt primitives (really QObject and collections) to whatever
OCaml/Lisp/Python/blabla provides, you can very cleanly port Qt codebase
to another language, and it will look pretty much as if it were written in
said language.

> In contrast, you can implement a GUI toolkit in OCaml that far exceeds the
> relevant limitations of Qt4 with quite easily.

Qt has very few language-inherent limitations that are not abstracted out to
the core. Whatever other limitations Qt has are design decisions that have
little to do with choice of the language.

> > I don't know if I mentioned it, but some time ago I
> > did a proof-of-concept of machine-translating QObject.cpp and friends to
> > LISP and it not only worked, but required no moc ;) So I'd say that as
> > soon as there's a good-enough C++ parser written in OCaml, and given
> > availability of a basic AI package (to implement a KB and searches), it
> > should be perfectly doable to translate Qt4 into human-readable,
> > not-too-bad OCaml.
>
> Then the question is simply whether it is easier to write a C++ parser in
> OCaml along with the translation code and a sane shim over the whole of Qt4
> or just replace it wholesale.

Qt has to cover a lot of platform-specific ground. Reimplementing it from
scratch implies having to fix most of the bugs that Qt folks have already
fixed. Qt's code base as a fine reference for a lot of platform-specific
borkedness that Qt's users have run into, and the trolls have fixed.

> > > > I wish I could use gtk
> > > > since it's easier to bind with, but I'd end up having to either
> > > > reimplement parts of Qt, or have to deal with lots of 3rd party
> > > > libraries, each from a different author who had a different API
> > > > design mindset. Qt takes care of those integration issues internally
> > > > and provides a relatively
> > > > self-consistent API -- this saves a metric crapton of time (I use the
> > > > darn thing).
> > >
> > > Swings and roundabouts. The metric crapton of time you save with Qt4's
> > > functionality is paid by having to use an awful language.
> >
> > Let's not flame about it,
>
> I would not regard that as flame bait here. I'm sure if OCaml had decent Qt
> bindings they would be very heavily used indeed (the OCaml language would
> excel at GUI programming, which is precisely why so many people here are
> yearning for such bindings) but Qt4 is nowhere near useful enough to make
> me want to go back to C++ or any language that does have Qt bindings.
>
> From what I've heard, a lot of OCaml programming use OpenGL for GUI
> programming instead of GUI toolkits.

Show me a generic, reuseable OCaml-written, OpenGL-based common widgets such
as model-view tables, buttons, editors, tree views, ... Then we'll talk.

> > > > > . Graphical throwback of the documentation related to what is under
> > > > > the mouse pointer.
> > > >
> > > > Easy to do -- goes on my to-do list.
> > >
> > > How would you implement it?
> >
> > 1. Everything has type annotations.
> > 2. I know scope of symbols from my simple parser.
> >
> > It's easy enough to look things up by name+context and type, right?
>
> You require the programmer to write type annotations everywhere?

OCaml does produce type annotations for you :) Camelia uses those.

> > > > > . Graphical throwback of errors and, in the case of type errors,
> > > > > optional highlighting of previous unification points.
> > > >
> > > > Camelia does that.
> > >
> > > Cool. AFAIK, OCaml does not export information about unification
> > > points. So how do you get hold of that data in Camelia?
> >
> > I was probably wrong about unification points. What are they?
>
> The points in the program where the type checker unified two or more types
> in order to check type correctness, e.g. the two branches of an "if"
> expression.
>
> When the programmer makes a mistake, the type checker can be misled early
> in the code but report an actual type error later in the code. So it can be
> helpful (particularly for newbies) to see where the type checker unified
> because the error will almost certainly have been at one of those points.
>
> For example, a function to sum a list of floats:
>
>   let rec sum = function
>
>     | [] -> 0
>     | h::t -> h +. sum t
>
> The type error is reported at the "+." operator because the type was
> incorrectly inferred to be "int" when the type checker came across the "0"
> in the first clause. Highlighting the unification points of that type
> immediately leads the programmer to the point of error. Without this, the
> programmer has no idea where the error really is.

So, OCaml compiler itself doesn't produce that? It'd be easier to add it to
OCaml, than to redo it from scratch.

> > > > > . Parallel so seven of my cores aren't idle while I'm waiting.
> > > >
> > > > Everything is done in one thread right now, but over time it can be
> > > > spread out. Implementing this properly requires refectoring of the
> > > > code first: right now Camelia is in no shape to attempt that. After
> > > > 2.0 release there will be time to attack that.
> > >
> > > It is trivial if you can pull the sources of the OCaml compiler into
> > > your IDE and if OCaml has a parallel GC. ;-)
> >
> > Doing even that requires a lot of refactoring. Camelia 1.1 had its OCaml-
> > awareness spread about everywhere, so before anything major happens I had
> > to get all language-specific stuff abstracted out anyway. I'm in the
> > process of doing that.
>
> If you want your IDE to support multiple languages, yes. My preference
> would be to write an IDE specifically for OCaml first.

Sure, but that should not imply that the code is a mess like it is right now.

> > > It is a logical progression from building your own GUI toolkit. You
> > > represent graphics using scene graphs. Everything in an interactive
> > > session is converted into scene graphs for rendering.
> > >
> > > So:
> > >
> > >   val pretty_printer : Expr.t -> string
> > >
> > > becomes:
> > >
> > >   val pretty_printer : Expr.t -> Scene.t
> > >
> > > and the resulting Scene.t is fed through a renderer like Smoke.
> >
> > 1. How exactly do you see the pretty_printer rendering things?
>
> Easiest for me to answer by just posting our code. Here is the code from
> the current version of Smoke that typesets paragraphs of text by
> overflowing words onto new lines:
>
> let rec charsmap = function
>
>     | 'f' :: 'f' :: 'i' :: t -> (`CMR, 177) :: charsmap t
>     | 'f' :: 'f' :: 'l' :: t -> (`CMR, 178) :: charsmap t
>     | 'f' :: 'f' :: t -> (`CMR, 174) :: charsmap t
>     | 'f' :: 'i' :: t -> (`CMR, 175) :: charsmap t
>     | 'f' :: 'l' :: t -> (`CMR, 176) :: charsmap t
>     | c :: t -> charmap c :: charsmap t
>     | [] -> []
>
> let word string =
>   let string = charsmap(list_of_string string) in
>   let aux x (font1, c1) (font2, c2) =
>     let contours = Cmfont.glyph font1 c1 in
>     let contours = List.map Contour.make contours in
>     let g = List.map (Contour.trans (translate x 0.)) contours in
>     let advance =
>       if font1=font2 then Cmfont.advance font1 c1 c2 else
>         Cmfont.advance `CMR 32 32 in
>     x +. advance, g in
>   let rec aux2 x = function
>
>     | [] -> []
>     | h1::t ->
>
>         let h2 = match t with h2::_ -> h2 | _ -> `CMR, 32 in
>         let x, g = aux x h1 h2 in
>         g :: aux2 x t in
>   aux2 0. string |> List.concat |> ContourGeometry.of_contours
>
> let word = memoize (fun _ -> word)
>
> let paragraph ~skip ~justify ~width ~string =
>   let words = List.map word (String.split ' ' string) in

LOL. If you seriously think it's worth reimplementing the wheel for
a millionth time, go for it. But I don't think this would be the
best way to spend my time just to get text rendered using OpenGL.

Qt already can do rendering in OpenGL, so if one wants to do something
that actually really needs OpenGL, it can be done.

But to just render a paragraph of text? There's code for it in Qt ;)

As for showing more complex flat views of data, one can use QGraphicsView
& friends.

Have you ran recent Qt demos distributed with Qt? I'd say they look pretty
cool in my book.

>
> > 2. How easy it is to replace pretty_printer built into OCaml?
>
> Already trivial:
>
> $ ocaml
>         Objective Caml version 3.10.2
>
> # 3.4;;
> - : float = 3.4
> # open Format;;
> # let print_float ff x = fprintf ff "%0.20f" x;;
> val print_float : Format.formatter -> float -> unit = <fun>
> # #install_printer print_float;;
> # 3.4;;
> - : float = 3.39999999999999991118
>
> However, I'd rather OCaml carried run-time type information and the pretty
> printer associated run-time types with typesetting functions.
>
> > I presume that the running OCaml instance (toplevel) would
> > dump scene graphs, and then a separate OCaml instance would
> > take those and render them?
>
> I would just replace the backend of the current top-level to generate
> graphics instead of text.
>
> > > > Processing toplevel output is an issue nicely orthogonal to editor
> > > > and knowledgebase, so this doesn't block on the major refactoring
> > > > that has to happen on the editor end.
> > >
> > > Yes and no. I assume your editor is completely hard-wired from the
> > > ground up for editing plain text and maybe even unicode but is
> > > completely incapable of rendering arbitrary vector graphics. If so, it
> > > will need to be completely gutted.
> >
> > Well, the thing about toplevel is that it's completely separate from the
> > actual source editor.
>
> In the current design, yes.
>
> > So I can actually replace toplevel at any time by simply substituting a
> > different widget for it. The toplevel widget talks to a wrapper around
> > the real OCaml process, which would be re-used.
>
> You really want to preserve information (e.g. types) in the graphical
> output for throwback to work so I would go for tighter integration of the
> top-level and IDE.

All of that can certainly be done in the future.

Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Tuesday 04 November 2008 18:35:45 Kuba Ober wrote:
> On Monday 03 November 2008, Jon Harrop wrote:
> > On Monday 03 November 2008 14:15:38 Kuba Ober wrote:
> > > I could port Camelia to OCaml if
> > > someone would first develop Qt bindings for OCaml that would allow me
> > > to do in OCaml what I'm doing in C++ so far ;)
> >
> > That may already be possible if you go via more mainstream dynamic
> > languages like Python. However, python-qt4-dev has fewer installs on
> > Debian and Ubuntu than OCaml does, so you may well find that the Python
> > bindings are inadequate as well.
>
> Python Qt bindings are pretty much feature-complete, but C++'s class system
> maps perhaps better to Python/LISP than to OCaml?

You'll just be invoking autogenerated Python code using OCaml so OCaml's class 
system is only relevant if you want to do some fancy statically-typed shim. 
I'd forget about that and just focus on making the whole of Qt4 available 
safely from OCaml in any form first. Even this is an unsolved problem in the 
OCaml world!

> > > That's an undertaking bigger than Camelia itself. I will not develop
> > > for gtk-anything as lost feature parity with Qt right around the time
> > > when Qt 3 came around, IIRC.
> >
> > I can well believe that. Another option is to create a new GUI toolkit
> > from scratch in OCaml.
>
> Since Camelia uses so much of Qt's functionality, this is a task on par
> with reimplementing Qt. Good luck with that ;)

From Qt4's architecture diagram:

  http://trolltech.com/images/template/product-architecture-diagram-collapsed

  Core, GUI, database, scripting, network, OpenGL, XML, Multimedia, Font 
Engine and Webkit

Of those, only core and GUI might be relevant here but the core lacks 
first-class functions for events and callbacks and the GUI is unable to 
express integrated graphics (e.g. OpenGL layers).

So the amount of Qt that is objectively beneficial is tiny and the cost of 
using it is very high.

> > > Qt 4 is leaps and bounds above anything gtk provides, in
> > > terms of integrated functionality. This is not meant as a flamebait, I
> > > believe it to be an accurate statement of fact.
> >
> > And WPF is leaps and bounds above anything Qt 4 provides, in terms of
> > functionality, integration and performance. Combined with the fact that
> > using Qt4 from a decent language is very hard and basically completely
> > pointless by design anyway, I think there is a strong argument for
> > starting from scratch.
>
> WPF is just another thing, and it's not really portable in any decent sense
> of the word.

Sure. My point is that you're building on antique technology when you could be 
building modern technology instead.

> Camelia could be run on a 486 system with perhaps 64MB of 
> memory when compiled using Qt/Embedded. While one can question whether it's
> useful or not, Qt has the benefit of targeting all major computing
> platforms out there.

That sales hype for Qt is just a reflection of the fact that Qt was built on 
sand using a dying technology (C++). In practice, the world moved on to 
garbage collected virtual machines for GUI programming years ago. Qt was left 
behind and is desperately trying to catch up by migrating to the JVM but the 
JVM is now dying...

> Using Qt4 in a decent language will be easy once there is a C++ parser in
> said decent language.

You'll be Greenspunning managed C++ from the .NET world. That's a fine idea if 
you regard Qt as useful legacy code but I don't see the point myself. Qt will 
always have a stone-age API and reimplementing managed C++ is a huge 
undertaking.

In contrast, you can implement a GUI toolkit in OCaml that far exceeds the 
relevant limitations of Qt4 with quite easily.

> I don't know if I mentioned it, but some time ago I 
> did a proof-of-concept of machine-translating QObject.cpp and friends to
> LISP and it not only worked, but required no moc ;) So I'd say that as soon
> as there's a good-enough C++ parser written in OCaml, and given
> availability of a basic AI package (to implement a KB and searches), it
> should be perfectly doable to translate Qt4 into human-readable,
> not-too-bad OCaml.

Then the question is simply whether it is easier to write a C++ parser in 
OCaml along with the translation code and a sane shim over the whole of Qt4 
or just replace it wholesale.

> > > I wish I could use gtk
> > > since it's easier to bind with, but I'd end up having to either
> > > reimplement parts of Qt, or have to deal with lots of 3rd party
> > > libraries, each from a different author who had a different API design
> > > mindset. Qt takes care of those integration issues internally and
> > > provides a relatively
> > > self-consistent API -- this saves a metric crapton of time (I use the
> > > darn thing).
> >
> > Swings and roundabouts. The metric crapton of time you save with Qt4's
> > functionality is paid by having to use an awful language.
>
> Let's not flame about it,

I would not regard that as flame bait here. I'm sure if OCaml had decent Qt 
bindings they would be very heavily used indeed (the OCaml language would 
excel at GUI programming, which is precisely why so many people here are 
yearning for such bindings) but Qt4 is nowhere near useful enough to make me 
want to go back to C++ or any language that does have Qt bindings.

From what I've heard, a lot of OCaml programming use OpenGL for GUI 
programming instead of GUI toolkits.

> but as a pure exercise I have implemented 
> everything (as in all presented algorithms/approacheds) for three "major"
> courses from www.osu.edu (MATH707/727, CSE630 and CSE680), in LISP, OCaml
> and C++. The code in each case has similar readability and uses similarly
> high-level concepts. I'd say that if you think in OCaml or LISP and
> implement in C++, you can still get pretty good code ;) Of course some
> LISP/OCaml-isms are unavailable in C++, but then some other ones can be
> implemented with relative cleanliness using available template
> metaprogramming.

I've no idea what those exercises where but get your OCaml code peer reviewed 
here before drawing a conclusion. There are very few tasks where C++ is 
competitively comprehensible.

> > > > . Graphical throwback of the documentation related to what is under
> > > > the mouse pointer.
> > >
> > > Easy to do -- goes on my to-do list.
> >
> > How would you implement it?
>
> 1. Everything has type annotations.
> 2. I know scope of symbols from my simple parser.
>
> It's easy enough to look things up by name+context and type, right?

You require the programmer to write type annotations everywhere?

> > > > . Graphical throwback of errors and, in the case of type errors,
> > > > optional highlighting of previous unification points.
> > >
> > > Camelia does that.
> >
> > Cool. AFAIK, OCaml does not export information about unification points.
> > So how do you get hold of that data in Camelia?
>
> I was probably wrong about unification points. What are they?

The points in the program where the type checker unified two or more types in 
order to check type correctness, e.g. the two branches of an "if" expression.

When the programmer makes a mistake, the type checker can be misled early in 
the code but report an actual type error later in the code. So it can be 
helpful (particularly for newbies) to see where the type checker unified 
because the error will almost certainly have been at one of those points.

For example, a function to sum a list of floats:

  let rec sum = function
    | [] -> 0
    | h::t -> h +. sum t

The type error is reported at the "+." operator because the type was 
incorrectly inferred to be "int" when the type checker came across the "0" in 
the first clause. Highlighting the unification points of that type 
immediately leads the programmer to the point of error. Without this, the 
programmer has no idea where the error really is.

> > > > . Parallel so seven of my cores aren't idle while I'm waiting.
> > >
> > > Everything is done in one thread right now, but over time it can be
> > > spread out. Implementing this properly requires refectoring of the code
> > > first: right now Camelia is in no shape to attempt that. After 2.0
> > > release there will be time to attack that.
> >
> > It is trivial if you can pull the sources of the OCaml compiler into your
> > IDE and if OCaml has a parallel GC. ;-)
>
> Doing even that requires a lot of refactoring. Camelia 1.1 had its OCaml-
> awareness spread about everywhere, so before anything major happens I had
> to get all language-specific stuff abstracted out anyway. I'm in the
> process of doing that.

If you want your IDE to support multiple languages, yes. My preference would 
be to write an IDE specifically for OCaml first.

> > It is a logical progression from building your own GUI toolkit. You
> > represent graphics using scene graphs. Everything in an interactive
> > session is converted into scene graphs for rendering.
> >
> > So:
> >
> >   val pretty_printer : Expr.t -> string
> >
> > becomes:
> >
> >   val pretty_printer : Expr.t -> Scene.t
> >
> > and the resulting Scene.t is fed through a renderer like Smoke.
>
> 1. How exactly do you see the pretty_printer rendering things?

Easiest for me to answer by just posting our code. Here is the code from the 
current version of Smoke that typesets paragraphs of text by overflowing 
words onto new lines:

let rec charsmap = function
    | 'f' :: 'f' :: 'i' :: t -> (`CMR, 177) :: charsmap t
    | 'f' :: 'f' :: 'l' :: t -> (`CMR, 178) :: charsmap t
    | 'f' :: 'f' :: t -> (`CMR, 174) :: charsmap t
    | 'f' :: 'i' :: t -> (`CMR, 175) :: charsmap t
    | 'f' :: 'l' :: t -> (`CMR, 176) :: charsmap t
    | c :: t -> charmap c :: charsmap t
    | [] -> []

let word string =
  let string = charsmap(list_of_string string) in
  let aux x (font1, c1) (font2, c2) =
    let contours = Cmfont.glyph font1 c1 in
    let contours = List.map Contour.make contours in
    let g = List.map (Contour.trans (translate x 0.)) contours in
    let advance =
      if font1=font2 then Cmfont.advance font1 c1 c2 else
        Cmfont.advance `CMR 32 32 in
    x +. advance, g in
  let rec aux2 x = function
    | [] -> []
    | h1::t ->
        let h2 = match t with h2::_ -> h2 | _ -> `CMR, 32 in
        let x, g = aux x h1 h2 in
        g :: aux2 x t in
  aux2 0. string |> List.concat |> ContourGeometry.of_contours

let word = memoize (fun _ -> word)

let paragraph ~skip ~justify ~width ~string =
  let words = List.map word (String.split ' ' string) in

> 2. How easy it is to replace pretty_printer built into OCaml?

Already trivial:

$ ocaml
        Objective Caml version 3.10.2

# 3.4;;
- : float = 3.4
# open Format;;
# let print_float ff x = fprintf ff "%0.20f" x;;
val print_float : Format.formatter -> float -> unit = <fun>
# #install_printer print_float;;
# 3.4;;
- : float = 3.39999999999999991118

However, I'd rather OCaml carried run-time type information and the pretty 
printer associated run-time types with typesetting functions.

> I presume that the running OCaml instance (toplevel) would
> dump scene graphs, and then a separate OCaml instance would
> take those and render them?

I would just replace the backend of the current top-level to generate graphics 
instead of text.

> > > Processing toplevel output is an issue nicely orthogonal to editor and
> > > knowledgebase, so this doesn't block on the major refactoring that has
> > > to happen on the editor end.
> >
> > Yes and no. I assume your editor is completely hard-wired from the ground
> > up for editing plain text and maybe even unicode but is completely
> > incapable of rendering arbitrary vector graphics. If so, it will need to
> > be completely gutted.
>
> Well, the thing about toplevel is that it's completely separate from the
> actual source editor.

In the current design, yes.

> So I can actually replace toplevel at any time by simply substituting a
> different widget for it. The toplevel widget talks to a wrapper around the
> real OCaml process, which would be re-used.

You really want to preserve information (e.g. types) in the graphical output 
for throwback to work so I would go for tighter integration of the top-level 
and IDE.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
> On Tuesday 04 November 2008, Jon Harrop wrote:
> > You'll just be invoking autogenerated Python code using OCaml so OCaml's
> > class system is only relevant if you want to do some fancy
> > statically-typed shim. I'd forget about that and just focus on making the
> > whole of Qt4 available safely from OCaml in any form first. Even this is
> > an unsolved problem in the OCaml world!
>
> Python bindings for Qt extensively use Python's API. You'd need OCaml to
> provide said API first.

No, you just invoke the existing Python bindings. OCaml doesn't have to 
implement anything except bindings to Python, which are already done.

> > Of those, only core and GUI might be relevant here but the core lacks
> > first-class functions for events and callbacks
>
> Maybe they are not first-class, but the way they've done it is via
> preprocessing using moc and things behave like they were first-class.
>
> In Qt, if you have a user interface dialog box (a form) called MyForm
> with an element named say ExitButton, you'd have this:
>
> class MyForm : public QDialog {
> Q_OBJECT
> 	Ui::MyForm ui;
>
> 	MyForm::MyForm(QWidget * parent) : QDialog(parent) {
> 	  ui.setupUi(this); // calls code autogenerated by UI compiler
>         }
>
> public slots:
>         void on_ExitButton_clicked() {
>            ui.ExitButton->hide()
>         }
> };

Compare with the equivalent F#+WPF code:

  button.Click.Add(fun _ -> window.Close())

> The code is hopefully easy to understand and as you can see you don't even
> have to connect signals and slots manually if you don't want to. All the
> magic happens behind the scenes. It's very easy to use.

I prefer my F# to your C++.

> > > WPF is just another thing, and it's not really portable in any decent
> > > sense of the word.
> >
> > Sure. My point is that you're building on antique technology when you
> > could be building modern technology instead.
>
> With Qt there's a real chance of machine-translating the code to say LISP
> or OCaml or what have you.

Even if anyone ever managed to do that, the result would be an unusable buggy 
mess.

> With WPF, you're stuck with .Net and that's the end of it.

That is not a reason to ignore WPF's design.

> > > Camelia could be run on a 486 system with perhaps 64MB of
> > > memory when compiled using Qt/Embedded. While one can question whether
> > > it's useful or not, Qt has the benefit of targeting all major computing
> > > platforms out there.
> >
> > That sales hype for Qt is just a reflection of the fact that Qt was built
> > on sand using a dying technology (C++). In practice, the world moved on
> > to garbage collected virtual machines for GUI programming years ago. Qt
> > was left behind and is desperately trying to catch up by migrating to the
> > JVM but the JVM is now dying...
>
> Qt has not migrated to JVM. Relevant Qt classes implement parent-child
> ownership, implicit copy-on-write and reference counting, and are used
> just like you would any random collection of things in a garbage-collected
> language. You're also free to use a garbage collector with any C++ project,
> this has nothing to do with Qt.

You'd have to Greenspun managed C++ if you want a real GC for your C++ code. 
You can pull in Boehm but it breaks existing code and is not reliable (hence 
the Mono project are desperately trying to remove it).

So you are not "free to use a garbage collector with any C++ project" at all. 
Quite the contrary in fact: you're completely screwed if you choose C++.

Even industry are running from C++ like rats from a sinking ship:

  http://www.itjobswatch.co.uk/jobs/uk/c++.do

Is that really the trend you want to join?

> > > Using Qt4 in a decent language will be easy once there is a C++ parser
> > > in said decent language.
> >
> > You'll be Greenspunning managed C++ from the .NET world. That's a fine
> > idea if you regard Qt as useful legacy code but I don't see the point
> > myself. Qt will always have a stone-age API and reimplementing managed
> > C++ is a huge undertaking.
>
> This is not about greenspunning anything. Most of Qt code is written in
> such way that the C++-isms are completely abstracted out at the level of
> core classes such as QObject and collections (QList, QVector, etc).

The C++isms are nowhere near being abstracted out. Just look at that code you 
posted above.

> By 
> translating the use of basic Qt primitives (really QObject and collections)
> to whatever OCaml/Lisp/Python/blabla provides, you can very cleanly port Qt
> codebase to another language, and it will look pretty much as if it were
> written in said language.

A triumph of hope over reality.

> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Qt has very few language-inherent limitations that are not abstracted out
> to the core. Whatever other limitations Qt has are design decisions that 
> have little to do with choice of the language.

I was referring to the limitations of Qt itself. Look at this example from one 
of our products:

  http://www.ffconsultancy.com/products/fsharp_for_visualization/demo2.html

That uses a 3D layer with a 2D layer overlaid. The labels are 2D widgets. 
That's trivial with WPF because it renders everything through a single 
pipeline: you just put a 2D widget over a 3D widget. That's impossible with 
Qt its OpenGL widget is completely uninteroperable.

Trolltech are hailing Mathematica 6 as a success story for Qt. Look at the 
Mathematica notebook interface:

http://reference.wolfram.com/mathematica/tutorial/Files/DoingComputationsInNotebooks.en/1.gif

That is one giant OpenGL widget covering the whole window and everything is 
rendered using custom code precisely because Qt does not provide the required 
functionality.

> > > I don't know if I mentioned it, but some time ago I
> > > did a proof-of-concept of machine-translating QObject.cpp and friends
> > > to LISP and it not only worked, but required no moc ;) So I'd say that
> > > as soon as there's a good-enough C++ parser written in OCaml, and given
> > > availability of a basic AI package (to implement a KB and searches), it
> > > should be perfectly doable to translate Qt4 into human-readable,
> > > not-too-bad OCaml.
> >
> > Then the question is simply whether it is easier to write a C++ parser in
> > OCaml along with the translation code and a sane shim over the whole of
> > Qt4 or just replace it wholesale.
>
> Qt has to cover a lot of platform-specific ground. Reimplementing it from
> scratch implies having to fix most of the bugs that Qt folks have already
> fixed. Qt's code base as a fine reference for a lot of platform-specific
> borkedness that Qt's users have run into, and the trolls have fixed.

FUD. Those are design flaws specific to Qt. OCaml+OpenGL source code is 
already portable.

> > I would not regard that as flame bait here. I'm sure if OCaml had decent
> > Qt bindings they would be very heavily used indeed (the OCaml language
> > would excel at GUI programming, which is precisely why so many people
> > here are yearning for such bindings) but Qt4 is nowhere near useful
> > enough to make me want to go back to C++ or any language that does have
> > Qt bindings.
> >
> > From what I've heard, a lot of OCaml programming use OpenGL for GUI
> > programming instead of GUI toolkits.
>
> Show me a generic, reuseable OCaml-written, OpenGL-based common widgets
> such as model-view tables, buttons, editors, tree views, ... Then we'll
> talk.

I've actually implemented most of that in Smoke and Presenta already. We never 
made any money out of it (selling OCaml libraries to OCaml programmers is 
almost impossible) so I am considering open sourcing it all.

> > The type error is reported at the "+." operator because the type was
> > incorrectly inferred to be "int" when the type checker came across the
> > "0" in the first clause. Highlighting the unification points of that type
> > immediately leads the programmer to the point of error. Without this, the
> > programmer has no idea where the error really is.
>
> So, OCaml compiler itself doesn't produce that? It'd be easier to add it to
> OCaml, than to redo it from scratch.

Yes.

> > > > It is a logical progression from building your own GUI toolkit. You
> > > > represent graphics using scene graphs. Everything in an interactive
> > > > session is converted into scene graphs for rendering.
> > > >
> > > > So:
> > > >
> > > >   val pretty_printer : Expr.t -> string
> > > >
> > > > becomes:
> > > >
> > > >   val pretty_printer : Expr.t -> Scene.t
> > > >
> > > > and the resulting Scene.t is fed through a renderer like Smoke.
> > >
> > > 1. How exactly do you see the pretty_printer rendering things?
> >
> > Easiest for me to answer by just posting our code. Here is the code from
> > the current version of Smoke that typesets paragraphs of text by
> > overflowing words onto new lines:
> >
> > let rec charsmap = function
> >
> >     | 'f' :: 'f' :: 'i' :: t -> (`CMR, 177) :: charsmap t
> >     | 'f' :: 'f' :: 'l' :: t -> (`CMR, 178) :: charsmap t
> >     | 'f' :: 'f' :: t -> (`CMR, 174) :: charsmap t
> >     | 'f' :: 'i' :: t -> (`CMR, 175) :: charsmap t
> >     | 'f' :: 'l' :: t -> (`CMR, 176) :: charsmap t
> >     | c :: t -> charmap c :: charsmap t
> >     | [] -> []
> >
> > let word string =
> >   let string = charsmap(list_of_string string) in
> >   let aux x (font1, c1) (font2, c2) =
> >     let contours = Cmfont.glyph font1 c1 in
> >     let contours = List.map Contour.make contours in
> >     let g = List.map (Contour.trans (translate x 0.)) contours in
> >     let advance =
> >       if font1=font2 then Cmfont.advance font1 c1 c2 else
> >         Cmfont.advance `CMR 32 32 in
> >     x +. advance, g in
> >   let rec aux2 x = function
> >
> >     | [] -> []
> >     | h1::t ->
> >
> >         let h2 = match t with h2::_ -> h2 | _ -> `CMR, 32 in
> >         let x, g = aux x h1 h2 in
> >         g :: aux2 x t in
> >   aux2 0. string |> List.concat |> ContourGeometry.of_contours
> >
> > let word = memoize (fun _ -> word)
> >
> > let paragraph ~skip ~justify ~width ~string =
> >   let words = List.map word (String.split ' ' string) in
>
> LOL. If you seriously think it's worth reimplementing the wheel for
> a millionth time, go for it.
>
> Qt already can do rendering in OpenGL, so if one wants to do something
> that actually really needs OpenGL, it can be done.
>
> But to just render a paragraph of text? There's code for it in Qt ;)

You have completely missed the point, of course.

You will need to use some modern GUI applications before you can begin to 
understand how they are designed. These screenshots might help:

http://download.infragistics.com/users/AndrewF/WPF-CAB.png
http://www.deepshift.com/images/WPFSampleSourcePosted_B5E0/SNAG000015.jpg
http://www.mismashd.com/BlogImages/EndtoendWPFdemoFamily.Show_E22C/familyshow3.jpg
http://wpf.netfx3.com/photos/articles/images/785/425x307.aspx
http://mdavey.files.wordpress.com/2007/03/lab49wpfequitiestradingdemo.jpg

Note how the GUI elements are arbitrary 2D and 3D graphics. They may be 
overlaid whereas Qt's native and OpenGL widgets cannot be. They have a 
uniform representation whereas Qt widgets and OpenGL content are completely 
separate and uninteroperable. And they can interact with each other whereas 
Qt is completely oblivious to whatever you do in an OpenGL widget.

> Have you ran recent Qt demos distributed with Qt? I'd say they look pretty
> cool in my book.

They would not have impressed me a decade ago, let alone today. Many of them 
don't even work on either of my Debian machines.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Paolo Donadeo]

> In contrast, you can implement a GUI toolkit in OCaml that far exceeds the
> relevant limitations of Qt4 with quite easily.

Jon, did you ever used Qt in a big C++ or Python project? Qt is the
best GUI framework out there, GTK is a ridiculous toy in comparison,
and it took ages to reach this level of "completeness". Frankly, I
think you are heavily undervaluing the task of building a *decent* GUI
from scratch.


-- 
Paolo
~
~
:wq

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Paolo Donadeo]

> No, you just invoke the existing Python bindings. OCaml doesn't have to
> implement anything except bindings to Python, which are already done.

>From this sentence I deduce you don't know *how* the PyQt binding is
generated. It's not a trivial task and the binding layer adds it's own
bugs and glitches, of course. PyQt doesn't interact well with the
Python garbage collector [1] and sometimes you have segfaults *VERY*
hard to be debugged.


[1] I mean: everything works perfectly 99% of times, but problems still persist.


-- 
Paolo
~
~
:wq

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Wednesday 05 November 2008, Jon Harrop wrote:
> On Tuesday 04 November 2008 23:06:00 Kuba Ober wrote:
> > On Tuesday 04 November 2008, Jon Harrop wrote:
> > > You'll just be invoking autogenerated Python code using OCaml so
> > > OCaml's class system is only relevant if you want to do some fancy
> > > statically-typed shim. I'd forget about that and just focus on making
> > > the whole of Qt4 available safely from OCaml in any form first. Even
> > > this is an unsolved problem in the OCaml world!
> >
> > Python bindings for Qt extensively use Python's API. You'd need OCaml to
> > provide said API first.
>
> No, you just invoke the existing Python bindings. OCaml doesn't have to
> implement anything except bindings to Python, which are already done.

Are those bindings fully functional? As in: can Python use classes/objects
declared in OCaml?

>
> > > Of those, only core and GUI might be relevant here but the core lacks
> > > first-class functions for events and callbacks
> >
> > Maybe they are not first-class, but the way they've done it is via
> > preprocessing using moc and things behave like they were first-class.
> >
> > In Qt, if you have a user interface dialog box (a form) called MyForm
> > with an element named say ExitButton, you'd have this:
> >
> > class MyForm : public QDialog {
> > Q_OBJECT
> > 	Ui::MyForm ui;
> >
> > 	MyForm::MyForm(QWidget * parent) : QDialog(parent) {
> > 	  ui.setupUi(this); // calls code autogenerated by UI compiler
> >         }
> >
> > public slots:
> >         void on_ExitButton_clicked() {
> >            ui.ExitButton->hide()
> >         }
> > };
>
> Compare with the equivalent F#+WPF code:
>
>   button.Click.Add(fun _ -> window.Close())

This certainly looks better, but it's not an order of magnitude better.
You can also say in Qt:

connect(ui.ExitButton, SIGNAL(clicked()), ui.ExitButton, SLOT(hide()));

If you want lambda-like functionality, that's doable too via metaprogramming,
although the Trolls didn't venture that way yet. And for a good reason: Qt
still largely compiles (IIRC) with VC 6, and trolls kept it that way ;)

> > The code is hopefully easy to understand and as you can see you don't
> > even have to connect signals and slots manually if you don't want to. All
> > the magic happens behind the scenes. It's very easy to use.
>
> I prefer my F# to your C++.

That's an issue of taste. I do understand the benefits of languages with
first-class functions and other goodies that say OCaml provides, of course,
and I'd much rather use F#, but given that Camelia has to run on modest
hardware and without downloading umpteen megabytes of dependencies, C++
is the right choice for now.

> > > > WPF is just another thing, and it's not really portable in any decent
> > > > sense of the word.
> > >
> > > Sure. My point is that you're building on antique technology when you
> > > could be building modern technology instead.
> >
> > With Qt there's a real chance of machine-translating the code to say LISP
> > or OCaml or what have you.
>
> Even if anyone ever managed to do that, the result would be an unusable
> buggy mess.

My really limited experiments would indicate that in fact it can be done
very cleanly and without introducing bugs. If you have a relatively well
designed codebase, it's easy to port it to almost anything. If you have a big
mess then of course the result will be just as horrible.

C++ code with basic use of templates (what you'll find in most sane code)
translates very well to LISP, whose generics map pretty well to any language
with static and/or explicit types.

> > With WPF, you're stuck with .Net and that's the end of it.
>
> That is not a reason to ignore WPF's design.

I'm just rambling here since I know nothing about WPF, but Qt is quite 
reasonable in how well can UIs designed in it look. It's relatively easy
to use widgets designed in SVG, and it's just as easy to use various
"web 2.0" widgets. A friend of mine recently had a Qt application that
called for a "snazzy" timeline widget. It turned out there was one
written in JavaScript/html by someone, and he just pasted it right into
the application. The integrated webkit took care of rendering it, and
after minor tweaks you would never tell that the control was implemented
on a sub-platform of sorts.

> > > > Camelia could be run on a 486 system with perhaps 64MB of
> > > > memory when compiled using Qt/Embedded. While one can question
> > > > whether it's useful or not, Qt has the benefit of targeting all major
> > > > computing platforms out there.
> > >
> > > That sales hype for Qt is just a reflection of the fact that Qt was
> > > built on sand using a dying technology (C++). In practice, the world
> > > moved on to garbage collected virtual machines for GUI programming
> > > years ago. Qt was left behind and is desperately trying to catch up by
> > > migrating to the JVM but the JVM is now dying...
> >
> > Qt has not migrated to JVM. Relevant Qt classes implement parent-child
> > ownership, implicit copy-on-write and reference counting, and are used
> > just like you would any random collection of things in a
> > garbage-collected language. You're also free to use a garbage collector
> > with any C++ project, this has nothing to do with Qt.
>
> You'd have to Greenspun managed C++ if you want a real GC for your C++
> code. You can pull in Boehm but it breaks existing code and is not reliable
> (hence the Mono project are desperately trying to remove it).
>
> So you are not "free to use a garbage collector with any C++ project" at
> all. Quite the contrary in fact: you're completely screwed if you choose
> C++.
>
> Even industry are running from C++ like rats from a sinking ship:
>
>   http://www.itjobswatch.co.uk/jobs/uk/c++.do
>
> Is that really the trend you want to join?

First of all, I fully appreciate that there are better things than C++ out
there. I also appreciate that you are after using more up-to-date
programming paradigms / environments. But the deal is that at the end
of the day the reality wins and either you have a platform that can do
90% of the boring stuff for you, or you'll implement it yourself.

In the "good old" high school days, I used Borland Pascal for DOS
and I had to deal with maintaining my own text rendering / UI libraries.
I'd much rather not repeat that experience.

.Net for Camelia is not a choice for me (at least not now) simply because
even if I had it run on Mono, there's just so much of Qt's functionality
absent from the libraries that Mono provides -- heck, even from what .Net
provides w/o 3rd party add-ons.

> > > > Using Qt4 in a decent language will be easy once there is a C++
> > > > parser in said decent language.
> > >
> > > You'll be Greenspunning managed C++ from the .NET world. That's a fine
> > > idea if you regard Qt as useful legacy code but I don't see the point
> > > myself. Qt will always have a stone-age API and reimplementing managed
> > > C++ is a huge undertaking.
> >
> > This is not about greenspunning anything. Most of Qt code is written in
> > such way that the C++-isms are completely abstracted out at the level of
> > core classes such as QObject and collections (QList, QVector, etc).
>
> The C++isms are nowhere near being abstracted out. Just look at that code
> you posted above.

While I do understand that you're passing an in-place generated function
as an argument in your example, but still for typical cases that's just
syntactic sugar and gives you nothing apart from code that's perhaps
less verbose than C++. You still need to write the guts of the function
somewhere, and doing it outside of the function invocation is not
that much of a loss. OCaml does not have what amounts to truly first-class
functions IMHO. For a function to be first class -- to be really akin to
any other data type -- there must exist a facility for runtime generation
of the same. I mean, you can create integers and strings at runtime, from
external input, so you should be able to do the same with functions?

LISP has that, OCaml doesn't, right? Porting from LISP to C++ is in
generally impossible if the LISP code generates functions at runtime --
there's no way to do that in pure C++, not even with preprocessing like
trols do with Qt's meta object system.

OCaml doesn't do runtime function generation either, and is in the
same "class" of languages as C++ when it comes to that. Heck, metaprogramming
in C++ is impossible to do in OCaml (right?), but is trivial in LISP! So I'd
even argue that C++ has some compile-time code generation built right in
that's lacking in OCaml.

> > By
> > translating the use of basic Qt primitives (really QObject and
> > collections) to whatever OCaml/Lisp/Python/blabla provides, you can very
> > cleanly port Qt codebase to another language, and it will look pretty
> > much as if it were written in said language.
>
> A triumph of hope over reality.

OK, whenver I get time I will post some side-by-side code taken verbatim
from Qt's sources, and how it looks hand-translated to OCaml; I'll strive
to do the hand-translation using methods that would be easy to implement.

> > > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > > the relevant limitations of Qt4 with quite easily.
> >
> > Qt has very few language-inherent limitations that are not abstracted out
> > to the core. Whatever other limitations Qt has are design decisions that
> > have little to do with choice of the language.
>
> I was referring to the limitations of Qt itself. Look at this example from
> one of our products:
>
>   http://www.ffconsultancy.com/products/fsharp_for_visualization/demo2.html
>
> That uses a 3D layer with a 2D layer overlaid. The labels are 2D widgets.
> That's trivial with WPF because it renders everything through a single
> pipeline: you just put a 2D widget over a 3D widget. That's impossible with
> Qt its OpenGL widget is completely uninteroperable.

You havent recently looked at Qt's demos, did you? Qt lets you do just that.

> Trolltech are hailing Mathematica 6 as a success story for Qt. Look at the
> Mathematica notebook interface:
>
> http://reference.wolfram.com/mathematica/tutorial/Files/DoingComputationsIn
>Notebooks.en/1.gif
>
> That is one giant OpenGL widget covering the whole window and everything is
> rendered using custom code precisely because Qt does not provide the
> required functionality.

What you say may well be true, but the example screenshot you provided is
trivial to implement in Qt without going anywhere near OpenGL. If what the
screenshot shows is done in  OpenGL then they surely spent a lot of time
reinventing the wheel. Do you have any links to screenshots that actually show
benefits of using OpenGL for that?

> > Qt has to cover a lot of platform-specific ground. Reimplementing it from
> > scratch implies having to fix most of the bugs that Qt folks have already
> > fixed. Qt's code base as a fine reference for a lot of platform-specific
> > borkedness that Qt's users have run into, and the trolls have fixed.
>
> FUD. Those are design flaws specific to Qt. OCaml+OpenGL source code is
> already portable.

Correct me if I'm wrong, but isn't core OpenGL a one-way street? As in it's
oblivious to everything but getting the scene rendered? Admittedly I've last
dealt with OpenGL sometime in late 90s, but from what I recall all notion of
user input was handled very rudimentarily by what amounted to bolt-on 
libaries. And said bolt-on libraries were completely oblivious to the rest of
the common services provided by the underlying operating system.

I can't see, for example, how OCaml+OpenGL code could inherently interoperate
with  anything when it comes to rendering the same thing on screen and
on the printer. Or passing data between applications (think clipboard). Or
embedding itself in another application (think browser plugins or ActiveX
controls, or their equivalent on OS X whatever it may be). And so on.
All of that is provided by any modern application development framework
such as Qt, or Carbon, or Cocoa.

When it comes to those "little things", I presume that the framework that you
developed simply skips over them, and that's where a lot of hard, mundane
work goes.

> > Show me a generic, reuseable OCaml-written, OpenGL-based common widgets
> > such as model-view tables, buttons, editors, tree views, ... Then we'll
> > talk.
>
> I've actually implemented most of that in Smoke and Presenta already. We
> never made any money out of it (selling OCaml libraries to OCaml
> programmers is almost impossible) so I am considering open sourcing it all.

Now you've perhaps got my attention, although I still dislike the idea of
using OpenGL to render it, since on many everyday platforms OpenGL is in
useless state. Perhaps if there was an abstraction layer that could
work on OpenGL and DirectX 9 and 10, then maybe it'd be worthwhile.

I still would like seeing how it works in practice - say your application
embeds itself via OLE into a typical Office application. How many concurrently
embedded OLE documents can be open before you run into limitations of
OpenGL or DirectX in number of visible "windows"? And so on...

> > > Easiest for me to answer by just posting our code. Here is the code
> > > from the current version of Smoke that typesets paragraphs of text by
> > > overflowing words onto new lines:
> > >
> > > let rec charsmap = function
> > >
> > >     | 'f' :: 'f' :: 'i' :: t -> (`CMR, 177) :: charsmap t
> > >     | 'f' :: 'f' :: 'l' :: t -> (`CMR, 178) :: charsmap t
> > >     | 'f' :: 'f' :: t -> (`CMR, 174) :: charsmap t
> > >     | 'f' :: 'i' :: t -> (`CMR, 175) :: charsmap t
> > >     | 'f' :: 'l' :: t -> (`CMR, 176) :: charsmap t
> > >     | c :: t -> charmap c :: charsmap t
> > >     | [] -> []
> > >
> > > let word string =
> > >   let string = charsmap(list_of_string string) in
> > >   let aux x (font1, c1) (font2, c2) =
> > >     let contours = Cmfont.glyph font1 c1 in
> > >     let contours = List.map Contour.make contours in
> > >     let g = List.map (Contour.trans (translate x 0.)) contours in
> > >     let advance =
> > >       if font1=font2 then Cmfont.advance font1 c1 c2 else
> > >         Cmfont.advance `CMR 32 32 in
> > >     x +. advance, g in
> > >   let rec aux2 x = function
> > >
> > >     | [] -> []
> > >     | h1::t ->
> > >
> > >         let h2 = match t with h2::_ -> h2 | _ -> `CMR, 32 in
> > >         let x, g = aux x h1 h2 in
> > >         g :: aux2 x t in
> > >   aux2 0. string |> List.concat |> ContourGeometry.of_contours
> > >
> > > let word = memoize (fun _ -> word)
> > >
> > > let paragraph ~skip ~justify ~width ~string =
> > >   let words = List.map word (String.split ' ' string) in
> >
> > LOL. If you seriously think it's worth reimplementing the wheel for
> > a millionth time, go for it.
> >
> > Qt already can do rendering in OpenGL, so if one wants to do something
> > that actually really needs OpenGL, it can be done.
> >
> > But to just render a paragraph of text? There's code for it in Qt ;)
>
> You have completely missed the point, of course.
>
> You will need to use some modern GUI applications before you can begin to
> understand how they are designed. These screenshots might help:
>
> http://download.infragistics.com/users/AndrewF/WPF-CAB.png
> http://www.deepshift.com/images/WPFSampleSourcePosted_B5E0/SNAG000015.jpg
> 
http://www.mismashd.com/BlogImages/EndtoendWPFdemoFamily.Show_E22C/familyshow3.jpg
>http://wpf.netfx3.com/photos/articles/images/785/425x307.aspx 
> http://mdavey.files.wordpress.com/2007/03/lab49wpfequitiestradingdemo.jpg

That's what Qt is for - it's no big deal to do it in Qt, and moreover it
will still work reasonably well on a platform with no hardware 3D support
at all.

I really suggest you look at demos in Qt.

> Note how the GUI elements are arbitrary 2D and 3D graphics. They may be
> overlaid whereas Qt's native and OpenGL widgets cannot be. They have a
> uniform representation whereas Qt widgets and OpenGL content are completely
> separate and uninteroperable. And they can interact with each other whereas
> Qt is completely oblivious to whatever you do in an OpenGL widget.

Qt's OpenGL widget is just as any other widget in terms of
"interoperability". Qt fully supports rendering its own widgets into
textures that can be then used in OpenGL, and vice versa. The biggest deal
with most of what you've shown is that none of it really requires OpenGL --
it's mostly basic SVG stuff and basic transforms available in Qt.
For the few examples where there really are views that benefit from true
3D rendering, you can use OpenGL just for that. Output from OpenGL can be
sliced, diced and integrated anywhere you want within Qt's regular widget
system -- it may not be as clean as writing everything in OpenGL, but then
trolls are not really sitting idly on their hands. Almost every major Qt
release includes big chunks of new functionality that's not only non-trivial,
but has comparatively modest hardware requirements.

> They would not have impressed me a decade ago, let alone today. Many of
> them don't even work on either of my Debian machines.

Interesting that they don't work -- I wonder why. As for the demos, they show
mostly the same stuff that you show in the included screenshots.


Please don't understand me wrong: I do understand the benefits of using
higher-level concepts for description of stuff to be shown to the user.
3D scene descriptions are just a logical step above display postscript,
which is alive and well in OS X. I would just as well use them.

Qt is going that way: they have painter paths, which are a concept straight
from display postscript, and I doubt they are just ignorant as to what
everyone else is doing.

But the big deal is that a lot of that has still to work on quite
low-common-denominator systems. One thing is designing say a $10k-priced
CAD system, or something else for a vertical market where you can either ship
an Nvidia card bundled in the box, or give them coupons for discounts on new
laptops that have relevant chip in them. Or just bundle the darn machine
in the box. But something that will work well on 5 year old hardware has to do
much better than simply use OpenGL "sticking to the book". I'm sure you've
heard of various OpenGL implementation bugs -- Qt folks had to work around
them, and any OCaml-or-otherwise OpenGL -based toolkit you'll use has to work
around them too.

So it's not like OpenGL suddenly gets rid of all platform quirks: that'd be
ideal, but it just ain't so, and the same goes for a more "classic" toolkit
like Qt.

As Qt is actively pursing more advanced display models, bashing
them for being continously outdated is like bashing M$ -- it lets you vent,
but is unproductive. I doubt they won't go in that general direction, but
the benefit you get from using their platform is that it quite simply
works -- even on ancient Windows 95 hardware that they claim they don't
support anymore.

Things like this
http://doc.trolltech.com/4.4/qt4-4-intro.html#widgets-in-graphics-view
and that
http://doc.trolltech.com/4.4/qt4-4-intro.html#qt-for-embedded-linux
actually work on very modest hardware, which cannot really be said about
OpenGL.

I of course agree that if both Qt and OpenGL folks did their homeworks
properly, both methods of rendering 3D content (or what pretends to be 3D)
have same asymptotic complexity. After all, if you're say rendering
a transformed bitmap, no matter what the underlying toolkit, the mathematics
are the same. Where Qt wins is that the darned constant factor, conveniently
ignored even in "mid-level" CS courses, is pretty important. Mesa software
renderer works, but good luck persuading anyone to use it ;)


Commonalizing 3D scene descriptions and bringing them into use as a common
way of doing things requires some serious manpower -- if any "small player"
could pull that off, it'll be either trolls or some well-funded startup that
better had a few key customers in line. Qt is getting to be quite entrenched
in some fields, and the big win with Qt is that it interoperates with a lot
of legacy code (Motif or WINAPI). A company with a million-line C/C++ codebase
won't just suddenly abandon it all and decide to port it to OCaml. Not unless
there are tools that for the most case can recompile said code into 
maintainable OCaml (perhaps C++-resembling OCaml, but still OCaml).

Imagine you have a huge C++ codebase that currently uses Qt, and someone tries
to persuade you to port it to MPF in C# or say OCaml/OpenGL based framework.
They will be much more likely to attempt that if they can, with minimal
effort, translate their current codebase to the new platform. They can then
test it, hone out bugs and release, and then work on refactoring it to take
advantage of what the language provides.

The example that comes to mind is how Alibre folks have went. They have a nice
CAD system originally developed for M$ Java. They recently released a port
to .Net J#, and now can work on porting it bit-by-bit to say C# (though
I wish they used F#!). J# & friends took care of "translating" the code
to make it work in the new environment.

Doing it with managed C++ is somewhat harder methinks, even though
managed C++ does exist. The big deal with managed C++ is that C++ never
had a "standard" framework for doing UI stuff. Java code uses Swing
or whatnot, so J# folks reimplemented parts of that (IIRC). Most C/C++
code will use MFC and/or WINAPI and/or GTK and/or Qt. That's a pretty
big target for M$ so they couldn't be as helpful in porting C/C++
code to .Net: it's not really so much plug-and-play anymore.


Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 08:53:28 Paolo Donadeo wrote:
> > No, you just invoke the existing Python bindings. OCaml doesn't have to
> > implement anything except bindings to Python, which are already done.
>
> From this sentence I deduce you don't know *how* the PyQt binding is
> generated. It's not a trivial task and the binding layer adds it's own
> bugs and glitches, of course. PyQt doesn't interact well with the 
> Python garbage collector [1] and sometimes you have segfaults *VERY*
> hard to be debugged.

Yes, that was my concern but note that I was not talking about porting PyQt to 
OCaml. However, Trolltechs own demos segfault on my machine regularly and KDE 
is unreliable despite being written almost entirely in Qt's native language. 
So I would not be so hasty to blame PyQt for Qt's reliability problems.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> However, Trolltechs own demos segfault on my machine regularly
> and KDE is unreliable despite being written almost entirely in Qt's native
> language. So I would not be so hasty to blame PyQt for Qt's reliability
> problems.

As a longtime KDE user, I'm very much disappointed by the most recent
major KDE release, in terms of how much slower it got on my
not-all-that-old-hardware (an AMD64 Compaq machine running in 32 bits).
A lot of it comes from the fact that my home directory is mounted via NFS,
but this used to work a lot better.

A typical KDE application literally hammers the filesystem upon every
single application startup, and it got progressively worse every major
KDE release. Qt is not an angel in that respect either -- that's about
the major gripe I have with Qt.

As a longtime developer who uses Qt (recently only for open source stuff),
I do know that Qt's performance in general has continuously improved, and
they have made real low-level architectural improvements. New KDE releases
always hammered Qt pretty hard, it was a similar story when KDE 3 came
out, although the perceived slowdown wasn't as bad (and it was on worse
hardware).

But Qt can't really help with the application and the KDE "middleware"
making things worse than they need to be...

As for Qt demos segfaulting: I wonder if that may be due to OpenGL bugs.
Seriously.

Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > pretty cool in my book.
>
> They would not have impressed me a decade ago, let alone today. Many of
> them don't even work on either of my Debian machines.

I have one question regarding OpenGL: maybe it's just me, but isn't core,
or "historical" core OpenGL blissfully unaware of simple concepts such as a
path, a brush, stroking a path etc? This was long time ago, but I recall that
drawing a circle using OpenGL implies that you (or some middleman library) has
to discretize the circle into triangles, and then render that.

Again, correct me if I'm wrong, but typical OpenGL-based UI rendering
will do good old antialiased software 2D rendering on OpenGL textures,
and the composite some simple 3D models with those textures applied.
[Or it may, at a cost of generating *way more* triangles, use shader
programs.]

That way you can get goodies like shadows of text rendered in a window
with transparent background, but it's really awkward to do directly in
OpenGL. These days I imagine this "2D" rendering can be done using
shader programs, but that excludes a lot of commonplace hardware
outright, and hits some implementation bugs hard (just look around at
various game forums). And I really don't quite love the idea of
generating a bazillion triangles for the 3D hardware to then
shade: I wish 3D hardware could work with splines of some sort (does it?).

AFAIK/IIRC, as soon as you wish to move to a higher level scene
description, where basic primitives such as paths live in 3D, you have
to implement a whole lot on top of OpenGL, and there are no real
standards as to how to do it. If anything, Cocoa and MPF (?) may be
examples of how to go about it, but that's a long shot of where
we'd all like to be.

I would like nothing better than to work with hierarchical interactive
display representation, where simple things remain simple: say you have
a letter shown in your text editor widget, and you want to know where
the said letter is located. With a scene description graph, you can
extract that information -- the way Qt does it so far either requires the
text layouter to provide you with relevant API, or you have to plug yourself
between the layouter and the paint engine and literally listen for where the
glyphs get painted. The scene description would be easier to use, of
course. If the scene description has links into the underlying text document,
as it well should, then it gets even easier.

So, please understand that I'm not oblivious to benefits of thinking in
higher levels of abstraction, but I'm also practical and know that Qt
provides me with a whole big lot of cross-platform functionality that
simply doesn't exist anywhere else in one coherent platform.

Oh, and it's not like scene graphs and whatnot cannot be nicely done
in C++ ;) (ducks and runs).

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Wednesday 05 November 2008, Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK is a ridiculous toy in comparison,
> and it took ages to reach this level of "completeness". Frankly, I
> think you are heavily undervaluing the task of building a *decent* GUI
> from scratch.

I wholeheartedly agree.

Jon's valid point is that some concepts in Qt's core are unnecessarily
complicated due to the fact that there is no higher-level concept of
a display list or scene description.

This necessitates things which in would be hacks given display lists
/ scene descriptions. Case in point:

A QTextEditor or QPlainTextEditor is an editor widget which works on
a QTextDocument. A QTextDocument has an associated implementation of an
QAbstractTextDocumentLayout. The latter has methods such as anchorAt(QPoint),
blockBoundingRect(QTextBlock) and hitTest(QPoint). Those methods
are only necessary since once a document is laid out by the layout
engine, any links between the rendered representation and 
the document are hidden by the Q...TextDocumentLayout. What 
QTextDocumentLayout does is to simply send a bunch of primitives to
the QPainter which actually renders them on some device, but this
is done without using any sort of a list.

Even if a display list (QPicture passes for it) was used, it's a closed-up
class that, while holding a display list, provides no trivial access for it.
You can of course play() a QPicture on your own a QPaintDevice that talks to
your own QPaintEngine, but there is no functionality in place to attach
your own data to elements of such a display list, unless you resort
of course to another layer of hacks. No such metadata functionality
exists for QPainterPath (which is closer to a real display list) either.

And neither QPainterPath nor QPicture are really hierarchical. About the only
way to think of a hierarchy for Qt's drawing system is at the level of 
QPainter, which provides save() / restore() functionality for its state.
All of this structure is implemented by the QPainter(), so as soon as
a QPainter() paints on a QPaintDevice(), what little hierarchy was there
is irretrieveably lost.

So Qt would benefit from having real, hierarchical display lists, which could
then be expanded to include 3D functionality. Trolls may well be working
on this (I hope they do!), but it's no small feat to have it done in a way
which "just works" like most of Qt does.

Qt is not bug free, and a colleague of mine is hard at work bugging the trolls
with a new (mostly event-related) bug every week (not kidding you). But he
really runs into some corner/less-than-well-documented cases due to what
he's trying to do. Yet that's still way better than dealing with a toolkit
that's fairly new (MPC) or something that gives you 10% of the functionality
you need.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Wednesday 05 November 2008, Jon Harrop wrote:
> On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
[snip]
> > So, please understand that I'm not oblivious to benefits of thinking in
> > higher levels of abstraction, but I'm also practical and know that Qt
> > provides me with a whole big lot of cross-platform functionality that
> > simply doesn't exist anywhere else in one coherent platform.
>
> Maybe if I release Smoke as open source software OCaml will become usable
> for advanced GUI programming. If I don't, I think OCaml is dead in the
> water in this respect.

Would it be useful, then, to have Smoke have a built-in renderer for
embedded/non-accelerated platforms? It should still be faster than Mesa,
since you can work with higher-level objects that can perhaps be drawn
faster with object-specific rendering functions, instead of having
to tesselate everything and then just work on triangles?

I'm pretty sure that such built-in rendering would perform better and
have smaller footprint for non-accelerated platforms than going through
the whole OpenGL stack.

What do you think?

Then, there's still a whole lot of work in getting OCaml interoperate
with native platform (think OLE, browser plugins, yada yada).

Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jérémie Dimino]

Jon Harrop <jon@ffconsultancy.com> writes:

> I'd forget about that and just focus on making the whole of Qt4 available 
> safely from OCaml in any form first. Even this is an unsolved problem in the 
> OCaml world!

I suggest an idea. I know that Qt4 offer some facility to export
objects trough DBus [1]. So one can write a small C++ application that
allow other applications to create Qt objects and export them, then
use Qt in ocaml via DBus.

Here are the advantages i see:

- the C++ code and the ocaml code would run in different processes, so
  we do not have to care about all the C++isms of Qt in the ocaml
  application.

- this would make Qt available to any languages that have DBus.
  For ocaml i am currently writing a pure ocaml DBus implementation [2].

[1] http://en.wikipedia.org/wiki/D-Bus

[2] http://forge.ocamlcore.org/projects/obus/

-- 
Jérémie Dimino <jeremie@dimino.org>

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 15:20:26 Kuba Ober wrote:
> > > Have you ran recent Qt demos distributed with Qt? I'd say they look
> > > pretty cool in my book.
> >
> > They would not have impressed me a decade ago, let alone today. Many of
> > them don't even work on either of my Debian machines.
>
> I have one question regarding OpenGL: maybe it's just me, but isn't core,
> or "historical" core OpenGL blissfully unaware of simple concepts such as a
> path, a brush, stroking a path etc?

That is correct. Smoke already implements all of that:

  http://www.ffconsultancy.com/products/smoke_vector_graphics/?ob

> This was long time ago, but I recall 
> that drawing a circle using OpenGL implies that you (or some middleman
> library) has to discretize the circle into triangles, and then render that.

Smoke uses a much more sophisticated approach based upon anisotropic 
hierarchical decomposition that provides high-performance culling of 
arbitrary vector shapes. So you can feed it a Gb map of the world and use it 
to fly around in real-time without having to write anything difficult 
yourself. You can even apply arbitrary affine transforms to vector shapes and 
it will continue to make maximal reuse of tesselations and cache them on 
graphics hardware if it is available.

> Again, correct me if I'm wrong, but typical OpenGL-based UI rendering
> will do good old antialiased software 2D rendering on OpenGL textures,
> and the composite some simple 3D models with those textures applied.
> [Or it may, at a cost of generating *way more* triangles, use shader
> programs.]

No, Smoke keeps everything in vector form and renders triangles. Smoke can 
also run entirely in software using Mesa and can render PostScript in 
software over an order of magnitude faster than GhostView. But Smoke was 
designed specifically to leverage hardware accelerated OpenGL and it runs 
about two orders of magnitude faster when that is available.

> That way you can get goodies like shadows of text rendered in a window
> with transparent background, but it's really awkward to do directly in
> OpenGL. These days I imagine this "2D" rendering can be done using
> shader programs, but that excludes a lot of commonplace hardware
> outright, and hits some implementation bugs hard (just look around at
> various game forums). And I really don't quite love the idea of
> generating a bazillion triangles for the 3D hardware to then
> shade: I wish 3D hardware could work with splines of some sort (does it?).

The nVidia 9 series is the first hardware to provide decent support for 
splines, AFAIK. Decent support requires vertex creation in-hardware.

> AFAIK/IIRC, as soon as you wish to move to a higher level scene
> description, where basic primitives such as paths live in 3D, you have
> to implement a whole lot on top of OpenGL, and there are no real
> standards as to how to do it. If anything, Cocoa and MPF (?) may be
> examples of how to go about it, but that's a long shot of where
> we'd all like to be.

I don't think it is a long shot at all.

> I would like nothing better than to work with hierarchical interactive
> display representation, where simple things remain simple: say you have
> a letter shown in your text editor widget, and you want to know where
> the said letter is located. With a scene description graph, you can
> extract that information -- the way Qt does it so far either requires the
> text layouter to provide you with relevant API, or you have to plug
> yourself between the layouter and the paint engine and literally listen for
> where the glyphs get painted. The scene description would be easier to use,
> of course. If the scene description has links into the underlying text
> document, as it well should, then it gets even easier.

Smoke already provides a basic form of that functionality. It uses OpenGL 
picking to provide a list of integers that describe the path through the 
scene graph to the nearest shape in the given region. Check out the source 
code to the interactive tiger demo, for example.

> So, please understand that I'm not oblivious to benefits of thinking in
> higher levels of abstraction, but I'm also practical and know that Qt
> provides me with a whole big lot of cross-platform functionality that
> simply doesn't exist anywhere else in one coherent platform.

Maybe if I release Smoke as open source software OCaml will become usable for 
advanced GUI programming. If I don't, I think OCaml is dead in the water in 
this respect.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

> > And neither QPainterPath nor QPicture are really hierarchical. About the
> > only way to think of a hierarchy for Qt's drawing system is at the level
> > of QPainter, which provides save() / restore() functionality for its
> > state. All of this structure is implemented by the QPainter(), so as soon
> > as a QPainter() paints on a QPaintDevice(), what little hierarchy was
> > there is irretrieveably lost.
>
> There shouldn't even be any state.

I agree, but in absence of hierarchy they resort to kludges like that...

> > So Qt would benefit from having real, hierarchical display lists, which
> > could then be expanded to include 3D functionality. Trolls may well be
> > working on this (I hope they do!), but it's no small feat to have it done
> > in a way which "just works" like most of Qt does.
>
> That is exactly what WPF already provides. Trolltech told me they were
> working on it when I was evaluating buying the commercial Qt. That was at
> least 5 years ago. I doubt Qt will live long enough to ever see it
> implemented.

At least they now have QPainterPath -- I wish they worked harder on
ubiquitous display lists, though.

> > Qt is not bug free, and a colleague of mine is hard at work bugging the
> > trolls with a new (mostly event-related) bug every week (not kidding
> > you). But he really runs into some corner/less-than-well-documented cases
> > due to what he's trying to do. Yet that's still way better than dealing
> > with a toolkit that's fairly new (MPC) or something that gives you 10% of
> > the functionality you need.
>
> What is MPC?

s/MPC/WPF/
My brain is playing tricks on me ;)

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Kuba Ober]

On Wednesday 05 November 2008, Jérémie Dimino wrote:
> Jon Harrop <jon@ffconsultancy.com> writes:
> > I'd forget about that and just focus on making the whole of Qt4 available
> > safely from OCaml in any form first. Even this is an unsolved problem in
> > the OCaml world!
>
> I suggest an idea. I know that Qt4 offer some facility to export
> objects trough DBus [1]. So one can write a small C++ application that
> allow other applications to create Qt objects and export them, then
> use Qt in ocaml via DBus.
>
> Here are the advantages i see:
>
> - the C++ code and the ocaml code would run in different processes, so
>   we do not have to care about all the C++isms of Qt in the ocaml
>   application.
>
> - this would make Qt available to any languages that have DBus.
>   For ocaml i am currently writing a pure ocaml DBus implementation [2].

The biggest problem is that this limits you to what's exposed by Qt's
signal/slot interface. That's too little to actually use Qt but for very
simple applications that pass either relatively simple data types around,
or pass QObjects around.

If you want to create and pass something less-than-simple, say a QList<>
of some custom type, you're screwed and this functionality is necessary
for any real Qt interoperability.

Cheers, Kuba

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 08:39:32 Paolo Donadeo wrote:
> > In contrast, you can implement a GUI toolkit in OCaml that far exceeds
> > the relevant limitations of Qt4 with quite easily.
>
> Jon, did you ever used Qt in a big C++ or Python project? Qt is the
> best GUI framework out there, GTK is a ridiculous toy in comparison,
> and it took ages to reach this level of "completeness". Frankly, I
> think you are heavily undervaluing the task of building a *decent* GUI
> from scratch.

I've implemented GUIs in C++ using Qt, and in OCaml using Smoke, and in F# 
using WPF. Qt is by far the most limited in terms of functionality and is 
filled with incidental complexity to boot. Finally, Qt isn't even safe so Qt 
GUI apps are prone to crashing to the extent that even Trolltech's own tiny 
demo programs crash.

I agree that GTK is worse but my point is simply that Qt leaves a lot to be 
desired, primarily because it is entirely founded upon old-school programming 
practice that is long since outdated.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 15:05:13 Kuba Ober wrote:
> > However, Trolltechs own demos segfault on my machine regularly
> > and KDE is unreliable despite being written almost entirely in Qt's
> > native language. So I would not be so hasty to blame PyQt for Qt's
> > reliability problems.
>
> As a longtime KDE user, I'm very much disappointed by the most recent
> major KDE release, in terms of how much slower it got on my
> not-all-that-old-hardware (an AMD64 Compaq machine running in 32 bits).
> A lot of it comes from the fact that my home directory is mounted via NFS,
> but this used to work a lot better.

I now have a terabyte of ext3, 4Gb of RAM and eight 2.1GHz Opteron cores and 
KDE still runs like a dog, burning only 1 core at a time. This is a fresh 
install on a new machine as well, so distro baggage isn't the problem.

> A typical KDE application literally hammers the filesystem upon every
> single application startup, and it got progressively worse every major
> KDE release. Qt is not an angel in that respect either -- that's about
> the major gripe I have with Qt.

I believe that fixing this is tantamount to Greenspunning managed C++ so I 
don't believe that will ever happen. Qt will be relegated to the embedded 
niche before dying completely.

> As a longtime developer who uses Qt (recently only for open source stuff),
> I do know that Qt's performance in general has continuously improved, and
> they have made real low-level architectural improvements. New KDE releases
> always hammered Qt pretty hard, it was a similar story when KDE 3 came
> out, although the perceived slowdown wasn't as bad (and it was on worse
> hardware).

I think these are all knock-on effects. C++ is an awful programming language 
for high-level work because it is so inefficient (e.g. no GC). Qt is 
effectively C++-only so almost all non-trivial Qt applications are sluggish.

If you build a GUI toolkit on a solid foundation like OCaml (when it gets its 
parallel GC) then GUI programming becomes much easier and much more 
efficient. That is unquestionably the way forward, as .NET has proven. Using 
Qt or C++ is just building on sand.

> As for Qt demos segfaulting: I wonder if that may be due to OpenGL bugs.
> Seriously.

This is a high-performance OpenGL workstation that is used almost entirely for 
scientific visualization using OpenGL. None of our other software has any 
problems, just Qt.

My guess is the Qt code isn't detecting error conditions at startup when it is 
obliged to, whereas glut and SDL are. Moreover, these are old bugs in Qt: I 
saw them years ago as well.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 15:44:24 Kuba Ober wrote:
> And neither QPainterPath nor QPicture are really hierarchical. About the
> only way to think of a hierarchy for Qt's drawing system is at the level of
> QPainter, which provides save() / restore() functionality for its state.
> All of this structure is implemented by the QPainter(), so as soon as a
> QPainter() paints on a QPaintDevice(), what little hierarchy was there is
> irretrieveably lost.

There shouldn't even be any state.

> So Qt would benefit from having real, hierarchical display lists, which
> could then be expanded to include 3D functionality. Trolls may well be 
> working on this (I hope they do!), but it's no small feat to have it done
> in a way which "just works" like most of Qt does.

That is exactly what WPF already provides. Trolltech told me they were working 
on it when I was evaluating buying the commercial Qt. That was at least 5 
years ago. I doubt Qt will live long enough to ever see it implemented.

> Qt is not bug free, and a colleague of mine is hard at work bugging the
> trolls with a new (mostly event-related) bug every week (not kidding you).
> But he really runs into some corner/less-than-well-documented cases due to
> what he's trying to do. Yet that's still way better than dealing with a
> toolkit that's fairly new (MPC) or something that gives you 10% of the
> functionality you need.

What is MPC?

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 15:55:24 Kuba Ober wrote:
> Would it be useful, then, to have Smoke have a built-in renderer for
> embedded/non-accelerated platforms? It should still be faster than Mesa,
> since you can work with higher-level objects that can perhaps be drawn
> faster with object-specific rendering functions, instead of having
> to tesselate everything and then just work on triangles?
>
> I'm pretty sure that such built-in rendering would perform better and
> have smaller footprint for non-accelerated platforms than going through
> the whole OpenGL stack.
>
> What do you think?

Smoke already runs fine using Mesa and Mesa is still seeing huge performance 
improvements, e.g. using run-time generated code via LLVM. If you desperately 
needed Smoke on an embedded platform, I would just port it to OpenGL ES 
instead of reinventing the wheel.

> Then, there's still a whole lot of work in getting OCaml interoperate
> with native platform (think OLE, browser plugins, yada yada).

I would opt for the loosest available binding, e.g. sending XML over sockets, 
and avoid native code FFI in OCaml for anything high-level at all costs.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 17:08:21 Jon Harrop wrote:
> Smoke already runs fine using Mesa and Mesa is still seeing huge
> performance improvements, e.g. using run-time generated code via LLVM. If
> you desperately needed Smoke on an embedded platform, I would just port it
> to OpenGL ES instead of reinventing the wheel.

Incidentally, I think the most kickass development in hardware I've seen 
recently is the latest quad core GHz ARM CPUs with integrated nVidia graphics 
hardware. ARM are really stamping on Intel's face and kicking AMD in the 
balls these days.

BTW, anyone got OCaml running on a Pandora? :-)

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Wednesday 05 November 2008 16:33:43 Jérémie Dimino wrote:
> Jon Harrop <jon@ffconsultancy.com> writes:
> > I'd forget about that and just focus on making the whole of Qt4 available
> > safely from OCaml in any form first. Even this is an unsolved problem in
> > the OCaml world!
>
> I suggest an idea. I know that Qt4 offer some facility to export
> objects trough DBus [1]. So one can write a small C++ application that
> allow other applications to create Qt objects and export them, then
> use Qt in ocaml via DBus.
>
> Here are the advantages i see:
>
> - the C++ code and the ocaml code would run in different processes, so
>   we do not have to care about all the C++isms of Qt in the ocaml
>   application.
>
> - this would make Qt available to any languages that have DBus.
>   For ocaml i am currently writing a pure ocaml DBus implementation [2].

Yes, that's exactly the kind of loose binding I would opt for. Good thinking!

There's still the question of how to write the C++ bit. Longer term, 
generating C++ at run-time using the LLVM's CLang project might be an 
alluring option but I'd still value process separation as long as unsafe 
languages are in the mix.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Richard Jones]

On Sat, Nov 15, 2008 at 01:02:53PM +0000, Jon Harrop wrote:
>   http://video.msn.com/video.aspx?vid=0bcf031b-4213-48ef-adff-0e60f8dbce4b
> 
> Linux has nothing like this.

Huh?  Guess you've not used compiz then?  Linux has had it since
before 2005 and it's so annoying I always turn it off.

Rich.

-- 
Richard Jones
Red Hat

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

We were discussing GUI programming in OCaml recently. I just stumbled upon 
this video "wpf graphics" that demonstrates some of the capabilities of 
Microsoft's Windows Presentation Foundation:

  http://video.msn.com/video.aspx?vid=0bcf031b-4213-48ef-adff-0e60f8dbce4b

Linux has nothing like this. If OCaml gets a parallel GC then I think it would 
be well worth implementing an alternative GUI toolkit from scratch in OCaml 
using OpenGL and drawing upon WPF's core design that centers around a single 
unified renderer and unified (and safe!) representation. OCaml has great 
potential for GUI programming...

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Jon Harrop]

On Saturday 15 November 2008 12:25:17 Richard Jones wrote:
> On Sat, Nov 15, 2008 at 01:02:53PM +0000, Jon Harrop wrote:
> > ...design that centers around a single unified renderer and unified
> > (and safe!) representation ...
>
> Huh?  Guess you've not used compiz then?

Compiz does not provide a unified rendering pipeline for GUI programming, it 
just composes pixmaps into OpenGL textures.

> Linux has had it since before 2005 and it's so annoying I always turn it
> off. 

Yes, the value is in a unified foundation and not the wobbly windows.

For example, WPF allows you to define custom 3D objects and use them 
interoperably within the GUI framework. The contents of any widget may be any 
scene graph. They expose the same events and so on.

-- 
Dr Jon Harrop, Flying Frog Consultancy Ltd.
http://www.ffconsultancy.com/?e

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Florent Monnier]

> it just composes pixmaps into OpenGL textures.

in case there would be Xlib/openGL hackers interested by this technique 
which is explained here for C:
http://www.opengl.org/wiki/index.php/Programming_OpenGL_in_Linux:_Creating_a_texture_from_a_Pixmap
it can be achieved in OCaml too, this demo program converted from C to ocaml 
as the script called "pixmap_to_gl.ml" is in the Xlib-OCaml bindings there:
http://www.linux-nantes.org/~fmonnier/OCaml/Xlib/

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Maxence Guesdon]

On Thu, 23 Oct 2008 15:53:19 +0200
"Baudet David" <dafide18@gmail.com> wrote:

> > I agree.  There are many different use cases, different types of developers
> > with different goals and styles.  Putting most of the heavy lifting into
> > external tools so that can be integrated into any editor would be a great
> > boon across the board.
> >
> > Actually, how did ocamlwizard go?  I seemed to have missed the OSC results.
> > The proposal looked promising..
> >
> 
> 
> Ocamlwizard is available here from Osp Meeting: http://ocamlwizard.lri.fr/
> The OSP result is here : http://ocaml.janestreet.com/?q=node/38
> 
> Me and Mohammed were very busy this last month (from the osp meeting), but
> Mohamed have updated the website and the Newer will be online in few days, I
> think...
> 
> Me, I try to finish the "developper documentation" this next week to help
> some best implementation of this tools in emacs and other IDE... and to
> explain our implementation, I prepare too a short video to show "how
> install" and "use" ocamlwizard.
> 
> We try to finish some part of ocamlwizard, but we can't promise when... for
> this time.
> 
> We didn't answer at all question on ocamlwizard, but I have read it (and I
> am sure, Mohamed too) and I wil continue every weeks to read caml list...
> and I hope this developper documentation answer for me.

Talking about ocamlwizard, why does it embed a part of ocaml sources
rather than use a configure option to find the compiled sources of ocaml ?
This would allow to compile ocamlwizard with any (compatible) version of
ocaml (even a cvs version). For example, how to use it with ocaml 3.11 beta1
without modifying the copied parts of ocaml present in ocamlwizard ?

That's how topcameleon is compiled, asking the user where the compiled
sources of ocaml are located.

Having the compiled sources of ocaml is not a problem for an ocaml
developer, and the ocamlwizard users are ocaml developers, aren't they ?

For users of pre-compiled packages (debian, etc.), this is not a problem
for the packagers to have ocamlwizard compiled using the sources of ocaml
used for the ocaml package.

Regards,


-- 
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/

Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?

[Baudet David]

[-- Attachment #1: Type: text/plain, Size: 1434 bytes --]

> I agree.  There are many different use cases, different types of developers
> with different goals and styles.  Putting most of the heavy lifting into
> external tools so that can be integrated into any editor would be a great
> boon across the board.
>
> Actually, how did ocamlwizard go?  I seemed to have missed the OSC results.
> The proposal looked promising..
>


Ocamlwizard is available here from Osp Meeting: http://ocamlwizard.lri.fr/
The OSP result is here : http://ocaml.janestreet.com/?q=node/38

Me and Mohammed were very busy this last month (from the osp meeting), but
Mohamed have updated the website and the Newer will be online in few days, I
think...

Me, I try to finish the "developper documentation" this next week to help
some best implementation of this tools in emacs and other IDE... and to
explain our implementation, I prepare too a short video to show "how
install" and "use" ocamlwizard.

We try to finish some part of ocamlwizard, but we can't promise when... for
this time.

We didn't answer at all question on ocamlwizard, but I have read it (and I
am sure, Mohamed too) and I wil continue every weeks to read caml list...
and I hope this developper documentation answer for me.

...Sorry for my english...


| Ocamlwizard Team
| ------------------
| Baudet David
| M2 Programmation and Developpment, Gamagora
| ------------------
| http://dafide.free.fr/
| (En construction)
| -------------------

[-- Attachment #2: Type: text/html, Size: 2003 bytes --]