Re: [Caml-list] Compiling recursive modules into a .cma.
Stéphane Glondu a écrit : > > It seems that chain.cmo is linked before protection.cmo inside the .cma. > The order of modules inside of a .cma file is important. The behaviour > is the same as if they were #loaded in the same order in a toplevel. Try > writing explicitly all .ml files of $(SOURCE) in topological order. Yes. Indeed. This is the problem. I was misled by the fact that compiling things manually and in order didn't work at first, and I believed something else was wrong, but I was mistaken. It now works. Thanks. Guillaume. ___ 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 thread
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?
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?
> 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 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?
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?
> 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] Camelia progress, indenter
On Monday 20 October 2008, Romain Bardou wrote: > Kuba Ober a écrit : > >> I'm not sure that parsing ocamlbuild file is the right thing to do. For > >> a simple OCaml project (which would probably mean most Camelia > >> projects), there are no OCamlBuild files at all. > >> > >> Mmmhhh there's .itarget (i.e. a list of files you wish generated > >> after compilation), but that's about it. And, again, most projects don't > >> have any. > > > > OK, so I'll focuse on .itarget instead, since that's the thing that the > > debugger has to cooperate with to decide what executable to run and > > debug. > > Err... I'm not sure .itarget is what you want. It's close of what you > want, sure, but you may have several .itarget for the same project, > things like that. > > A typical project may have: >* some source files (.ml .mli .mly .mll); >* several main targets (.byte .native .mllib .mlpack), that may or > may not be put together in one or several .itarget; >* a documentation (.odocl); >* some special rules (_tags myocamlbuild.ml), like some libraries to > use; * a configure script. > This is not, IMO, easily relatable to the project itself, which is > simply a list of files... > > Given a list of files, an IDE can guess interesting targets such as: >* .docdir/index.html for each .odocl; >* .cma .cmxa for each .mllib; >* .cmo for each .mlpack. > But potentially every file can generate several interesting targets. For > instance, from the file x.mlpack, one can generate x.cmo, x.cmx, x.cma, > x.cmxa, x.mli, or even x.docdir/index.html. > > IMO, simply allowing to view the whole contents of a directory is > enough, especially thanks to the fact that ocamlbuild does not pollute > your source directory. That works for me. In future I can implement functionality similar to Visual Studio's .vcproj files, where you can basically hand-tune the build process, all without leaving the IDE. I have had a go at writing a proof-of-concept stand-alone "executor" or "builder" for .vcproj files, and it's not only doable, but the concept should be easy to duplicate and is relatively user-friendly - certainly better than dealing with Makefiles directly, and better than dealing with qmake's .pro files too. 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] Camelia progress - indenter (this time for real)
> I thought of reading through the code and maybe contributing, but the fact > that it's all in C++ is holding me back a bit. Still, I'm going to take a > look once I have time. > Actually, porting the code to pure OCaml might prove the most interesting > task to me. I wonder what is the state of QT4 bindings, though: you > mentioned they were incomplete or non-nexistant, so is it possible to > overcome this without writing the whole QT4 bindings package? It also might > be a bit early to start porting, but then, if I start now, by the time I'd > have anything basic, you would probably complete most of the features > (considering that I have little practical experience with OCaml and no > experience with QT). PyQt may be a good thing to look at, but I don't know how easy it would be to port PyQt to OCaml. The only language I found it easy to bind to almost any binary API is Lisp, since it can actually execute nontrivial programs at compilation time. I guess the starting point would be to look at Qt's C++ API and design an API for Qt in OCaml, and only then try to bridge the gap. 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?
-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?
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?
On Mon, 2008-10-20 at 09:45 -0600, Robert Morelli wrote: > So, my dream would be for someone to build a text editor with the same > basic philosophy as Emacs, > cloning a good bit of its core functionality, but built on a sound > architecture, and capable of dealing with > the demands of modern complex software systems, like IDEs. Roughly > speaking, Emacs built on top of > a "real" language like OCaml, and with the capabilities of modern gui > systems, networks, work flows, > etc. in mind. Just for the sake of bibliography, this reminds me of efuns [1] and Chamo [2]. [1] http://pauillac.inria.fr/cdrom/prog/unix/efuns/eng.htm [2] http://home.gna.org/cameleon/ Cheers, David -- David Teller-Rajchenbach Security of Distributed Systems http://www.univ-orleans.fr/lifo/Members/David.Teller Angry researcher: French Universities need reforms, but the LRU act brings liquidations. ___ 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?
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] Camelia progress, indenter
Kuba Ober a écrit : I'm not sure that parsing ocamlbuild file is the right thing to do. For a simple OCaml project (which would probably mean most Camelia projects), there are no OCamlBuild files at all. Mmmhhh there's .itarget (i.e. a list of files you wish generated after compilation), but that's about it. And, again, most projects don't have any. OK, so I'll focuse on .itarget instead, since that's the thing that the debugger has to cooperate with to decide what executable to run and debug. Err... I'm not sure .itarget is what you want. It's close of what you want, sure, but you may have several .itarget for the same project, things like that. A typical project may have: * some source files (.ml .mli .mly .mll); * several main targets (.byte .native .mllib .mlpack), that may or may not be put together in one or several .itarget; * a documentation (.odocl); * some special rules (_tags myocamlbuild.ml), like some libraries to use; * a configure script. This is not, IMO, easily relatable to the project itself, which is simply a list of files... Given a list of files, an IDE can guess interesting targets such as: * .docdir/index.html for each .odocl; * .cma .cmxa for each .mllib; * .cmo for each .mlpack. But potentially every file can generate several interesting targets. For instance, from the file x.mlpack, one can generate x.cmo, x.cmx, x.cma, x.cmxa, x.mli, or even x.docdir/index.html. IMO, simply allowing to view the whole contents of a directory is enough, especially thanks to the fact that ocamlbuild does not pollute your source directory. -- 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 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?
> 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] Compiling recursive modules into a .cma.
Hello, Guillaume Yziquel wrote: > I've been recently trying to compile a module I made. I can load the > .cmo I generate out of it, but not the .cma I generate out of it. > [...] >> # #load "ocaml-yziquel.cma";; >> Reference to undefined global `Protection' >> [...] IIUC, in this .cma, there are (at least) Protection and Chain modules, the latter depending on the former. However: > [...] > Here is the makefile: > [...] >> SOURCE = $(wildcard *.ml) >> [...] >> BYTE_COMPILED_OBJECT = $(SOURCE:.ml=.cmo) >> [...] >> ocaml-yziquel.cma: $(BYTE_COMPILED_INTERFACE) $(BYTE_COMPILED_OBJECT) >> $(OCAMLC) $(PACKAGES) -a -o ocaml-yziquel.cma $(BYTE_COMPILED_OBJECT) >> [...] It seems that chain.cmo is linked before protection.cmo inside the .cma. The order of modules inside of a .cma file is important. The behaviour is the same as if they were #loaded in the same order in a toplevel. Try writing explicitly all .ml files of $(SOURCE) in topological order. Cheers, -- Stéphane ___ 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] Camelia progress, indenter
> I'm not sure that parsing ocamlbuild file is the right thing to do. For > a simple OCaml project (which would probably mean most Camelia > projects), there are no OCamlBuild files at all. > > Mmmhhh there's .itarget (i.e. a list of files you wish generated > after compilation), but that's about it. And, again, most projects don't > have any. OK, so I'll focuse on .itarget instead, since that's the thing that the debugger has to cooperate with to decide what executable to run and debug. 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
[Caml-list] What does Jane Street use/want for an IDE? What about you?
I have questions to the kind folks at Jane Street, and others who use OCaml for commercial/non-research development: what do you guys use for your development environment? What would be the minimal set of functionality that would make you happy for an IDE? What are killer features you dream of? I'm trying to come up with a longer time plan for Camelia -- this so far relegated, to the dismay of my wife and daughter -- to prolonging my morning showers, so I may as well ask around. None of those plans/feedback would have immediate effect, but I wouldn't mind it simmering for a bit. The reason I got into camelia is not only OCaml, but it seems like a small and manageable enough IDE to base other tools that I'm working on for various embedded architectures. In the long run, for Windows platform I will statically link it and literally have it be a single executable, so that it can be trivially shared, it would also make it easier to consume by people on locked-down computers where software installations are disallowed. Of course OCaml is another deal here, but you have to start with something :) Cheers, Kuba ___ 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] Camelia progress, indenter
I'm not sure that parsing ocamlbuild file is the right thing to do. For a simple OCaml project (which would probably mean most Camelia projects), there are no OCamlBuild files at all. Mmmhhh there's .itarget (i.e. a list of files you wish generated after compilation), but that's about it. And, again, most projects don't have any. Cheers, David On Mon, 2008-10-20 at 09:01 -0400, Kuba Ober wrote: > On Friday 17 October 2008, David Teller wrote: > > A notion of projects would be nice, which would give the ability to > > save/load multiple files. > > At first, I will add "Save all" to the menu (if not already there), so > that all modified documents will be saved with a single action. > > As for real project support, there will be a parser/generator for ocamlbuild > files, although I have never played with ocamlbuild before so I have to see > first how to go about it. > > 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 > -- 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] Camelia progress - indenter (this time for real)
Replying to myself -- must be old age ;) I know that the indenter support will be gone at least for the alpha version, as the indenter needs a revamp -- the QSyntaxHighlighter machinery can be (ab)used to modify the text in-place, and will most likely host all of the indenter. Right now, indenter has a big bunch of regexps and is a bit hard on the eyes. What I will do instead is to tokenize each line and work off the token stream; I expect this will cut the code size a lot. The syntax highlighter has a notion of state for each line, and the state of preceding line, and is automatically invoked by Qt whenever the lines change. I have to check, but I think it is also invoked when the state of the preceding line changes. So it's fairly easy to work with. Anyway, the plan is not to drop features, so the final release will have a hopefully nice indenter and whatnot. Also note that I'm submitting everything to SVN pretty much as I go, and I try to keep the code compileable, so if anyone feels like contributing, let me know. It may be easier to work on it once it all gets to compile, which is still one file away and I will of course brag once it hits the "it compiles and pretends to run" mark. Cheers, Kuba ___ 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] Camelia progress, indenter
On Friday 17 October 2008, David Teller wrote: > A notion of projects would be nice, which would give the ability to > save/load multiple files. At first, I will add "Save all" to the menu (if not already there), so that all modified documents will be saved with a single action. As for real project support, there will be a parser/generator for ocamlbuild files, although I have never played with ocamlbuild before so I have to see first how to go about it. 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] Camelia progress
On Saturday 18 October 2008, you wrote: > Hi, > > In the meantime, is there a public source control with the current version > or a tarball? (I'd just like to take a look at the code, not necessarily > run it). SVN is in the usual sourceforge.net location. The original 1.1 release from a couple years ago is tagged, and I'm chopping away at it in the trunk. Browse it at: http://camelia.svn.sourceforge.net/ Checkout: svn co https://camelia.svn.sourceforge.net/svnroot/camelia camelia Cheers, Kuba ___ 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] ocamlopt performance in 3.11
Alain Frisch wrote: > David Allsopp wrote: > > OK, so I've tried using the -nodynlink option with all calls to ocamlopt > > and spotted *no* timing difference. A quick binary comparison of the EXE > > produced reveals that ocamlopt -nodynlink is making ABSOLUTELY NO > > difference in the resulting code. > > -nodynlink only makes a difference for the AMD64 backend. It is accepted > by ocamlopt for all ports in order to simplify Makefiles. Ah, I didn't realise that. Perhaps ocamlopt -help could include a note to that effect? > > While I can see a benefit to having native code compile for use with > > dynlink > > by default, given the performance hit I'm seeing, wouldn't it be better > > in terms of backwards compatibility if you had to specify, say, - > > fordynlink in order to compile a .cmx (and, presumably more importantly, > > .o file) for use with ocamlopt -shared? > > There were reasonable arguments for turning the "ready for dynlink" > behavior on by default, namely that nobody would do it otherwise in the > Makefiles of their distributed libraries since it is required only on > one port. Indeed - that's the benefit I was referring to! However... > Also, according to a few benchmarks, the impact on performance is very > limited. Then why might my program be running ~25% slower when compiled with ocamlopt 3.11.0 vs 3.10.2? I'm assuming that there's little to no difference between ocamlopt using masm and ocamlopt using gas in terms of resulting performance? David ___ 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] ocamlopt performance in 3.11
David Allsopp wrote: OK, so I've tried using the -nodynlink option with all calls to ocamlopt and spotted *no* timing difference. A quick binary comparison of the EXE produced reveals that ocamlopt -nodynlink is making ABSOLUTELY NO difference in the resulting code. -nodynlink only makes a difference for the AMD64 backend. It is accepted by ocamlopt for all ports in order to simplify Makefiles. While I can see a benefit to having native code compile for use with dynlink by default, given the performance hit I'm seeing, wouldn't it be better in terms of backwards compatibility if you had to specify, say, -fordynlink in order to compile a .cmx (and, presumably more importantly, .o file) for use with ocamlopt -shared? There were reasonable arguments for turning the "ready for dynlink" behavior on by default, namely that nobody would do it otherwise in the Makefiles of their distributed libraries since it is required only on one port. Also, according to a few benchmarks, the impact on performance is very limited. -- Alain ___ 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] ocamlopt performance in 3.11
Andrew Varon wrote: > On Oct 17, 2008, at 5:59 AM, David Allsopp wrote: > > > Pleased to say that I've got my 3 current projects compiled and > > running > > under 3.11+beta1 > > > > Unfortunately for one of the projects, its "reference" run (a > > computationally intensive, repeatable operation the speed of which > > interests > > me) has gone from repeatedly taking ~38 seconds in 3.10.2 to ~46 > > seconds in > > 3.11.0+beta1. The other two projects don't have as easy a way for me > > to > > calibrate speed (they spend most of their time blocked on I/O > > anyway!). > > > > Has anything apart from the linker changed much in the 3.11 code > > generator > > and has anyone else noticed a performance drop in any other programs? > > The Changes list do mention a number of important changes in the > runtime system. Yes, still blushing that I'd failed to check the Changes file first... > For most of my programs the bottleneck functions are implemented in C. > For one of the few cases where OCaml is taking care of the core loop, > ocaml 3.11.0beta1 produce a consistently slower native executable than > 3.10.2 by a very small factor (around 0.5%). I have not timed in > Windows, and I run Windows inside a virtual machine, so I'm not sure > if the differences I will observe there are just an artifact of that > setup. OK, so I've tried using the -nodynlink option with all calls to ocamlopt and spotted *no* timing difference. A quick binary comparison of the EXE produced reveals that ocamlopt -nodynlink is making ABSOLUTELY NO difference in the resulting code. While I can see a benefit to having native code compile for use with dynlink by default, given the performance hit I'm seeing, wouldn't it be better in terms of backwards compatibility if you had to specify, say, -fordynlink in order to compile a .cmx (and, presumably more importantly, .o file) for use with ocamlopt -shared? David ___ 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] Camelia progress
Since I am slightly responsible for getting you into this exercise, I volunteer to test the code on Ubuntu 7.04, Intel and AMD64 architectures. Let me know when you want something done. Best regards, Andrej ___ 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] ALICS workshop at LPAR
- *ALICS* - Applications of Logic in Computer Security LPAR 2008 workshop, November 22, Doha, Qatar - EXTENDED SUBMISSION DEADLINE - 24th October - Organizer: Catherine Meadows, NRL Submission deadline: October 24, 2008 Submission: 1-5 pages abstract Web: http://chacs.nrl.navy.mil/projects/ALICS08 Scope: ALICS is intended to be an informal workshop devoted to the applications of logic in computer security. This workshop is intended for presentation and discussion of work in progress and the discussion of emerging and foundational ideas. We are interested in all aspects of the application of logic to computer security. Applications of interest include security policy, access control, security protocols, information flow, but we are also interested in new and as yet untried applications of logic to different areas of computer security. We are also interested in discussion papers that raise fundamental questions and/or suggest new lines of research in this area. Work that has already appeared or is under consideration by other venues is welcome. No formal proceedings is planned, but accepted abstracts will be posted online. Program Committe and Organizers: Catherine Meadows, Naval Research Laboratory, USA (Workshop Organizer) Andreas Bauer, Australian National University, Australia Heiko Mantel, TU Darmstadt, Germany Mike Mislove, Tulane University, USA Dusko Pavlovic, Kestrel Institute (USA) and Oxford University(UK) Luca Vigano, University of Verona, Italy ___ 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] Compiling recursive modules into a .cma.
Hello, list. I've been recently trying to compile a module I made. I can load the .cmo I generate out of it, but not the .cma I generate out of it. > [EMAIL PROTECTED]:~/svn/ocaml-yziquel$ ocaml > Objective Caml version 3.10.2 > > # #load "ocaml-yziquel.cma";; > Reference to undefined global `Protection' > # The issue is, I think, the fact that it is a recursive module. You'll find the code at the end of this email. I needed a recursive module because the following (simplified code) did not manage to type things "correctly". For instance protected_value was supposed to have type 'a protected -> 'a... > type 'a protected = > | Protected of 'a * ((Mutex.t * Condition.t) ref protected * Mutex.t) > | Unprotected of 'a > > let rec protect data = match data with > | Unprotected _ -> () > | Protected (_, (locking_data, mutex)) -> > Mutex.lock mutex; > let (mut, cond) = !(protected_value locking_data) in > Mutex.lock mut > > and (protected_value: 'a protected -> 'a) = > function protected_data -> match protected_data with > | Unprotected d -> d > | Protected (d, _) -> d > > and unprotect data = match data with > | Unprotected _ -> () > | Protected (_, (locking_data, mutex)) -> > let (mut, cond) = !(protected_value locking_data) in > Mutex.unlock mut; > unprotect locking_data; > Mutex.unlock mutex;; > > val protect : 'a protected -> unit = > val protected_value : > (Mutex.t * Condition.t) ref protected -> (Mutex.t * Condition.t) ref = > > val unprotect : (Mutex.t * Condition.t) ref protected -> unit = A look at protection.cmo with ocamlobjinfo gave the following output: > Unit name: Protection > Interfaces imported: > 8ba3d1faa24d659525c9025f41fd0c57Pervasives > 19e9e3e1586622e6bee0a641bcbccbd7Condition > da1ce9168f0408ff26158af757456948List > dc6994f75cfd14f73e718f81aa215803CamlinternalMod > 855af44384a5465360efe6e8bff546abMutex > 09ed2ebaeb54934aa3f583a41f71ca7bProtection > 5cfae708052c692ea39d23ed930fd64dObj > Uses unsafe features: no The modules CamlinternalMod and Obj are not pulled down to chain.cmo (which depends on the Protection module). I do not know what these modules stand for. To sum up, I'm able to load the .cmo in the ocaml toplevel, but not the .cma file generated out of the Protection and Chain modules... Any ideas / suggestions / explanations are welcome... (Please keep my adress in Cc: when replying). All the best, Guillaume Yziquel. Here is the code of the protection.ml file: > [EMAIL PROTECTED]:~/svn/ocaml-yziquel$ cat protection.ml > module rec Protection : > sig > > type 'a protected = > | Protected of 'a * ((Mutex.t * Condition.t) ref protected * Mutex.t) > | Unprotected of 'a > > val protect : 'a protected -> unit > val protected_value : ?protection:bool -> ?force:bool -> 'a protected -> 'a > val unprotect : ?strongly:bool -> ?force:bool -> 'a protected -> unit > val try_protect : ?strongly:bool -> 'a protected -> bool > val protected : ?protection:bool -> ?lockdata:(Mutex.t * Condition.t) list > -> 'a -> 'a protected > val mutually_protected : ?protection:bool -> ?lockdata:(Mutex.t * > Condition.t) list -> 'a list -> 'a protected list > val lock_of_protected : ?force:bool -> 'a protected -> (Mutex.t * > Condition.t) ref protected > > end = struct > > type 'a protected = > | Protected of 'a * ((Mutex.t * Condition.t) ref protected * Mutex.t) > | Unprotected of 'a;; > > let protect data = > match data with > | Unprotected _ -> () > | Protected (_, (locking_data, mutex)) -> > Mutex.lock mutex; > let aux_cond = ref None in > while not > ( let (mut, cond) = !(Protection.protected_value locking_data) in > aux_cond := Some cond; > let b = Mutex.try_lock mut in > Protection.unprotect locking_data; b > ) do match !aux_cond with >| None -> failwith "Protection.protected" >| Some c -> Condition.wait c (Mutex.create ()) > done;; > > let protected_value ?protection:(protection=true) > ?force:(force=false) > (protected_data: 'a protected) = > if not force then protect protected_data; > match protected_data with > | Unprotected d -> d > | Protected (d, _) as protected_data -> > if (not force) & (not protection) > then Protection.unprotect protected_data; > d;; > > let unprotect ?strongly:(strongly=true) ?force:(force=false) data = > match data with > | Unprotected _ -> () > | Protected (_, (locking_data, mutex)) -> > let (mut, cond) = !(Protection.protected_value locking_data) in > if strongly then ( > Mutex.unlock mut;
[Caml-list] CAML?
Hi, Take a look: http://en.wikipedia.org/wiki/Collaborative_Application_Markup_Language and position of this link in google: http://www.google.pl/search?source=ig&hl=pl&rlz=&=&q=Caml&btnG=Szukaj+w+Google&meta= I'm sure that if you developed an XML-based language called VISUAL BASIC (some short name), the whole case would end up in the court. ;P And why caml.inria.fr doesn't work. Did I miss something? ;) Michal ___ 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] .annot files in 3.11
> Le 17 oct. 08 à 11:25, David Allsopp a écrit : > > > Has anyone else found that ocamlopt in 3.11 seems to ignore the - > > dtypes > > option? ocamlc creates .annot files as normal when passed -dtypes. > > According to the release notes -annot should now be used. However > there's no annot tag for ocamlbuild could that please be added for > 3.11 ? Stupidly, I forgot to read the Changes file so didn't know that I should be saying -annot :$ However, neither -dtypes or -annot seems to make ocamlopt create a .annot file...? David ___ 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
