Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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 ___ 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?
On Sat, Nov 15, 2008 at 01:02:53PM +, 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 ___ 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?
On Saturday 15 November 2008 12:25:17 Richard Jones wrote: On Sat, Nov 15, 2008 at 01:02:53PM +, 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 ___ 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?
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 ___ 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?
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 ___ 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?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
On Wednesday 05 November 2008, Jérémie Dimino wrote: Jon Harrop [EMAIL PROTECTED] 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 ___ 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?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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 ___ 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?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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 ___ 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?
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?
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 [EMAIL PROTECTED] 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 ___ 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?
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/ ___ 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
Indentation (was Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?)
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/ ___ 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?
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. ___ 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?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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 [EMAIL PROTECTED] 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?
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 [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] 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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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. ___ 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?
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. ___ 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?
-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- ___ 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
tags (Was: [Caml-list] What does Jane Street use/want for an IDE? What about you?)
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. ___ 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?
On Mon, Oct 20, 2008 at 5:19 PM, Kuba Ober [EMAIL PROTECTED] 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 ___ 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?
(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 ___ 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?
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?
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 ___ 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?
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 ___ 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?
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
Re: [Caml-list] What does Jane Street use/want for an IDE? What about you?
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/ ___ 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?
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. ___ 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?
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 ___ 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?
-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- ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
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 ___ 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?
On Mon, 20 Oct 2008 13:15:52 -0400 Yitzhak Mandelbaum [EMAIL PROTECTED] 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/ ___ 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?
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. ___ 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?
-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
