Re: [Caml-list] arm backend
On Tue, May 5, 2009 at 2:43 AM, Xavier Leroy xavier.le...@inria.fr 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 5:02 AM, Mattias Engdegård matt...@virtutech.se 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 Fri, May 1, 2009 at 3:12 PM, Jeffrey Scofield dynasti...@mac.com wrote: Nathaniel Gray n8g...@gmail.com 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] The new OCaml book (Objective Caml Programming Language by Tim Rentsch)
On Fri, Feb 27, 2009 at 4:27 AM, Richard Jones r...@annexia.org 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] 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 n8g...@gmail.com wrote: On Fri, Feb 27, 2009 at 9:42 AM, Richard Jones r...@annexia.org 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 r...@annexia.org 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] 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] 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] 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
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
[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] [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 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] 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] 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] 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
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
