Re: [Caml-list] performance of ocamlgraph and ocaml batteries
Hello, 2010/12/13 Eray Ozkural > Oww, is the imperative implementation using hash tables or maps then? > Imperative implementations use hash tables (except the ones called Matrix which use arrays of bitvectors) while persistent implementations use maps. > Shouldn't be too hard to plug your own in ocamlgraph if needed. > OcamlGraph is designed for such an use : each algorithm provided by the library is a functor parameterized by the required graph operations (iterators over vertices and edges, ...). Thus you can provide your own in an easy way. Hope this helps, Julien Signoles ___ 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] ocamlclean : an OCaml bytecode cleaner (Was: (Announce) "OCAPIC" : OCaml for PIC18 microcontrollers)
Hello, 2010/11/11 Philippe Wang > Shortly: > ocamlclean is now available in a separate package so that you don't have to > get the whole ocapic distribution just to try ocamlclean. > > More information: > ocamlclean takes a bytecode executable (which are generally but not > necessarily produced by "ocamlc" compiler) and reduces its size by > eliminating some dead code. Dead code is discriminated statically. (It's > impossible to eliminate all dead code, but in some cases it can reduce > bytecode executables tremendously) It is meant to be compatible with > standard bytecode such as produced by ocamlc. (DBUG section is currently not > supported and is removed during the cleaning process. Other unsupported > sections are left untouched.) > Is ocamlclean compatible with dynamic loading? That is code potentially used by some unknown dynamically-loaded code must be kept. -- Julien ___ 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] Marshalling question
2010/10/12 Mathias Kende > To represent "abstract" graphs (those were the > equality for the nodes type is not used to check if two nodes of a graph > are the same), the library uses an internal counter. This counter must > be serialised along with the graphs and then it must be updated > correctly when graphs are unserialised to avoid creating a node with the > same identifier than o node in the unserialised graphs. > > This is explained in the FAQ : > http://ocamlgraph.lri.fr/FAQ > I didn't remember myself that the OcamlGraph FAQ contains a section about that ;-). But I bielieve that the FAQ got it wrong in case multiple graphs are > unserialised, or nodes are created before the unserialisation of other > nodes. In these situation using concrete graphs, which do not suffer > from this problem, is certainly easier (as advertised by the manual). > And I manually add identifiers to the nodes if I need many nodes with > the same label. > Of course you're right (see also my own answer to Alexey) : I will update the OcamlGraph FAQ accordingly. Thanks, Julien ___ 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] Marshalling question
Hello, 2010/10/12 Alexey Rodriguez > On Fri, Oct 8, 2010 at 3:48 PM, Mathias Kende > wrote: > > > Exception are some complex datastructure which may require additional > > care when marshalled. An example of which are the graphs of the > > ocamlgraph library (even the functional one), but there is none in the > > standard library. > > Mathias, can you elaborate on "additional care"? We are using the > functional graphs from ocamlgraph, so I am very interested in your > experiences with it. > To my knowledge, issues come with the so-called "abstract" graphs from OcamlGraph in which vertices have unique ids. 1) if there are abstract vertices in RAM while unmarshalling some others, you have to be sure that RAM vertices do not share ids with unmarshalled ones (except if you really want that). 2) Before creating new abstract vertices, you have to set the global id counter Graph.Blocks.cpt_vertex in the right way (by marshalling it and by calling Graph.Blocks.after_unserialization after unmarshalling). I'm not aware of any other (un)marshalling issue with OcamlGraph datastructures. Beyond OcamlGraph, similar issues potentially exist for any datastructure which uses unique ids as keys and/or hashconsing techniques. For instance, a quite big job is done for solving this issue in Frama-C (http://frama-c.com) which uses many hashconsed datastructures (included abstract ocamlgraph vertices, but only the above-mentioned issue 2 applies in the Frama-C context) Hope this helps, Julien Signoles ___ 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] Create a constraint between variant type and data list
let () = match GPL with > | GPL | LGPL -> > assert >(let s = "Do not forget to add new constructors to the data list > above." in > Format.ifprintf Format.std_formatter "%s" s; > true) > Sorry could be much better like this: let () = match GPL with GPL | LGPL -> ignore "Do not forget to add new constructors to the data list above." -- Julien ___ 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] Create a constraint between variant type and data list
Hello Sylvain, 2010/9/3 Sylvain Le Gall > I would like to define: > > type license = GPL | LGPL > > and > > let data = [ GPL, "GNU Public license"; > LGPL, "GNU Lesser General Public license" ] > > > I would like to enforce that all variants of license are in the > association list. > As said by other guys, you can't enforce statically such an invariant without a code generator. In pure ocaml, the below solution use a "social check" : it works only if the developer who adds a new constructor is not too bad and takes care of context when solving an error ;-). type license = GPL | LGPL let data = [ GPL, "GNU Public license"; LGPL, "GNU Lesser General Public license" ] let () = match GPL with | GPL | LGPL -> assert (let s = "Do not forget to add new constructors to the data list above." in Format.ifprintf Format.std_formatter "%s" s; true) Hope this helps, Julien ___ 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] Julien Signoles souhaite rester en contact sur LinkedIn
LinkedIn Julien Signoles requested to add you as a connection on LinkedIn: -- Zaynah, J'aimerais vous inviter à rejoindre mon réseau professionnel en ligne, sur le site LinkedIn. Julien Signoles Accept invitation from Julien Signoles http://www.linkedin.com/e/-fomxqx-gdfz8vhe-2l/XYjaplUyQvjdEKbig4eYk0nEDDsIa9/blk/I2299720931_2/1BpC5vrmRLoRZcjkkZt5YCpnlOt3RApnhMpmdzgmhxrSNBszYOnP4Pej0OdPAVcz99bQF6jSANokNSbPgUcz4OdP8Ndz4LrCBxbOYWrSlI/EML_comm_afe/ View invitation from Julien Signoles http://www.linkedin.com/e/-fomxqx-gdfz8vhe-2l/XYjaplUyQvjdEKbig4eYk0nEDDsIa9/blk/I2299720931_2/39vcjcVc38TejAOcAALqnpPbOYWrSlI/svi/ -- DID YOU KNOW you can use your LinkedIn profile as your website? Select a vanity URL and then promote this address on your business cards, email signatures, website, etc http://www.linkedin.com/e/-fomxqx-gdfz8vhe-2l/ewp/inv-21/ -- (c) 2010, LinkedIn Corporation___ 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 Tuareg Mode
Hello Romain, 2010/7/20 Romain Bardou > So I've updated my Debian a few weeks ago and it updated tuareg-mode. It's > great to know that Tuareg is still maintained. I remembered seeing a thread > here with some reproaches, about colors or something. Well I don't really > care about colors, they have always been ugly anyway. However I do care > about indentation and there was a modification that I don't really like. The > following code: > > let f = function > | A -> > 1 > | B -> > 2 > > match x with > | A -> > 1 > | B -> > 1 > > is now indented like this: > > let f = function > | A -> >1 > | B -> >2 > > match x with > | A -> >1 > | B -> >1 > > I find it less readable. I don't care about indenting too much on the right > : if the indentation is too large I can simply cut the code into several > functions. Which is good practise anyway. > > Problem is, I can't find a way to configure Tuareg to indent > pattern-matching the way it did before. I tried to change everything related > to |, with, and -> with no success. > This issue is already reported and discussed on the Tuareg BTS at ocamlforge, as well as some other issues : https://forge.ocamlcore.org/tracker/index.php?func=detail&aid=659&group_id=43&atid=255 . -- Julien ___ 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] Help Utilisation de modules avec Ocamlyacc...
Hello, For caml-list readers who do not speak French, the initial question is about the compilation of an ocamlyacc parser which uses the OcamlGraph library. Le 14 juin 2010 17:32, Rabea Ameur-Boulifa < rabea.ameur-boul...@telecom-paristech.fr> a écrit : > J'utilise la librairie ocamlgraph pour la génération d'automates (LTS)... > Je vous explique mon problème qui n'est pas un problème de Ocamlgraph mais > d'utilisation avec Ocamlyacc. > > *La compilation donne ceci* > ocamlc -c parser.mli > File "parser.mli", line 41, characters 48-72: > Unbound type constructor Graph.Builder.I(LTS).G.t > I don't know which build system (make, ocamlbuild, OcamlMakefile, etc) you are using but you must add the directory where OcamlGraph is installed to the list of directories searched for compiled files: ocamlc -c -I +ocamlgraph parser.mli The above line assumes a standard OcamlGraph installation. Hope this helps, Julien PS: this kind of question should be posted on the beginner's list ( http://tech.groups.yahoo.com/group/ocaml_beginners) ___ 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] Questions concerning modules as first-class values
Hello, 2010/6/2 Dario Teixeira > - > | | 0-arity | n-arity (n>0) | > - > | Valueish | value | function | > | | | | > | Moduleish | module| functor | > - > I disagree with your terminology. Below is the one I use: - > | | 0-arity | n-arity (n>0) | > - > | Value | constant| function | > | | || > | Module | structure | functor| > - > > Second, does the promotion of modules to first-class values also extend to > higher-order modules, ie, functors? > If I well understood what Alain Frisch and Xavier Leroy explained, modules (including both structures and functors) become first class value: structures may be converted to records and functors to functions; and conversely. But I let more informed person confirm this. -- Julien ___ 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] RFH: Values do not match: val bar1 : Foo.foo_t is not included in val bar1 : Foo.foo_t
Hello, 2010/5/24 Goswin von Brederlow > I'm playing around with packs and ways to avoid having to duplicate > module signatures all over the place. So I came up with the following > idea: Each module declares an external and internal module type and > restricts itself to the internal type. The pack then further restricts > the module to the external type. > > But then I get a type error I can't make heads or tails of: > File "pack.cmx", line 1, characters 0-1: > Error: The implementation (obtained by packing) > does not match the interface pack.mli: > Modules do not match: > sig > module type Extern = sig val bar1 : Foo.foo_t end > module type Intern = > sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end > module I : sig val bar1 : Foo.foo_t val bar2 : Foo.foo_t end > val bar1 : Foo.foo_t > val bar2 : Foo.foo_t > end > is not included in > sig val bar1 : Foo.foo_t end > Values do not match: > val bar1 : Foo.foo_t > is not included in > val bar1 : Foo.foo_t > make: *** [all] Error 2 > > Can anyone explain that to me? > The error message is not very helpful here. But don't refer to an internal generative type (namely Foo.foo_t) in your packing signature pack.mli. To solve your issue, you have to declare the type foo_t outside the pack like I said in a previous message ( http://caml.inria.fr/pub/ml-archives/caml-list/2010/05/b79d812d9dfb99e12c8e924f83d7168c.en.html ). Hope this helps, Julien ___ 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] Private modules in packages
2010/5/21 Goswin von Brederlow > Julien Signoles writes: > > > Hello, > > > > 2010/5/21 Ashish Agarwal > > > > > write a script to generate the P.mli file > > > > Why do you need Bar.mli and Foo.mli at all? Just write the P.mli > only. > > > > > > If your pack is big, you may want to mask internals of Bar and Foo to > others > > modules of the pack. Actually, values exported in Bar/Foo but not in P > exactly > > are the module counterparts of "friend methods" in OO languages. > > But then, if you have methods in Bar and Foo visible inside the pack but > not from outside, you can't just cat Bar.mli and Foo.mli into > P.mli. You need to process it to remove the 'friends' functions. > You can do something like that (pure ocaml without any external script): === file baz.mli (outside the pack P) === module type Foo = sig ... (* my public values here *) end === file p.mli === module Foo: Baz.Foo === file foo.mli === include Baz.Foo ... (* my friend values *) === file foo.ml === ... (* all my internals: defining my public+friends+private values *) Hope this helps, Julien ___ 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] Private modules in packages
Hello, 2010/5/21 Ashish Agarwal > > write a script to generate the P.mli file > > Why do you need Bar.mli and Foo.mli at all? Just write the P.mli only. > If your pack is big, you may want to mask internals of Bar and Foo to others modules of the pack. Actually, values exported in Bar/Foo but not in P exactly are the module counterparts of "friend methods" in OO languages. -- Julien ___ 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] Private modules in packages
Hello, 2010/5/21 Hans Ole Rafaelsen > When packing a set of modules into a top module using -pack, is there a way > to have some of the modules private to the package? > > If I have the modules Helper, Foo and Bar. Helper provides helper functions > used by Foo and Bar. When I'm packing them into a top mudule P, I do not > want to expose the functions of Helper to users of P. > > Is there some way to achieve this? If not, do anyone know of other ways > for packing libraries and keeping some of the modules private to the > library? > Just write yourself a file p.mli without your private modules: === p.mli === module Foo : ... module Bar : ... == Of course, you can not refer to signatures of modules Foo and Bar in p.mli. Thus you have to duplicate them or, better, to write them somewhere outside the package. >From a compilation point of view, be sure to generate p.cmi by using p.mli before generating the pack files p.cm[ox]. We use such a trick in the Frama-C tool (http://frama-c.com) for providing (usually empty) interfaces of its plug-ins. But I do not recommend you to read the Frama-C Makefiles for looking at the corresponding compilation lines (except if you are **very** motivated). Hope this helps, Julien ___ 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] OCaml defunctorization and other optimizations
Hello, 2010/5/20 Török Edwin > > On 05/20/2010 11:41 AM, Julien Signoles wrote: > I think that'll have to be someone else than me, as I consider myself > just a beginner in OCaml. > However if you think that implementing AST transforms would be possible > for a beginner (in OCaml, I do have experience with compilers), I'm > willing to give it a try. > I wrote ocamldefun during my master project where I done both the theory and the implementation of this tool: I was a beginner both in ocaml and in functional programming since I only wrote a mini-compiler in ocaml during my studies without any lecture on functional programming. But ok: there were ocaml experts in my research team which provide me some wonderful helps :-). > > I think that if there is a defunctorizer written it should live in the > OCaml distribution itself (maybe in contrib/). > Ocaml is not Coq: there is no such "contrib/" directory ;-). As far as I know, the Ocaml development team does not accept so much external contributions (for many good reasons). > I certainly don't intend to write an external tool that uses OCaml > internal modules. > That is what ocamldefun actually does. Best regards, Julien ___ 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] OCaml defunctorization and other optimizations
Hello, 2010/5/19 Török Edwin > I was able to find the sources via the wayback machine. > Unsurprisingly it doesn't build with OCaml 3.11.2 (it wants OCaml 3.06). > Is there a more up to date variant of ocamldefun? Would it be possible > to port it to 3.11.2? > As far as I know, there is no up to date variant of ocamldefun. For porting to 3.11.2, you have at least to: - update the caml AST - migrate all the camlp4 stuff to new camlp4 or camlp5 - update the different analyses to take into account AST changes (in particular the new caml constructs like recursive modules). Besides ocamldefun could be hugely improved in order to generate more efficient caml code. I know (I knew?) what to do for this purpose, but I have no time from a while ago in order to implement myself a new version of ocamldefun. I could provide some helps to someone motivated... Is it possible to implement ocamldefun-like functionality via Camlp4's > AST filters? > Defunctorisation is a fully syntactic task (that's not so true in presence of recursive modules). But, among other thinks, defunctorisation requires to perform the very same scope analysis than ocaml for binding each use of variable to its declaration. I am not an expert of Camlp4 possibilities, but defunctorisation requires to manipulate the full caml AST. > Also is it possible to implement function specialization > (monomorphization?) using an AST filter? > The example from the OCaml tutorial is not optimized by > http://www.ocaml-tutorial.org/performance_and_profiling. > I'm not an expert (again) but typing information should be required, isn't it? > Or is it possible to get access to the OCaml compiler's IL > representation and make optimizations on that? > At this day, there is no public interface to the internal modules of the caml compiler. But, depending on the context (possible license issues), you could embed some parts of the caml compiler in your tool. Hope this helps, Julien ___ 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
Fwd: [Caml-list] Balancing algorithm of Set/Map implementation
Sorry miss the Cc-ing to the caml list. -- Forwarded message -- From: Julien Signoles Date: 2010/5/14 Subject: Re: [Caml-list] Balancing algorithm of Set/Map implementation To: Yoriyuki Yamagata Hello, 2010/5/14 Yoriyuki Yamagata > When I read the balancing function of stdlib's Set/Map several years ago, I > thought I have understand how it works. But now, I read it again and I'm > less confident now. Could someone answer my questions? > > Is this code right? If r is Empty and lr and ll are huge trees, > > doesn't it create a massively unbalanced tree? > > Another question is that why OCaml implementation allows > a balancing factor up to *2*, which is usually allowed only up to 1? > > > Maybe my question is naive one, but I would appreciate if your could comment > it. > > Some years ago, Jean-Christophe Filliâtre and Pierre Letouzey formally proved within the Coq proof assistant (http://coq.inria.fr) that this algorithm is correct. Explanations provided by their paper [1] should answer your 2 questions. [1] Jean-Christophe Filliâtre and Pierre Letouzey. Functors for Proofs and Programs. In *Proceedings of The European Symposium on Programming*, volume 2986 of *Lecture Notes in Computer Science*, pages 370-384, Barcelona, Spain, April 2004. Hope this helps, Julien Signoles ___ 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
[Fwd: Re: [Caml-list] Re: Improving OCaml's choice of type to display]
Sorry, forgot the caml-list. --- Begin Message --- Jun Furuse a écrit : I have not tested it well but it counts dots and should try to find the minimal one. A problem I have found so far is that it prints something confusing, ex. module M = struct type t end module N = struct type t end open M open N let _ = ( 1 : M.t ) Error: This expression has type int but an expression was expected of type t (which t ?!?!?) From the typing environment, it refers to N.t. Hence the type error message is not correct. If there are types M.t and N.t and the both of M and N are opened, these types are printed just "t". This can be avoided by testing the result name "t" against the current typing envrionment to see it really means the original type "M.t". This requires more coding but the weekend has ended in the far east already :-) (It's 0:24 Monday now.) One solution could be the following. Let M.t the unique long type name to simplify and let P the longest prefix of M removed with the "do not print opened modules" rule. After simplifying the long name M.t to (M - P).t (that is what your implementation does, if I well understood), add the shortest suffix S of M.t such that (M - P).S.t is visible in the current typing environment. Don't know how hard is to implement such a solution in the caml compiler. -- Julien --- End Message --- ___ 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
[Fwd: Re: [Caml-list] Re: Improving OCaml's choice of type to display]
Sorry, forgot the caml-list. --- Begin Message --- Jun Furuse a écrit : I have quickly wrote a small patch against 3.11.1 for this feature, to see what it would be like. http://sites.google.com/a/furuse.info/jun/hacks/other-small-ocaml-patches With this patch, path names are printed without opened modules in the context. Do not print included modules as well would be better. However, after a quick look in the source of the caml compiler, it seems to be really harder to implement that the "do not print opened" rule. It also tries heuristic data type name simplification: if a variant/record data type is an alias of another data type whose name is shorter than the original, the printer uses the latter. # type long_name = int;; type long_name = int # (1 : t);; - : t = 1 (* t is the shorter than its original type int *) # (1 : long_name);; - : int = 1 (* int is shorter name for long_name. t is even shorter but not aliased unfortunatelly. *) I definitevely prefer to have long_name instead of int here: long_name is the name that the user choses in this context. From my point of view, the compiler should always use the name choosen by the user whenever possible. -- Julien --- End Message --- ___ 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] Why don't use batteries
Hello, Here are my personal reasons: 2) It's not 1.0 yet, I'll try it then Changing "try" by "have another look at" ;-) 3) It makes my executables too big Yes, even if it seems to be improved in a close future. 4) It's too hard to install (dependencies, godi failures) Yes: pretty sure that it's not an issue for me but one for users of my own libraries/tools. 5) It's difficult to compile against See point 4. 6) It doesn't work on my platform See point 4. 7) It uses camlp4 Yes. I'm not a camlp4's fan (mostly for the same reasons that I'm not a batteries' fan and also because it's look like another dsl I prefer to don't use whenever possible). 8) Other (please explain) 8a) Not mature enough, so not usable for developing (what I would like to be) mature libraries/tools. I'm even not sure that "not yet 1.0" are the key point here since maturity is not just a question of naming: the latest Jane Street's core library is 0.5.3, I'm pretty sure it is mature enough and I'm pretty sure that batteries 1.5.3 will not be... I hope I'm wrong for the last part of the last sentence. 8b) I'd like to see what is stable, what is experimental, especially for big libraries like batteries. 8c) Not homogeneous enough. 8d) Not clear enough for me what is the targeted audience: seem to be first for students, now for any developers but still with a dedicated focus for students (hum, maybe not after all?). 8e) My point of view is that the Jane Street's core library looks like what I would like to have as an extension of the caml stdlib: mature enough, well tested, documented enough, homogeneous (with excellent conventions), easy to use, not too big, big enough to provide useful features. Well guys, sorry: I'm quite critical with batteries here... But hopefully batteries will be improved in the future. I know that designing and implementing such a library is a very hard and time-consuming task. So thank's for your work and for doing your best for the caml community. -- Julien ___ 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] ocamlgraph predecessors
Edgar Friendly a écrit : This is another solution to the slow predecessor performance, and will have different performance characteristics than predecessor lookup-tables. Note that the lookup table solution is isomorphic to building a second graph with all the arrows reversed, and using the efficient successor operations on it. Maybe this'll be easier than keeping a merged graph. Maybe not. This solution should be easy to implement with ocamlgraph because this operation already exists in ocamlgraph : that's the "mirror" function. See here : http://ocamlgraph.lri.fr/doc/Oper.Make.html -- Julien Signoles ___ 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] ocamlgraph predecessors
Benjamin Ylvisaker a écrit : I have been using ocamlgraph for a while, and have been generally happy with it. I experienced some poor performance with moderately large graphs (10-100k vertices) recently, which led me to look through the source code a little. It seems that doing anything with the predecessors of a vertex, even just getting a list of them, requires scanning through all the vertices in a graph. This seems a little crazy to me. Am I missing something? Is there some kind of work-around that gives reasonable performance for predecessor operations (i.e. not O(|V|)). Actually, looking at the current implementation, accessing predecessors is worse that O(|V|): that is max(O(|V|,O(|E|)). If you use concrete (imperative directional) graphs, the simpler work-around is to use Imperative.Digraph.ConcreteBidirectional as suggested by Kevin Cheung. It uses more memory space (at worse the double) that standard concrete directional graphs. But accessing predecessors is in O(1) amortized instead of max(O(|V|,O(|E|)) and removing a vertex is in O(D*ln(D)) where D is the maximal degree of the graph instead of O(|V|*ln(|V|)). If you don't use this functor, other work-arounds have been suggested in other posts. By the way contributing to ocamlgraph by adding Imperative.Digraph.AbstractBidirectional (for instance) is still possible and welcome :o). -- Julien Signoles ___ 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] Mastering the garbage collector
Hello,
More
generally, is there a specification of the notion of root used by the
garbage collector somewhere ?
I recommend you the following article. You should find what you want inside.
@inproceedings{DBLP:conf/ml/CuoqD08,
author= {Pascal Cuoq and
Damien Doligez},
title = {Hashconsing in an incrementally garbage-collected system:
a story of weak pointers and hashconsing in ocaml 3.10.2},
booktitle = {ML},
year = {2008},
pages = {13-22},
ee= {http://doi.acm.org/10.1145/1411304.1411308},
crossref = {DBLP:conf/ml/2008},
bibsource = {DBLP, http://dblp.uni-trier.de}
}
Hope this helps,
Julien Signoles
--
Researcher-engineer
CEA LIST, Software Reliability Lab
91191 Gif-Sur-Yvette Cedex
tel:(+33)1.69.08.71.83 fax:(+33)1.69.08.83.95 julien.signo...@cea.fr
___
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] Typing diff between 3.10.0 and 3.11.0
Hello all, Does someone know why the following code compiles with ocaml 3.11.0 and does not with ocaml 3.10.0? I find nothing in the documented ocaml changes which could imply such a diff. = let output = print_endline ""; (* all is fine without this side effect *) (fun fmt -> Format.printf fmt) let () = output "%s" ""; output "" = Best regards, Julien Signoles ___ 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] small typing problem with modules ...
Hello, My problem here is that I'd like to have a module type T for the functor Make in b.ml and to avoid the signature duplication in b.mli ... ideally I'd like to write in b.mli something like : module type T = sig end module Make : functor (Extra : A.Extra) -> functor (A : A.T with type extra = Extra.t) -> T with ... include T with ... It's clear that I cannot write a module type as follows because the the "open A" will consider the default type of A and not it's parametrized version ... module type T = sig open A val f : extra -> unit end how can I parametrize this signature ? I can write something like : module type T = functor (A : A.T) -> sig open A val f : extra -> unit end ;; but then I'm a bit lost putting all this together ... I know I'm close ... a small hint ? Hum, module types cannot be parameterized. If you want to use a functor signature, you can write the following : = module type T = functor (Extra : A.Extra) -> functor (A : A.T with type extra = Extra.t) -> sig val f : A.extra -> unit end module Make : T open A val f : extra -> unit = But I'm pretty sure that is not really what is expected... However why cannot you just add an another abstract type in your signature like below? = module type T = sig type extra val f : extra -> unit end module Make(Extra : A.Extra)(A : A.T with type extra = Extra.t) : T with type extra = A.extra open A val f : extra -> unit = Hope this helps, Julien Signoles ___ 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] Dynamic loading of native code : what about librairies and packs ?
Hello, > I am discovering this feature of loading dynamically native code. The > Frama-C framework (www.frama-c.cea.fr) provides now a plugin > architecture that allows you to develop your own plugin and loads it > directly in the framework. > > I targeted to adapt a simple tool I developped as a Frama-C plugin and > faced some difficulties. I did not found enough information about the > compilation of cmxs files. Alain's answers are very good. I confirm that packing and dynamic loading are compatible features: all Frama-C plug-ins are packed and some of them are dynamically loaded. However, in the current distributed release of Frama-C, dynamic loading of plug-ins is still experimental. This feature will be improved in the next release and it should be easier for plug-in developers to compile dynamic plug-ins. Anyway, if you have any additional Frama-C-specific questions/feedbacks about plug-in development, don't hesitate to sent a message on the Frama-C public mailing list (http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/frama-c-discuss). Br, Julien Signoles -- Researcher-engineer CEA LIST, Software Reliability Lab 91191 Gif-Sur-Yvette Cedex tel:(+33)1.69.08.71.83 fax:(+33)1.69.08.83.95 julien.signo...@cea.fr ___ 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] Cannot safely evaluate the definition of the recursively-defined module
Hello, > module rec A1 : AA with type q = ASet.t > with type t = string > = struct > type q = ASet.t > type t = string > > let compare s1 s2 = Pervasives.compare s1 s2 > let add e s = ASet.add e s > let empty = ASet.empty > end > and ASet : Set.S with type elt = A1.t > = Set.Make(A1) > > No. It doens't work. > > however I am getting the following error: > > > > Cannot safely evaluate the definition of the recursively-defined module > > (refers to "AA.empty" when implemented as a constant value) That is consistent with the behaviour specified in Section 7.8 of the reference manual [1]. Both A1 and ASet are not safe according to the definition given in this section. So a type error occurs because ocaml does know that the program won't be safely evaluated. For additional details, you could refer to the Xavier Leroy's notes describing the implementation of recursive modules in ocaml [2]. [1] http://caml.inria.fr/pub/docs/manual-ocaml/manual021.html#toc75 [2] http://caml.inria.fr/pub/papers/xleroy-recursive_modules-03.pdf Hope this helps, Julien Signoles -- Researcher-engineer CEA LIST, Software Reliability Lab 91191 Gif-Sur-Yvette Cedex tel:(+33)1.69.08.71.83 fax:(+33)1.69.08.83.95 julien.signo...@cea.fr ___ 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] changing labels on ocamlgraph edges
Hello, > It looks like the only way to change a label on an edge e -- say > increment it -- is to read off the old one with G.E.label, then > remember the src and dst with G.E.src/dst, then G.remove_edge_e g e, > create a new edge e' with G.V.create src (label+1) dst, and > G.add_adge_e g e'. Is this supposed to be so complicated even for the > imperative graphs? No it is not :-). You just have to define yourself a mutable label. Here is an example. == open Graph module G = Imperative.Digraph.ConcreteLabeled (struct include String let equal = (=) let hash = Hashtbl.hash end) (struct type t = int ref let default = ref 0 let compare = Pervasives.compare end) let g = G.create () let print_edge v1 v2 = Format.printf "edge = %...@." !(G.E.label (G.find_edge g v1 v2)) let e = G.E.create "foo" (ref 1) "bar" let () = G.add_edge_e g e; print_edge "foo" "bar"; G.E.label e := 2; print_edge "foo" "bar" == Hope this helps, Julien Signoles ___ 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] Warning wished
Hello Dmitri, > no warning should be issued in this case since you have polymorphic > function: > applying g to () you will definitely have f x of type unit :) Applying g to 1 you will definitely have f x of type int and you have to take care of the returned integer. Unfortunatly caml emits no warning in this case (even if I understand why) :(. -- Julien ___ 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: Re : [Caml-list] Warning wished
Le mercredi 28 janvier 2009 à 14:07 +, Matthieu Wipliez a écrit : > > Hello, > > > > Is it a bug or a well-known feature that the above program does not emit > > a warning (because "f x" should have type unit in the body of "g") ? > > > > = > > let f x = x > > let g x = f x; 1 > > (* let _ = g 2 *) > > > > I'm not familiar with the internals of the compiler, but what I suppose is > happening is that it tries to unify the type of "f x" and "unit", and this > succeeds because "f x" has type 'a, which can be unified with anything. The > meaning of "a;b" seems to be let _ = a in b rather than let () = a in b. > > But like I said, these are suppositions. Sure. However in my real case, I had an "ok" code like this : let f x : 'a -> unit = ... let g x = f x; x I changed a little bit the specification of f : let f x : 'a -> 'a = ... I just expected that caml helps me to find all the instances where I had to take care of this specification change. Such a thing is one of the very good features of caml. Unfortunatly, in this case, caml did not help me while the old implementation of "g" became wrong with the new specification of "f" :-(. -- Julien ___ 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] Warning wished
Hello, Is it a bug or a well-known feature that the above program does not emit a warning (because "f x" should have type unit in the body of "g") ? = let f x = x let g x = f x; 1 (* let _ = g 2 *) Best regards, Julien Signoles ___ 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] Marshal.to_string and closures
Hello,
I have a not-so-easy-to-reproduce case in which
=
let tbl = Hashtbl.create 7
let f x = Hashtbl.find tbl x
let g b = Marshal.to_string (fun _ -> f b) [ Marshal.Closures ]
...
let _ = g ...
=
may raise the exception
=
Fatal error: exception Invalid_argument("output_value: abstract value
(Abstract)").
=
If I wrote the above code like below, all is fine:
=
let tbl = Hashtbl.create 7
let f x = Hashtbl.find tbl x;;
let g b =
let y = f b in
Marshal.to_string (fun _ -> y) [ Marshal.Closures ]
...
let _ = g ...
=
After debugging, that is the marshalling of the field 1 of the closure
(the environment?) which raises this exception.
Can someone confirm that such a behaviour is possible whenever the
environment contains a value tagged as abstract? Or in any other cases?
If that is a known behaviour for Marshal.to_string, maybe it could be
properly documented?
Best regards,
Julien Signoles
___
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] Caml implementation of the relaxed value restriction
Hello,
In the article "Many Holes in Hindley-Milner" [1], Sam Lindley claims
that the type of x is ('a * 'a s, int) NList.t in the following ocaml
program because of Garrigue's relaxed value restriction [2].
==
type 'a s
module NList : sig
type (+'length, +'elem_type) t
val nil : ('m*'m, 'a) t
val cons: 'a * ('m*'n, 'a) t -> ('m*'n s,'a) t
end = struct
type ('i,'a) t = 'a list
let nil = []
let cons (x, l) = x :: l
end
let x = NList.cons (1, NList.nil)
==
But, both with ocaml v3.10.2 and ocaml v3.12.0+dev1 (2008-12-03) (that
is the current cvs version), the infered type of [x] only contains a
weak type variable: ('_a * '_a s, int) NList.t.
I quickly look at the typing rules introduced by Jacques Garrigue in [2]
and it seems to me that Sam Lindley is right: [x] is generalisable in
the above program.
So, what's wrong here?
[1] Many Holes in Hindley-Milner.
Sam Lindley. In ACM Sigplan Workshop of ML 2008, Victoria, British
Columbia, Canada, September 2008.
[2] Relaxing the value restriction.
Jacques Garrigue. In International Symposium on Functional and
Logic Programming, Nara, April 2004. Springer-Verlag LNCS 2998.
Best regards,
Julien Signoles
--
Researcher-engineer
CEA LIST, Software Reliability Lab
91191 Gif-Sur-Yvette Cedex
tel:(+33)1.69.08.71.83 fax:(+33)1.69.08.83.95 julien.signo...@cea.fr
___
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] Problem with Functors and Module Types
Hello, once again I have some problems using functors with module types. I produced following (almost?) minimal example: module type MT_M = sig type s type t = A of s | B of t list val f : t -> t end module type MT_N = sig module M : MT_M val f : 'a -> M.t end module type MT_A = sig type t end module MakeM (A : MT_A) : MT_M with type s = A.t = struct type s = A.t type t = A of s | B of t list let f x = x end module MakeN (A : MT_A) (* : MT_N *) = struct module M = MakeM (A) let f _ = M.B [] end module A = struct type t = int end module M = MakeM (A) module N = MakeN (A) let _ = (M.f (N.f 1)) This expression has type N.M.t = MakeN(A).M.t but is here used with type M.t = MakeM(A).t There are two different solutions (at least). === 1) Externalize the sum type and use the "with type" construct: type 'a m = A of 'a | B of 'a m list module type MT_M = sig type s type t = s m val f : t -> t end ... module MakeM(A:MT_A):MT_M with type s = A.t = struct type s = A.t type t = s m let f x = x end module MakeN(A:MT_A):MT_N with type M.s = A.t and type M.t = A.t m = struct ... end ... === 2) Use the "with module construct" module MakeN(A:MT_A):MT_N with module M = MakeM(A) = struct ... end === The second solution is more elegant. Hope this helps, Julien Signoles ___ 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] Documenting submodules ?
When invoking ocamldoc, either directly or through ocamlbuild + .odocl,
the generated documentation only contains the name of modules, without
any of the comments or even the values.
Usually ocamldoc works fine with submodule:
= sub.ml
(** This is {!A}. It contains a properly-documented submodule {!A.B} and a
single value {!A.a}. *)
module A = struct
(** This is {!B}. It contains a single value {!B.b}. *)
module B = struct let b = 1 end
let a = 0
end
=
$ ocamldoc -version
Ocamldoc 3.10.1
$ ocamldoc -html sub.ml
Hope this helps,
Julien Signoles
___
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
