[Caml-list] JFLA 2009: 1er appel aux communications
(This message is intentionally written in French) * MERCI DE FAIRE CIRCULER * MERCI DE FAIRE CIRCULER * MERCI DE FAIRE CIRCULER * PREMIER APPEL AUX COMMUNICATIONS PREMIER APPEL AUX COMMUNICATIONS JFLA'2009 (http://jfla.inria.fr/) Journées Francophones des Langages Applicatifs Organisées par l'INRIA 31 janvier au 3 février 2009 JFLA'2009 est la vingtième conférence francophone organisée autour des langages applicatifs et des techniques de certification basées sur la démonstration. Ces nouvelles journées se tiendront du 31 janvier au 3 février 2009. Elles auront lieu à la montagne, très probablement à Saint-Quentin sur Isère, au pied du Vercors, à proximité de Grenoble. Toujours centrée sur l'approche fonctionnelle de la programmation, la conférence porte également sur les techniques et outils complémentaires qui élèvent le niveau de qualité des logiciels (systèmes d'aide à la preuve, réécriture, tests, démonstration automatique, vérification). Les JFLA réunissent concepteurs et utilisateurs dans un cadre agréable qui facilite la communication; ces journées ont pour ambition de couvrir le domaine des langages applicatifs au sens large, en y incluant les apports d'outils d'autres domaines qui permettent la construction de systèmes logiciels plus sûrs. L'enseignement de l'approche fonctionnelle du développement logiciel (spécification, sémantiques, programmation, compilation, certification) est également un sujet qui concerne au plus haut point les JFLA. C'est pourquoi des contributions sur les thèmes suivants sont particulièrement recherchées (liste non exclusive) : - Langages applicatifs : sémantique, compilation, optimisation, mesures, tests, extensions par d'autres paradigmes de programmation. - Spécification, prototypage, développements formels d'algorithmes. - Utilisation industrielle des langages applicatifs. - Assistants de preuve : implémentation, nouvelles tactiques, développements présentant un intéret technique ou méthodologique. - Enseignement dans ses aspects liés à l'approche fonctionnelle du développement. Les JFLA cherchent avant tout des articles de recherche originaux qui apportent une réelle nouveauté. Toutefois, un article traitant d'un sujet qui intéresse plusieurs disciplines sera examiné avec soin, même s'il a préalablement été présenté à une autre communauté sans rapport avec celle des JFLA. Un article ayant été traduit en français à partir d'une publication récente en anglais sera examiné, à condition que la traduction apporte un élément nouveau. Les articles soumis aux JFLA sont relus par au moins 2 personnes s'ils sont acceptés, 3 personnes s'ils sont rejetés. Les critiques des relecteurs sont toujours bienveillantes et la plupart du temps encourageantes et constructives, même en cas de rejet. Il n'y a donc pas de raison de ne pas soumettre aux JFLA ! Orateurs invités Vincent Balat (Université Paris 7): "Ocsigen : approche fonctionnelle typée de la programmation Web." Eduardo Giménez (Trusted Logic). Cours - Gérard Huet (INRIA Paris-Rocquecourt): "Automates, transducteurs et machines d'Eilenberg applicatives dans la boîte à outils Zen. Applications au traitement de la langue." Assia Mahboubi (LIX, INRIA Saclay - Île-de-France): "Présentation de SSRefelect." Comité de programme --- Alan Schmitt, Président (LIG, INRIA Grenoble - Rhône-Alpes) Micaela Mayero, Vice-Présidente (LIPN, Université Paris 13) Boutheina Chetali (Gemalto) Sylvain Conchon (LRI, Université Paris-Sud) David Delahaye (CEDRIC, CNAM) Hugo Herbelin (LIX, INRIA Saclay - Île-de-France) Didier Le Botlan (LAAS-CNRS, INSA de Toulouse) Jean-Vincent Loddo (LIPN, Université Paris 13) Alexandre Miquel (PPS, Université Paris 7) Davide Sangiorgi (Université de Bologne) Soumission -- Date limite de soumission : 15 octobre 2008 Les soumissions doivent être soit rédigées en français, soit présentées en français. Elles sont limitées à 15 pages A4. Le style latex est imposé et se trouve sur le site WEB des journées à l'adresse suivante : http://jfla.inria.fr/2009/actes.sty La soumission est uniquement électronique, selon la méthode détaillée dans http://jfla.inria.fr/2009/instructions-fra.html Les soumissions sont à envoyer au président du comité de programme, avec pour titre de votre message ``SOUMISSION JFLA 2008'', à l'adresse suivante : [EMAIL PROTECTED] Les intentions de soumission envoyées le plus tôt possible à l'adresse ci-dessus seront les bienvenues. Dates importantes - 15 octobre 2008 : Date limite de soumission 21 novembre 2008 : Notification aux auteurs 10 décembre 2008 : Remise des art
Re: [Caml-list] Re: thousands of CPU cores
Gerd Stolpmann wrote: Well, there's now SFU for Windows (but only for XP Professional and Windows 2003, not for XP Home and Vista, AFAIK). That's a cool solution when you want to run Win32 and POSIX programs on the same system, and maybe an alternative to using virtualization. But it is nothing for developing consumer programs on Windows. Btw, has something tried to compile O'Caml on SFU? It's a 230M free download. There seems to be gcc and lots of GNU stuff, too (yes, it's from MS...). I did this a few monthes ago, I followed the NetBSD way, since SFU is supported by NetBSD's `pkgsrc'. This was really *easy*, thanks to the efforts of the `pkgsrc' maintainers. However, I did not play that much with the system, my point was to test SFU by running very Unix-oriented and complex proecdures in it. See http://www.netbsd.org/docs/software/packages.html for general information about NetBSD's pkgsrc; Microsoft SFU is refered to as Interix here, e.g. in the ``Supported Platforms'' section. The `pkgsrc' software is a port infrastructure similar to what is found on *BSD and MacPorts, if you have used one of them, you certainly will feel comfortable with `pkgsrc'. Documentation for `pkgsrc' is available at http://www.netbsd.org/docs/pkgsrc/, besides the introduction, see especially sections 3.2 (Bootstrapping) and 4.2 (Installing ports), it shall be enough to get started! -- Cheers, Michaël ___ 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] Q: type conversion with Gdome
Hello everyone, I've been using Gdome for some time now and I always find it difficult to deal with the type system. Here is the issue: The document class has a method getElementsByTagName : tagname:Gdome.domString -> Gdome.nodeList and from a nodeList object I can only get Gdome.node objects, while we know they should be Gdome.element objects. My question is how to convert from Gdome.node to Gdome.element? P.S. Gdome.element can be converted to Gdome.node, but not in the other direction as far as I know. TIA, shouxun ___ 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] Q: type conversion with Gdome
Dear Yang, not every node is an element. Thus you need to use dinamic cast: let node = ... in (* next line may raise GdomeInit.DOMCastException *) let element = Gdome.element_of_node node in ... Cheers, C.S.C. On Wed, 2008-07-16 at 17:13 +0800, Yang Shouxun wrote: > Hello everyone, > > I've been using Gdome for some time now and I always find it difficult to > deal > with the type system. Here is the issue: > > The document class has a > method getElementsByTagName : > tagname:Gdome.domString -> Gdome.nodeList > and from a nodeList object I can only get Gdome.node objects, while we know > they should be Gdome.element objects. > > My question is how to convert from Gdome.node to Gdome.element? > > P.S. Gdome.element can be converted to Gdome.node, but not in the other > direction as far as I know. > > TIA, > > shouxun > > ___ > 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 > -- Real name: Claudio Sacerdoti Coen Doctor in Computer Science, University of Bologna E-mail: [EMAIL PROTECTED] http://www.cs.unibo.it/~sacerdot ___ 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: thousands of CPU cores
On a different, but not unrelated topic, Debian have a cross-compiler (based on MinGW) so you don't need to leave the safety & comfort of Linux in order to build Windows DLLs and binaries. http://packages.debian.org/search?keywords=mingw32 Fedora are going to offer a MinGW cross-compiler and libraries too, shortly: https://fedoraproject.org/wiki/SIGs/MinGW Rich. -- Richard Jones Red Hat ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Another question about modules
Le 16 juil. 08 à 03:05, Ashish Agarwal a écrit : It seems the circular dependency error is given only when you do ocamlbuild a.native Some errors are reported differently when you use ocamlbuild because of its automatic dependency analysis, I started a list here [1]. Daniel [1] http://brion.inria.fr/gallium/index.php/New_kinds_of_build_errors ___ 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] Another question about modules
On Wed, 2008-07-16 at 03:54 +0200, Martin Jambon wrote: > I hope you'll find this useful > :-) It was, thanks :) I am translating this code to ocaml, and the original version is written in an object-oriented fashion, so there's naturally an impedance mismatch on the translation... I'll wait a bit to decide if I should use objects in ocaml or if it's better to try to redesign the code to make it more... ocamly :p Thanks again, Andre ___ 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] memory usage
On Jul 15, 2008, at 3:38 PM, Jean Krivine wrote: I'd be glad to try the patch if you could post it somewhere! I have posted it in: http://research.amnh.org/~avaron/ocaml/ best, Andres J On Tue, Jul 15, 2008 at 3:31 PM, Andres Varon <[EMAIL PROTECTED]> wrote: Hello Jean, There is no 64-bit native OCaml compiler for Mac OS X intel. I have a patch that works in Leopard, but did not compile opt.opt in Tiger, meaning that something is not OK, so I did not offer it to the community. The bootstrap went fine, findlib and godi compiled OK too. I can post the patches somewhere if you want to give it a shot. My memory intensive application runs fine in Leopard with this compiler. But the binaries do not execute in Tiger (I found that other people had the same trouble copying a 64 bit apps from Leopard to Tiger and the other way around, but didn't look into it). If you want it ... I can post it, maybe someone can cleanup my job? All that would be needed after patching is: ./configure -host x86_64-apple-darwin -prefix /opt/ocaml/experimental (The prefix I always add for my ocaml-modified comilers). best, Andres On Jul 15, 2008, at 1:06 PM, Jean Krivine wrote: Dear all I downloaded the last version of ocaml (3.10.2) but I must confess I don't know what option I should pass to the compiler to make a binary that uses 64 bits. I tried naively ocamlopt -ccopt -arch -ccopt x86_64 but that doesn't work. Any idea? On Fri, Jul 11, 2008 at 6:01 PM, Richard Jones <[EMAIL PROTECTED]> wrote: On Fri, Jul 11, 2008 at 03:49:26PM -0400, Jean Krivine wrote: I am trying to run a stochastic simulator (written in ocaml) on a huge data set and I have the following error message: I can confirm that OCaml works fine with huge datasets, on 64 bit platforms anyway. sim(9595) malloc: *** mmap(size=1048576) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Fatal error: out of memory. My system: Mac Pro running OS X 10.5.4 Processor: 2 x 2.8 GHz Quad-Core Intel Xeon Memory: 10 GB 800 MHz DDR2 FB-DIMM Does someone know what happened? Do you have any idea of any parameter I could tune in order to avoid that? Is the compiler 32 bits or 64 bits on this machine? Try doing: $ ocaml # Sys.word_size ;; It should print out either '32' or '64'. Also run your program under whatever the OS X equivalent of 'strace' is (ktrace?) to find out exactly why the mmap call fails. OCaml <= 3.10.2 on Linux suffers a nasty problem with its use of mmap and randomized address spaces (https://bugzilla.redhat.com/show_bug.cgi?id=445545#c9) but it doesn't seem like this is the same issue. Rich. -- Richard Jones Red Hat ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ 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] memory usage
Great thanks! J On Wed, Jul 16, 2008 at 10:16 AM, Andres Varon <[EMAIL PROTECTED]> wrote: > > On Jul 15, 2008, at 3:38 PM, Jean Krivine wrote: > >> I'd be glad to try the patch if you could post it somewhere! > > I have posted it in: > > http://research.amnh.org/~avaron/ocaml/ > > best, > > Andres >> >> J >> >> On Tue, Jul 15, 2008 at 3:31 PM, Andres Varon <[EMAIL PROTECTED]> wrote: >>> >>> Hello Jean, >>> >>> There is no 64-bit native OCaml compiler for Mac OS X intel. I have a >>> patch >>> that works in Leopard, but did not compile opt.opt in Tiger, meaning that >>> something is not OK, so I did not offer it to the community. The >>> bootstrap >>> went fine, findlib and godi compiled OK too. I can post the patches >>> somewhere if you want to give it a shot. >>> >>> My memory intensive application runs fine in Leopard with this compiler. >>> But >>> the binaries do not execute in Tiger (I found that other people had the >>> same >>> trouble copying a 64 bit apps from Leopard to Tiger and the other way >>> around, but didn't look into it). >>> >>> If you want it ... I can post it, maybe someone can cleanup my job? All >>> that >>> would be needed after patching is: >>> >>> ./configure -host x86_64-apple-darwin -prefix /opt/ocaml/experimental >>> >>> (The prefix I always add for my ocaml-modified comilers). >>> >>> best, >>> >>> Andres >>> >>> On Jul 15, 2008, at 1:06 PM, Jean Krivine wrote: >>> Dear all I downloaded the last version of ocaml (3.10.2) but I must confess I don't know what option I should pass to the compiler to make a binary that uses 64 bits. I tried naively ocamlopt -ccopt -arch -ccopt x86_64 but that doesn't work. Any idea? On Fri, Jul 11, 2008 at 6:01 PM, Richard Jones <[EMAIL PROTECTED]> wrote: > > On Fri, Jul 11, 2008 at 03:49:26PM -0400, Jean Krivine wrote: >> >> I am trying to run a stochastic simulator (written in ocaml) on a huge >> data set and I have the following error message: > > I can confirm that OCaml works fine with huge datasets, on 64 bit > platforms anyway. > >> sim(9595) malloc: *** mmap(size=1048576) failed (error code=12) >> *** error: can't allocate region >> *** set a breakpoint in malloc_error_break to debug >> Fatal error: out of memory. >> >> My system: >> >> Mac Pro running OS X 10.5.4 >> Processor: 2 x 2.8 GHz Quad-Core Intel Xeon >> Memory: 10 GB 800 MHz DDR2 FB-DIMM >> >> Does someone know what happened? Do you have any idea of any parameter >> I could tune in order to avoid that? > > Is the compiler 32 bits or 64 bits on this machine? Try doing: > > $ ocaml > # Sys.word_size ;; > > It should print out either '32' or '64'. > > Also run your program under whatever the OS X equivalent of 'strace' > is (ktrace?) to find out exactly why the mmap call fails. > > OCaml <= 3.10.2 on Linux suffers a nasty problem with its use of mmap > and randomized address spaces > (https://bugzilla.redhat.com/show_bug.cgi?id=445545#c9) but it doesn't > seem like this is the same issue. > > Rich. > > -- > Richard Jones > Red Hat > > ___ > Caml-list mailing list. Subscription management: > http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list > Archives: http://caml.inria.fr > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs > ___ 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] Re: thousands of CPU cores
Am Mittwoch, den 16.07.2008, 10:59 +0200 schrieb Michaël Grünewald: > Gerd Stolpmann wrote: > > > Well, there's now SFU for Windows (but only for XP Professional and > > Windows 2003, not for XP Home and Vista, AFAIK). That's a cool solution > > when you want to run Win32 and POSIX programs on the same system, and > > maybe an alternative to using virtualization. But it is nothing for > > developing consumer programs on Windows. > > > > Btw, has something tried to compile O'Caml on SFU? It's a 230M free > > download. There seems to be gcc and lots of GNU stuff, too (yes, it's > > from MS...). > > I did this a few monthes ago, I followed the NetBSD way, since SFU is > supported by NetBSD's `pkgsrc'. This was really *easy*, thanks to the > efforts of the `pkgsrc' maintainers. However, I did not play that much > with the system, my point was to test SFU by running very Unix-oriented > and complex proecdures in it. > > See http://www.netbsd.org/docs/software/packages.html > for general information about NetBSD's pkgsrc; Microsoft SFU is refered > to as Interix here, e.g. in the ``Supported Platforms'' section. Good to know. > The `pkgsrc' software is a port infrastructure similar to what is found > on *BSD and MacPorts, if you have used one of them, you certainly will > feel comfortable with `pkgsrc'. Documentation for `pkgsrc' is available > at http://www.netbsd.org/docs/pkgsrc/, besides the introduction, see > especially sections 3.2 (Bootstrapping) and 4.2 (Installing ports), it > shall be enough to get started! Yes, I know pkgsrc very well. I used it years ago to build software on Solaris. Later I took it as starting point for GODI. Gerd -- Gerd Stolpmann * Viktoriastr. 45 * 64293 Darmstadt * Germany [EMAIL PROTECTED] http://www.gerd-stolpmann.de Phone: +49-6151-153855 Fax: +49-6151-997714 ___ 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] memory usage
Good news, I just tested the patch and it works great with my application! I just had to modify the module random since a call to (Random.int max_int) may raise and exception (it is made for 32 bits integers). So I guess that modification should be included in the patch. Thanks a lot Andres. Jean On Wed, Jul 16, 2008 at 12:27 PM, Jean Krivine <[EMAIL PROTECTED]> wrote: > Great thanks! > > J > > On Wed, Jul 16, 2008 at 10:16 AM, Andres Varon <[EMAIL PROTECTED]> wrote: >> >> On Jul 15, 2008, at 3:38 PM, Jean Krivine wrote: >> >>> I'd be glad to try the patch if you could post it somewhere! >> >> I have posted it in: >> >> http://research.amnh.org/~avaron/ocaml/ >> >> best, >> >> Andres >>> >>> J >>> >>> On Tue, Jul 15, 2008 at 3:31 PM, Andres Varon <[EMAIL PROTECTED]> wrote: Hello Jean, There is no 64-bit native OCaml compiler for Mac OS X intel. I have a patch that works in Leopard, but did not compile opt.opt in Tiger, meaning that something is not OK, so I did not offer it to the community. The bootstrap went fine, findlib and godi compiled OK too. I can post the patches somewhere if you want to give it a shot. My memory intensive application runs fine in Leopard with this compiler. But the binaries do not execute in Tiger (I found that other people had the same trouble copying a 64 bit apps from Leopard to Tiger and the other way around, but didn't look into it). If you want it ... I can post it, maybe someone can cleanup my job? All that would be needed after patching is: ./configure -host x86_64-apple-darwin -prefix /opt/ocaml/experimental (The prefix I always add for my ocaml-modified comilers). best, Andres On Jul 15, 2008, at 1:06 PM, Jean Krivine wrote: > Dear all > > I downloaded the last version of ocaml (3.10.2) but I must confess I > don't know what option I should pass to the compiler to make a binary > that uses 64 bits. > I tried naively ocamlopt -ccopt -arch -ccopt x86_64 but that doesn't > work. Any idea? > > > > On Fri, Jul 11, 2008 at 6:01 PM, Richard Jones <[EMAIL PROTECTED]> wrote: >> >> On Fri, Jul 11, 2008 at 03:49:26PM -0400, Jean Krivine wrote: >>> >>> I am trying to run a stochastic simulator (written in ocaml) on a huge >>> data set and I have the following error message: >> >> I can confirm that OCaml works fine with huge datasets, on 64 bit >> platforms anyway. >> >>> sim(9595) malloc: *** mmap(size=1048576) failed (error code=12) >>> *** error: can't allocate region >>> *** set a breakpoint in malloc_error_break to debug >>> Fatal error: out of memory. >>> >>> My system: >>> >>> Mac Pro running OS X 10.5.4 >>> Processor: 2 x 2.8 GHz Quad-Core Intel Xeon >>> Memory: 10 GB 800 MHz DDR2 FB-DIMM >>> >>> Does someone know what happened? Do you have any idea of any parameter >>> I could tune in order to avoid that? >> >> Is the compiler 32 bits or 64 bits on this machine? Try doing: >> >> $ ocaml >> # Sys.word_size ;; >> >> It should print out either '32' or '64'. >> >> Also run your program under whatever the OS X equivalent of 'strace' >> is (ktrace?) to find out exactly why the mmap call fails. >> >> OCaml <= 3.10.2 on Linux suffers a nasty problem with its use of mmap >> and randomized address spaces >> (https://bugzilla.redhat.com/show_bug.cgi?id=445545#c9) but it doesn't >> seem like this is the same issue. >> >> Rich. >> >> -- >> Richard Jones >> Red Hat >> >> ___ >> Caml-list mailing list. Subscription management: >> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list >> Archives: http://caml.inria.fr >> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >> Bug reports: http://caml.inria.fr/bin/caml-bugs >> > > ___ > 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] Re: thousands of CPU cores
Richard Jones wrote: > On a different, but not unrelated topic, Debian have a cross-compiler > (based on MinGW) so you don't need to leave the safety & comfort of > Linux in order to build Windows DLLs and binaries. > > http://packages.debian.org/search?keywords=mingw32 I am the main author of a libsndfile (a library for reading/writing audio files like WAV, AIFF etc) written in C and widely used across all the major platforms. I have recently switched to doing all my windows builds for libsndfile on a Debian/Ubuntu box, cross-compiling using these MinGW tools and running the test suite under Wine (the windows emulator). For me, this is about 100 times easier than dealing with the pain that is windows. Erik -- - Erik de Castro Lopo - "Arguing that Java is better than C++ is like arguing that grasshoppers taste better than tree bark." -- Thant Tessman ___ 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] memory usage
On Jul 16, 2008, at 2:07 PM, Jean Krivine wrote: Good news, I just tested the patch and it works great with my application! I just had to modify the module random since a call to (Random.int max_int) may raise and exception (it is made for 32 bits integers). So I guess that modification should be included in the patch. I don't think that's a good idea. You have to use Random.int64 to get a 64 bit random integer. The Random.int function will return an integer between 0 and 2^30. Check the Random module documentation here: http://caml.inria.fr/pub/docs/manual-ocaml/libref/Random.html I wouldn't play with a random number generator unless I know exactly what I'm doing. Your results depend on it! (well, your messed-up-by- andres compiler could already have issues ... :-(, for what I use it I can verify the result with a 32 bit binary or a 64 bit linux binary, if you can, then do the same!). Andres Thanks a lot Andres. Jean On Wed, Jul 16, 2008 at 12:27 PM, Jean Krivine <[EMAIL PROTECTED]> wrote: Great thanks! J On Wed, Jul 16, 2008 at 10:16 AM, Andres Varon <[EMAIL PROTECTED]> wrote: On Jul 15, 2008, at 3:38 PM, Jean Krivine wrote: I'd be glad to try the patch if you could post it somewhere! I have posted it in: http://research.amnh.org/~avaron/ocaml/ best, Andres J On Tue, Jul 15, 2008 at 3:31 PM, Andres Varon <[EMAIL PROTECTED]> wrote: Hello Jean, There is no 64-bit native OCaml compiler for Mac OS X intel. I have a patch that works in Leopard, but did not compile opt.opt in Tiger, meaning that something is not OK, so I did not offer it to the community. The bootstrap went fine, findlib and godi compiled OK too. I can post the patches somewhere if you want to give it a shot. My memory intensive application runs fine in Leopard with this compiler. But the binaries do not execute in Tiger (I found that other people had the same trouble copying a 64 bit apps from Leopard to Tiger and the other way around, but didn't look into it). If you want it ... I can post it, maybe someone can cleanup my job? All that would be needed after patching is: ./configure -host x86_64-apple-darwin -prefix /opt/ocaml/ experimental (The prefix I always add for my ocaml-modified comilers). best, Andres On Jul 15, 2008, at 1:06 PM, Jean Krivine wrote: Dear all I downloaded the last version of ocaml (3.10.2) but I must confess I don't know what option I should pass to the compiler to make a binary that uses 64 bits. I tried naively ocamlopt -ccopt -arch -ccopt x86_64 but that doesn't work. Any idea? On Fri, Jul 11, 2008 at 6:01 PM, Richard Jones <[EMAIL PROTECTED]> wrote: On Fri, Jul 11, 2008 at 03:49:26PM -0400, Jean Krivine wrote: I am trying to run a stochastic simulator (written in ocaml) on a huge data set and I have the following error message: I can confirm that OCaml works fine with huge datasets, on 64 bit platforms anyway. sim(9595) malloc: *** mmap(size=1048576) failed (error code=12) *** error: can't allocate region *** set a breakpoint in malloc_error_break to debug Fatal error: out of memory. My system: Mac Pro running OS X 10.5.4 Processor: 2 x 2.8 GHz Quad-Core Intel Xeon Memory: 10 GB 800 MHz DDR2 FB-DIMM Does someone know what happened? Do you have any idea of any parameter I could tune in order to avoid that? Is the compiler 32 bits or 64 bits on this machine? Try doing: $ ocaml # Sys.word_size ;; It should print out either '32' or '64'. Also run your program under whatever the OS X equivalent of 'strace' is (ktrace?) to find out exactly why the mmap call fails. OCaml <= 3.10.2 on Linux suffers a nasty problem with its use of mmap and randomized address spaces (https://bugzilla.redhat.com/show_bug.cgi?id=445545#c9) but it doesn't seem like this is the same issue. Rich. -- Richard Jones Red Hat ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs ___ 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] memory usage
I agree. I should use Int64 instead of just int, but I still think that the application (Random.int max_int) should not be exception prone. Since max_int is architecture dependent, then so should be Random.int no? But you point is well taken. Thanks again J On Wed, Jul 16, 2008 at 2:44 PM, Andres Varon <[EMAIL PROTECTED]> wrote: > > > On Jul 16, 2008, at 2:07 PM, Jean Krivine wrote: > >> Good news, I just tested the patch and it works great with my application! >> I just had to modify the module random since a call to (Random.int >> max_int) may raise and exception (it is made for 32 bits integers). >> So I guess that modification should be included in the patch. > > I don't think that's a good idea. You have to use Random.int64 to get a 64 > bit random integer. The Random.int function will return an integer between 0 > and 2^30. Check the Random module documentation here: > > http://caml.inria.fr/pub/docs/manual-ocaml/libref/Random.html > > I wouldn't play with a random number generator unless I know exactly what > I'm doing. Your results depend on it! (well, your messed-up-by-andres > compiler could already have issues ... :-(, for what I use it I can verify > the result with a 32 bit binary or a 64 bit linux binary, if you can, then > do the same!). > > > Andres >> >> >> Thanks a lot Andres. >> Jean >> >> On Wed, Jul 16, 2008 at 12:27 PM, Jean Krivine >> <[EMAIL PROTECTED]> wrote: >>> >>> Great thanks! >>> >>> J >>> >>> On Wed, Jul 16, 2008 at 10:16 AM, Andres Varon <[EMAIL PROTECTED]> wrote: On Jul 15, 2008, at 3:38 PM, Jean Krivine wrote: > I'd be glad to try the patch if you could post it somewhere! I have posted it in: http://research.amnh.org/~avaron/ocaml/ best, Andres > > J > > On Tue, Jul 15, 2008 at 3:31 PM, Andres Varon <[EMAIL PROTECTED]> wrote: >> >> Hello Jean, >> >> There is no 64-bit native OCaml compiler for Mac OS X intel. I have a >> patch >> that works in Leopard, but did not compile opt.opt in Tiger, meaning >> that >> something is not OK, so I did not offer it to the community. The >> bootstrap >> went fine, findlib and godi compiled OK too. I can post the patches >> somewhere if you want to give it a shot. >> >> My memory intensive application runs fine in Leopard with this >> compiler. >> But >> the binaries do not execute in Tiger (I found that other people had >> the >> same >> trouble copying a 64 bit apps from Leopard to Tiger and the other way >> around, but didn't look into it). >> >> If you want it ... I can post it, maybe someone can cleanup my job? >> All >> that >> would be needed after patching is: >> >> ./configure -host x86_64-apple-darwin -prefix /opt/ocaml/experimental >> >> (The prefix I always add for my ocaml-modified comilers). >> >> best, >> >> Andres >> >> On Jul 15, 2008, at 1:06 PM, Jean Krivine wrote: >> >>> Dear all >>> >>> I downloaded the last version of ocaml (3.10.2) but I must confess I >>> don't know what option I should pass to the compiler to make a binary >>> that uses 64 bits. >>> I tried naively ocamlopt -ccopt -arch -ccopt x86_64 but that doesn't >>> work. Any idea? >>> >>> >>> >>> On Fri, Jul 11, 2008 at 6:01 PM, Richard Jones <[EMAIL PROTECTED]> >>> wrote: On Fri, Jul 11, 2008 at 03:49:26PM -0400, Jean Krivine wrote: > > I am trying to run a stochastic simulator (written in ocaml) on a > huge > data set and I have the following error message: I can confirm that OCaml works fine with huge datasets, on 64 bit platforms anyway. > sim(9595) malloc: *** mmap(size=1048576) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > Fatal error: out of memory. > > My system: > > Mac Pro running OS X 10.5.4 > Processor: 2 x 2.8 GHz Quad-Core Intel Xeon > Memory: 10 GB 800 MHz DDR2 FB-DIMM > > Does someone know what happened? Do you have any idea of any > parameter > I could tune in order to avoid that? Is the compiler 32 bits or 64 bits on this machine? Try doing: $ ocaml # Sys.word_size ;; It should print out either '32' or '64'. Also run your program under whatever the OS X equivalent of 'strace' is (ktrace?) to find out exactly why the mmap call fails. OCaml <= 3.10.2 on Linux suffers a nasty problem with its use of mmap and randomized address spaces (https://bugzilla.redhat.com/show_bug.cgi?id=445545#c9) but it doesn't seem like this is the same issue. Rich. >>>
Re: [Caml-list] Troublesome nodes
Hi,
> The first problem is that phantom types must be implemented in terms
> of abstract (or at least generative) types. A simple example to
> illustrate the problem: the types
>
> int t
> and
> float t
>
> denote the same type given the alias declaration
>
> type 'a t = unit
>
> but different types given the abstract type declaration
>
> type 'a t
>
> The clause "= private 'a" in your declaration above indicates that `t'
> denotes an alias, not an abstract type.
What mislead me was a simple experiment I made where declaring 't' private
had the same effect as making it abstract for purposes of creating
module values (thus forcing you to constructor functions), while at
the same time keeping the 't' open for purposes of pattern-matching.
Suppose you have a simple module that prevents the user from mixing the
proverbial apples and oranges:
module Fruit:
sig
type 'a t
val apples: int -> [`Apples] t
val oranges: int -> [`Oranges] t
val (+): 'a t -> 'a t -> 'a t
end =
struct
type 'a t = int
let apples n = n
let oranges n = n
let (+) = (+)
end
open Fruit
let foo = apples 10
let bar = oranges 20
let sum = foo + bar (* oops! *)
Now, if you un-abstract 't' by declaring "type 'a t = int" in the sig,
then the rogue unification makes the compiler accept the erroneous
top-level statements. However, if instead you declare it as "type
'a t = private int", then rogue unification is prevented, but the type
is not completely hidden. You can thus have your cake and eat it too.
(Please correct me if my interpretation of 'private' is off).
> Weak (ungeneralised) type variables are not allowed at module-level
> bindings. You'll see a similar error message if you try to compile a
> module containing the following binding, for example
>
> let x = ref None
>
> The solution to this problem is usually to change the form of the
> offending expression, for example by eta-expanding a term denoting a
> function. In your case, though, the solution is to change the
> declaration of the abstract type `t' to indicate that the type
> parameters do not occur negatively in the right-hand side. This takes
> advantage of a novel feature of OCaml -- the "relaxed value
> restriction" -- which uses a subtype-based analysis rather than a
> simple syntactic check to determine whether bindings can be made
> polymorphic.
Thanks for the explanation. The solution I adopted was to use the
'+' covariance modifier (is that its name?) *only* for parameter 'a,
because parameter 'b should always be "terminated" via a make_basic or
make_complex function: (there is no equivalent "termination" function
for parameter 'a because I want to allow documents to be composed from
other documents adlib).
type (+'a, 'b) t constraint 'a = [< super_node_t ]
val make_basic: ('a, [< `Basic]) t -> ('a, [`Basic]) t
val make_complex: ('a, [< `Basic | `Complex]) t -> ('a, [`Complex]) t
Also, I found it is alright to use ungeneralised type variables in
intermediate expressions, as long as the final expression generalises it:
(this is actually analogous to what happens when you declare "let x = ref
None"; it is fine as long as sooner or later you make the type concrete)
let doc =
let n1 = bold [text "hello"] in (* 'b is weak *)
let n2 = mref "ref" [n1] in (* 'b is still weak *)
make_complex n2 (* 'b is now concrete *)
Cheers,
Dario Teixeira
__
Not happy with your email address?.
Get the one you really want - millions of new email addresses available now at
Yahoo! http://uk.docs.yahoo.com/ymail/new.html
___
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] Troublesome nodes
From: Jeremy Yallop <[EMAIL PROTECTED]>
> Dario Teixeira wrote:
> > type ('a, 'b) t = private 'a constraint 'a = [< super_node_t ]
>
> I don't think this is quite what you want yet, although it's getting
> close!
>
> The first problem is that phantom types must be implemented in terms
> of abstract (or at least generative) types.
This is actually the other way round: abstract and private types allow
phantom types, but abbreviations and normal datatypes (generative
ones) don't.
So the above code really defines a phantom type.
Jacques Garrigue
___
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] Q: type conversion with Gdome
On Wednesday 16 July 2008 17:44:18 Claudio Sacerdoti Coen wrote: > Dear Yang, > > not every node is an element. Thus you need to use dinamic cast: > > let node = ... in > (* next line may raise GdomeInit.DOMCastException *) > let element = Gdome.element_of_node node in > ... Thank you very much. I haven't noticed element_of_node. As Gdome.element_of_node is a class and there is no equivalent function, thus my final version is like is: let element = new Gdnome.element_of_node node in > Cheers, > C.S.C. > On Wed, 2008-07-16 at 17:13 +0800, Yang Shouxun wrote: > > Hello everyone, > > > > I've been using Gdome for some time now and I always find it difficult to > > deal with the type system. Here is the issue: > > > > The document class has a > > method getElementsByTagName : > > tagname:Gdome.domString -> Gdome.nodeList > > and from a nodeList object I can only get Gdome.node objects, while we > > know they should be Gdome.element objects. > > > > My question is how to convert from Gdome.node to Gdome.element? > > > > P.S. Gdome.element can be converted to Gdome.node, but not in the other > > direction as far as I know. > > > > TIA, > > > > shouxun ___ 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] Re : Findlib fails to build on OS X Leopard
Hi, > 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//" || ... We had the same problem in Frama-C configure.in files and fixed it by replacing this test by OCAMLLIB=`ocamlc -where | tr -d '\\r'` Hope this helps, Benjamin ___ 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
