Re: [Caml-list] arm backend
On Tue, May 5, 2009 at 2:43 AM, Xavier Leroy wrote: > > Concerning the iPhone, it is not supported out of the box by 3.11 nor > by the CVS trunk code. For 3.11, several patches have been mentioned > on this list; it would be great if someone with iPhone development > experience could combine them and publish a unified patch. Feel free to attach any such patch to the bug in mantis: http://caml.inria.fr/mantis/view.php?id=4782 > For the CVS trunk code, it seems we are getting close: as far as I > could see, MacOSX/ARM uses EABI plus Apple's "signature" approach to > dynamic linking. However, I haven't yet succeeded in running Apple's > iPhone SDK compilers from the command-line. (It looks like one of > those Microsoft SDK's that assume everyone is developing from the > vendor-supplied IDE...) Again, I welcome feedback and patches from > iPhone development experts. I'm attaching (here and at the bug) a script I use to configure and build an e-mail library for both the iPhone simulator (x86) and the iPhone itself (arm). There's some extraneous junk in there but you should get the idea. The important flags are '-arch armv6' and '-isysroot /path/to/sdk'. It might also be worth mentioning that Apple prohibits the use of dynamic libraries in iPhone apps (for now at least) and most iPhone projects are built in Thumb mode by default. Cheers, -n8 configure-libetpan Description: Binary data ___ 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] Re: arm backend
On Fri, May 1, 2009 at 3:12 PM, Jeffrey Scofield wrote: > Nathaniel Gray writes: > >> Speaking of which, has anybody built an ocaml cross compiler for the >> iphone that can work with native cocoa touch apps built with the >> official SDK? It's probably too late for my current project but in >> the future I'd love to use ocaml for my iPhone projects. I tried >> following the instructions here[1] with some necessary >> modifications[2] to get the assembler to work but my test app crashed >> as soon as it entered ocaml code. I don't know enough about the ARM >> platform to say why. > > Yes, we have OCaml 3.10.2 cross compiling for iPhone OS 2.2. Great! > There are at least two more problems, however. Presumably > this is due to differences between the iPhone ABI and the one that > the ARM port (the old one I guess you could say) is targeted for. > > 1. arm.S uses r10 as a scratch register, but it is not a scratch > register on iPhone. It has to be saved/restored when passing > between OCaml and the native iPhone code (I think of it as > ObjC code). Note, by the way, that gdb shows r10 by the > alternate name of sl. This is confusing at first. > > 2. arm.S assumes r9 can be used as a general purpose register, > but it is used on the iPhone to hold a global thread context. > Again, it has to be saved/restored (or at least that's what we > decided to do). > > We saw crashes caused by both of these problems. Ok, I'm glad I left this to people who are familiar with ARM assembly programming. :-) > I'm appending a new version of arm.S that works for us with > one OCaml thread. (Multiple threads will almost certainly > require more careful handling of r9.) It has the patches > from Toshiyuki Maeda mentioned above and a few of our > own to fix these two problems. Awesome, but now I'm confused because the arm.S you included has lots of .global pseudo-ops. Do you not compile it with Apple's as? > We have an application that has been working well for > a couple months, so there's some evidence that these > changes are sufficient. What's your app? How are you managing the interface between Cocoa and OCaml? > We also made a small fix to the ARM code generator > (beyond the patches from Toshiyuki Maeda). In essence, > it fixes up the handling of unboxed floating return > values of external functions. Things mostly work without > this change; I'll save a description for a later post (if > anybody is interested). I am very interested in any and all information needed to get a correct OCaml port suitable for use in App Store applications. Please share! BTW, I've added an issue in mantis[1] now that I know this is more than a configuration problem. Thanks, -n8 [1] http://caml.inria.fr/mantis/view.php?id=4782 -- Nathan Gray http://www.n8gray.org/ ___ 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] Re: arm backend
On Fri, May 1, 2009 at 5:02 AM, Mattias Engdegård wrote: >>[2] I had to change all '.global' to '.globl' in arm.s and >>arm/emit.mlp. I have no idea what that signifies. > > Only that Apple's assembler only understands .globl. Gas (the assembler > in GNU binutils) should accept both .global and .globl, so it is probably > safe to use the latter only. There is no difference in semantics. Ah, mystery solved. Thanks! > Another pseudo-op that sometimes causes problems is .align whose exact > behaviour with respect to its argument varies between platforms. > Both gas and Apple's as accept .p2align, so this is usually a safer > choice. It's all very confusing to me because I thought Apple's assembler *was* gas. In the man page for as it's described as "Mac OS X Mach-O GNU-based assemblers". The -v flag for the iPhone version of as gives: "Apple Computer, Inc. version cctools-667.10.0~186, GNU assembler version 1.38" Very odd that they decided to take out support for .global in their version... Cheers, -n8 -- Nathan Gray http://www.n8gray.org/ ___ 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] Re: arm backend
On Thu, Apr 30, 2009 at 11:03 AM, Stéphane Glondu wrote: > > http://caml.inria.fr/mantis/view.php?id=3746 Speaking of which, has anybody built an ocaml cross compiler for the iphone that can work with native cocoa touch apps built with the official SDK? It's probably too late for my current project but in the future I'd love to use ocaml for my iPhone projects. I tried following the instructions here[1] with some necessary modifications[2] to get the assembler to work but my test app crashed as soon as it entered ocaml code. I don't know enough about the ARM platform to say why. Cheers, -n8 [1] http://web.yl.is.s.u-tokyo.ac.jp/~tosh/ocaml-on-iphone/ [2] I had to change all '.global' to '.globl' in arm.s and arm/emit.mlp. I have no idea what that signifies. -- Nathan Gray http://www.n8gray.org/ ___ 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] The new OCaml book (Objective Caml Programming Language by Tim Rentsch)
Sorry, this was meant to go to the list as well: On Fri, Feb 27, 2009 at 10:43 AM, Nathaniel Gray wrote: > On Fri, Feb 27, 2009 at 9:42 AM, Richard Jones wrote: >> On Fri, Feb 27, 2009 at 09:37:05AM -0800, Nathaniel Gray wrote: >>> On Fri, Feb 27, 2009 at 4:27 AM, Richard Jones wrote: >>> > I previously mentioned this book on the list and said that I'd been >>> > promised a review copy from the publisher: >>> > >>> > http://www.amazon.com/Objective-Caml-Programming-Language/dp/0981599206 >>> > >>> > I received the review copy from Abscissa Press yesterday and I have >>> > read the first few chapters. This book is in fact the Jason Hickey >>> > book which has been floating around on the net for a while, updated by >>> > Tim Rentsch who I think is Jason's colleague or student. >>> >>> As someone who *was* Jason's student, I'd suggest that if that book is >>> clearly derived from Jason's book but Jason's name isn't on the cover >>> you should definitely be asking questions about that. I would say >>> more but I don't want to put words in Jason's mouth. >> >> I don't think there is any suggestion that it was plagiarised from >> him. In fact I think the author mentions Jason in the introduction ... > > The list time I spoke to Jason he had a deal with a major publisher > for his book. I think it's safe to say that there is no chance that > Jason would allow somebody to publish his book or a derived work > without his name on the cover. > > Cheers, > -n8 > > -- > Nathan Gray > http://www.n8gray.org/ > ___ 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] The new OCaml book (Objective Caml Programming Language by Tim Rentsch)
On Fri, Feb 27, 2009 at 4:27 AM, Richard Jones wrote: > I previously mentioned this book on the list and said that I'd been > promised a review copy from the publisher: > > http://www.amazon.com/Objective-Caml-Programming-Language/dp/0981599206 > > I received the review copy from Abscissa Press yesterday and I have > read the first few chapters. This book is in fact the Jason Hickey > book which has been floating around on the net for a while, updated by > Tim Rentsch who I think is Jason's colleague or student. As someone who *was* Jason's student, I'd suggest that if that book is clearly derived from Jason's book but Jason's name isn't on the cover you should definitely be asking questions about that. I would say more but I don't want to put words in Jason's mouth. Cheers, -n8 -- Nathan Gray http://www.n8gray.org/ ___ 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] Teaching ocaml programming
On Fri, Sep 26, 2008 at 5:10 AM, Brighten Godfrey <[EMAIL PROTECTED]> wrote: > I use, on a daily basis, a small script which acts as a front-end to `make' > and automatically points you to the error in the code in nedit, highlighting > the characters that the ocaml compiler complains about. It uses the > existing nedit window if you have the file open already, or else opens it > for you. The script also works with gcc instead of ocaml, and (though I > can't vouch for it much) gvim instead of nedit. So my typical development > environment consists of nedit and a shell in which I compile via the script. > > If anyone is interested, I'd be happy to share this. I for one am interested -- that could come in handy! > I guess the main question would be integrating the toplevel with nedit. I > imagine there are a number of ways to do this, depending on your needs. You > might be able to put something together using nedit's scripting language, or > just do something entirely external to the editor. You won't have any luck integrating the toplevel into nedit. There's just no way to do it within the editor as it stands today. But it's not *that* hard to run a shell alongside your editor. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Teaching ocaml programming
On Fri, Sep 26, 2008 at 4:30 AM, Andrej Bauer <[EMAIL PROTECTED]> wrote: > Once again I am teaching a course on theory of programming languages in > which we will use ocaml to implement mini-languages. And once again I face > the question: which programming environment should we use? I used to use nedit + shell and it worked quite well. I've got a good syntax highlighting mode and some support scripts. These days I've switched to jEdit but I use much the same workflow. It *is* possible to use the "console" and "error list" plugins for jedit to build programs and get automatic error message highlighting, but the OCaml error format makes it a bit sub-optimal. If you want to try it I can tell you how to configure things. You would still need to run the toplevel in an external shell. The nice thing about jEdit is that it's cross-platform and not quite as bloated as Eclipse. Also, using omake for your build system has some nice advantages. The '-P' flag causes the project to automatically rebuild when any project file changes on disk. After you fix a bug the next error message is already waiting for you. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Extending .annot files
On Sun, Sep 21, 2008 at 11:08 PM, Maxence Guesdon <[EMAIL PROTECTED]> wrote: > On Fri, 19 Sep 2008 11:20:36 -0700 > "Nathaniel Gray" <[EMAIL PROTECTED]> wrote: >> >> For any identifier it would be good to know: >> 1. Its inferred type >> 2. Its fully-qualified module "path" > > All identifiers have not a fully qualified path (think of y in > let x = let y = ... in ...) That's a good point. I tend to think of those variables as being private parts of the current module, but perhaps that's inaccurate. So we can amend this request to be for "its fully qualified module path, if such a path exists". > and two identifiers may have the same > fully-qualified path. (e.g.: let x = 1;; let x = 2;;) That's fine. Nobody said it had to be unique. :) >> 3. Where it was defined, if it was defined in the current file. > > Would it be possible to have the location of the definition of all > identifiers, including the ones defined in another module (if there is > a .annot file for this module, of course) ? This strikes me as being beyond the scope of what the compiler can reasonably provide. If we're given the info that: 1. x resolves to Foo.Bar.x 2. Foo.Bar came from file /home/n8gray/src/foo/bar.cmo We can write the code that decides whether/how to find bar.annot, since that will be very build-system dependent. >> In addition, for each module referenced in the file it would be good >> to know what file the module was read from. (This will allow some >> hope of tracking down definitions in other files) >> >> It's hard for me to think of anything else that belongs in .annot >> files. If I stretch a bit I suppose annotating variable definitions >> with their range of scope might be cute. Maybe other people can think >> of more original ideas. > > A module containing the functions to read .annot files, so that > all developers using these files do not develop their own module. I agree, but this is something that can be developed outside the INRIA team if necessary. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Re: Extending .annot files
On Sun, Sep 21, 2008 at 7:15 PM, Jun Furuse <[EMAIL PROTECTED]> wrote: > Hi, > >> I'm really happy to hear that you're open to including some of this >> stuff. I think there are actually only a few data that one wants to >> have in .annot files (and that the compiler can reasonably provide). >> >> For any identifier it would be good to know: >> 1. Its inferred type >> 2. Its fully-qualified module "path" >> 3. Where it was defined, if it was defined in the current file. >> >> In addition, for each module referenced in the file it would be good >> to know what file the module was read from. (This will allow some >> hope of tracking down definitions in other files) > > In addition, ocamlspot records the following: > - compilation load paths to find referred modules Is this different from my last sentence? I'm not sure if you mean the path to the module file or the module search path. I would personally rather have the path to the specific file for each module so that the client doesn't have to write code for searching out modules. > - abstractions of internally defined modules to find definitions of > variables obtained from module aliases and functor applications Are there cases where you can't figure this out by following back the chain of definitions? > - some hack for packed modules > >> It's hard for me to think of anything else that belongs in .annot >> files. If I stretch a bit I suppose annotating variable definitions >> with their range of scope might be cute. Maybe other people can think >> of more original ideas. > > Many things: constructor/type/exception/module definition locations, Sure, by using the word "identifiers" above I meant to include these entities. > corresponding .mli entry positions and so on. That's a good idea, assuming the compiler has this information at the right time. > Some of them, especially > type related things, require compiler side support definitely, but the > others could be done by CamlP4 or something similar, I guess. I > personally like to modify the compiler since all the interesting > information is available at compilation for free and all we need is > just to export it to some file, in an extensible format. Probably in a > text file like the current annot, or as a marshaled value like > ocamlspot does. Marshalled values are nice since we do not need to > write parsers for them, and we can use lots of tool functions in the > compiler to handle them. But of course, it is more difficult to keep > backward compatibility, which Xavier is anxious about. Marshalled values are awful for .annot files because only OCaml code can read them without lots of effort. I'd venture a guess that most people want to exploit .annot files in their text editors. My text editor isn't (yet) written in OCaml, and I know I'm not the only one. >> Finally, it may be worth putting a little work into reducing the size >> of .annot files. One could certainly do much better with very little >> effort. > > The size of the current annot files are more than 600% larger than the > source ml files (I measured this by compiling ocaml compiler tree with > -annot). Gzipping them makes them 1/10 (about 60% of the source size). > However, the compiler should not rely on any external compression tool > is available by default. You can easily add few rules to your OCaml > project Makefiles to gzip annots automatically, and I guess it would > be also easy to extend caml-types.el to support gzipped annot files. I recently pointed out this very fact about gzipping .annot files, but if we're putting together a wish list for .annot file changes I would still like to see them be less bloated by default. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Extending .annot files
On Thu, Sep 18, 2008 at 10:02 AM, Xavier Leroy <[EMAIL PROTECTED]> wrote: > > From what I've heard, there's also an OCaml summer of code project > that enriched the info found in .annot files. So, it's certainly time > to discuss extensions to .annot files, but let's do that globally, not > one at a time. It is probably too late for inclusion in 3.11, but as > long as these extensions are backward compatible, inclusion in bugfix > releases can be considered. I'm really happy to hear that you're open to including some of this stuff. I think there are actually only a few data that one wants to have in .annot files (and that the compiler can reasonably provide). For any identifier it would be good to know: 1. Its inferred type 2. Its fully-qualified module "path" 3. Where it was defined, if it was defined in the current file. In addition, for each module referenced in the file it would be good to know what file the module was read from. (This will allow some hope of tracking down definitions in other files) It's hard for me to think of anything else that belongs in .annot files. If I stretch a bit I suppose annotating variable definitions with their range of scope might be cute. Maybe other people can think of more original ideas. Finally, it may be worth putting a little work into reducing the size of .annot files. One could certainly do much better with very little effort. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] New Ocaml Plug-in for NetBeans
On Tue, Sep 9, 2008 at 12:43 AM, Jon Harrop <[EMAIL PROTECTED]> wrote: > On Tuesday 09 September 2008 06:31:51 you wrote: >> Sure, I had the same thought, but gzip already exists, doesn't require >> approval from INRIA, and .gz is easily read in just about any language >> (including OCaml). Once the .annot files are smaller than the source >> files I'm completely willing to generate them all the time. > > I think you will find that GZip is orders of magnitude less efficient that the > approach I suggested and too slow to be useful in this case. > > For example, gzipping and unzipping the .annot files from the 4kLOC core of > Smoke takes 0.5s. So GZip is too slow for interactive use even on this tiny > code base. Why would you want to unzip more than one .annot file during interactive use? If I query the type of some token foo in bar.ml I only need to read from bar.annot.gz, not all the files in the project. The biggest .annot file I have lying around is from a 40KB source file. It's about 270KB before gzip, 30KB after. According to "time" it takes 0.009 seconds to gunzip on my MacBook Pro. I'd say that's plenty fast enough to be useful, even if your machine isn't quite as snappy as mine. I don't dispute that a more efficient encoding than gzip can be found, but good luck convincing anybody at INRIA to work on it. ;^) -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] New Ocaml Plug-in for NetBeans
On Sun, Sep 7, 2008 at 6:10 PM, Jon Harrop <[EMAIL PROTECTED]> wrote: > On Monday 08 September 2008 00:31:47 Nathaniel Gray wrote: >> In fact, gzip does a pretty fine job of optimizing .annot files. The >> source file this .annot came from is 15K, the .annot file is 78K, and >> gzipping it gets it down to 9K. > > Tokenizing that .annot format by simply mapping each string onto a unique > token and writing out the mapping first will shrink such files enormously > whilst still being easily dissected from any language. Moreover, the benefit > is super-linear... Sure, I had the same thought, but gzip already exists, doesn't require approval from INRIA, and .gz is easily read in just about any language (including OCaml). Once the .annot files are smaller than the source files I'm completely willing to generate them all the time. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] [ANN] OCamlSpotter: OCaml compiler extension for source browsing
On Mon, Sep 8, 2008 at 4:24 AM, Jun Furuse <[EMAIL PROTECTED]> wrote: > Hi, > > I have written a small compiler patch called ocamlspotter. It extends > -annot option and records all the variable definition locations, so > that we can jump from variable uses to their definitions easily from > editors such as emacs. You have completely blown my mind. I was thinking about this very idea about 10 minutes ago in my car, and *blam* there it is. I should think about some other, more profitable ideas... I would suggest submitting this as a patch for inclusion. I've heard there are going to be enhancements to the .annot format in 3.11 so it's not unprecedented. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] New Ocaml Plug-in for NetBeans
On Wed, Aug 20, 2008 at 9:32 AM, Jon Harrop <[EMAIL PROTECTED]> wrote: > On Wednesday 20 August 2008 07:29:21 you wrote: > >> 2. Use "dump" files to store the results of these tools and Makefile >> targets to produce them (that the way ocamldoc is used in Cameleon for >> browsing documentation) > > I have found -dtypes to be very slow on large code bases and I assume this is > because it generates such huge dump files. Perhaps this could be optimized > somehow? Definitely. .annot files are incredibly bloated. Here's a snippet from a .annot file I have on my hard drive: """ "ra_live.ml" 342 11092 11107 "ra_live.ml" 342 11092 7 type( Ra_type.code_class ) "ra_live.ml" 343 11121 11139 "ra_live.ml" 343 11121 11147 type( LiveSet.t ) "ra_live.ml" 344 11148 11172 "ra_live.ml" 344 11148 11177 type( Ra_type.label ) "ra_live.ml" 344 11148 11163 "ra_live.ml" 344 11148 11177 type( Ra_type.code_class ) """ See any opportunities for optimization? ;^) In fact, gzip does a pretty fine job of optimizing .annot files. The source file this .annot came from is 15K, the .annot file is 78K, and gzipping it gets it down to 9K. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] New Ocaml Plug-in for NetBeans
On Sat, Jul 26, 2008 at 4:40 AM, Jon Harrop <[EMAIL PROTECTED]> wrote: > On Saturday 26 July 2008 11:03:12 Erik de Castro Lopo wrote: >> >> I don't like emacs and vi. My editor of choice for the last 13 >> years has been nedit (Nirvana Editor) which has syntax highlighting >> for dozens of languages (and it easy to add new ones or modify >> existing ones), regex search/replace and macros. Its configurable >> so over the years I have bent it into the shape I want. The same >> goes for my Unix shell. > > I assume nedit does not even have basic type throwback, let alone > documentation throwback? As the guy who implemented one generic form of "throwback" for NEdit, namely calltips, I can tell you that it certainly does support it and I've used it extensively. It's an editor that is extremely flexible without being *too* obscure, so you can get it to do just about anything you want. I have been unable to find another editor that has the same combination of power, flexibility, and ease-of-use, and I've looked far and wide. Having said that, I'm afraid NEdit development has sunk into a tar pit. There is no effective leadership on the project and it's inextricably tied to the Motif toolkit, which means very few new developers will sign on. I've given up and switched to jEdit, which has a similar spirit (platform-independent, language-independent, flexible) but, being written in Java, a much higher bloat factor. But hey, with 2GB of ram it doesn't feel so bad to give 150MB to my text editor any more. I would *love* to have an alternative written in OCaml, since my forays into the jEdit code have left me with unpleasant feelings... Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Typeclasses in OCaml (Was: Haskell vs OCaml)
On Thu, Aug 14, 2008 at 7:46 AM, Jim Farrand <[EMAIL PROTECTED]> wrote: > 2008/8/14 Peng Zang <[EMAIL PROTECTED]>: > >> In Haskell you can write a function that takes anything that is "showable" (a >> type class) and print it out. The sig would be something like (I'm mixing >> OCaml and Haskell syntax here, but hopefully the point is still clear): > > Out of curiosity, are there any theoretical reasons why OCaml could > not be extended with type classes? They are one of my favourite > features of Haskell, and I think they would really improve OCaml. It could be done. See this paper from POPL '07: http://portal.acm.org/citation.cfm?id=1190215.1190229 Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Findlib fails to build on OS X Leopard
My colleague is trying to install GODI but it's choking on findlib 1.2.2. Specifically, the command used to locate the std. lib. in get_stdlib is not compatible with OS X's sed: ocamlc -where | sed "s/\r//" || ... The version of sed included with Leopard doesn't support backslash-escapes like \r. Instead, it treats '\r' just like 'r', so this turns '/Users/blah/...' into '/Uses/blah/...' and the std. lib. can't be found. Until this bug is fixed the workaround is to install gnu sed. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] deriving Show with type-conf
Hi, Has anybody used type-conv to write a "deriving Show" style printer generator they can share? Any other approaches? I was using the "deriving" package for a while but it's got a bad parsing bug. Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] ANN: patterns v0.4
On Fri, Jun 20, 2008 at 9:26 AM, Richard Jones <[EMAIL PROTECTED]> wrote: > > Can someone summarise active patterns for us? The MSDN site > containing the paper is down at the moment. Sure. Active patterns are a lot like Wadler's "views", and thus are similar to the stuff in micmatch. With active patterns you can invoke functions (implicitly) within pattern matches and match the results, which allows you to provide a "virtual" algebraic data structure for any value you might want to match against. Here's an example from the paper (using F# syntax): open LazyList let (|Cons|Nil|) l = if nonempty(l) then Cons(hd(l),tl(l)) else Nil let rec pairSum xs = match xs with | Cons (x, Cons (y,ys)) -> consl (x+y) (lazy (pairSum ys)) | Cons (x, Nil ()) -> consl x (lazy nil) | Nil () -> nil This expands to: let rec pairSum xs = if nonempty xs then let x, ys = hd xs, tl xs if nonempty ys then let y, zs = hd ys, tl ys consl (x+y) (lazy (pairSum zs)) else consl x (lazy nil) ) else nil There are other variations presented in the paper, including parameterized patterns. These are nice for doing things like regular expression matching. Again, from the paper: let (|ParseRE|_|) re s = let m = Regex(re).Match(s) if m.Success then Some [ for x in m.Groups -> x.Value ] else None let swap s = match s with | ParseRE "(\w+)-(\w+)" [l;r] -> r ^ "-" ^ l (* See below *) | _ -> s The matching syntax here is a bit confusing because it can be hard to tell where parameters end and patterns begin. In the example above, "(\w+)-(\w+)" is a parameter and [l;r] is a pattern. There's definitely room for improvement over this syntax. There are other variations and examples in the paper. I'd definitely recommend reading it. If you still can't get it from the website I can forward you a copy off-list. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] ANN: patterns v0.4
On Tue, Jun 17, 2008 at 4:20 AM, Jeremy Yallop <[EMAIL PROTECTED]> wrote: > I'm pleased to announce a new release of `patterns', an OCaml > framework for writing extensions to pattern matching using Camlp4. Ooh, very interesting! Have you looked at "active patterns" in F#? They look really useful and I've been wanting to code them up in camlp4 for a while now but haven't had the time. It sounds like your framework could make that much easier. Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Re: Building a universal binary on OS X?
On Sat, May 24, 2008 at 12:31 AM, Michel Schinz <[EMAIL PROTECTED]> wrote: > Alan Schmitt <[EMAIL PROTECTED]> writes: > > [...] > >> My goal is to be able to compile the OS GUI version of Unison on a >> single machine. Right now, using my intel-based notebook, I'm able to >> compile a version that runs both on 10.4 and 10.5, but only on intel. > > [...] > >> I think I remember an old message addressing this, but I have not been >> able to find it. > > You might be referring to this message: > > http://thread.gmane.org/gmane.comp.lang.caml.general/38930 > > The cute trick consists in building a PPC version of OCaml on a PPC > machine, and then copying it over to your Intel machine. It will run > fine (albeit slowly) under Rosetta, and generate PPC executables. See also: http://caml.inria.fr/mantis/bug_view_advanced_page.php?bug_id=4303 Cheers, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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] Request for GODI packagers
Dear GODI Packagers, If you're packaging a project that's gone to the trouble of writing ocamldoc documentation and example code, please do generate the documentation and install those example files. It's a bit silly that after installing a library with GODI you still need to download the source tarball and navigate its build system just to get the API docs. Thanks, -n8 -- >>>-- Nathaniel Gray -- Caltech Computer Science --> >>>-- Mojave Project -- http://mojave.cs.caltech.edu --> ___ 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
