Re: [Caml-list] Partially hiding modules in packages
Hi, Alexey Rodriguez a écrit : > My question is about how to hide modules (or parts thereof) in > an ocaml package from the outside world (users of the package). > > * Add the file foobar.mli which contains the signatures of Foo and Bar > but hiding > Foo.unsafe_change. I think it could work, but I would have to repeat > much of the Foo > and Bar interfaces. I tried this but it didn't work, ocaml complains > as follows: That's the solution we followed in Mlpost (http://mlpost.lri.fr/) and it works fine (you may have a look at the Makefile.in in mlpost sources). Indeed, you have to repeat (parts of) the modules interfaces, but since it is where we put all the ocamldoc documentation, in a single file, it appears to be a satisfying solution. -- Jean-Christophe ___ 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] ocamlfind and GODI packaging sprint summary
The OCaml packaging sprint is now complete. It was quite a success! In total, seven packages were worked on today as part of this effort: - cairo-ocaml - bitstring - mlpost - ocamlgsl - Deriving - coThreads - Uuidm Out of these seven packages, the packaging efforts are in several states. New package available in GODI: - ocamlgsl Ready for GODI, pending upload: - bitstring - Uuidm Almost ready, requiring a bit more testing/tweaking: - Cairo-OCaml - mlpost In progress: - Deriving - coThreads So ocamlgsl is out there now and installable in GODI, with the other packages hopefully following in the next few days. You can read more, and find some ideas for libraries to package if you are interested, at the wiki page: http://ocamlsprint.couch.it/ocamlfind_and_GODI_packaging Thanks to everyone who was involved in the packaging effort today! Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science ___ 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] [ANN] ocaml-fileutils v0.4.0
Hello, Ocaml fileutils is aimed to be a platform independent library to perform operation on file like: - mv - cp - rm - mkdir - touch - which... Comes also with a module to manipulate abstract filename: - classification - make_relative: made a filename relative to another - make_absolute This new release simplify module structure (nested modules are not required anymore) and comes with a more clear documentation. It also removes parser/lexer for path which was little bit overkilling. Some operations have been optimized for speed (like find) -- coming close in term of performance to standard POSIX commands. Link: http://le-gall.net/sylvain+violaine/ocaml-fileutils.html Regards Sylvain Le Gall ___ 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] Partially hiding modules in packages
On 9/9/2009 9:00 PM, Alexey Rodriguez wrote: My question is about how to hide modules (or parts thereof) in an ocaml package from the outside world (users of the package). It is not a well-known fact, but it is possible to provide an explicit interface for the packaged module (just create an ad hoc foobar.mli and compile it before doing the -pack'ing). -- Alain ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Partially hiding modules in packages
The problem with your packages.tgz example is that you use "module type Foo = .." in the .mli. This gives the signature of a module type, that is, it refers to a _module type_ defined in the implementation file. What you want to do here is to give the signature of a _module_, not a module types, so here is the correct syntax : module Foo : sig type foo_t val initial : foo_t val show : foo_t -> string end Regarding your original problem, I've had the same needs and came up with a slightly different solution : in order to avoid the additional indirection level related to -pack (Foobar.Foo), is used a flattened representation by adding a "foobar.ml" file containing only : include Foo (and possibly include of other modules in the package). Then the foobarl.mli is : type foo_t val initial : foo_t val show : foo_t -> string And values can be referred with Foobar.foo, instead of Foobar.Foo.foo. Of course this is only useful if you don't want the user to see the internal module hierarchy, wich may not be what you had in mind. ___ 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] Partially hiding modules in packages
Dear list, My question is about how to hide modules (or parts thereof) in an ocaml package from the outside world (users of the package). I am trying to build an ocaml package with internal functionality (types and functions) that I do not want to expose. I have two modules in the package implemented by foo.ml and bar.ml. The structure of each .mli looks like this: > module Foo = sig > type t > val make : t > val change : t -> t > > (* Internal, not to be exposed. *) > val unsafe_change : t -> t > end > module Bar = sig > type t > val combine : t -> Foo.t -> t (* uses unsafe_change *) > end As you see Foo exports unsafe_change because Bar needs it. I compile both modules using "-for-pack Foobar" and build them using the "-pack" option. However, now I want to hide "Foo.unsafe_change" from the package "export list" (if there is such a thing) so that main.ml cannot call it. I see the following options: * Merge foo.ml and bar.ml so that unsafe_change does not need to be exposed. I don't like this, the modules could be very large. * Split Foo into Foo_internal and Foo, and somehow keep Foo_internal invisible. I don't know how to do this. I would use "exposed-modules" in Cabal which is a package manager for Haskell. * Add the file foobar.mli which contains the signatures of Foo and Bar but hiding Foo.unsafe_change. I think it could work, but I would have to repeat much of the Foo and Bar interfaces. I tried this but it didn't work, ocaml complains as follows: > Error: The implementation (obtained by packing) >does not match the interface foobar.mli: >The field `Foo' is required but not provided I am attaching a tarball of this attempt in case someone knows what went wrong. The example is a bit different from the example in the email. So the question is: What solution do you follow when you want to hide (part of) a module in a package? Keep in mind that the hidden parts should still be exposed to the modules inside the package. A related question is how to expose the representation Foo.t so that Bar can manipulate it directly, but at the same time keep it hidden from users of the package. The following easy hack works. Create foo_type.mli with the definition of the type t: > type t = int and redefine Foo as follows: > module Foo = sig > type t = Foo_type.t > val make : t > val change : t -> t > > (* Internal, not to be exposed. *) > val unsafe_change : t -> t > end Now "t" is visible for Bar to use but we still have to hide it from the outside world. How do we do it? Well, just use "-pack" on foo.cmx and bar.cmx. We can omit Foo_types because it has no .cmx. As a consequence Foo.t becomes abstract. This probably works by accident and maybe it is not a good idea to rely on this trick. I would appreciate if you can share your experiences and perhaps point to some ocaml library that does module or partial module hiding so I can use it as an example. Thank you! Cheers, Alexey packages.tgz Description: GNU Zip compressed 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
[Caml-list] Re: ocamlfind and GODI packaging sprint this Wednesday, 9/9
This is just a reminder that the packaging sprint is currently in progress. For more information or to take part, please drop by #ocaml on freenode and/or check out the wiki page: http://ocamlsprint.couch.it/ocamlfind_and_GODI_packaging Hez ___ 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 and GPUs
On Wed, Sep 09, 2009 12:42:35 PM, Guillaume Hennequin wrote: > Hello, > > I was wondering if there has been any effort so far in interfacing OCaml > with GPU programming solutions like AMD Stream, or OpenCL. > I'm only aware of Daml (CUDA bindings). > > I wrote some pieces of AMD Brook bindings a while ago to do very basic > read/write operations on GPU, plus some kernel calls. Not aware of any other bindings. I think I got daml to a stage similar to your Brook bindings where you could allocate a floating point array in the gpu and then maybe do something with that array. I can't really remember. It's been a while since I looked at it. > I don't have much time to invest in this unfortunately. > With OpenCL's ability to compile kernels at runtime, bindings for Ocaml > could even offer the nice possibility to write the kernels in .ml files as > strings, which would save a lot of wrappers around kernel-only C files. > I would have expected CUDA to have a similar ability but haven't checked. ___ 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] OCaml and GPUs
Hello, I was wondering if there has been any effort so far in interfacing OCaml with GPU programming solutions like AMD Stream, or OpenCL. I'm only aware of Daml (CUDA bindings). I wrote some pieces of AMD Brook bindings a while ago to do very basic read/write operations on GPU, plus some kernel calls. I don't have much time to invest in this unfortunately. With OpenCL's ability to compile kernels at runtime, bindings for Ocaml could even offer the nice possibility to write the kernels in .ml files as strings, which would save a lot of wrappers around kernel-only C files. any ideas, comments, pointers ? Guillaume. ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] probability of some events
On Wednesday 09 September 2009 08:54:08 David Allsopp wrote: > > > Are you aware of such future changes in OCaml, that would lead to > > > incompatibility? > > With the usual caveat that past performance is not an indicator of future > wealth... > > In the last few years, the only change which caused a bit of an uproar was > camlp4 between 3.09 and 3.10 (which was totally incompatible but had the > same command name). This has all since resolved itself (camlp5 maintained > separately for developers who want the old mechanism and the new camlp4 now > in general use) but I think it's reasonable to say that the response to it > at the time means that it's unlikely that such a breaking change would be > introduced within the 3.x branch of OCaml in the future, but of course I > too don't speak for the guys at Inria. It seemed obvious from the list > posts at the time that 3.10.0 was adopted more slowly than normal minor > version-number releases because of the breaking change in camlp4. Equality was also changed and caused some problems but I agree that very few breaking changes have been made to OCaml in the recent past. -- Dr Jon Harrop, Flying Frog Consultancy Ltd. http://www.ffconsultancy.com/?e ___ 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: probability of some events
09/09/2009 11:04 AM, Sylvain Le Gall: We intend to begin huge developments in OCaml (Web, GUI, system,...) and such changes will make our task a bit more difficult. At least for the 2-3 years coming there will be no problem for sure. After that, we cannot predict the future ;-) It's enough. Thanks. -- Architecte Informatique chez Blueline/Gulfsat: Administration Systeme, Recherche & Developpement +261 34 29 155 34 ___ 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: probability of some events
Hello, On 09-09-2009, Rakotomandimby Mihamina wrote: > > 2°) Now the question > > Are you aware of such future changes in OCaml, that would lead to > incompatibility? OCaml is quite conservative and don't add incompatible features very easily. I think INRIA team is aware of that and wishing to keep it this way. > > We intend to begin huge developments in OCaml (Web, GUI, system,...) > and such changes will make our task a bit more difficult. > At least for the 2-3 years coming there will be no problem for sure. After that, we cannot predict the future ;-) But if your concern is stability of language, OCaml seems a good choice. Regards, Sylvain Le Gall ___ 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] probability of some events
> > Are you aware of such future changes in OCaml, that would lead to > > incompatibility? With the usual caveat that past performance is not an indicator of future wealth... In the last few years, the only change which caused a bit of an uproar was camlp4 between 3.09 and 3.10 (which was totally incompatible but had the same command name). This has all since resolved itself (camlp5 maintained separately for developers who want the old mechanism and the new camlp4 now in general use) but I think it's reasonable to say that the response to it at the time means that it's unlikely that such a breaking change would be introduced within the 3.x branch of OCaml in the future, but of course I too don't speak for the guys at Inria. It seemed obvious from the list posts at the time that 3.10.0 was adopted more slowly than normal minor version-number releases because of the breaking change in camlp4. Further history (looking only at Changes in the sources: I started using OCaml at version 3.06, I think) suggests that breaking changes between major versions have either been detectable and trivial to fix or aided with translation tools. For example, stdlib function names had to change between Caml Special Light 1.15 and Objective Caml 1.00 or new keywords between OCaml 1.07 and 2.00 and between OCaml 2.04 and 3.00, there appears to have been much concern for backwards compatibility with tools provided to help the transition from various different previous versions of the merged compilers. As for what gems OCaml 4.x may or may not feature, you'd have to bribe the priests at Inria for details of their dreams and wishes ;o) > We intend to begin huge developments in OCaml (Web, GUI, system,...) > and such changes will make our task a bit more difficult. Your (valid) worry about future incompatibilities definitely shouldn't put you off this! It's also painless to run multiple versions of OCaml side-by-side (at least if building from sources). HTH, David ___ Caml-list mailing list. Subscription management: http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list Archives: http://caml.inria.fr Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] probability of some events
Hi, On Wed, 9 Sep 2009 08:12:48 +0300, Rakotomandimby Mihamina wrote: > > Are you aware of such future changes in OCaml, that would lead to > incompatibility? I of course can't speak for the OCaml core developers but they have been very cautious not to introduce this kind of incompatibility. Now, OCaml is also different as it possess the wonderful Camlp4. In case such incompatibility would be required to move forward, it is very likely that a camlp4 syntax extension would be developed to translate your code automatically as much as possible. > We intend to begin huge developments in OCaml (Web, GUI, system,...) > and such changes will make our task a bit more difficult. Great to hear ! Cheers, ChriS ___ 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
