[Caml-list] ocamldoc: Howto crossreference another library?
Hi,
consider
(** Uses {!print_endline} *)
let f () = print_endline Hello
What do I have to do such that ocamldoc generates a
crossreference to
file:///usr/share/doc/ocaml-doc/ocaml.html/libref/Pervasives.html#VALprint_endline
?
Bye,
Hendrik
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] ocamldoc: Howto crossreference another library?
On Wed, 7 Mar 2012 09:58:02 +0100
Hendrik Tews t...@os.inf.tu-dresden.de wrote:
Hi,
Hello,
consider
(** Uses {!print_endline} *)
let f () = print_endline Hello
What do I have to do such that ocamldoc generates a
crossreference to
file:///usr/share/doc/ocaml-doc/ocaml.html/libref/Pervasives.html#VALprint_endline
?
OCamldoc can only create links to elements it knows about, i.e. in modules
given on command line (or loaded from a dump).
So the answer is: you can't.
Regards,
Maxence
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] concerning using of `deriving' syntactic plugin
Hi,
I would like to print out the response of a modified Ocaml's typechecker
to various inputs.
One way to do it would be to write a pretty-printer by hand.
Before I do that, I would like to apply deriving machinery:
http://code.google.com/p/deriving/wiki/Introduction
to this (chore) job.
In some cases I do not know what to do.
E.g., file types/types.mli contains the following definition:
and value_kind =
Val_reg
| Val_prim of Primitive.description
| Val_ivar of mutable_flag * string
| Val_self of
(Ident.t * type_expr) Meths.t ref *
(Ident.t * mutable_flag * virtual_flag * type_expr) Vars.t ref *
string * type_expr
| Val_anc of (string * Ident.t) list * string
| Val_unbound
If I add
deriving (Show)
at the end of the above definition, I get an error:
Error: Unbound module Meths.Show_t
That is expected but I am not sure what to do. That is, I am not sure
what is the official way to deriving-sify the Meth module which
defined in the following way:
module Meths = Map.Make(OrderedString)
without the need to modify files map.ml{i,}.
Is something like that possible?
Thank you very much in advance for any help.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
You can inject the definition you want in the following way:
module Meths = struct
include Meths
module Show_t = ...
end
type value_kind = ...
deriving (Show)
This works because deriving, being a Camlp4 extension, does not refer
to the module Meths, but any module Meths that is in scope at the
place of expansion. This could be seen as a defect of hygiene (indeed
that makes camlp4 macro non-hygienic according to the Scheme notion of
hygiene) but is also a feature, rather than a bug, of the syntactic
macro system; because as a macro-writer you can give flexibility to
the user by specifying the free variables you rely on.
On Wed, Mar 7, 2012 at 12:49 PM, Matej Košík
5764c029b688c1c0d24a2e97cd7...@gmail.com wrote:
Hi,
I would like to print out the response of a modified Ocaml's typechecker
to various inputs.
One way to do it would be to write a pretty-printer by hand.
Before I do that, I would like to apply deriving machinery:
http://code.google.com/p/deriving/wiki/Introduction
to this (chore) job.
In some cases I do not know what to do.
E.g., file types/types.mli contains the following definition:
and value_kind =
Val_reg
| Val_prim of Primitive.description
| Val_ivar of mutable_flag * string
| Val_self of
(Ident.t * type_expr) Meths.t ref *
(Ident.t * mutable_flag * virtual_flag * type_expr) Vars.t ref *
string * type_expr
| Val_anc of (string * Ident.t) list * string
| Val_unbound
If I add
deriving (Show)
at the end of the above definition, I get an error:
Error: Unbound module Meths.Show_t
That is expected but I am not sure what to do. That is, I am not sure
what is the official way to deriving-sify the Meth module which
defined in the following way:
module Meths = Map.Make(OrderedString)
without the need to modify files map.ml{i,}.
Is something like that possible?
Thank you very much in advance for any help.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
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 and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] odb questions
Hello, A few questions about odb. 1) Is it possible to specify in ~/.odb/packages a remote packages file (instead of just individual remote packages) ? 2) How does odb find out and manage dependencies ? How can I list them before installing a package ? 3) Are multiple versions of the same package supported (à la homebrew on osx) ? 4) Is something like odb install -file package.tbz possible ? The use case for 4) is both for testing and so that I can instruct my users once they have downloaded a tbz and went through the README that they can just install it with that command (provided they have installed other deps). Daniel P.S. I think odb should use a odb cmd scheme. Instead of just installing on odb pkg. The former scheme has better scaling opportunities. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
Are you familiar with type-conv and the family of syntax-extensions that go
along with it? You can do thinks like:
type t = { foo: int; bar: string }
with sexp, compare, bin_io
and automatically get sexp-conversion functions, a comparison function, and
binary protocol converters. And type-conv has been used to build other
type-directed functions by other people outside of Jane Street.
The latest version is available on bitbucket, and we'll have a new blessed
release in a few days.
https://bitbucket.org/yminsky/ocaml-core/
Note that this is done purely syntactically, and yet gets you there.
y
On Wed, Mar 7, 2012 at 6:49 AM, Matej Košík
5764c029b688c1c0d24a2e97cd7...@gmail.com wrote:
Hi,
I would like to print out the response of a modified Ocaml's typechecker
to various inputs.
One way to do it would be to write a pretty-printer by hand.
Before I do that, I would like to apply deriving machinery:
http://code.google.com/p/deriving/wiki/Introduction
to this (chore) job.
In some cases I do not know what to do.
E.g., file types/types.mli contains the following definition:
and value_kind =
Val_reg
| Val_prim of Primitive.description
| Val_ivar of mutable_flag * string
| Val_self of
(Ident.t * type_expr) Meths.t ref *
(Ident.t * mutable_flag * virtual_flag * type_expr) Vars.t ref *
string * type_expr
| Val_anc of (string * Ident.t) list * string
| Val_unbound
If I add
deriving (Show)
at the end of the above definition, I get an error:
Error: Unbound module Meths.Show_t
That is expected but I am not sure what to do. That is, I am not sure
what is the official way to deriving-sify the Meth module which
defined in the following way:
module Meths = Map.Make(OrderedString)
without the need to modify files map.ml{i,}.
Is something like that possible?
Thank you very much in advance for any help.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
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 and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/07/2012 07:32 AM, Daniel Bünzli wrote: Hello, A few questions about odb. 1) Is it possible to specify in ~/.odb/packages a remote packages file (instead of just individual remote packages) ? Not at the moment, but this is an interesting idea. The only support for remote packages is the querying of oasis-db. The protocol is nearly trivial, so you're welcome to make your own server (can be just a plain web server serving static text files) and set the odb repository URL to it. 2) How does odb find out and manage dependencies ? How can I list them before installing a package ? Odb uses findlib to determine what libraries are installed. For executables, the unix command `which` is used. In the works is extracting the version of executables from running the command with `-version`. The other end of this is handled by odb's metadata that specifies things like where to get the source code, dependencies, installation requirements, and other useful information for installing. There are two sources for this metadata: 1) oasis-db by http 2) packages files locally. The packages files are parsed on startup, if odb needs info about a package not in this cache, it queries oasis-db for the metadata. I like the idea of printing deps without installing, and it should be pretty easy to implement. It'd probably suffice to just print the whole metadata; it's quite readable. Maybe metadata + dependency check will satisfy your needs? 3) Are multiple versions of the same package supported (à la homebrew on osx) ? This is supported in two ways. First through environment variables that basically switch between different ocaml installations / ocamlfind root paths. Odb relies on findlib to manage libraries, and it supports this through tweaking install paths. The other way is to have packages batteries1 and batteres2 that both install different versions of batteries, and as long as they register in findlib with the names batteries1 and batteries2, odb will treat them as different. 4) Is something like odb install -file package.tbz possible ? It's planned to be able to give a full package info on the command line, so this would be more like: odb tarball=package.tbz deps=odn,batteries The use case for 4) is both for testing and so that I can instruct my users once they have downloaded a tbz and went through the README that they can just install it with that command (provided they have installed other deps). The current way to do testing is to put a line in your local packages file (two locations that are scanned for one: ~/.odb and the odb script dir), and use the info there for testing. Then once you've got it working, make a simple _oasis file for it, and upload it to oasis-db - then everyone will gain access to it automatically. Daniel P.S. I think odb should use a odbcmd scheme. Instead of just installing on odbpkg. The former scheme has better scaling opportunities. Except I don't intend odb to scale. It's hovering right around 500 lines of code, and if I can keep it around that size, I'll be happy. I don't intend odb to ever have a `odb remove foo` command, nor an `odb update`. Maybe I'll have an `odb upgrade`, but I'm happy leaving this as `odb --upgrade`. Odb's goal is to be an 80% solution, and it was that a while ago, I think. It's approaching 90%, and I'm going to try to avoid it feature creeping to 100%. Oddities should be handled by the package installers themselves or the metadata repository as much as possible, leaving pretty little work for odb. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] Can one implement greedy/inline data structures in ocaml?
Hi,
I'm wondering if it is possible to implement greedy/inline data
structures in ocaml in a generic and reusable way.
Maybe you don't know what greedy/inline data structures are or maybe I'm
using the wrong name. So here is what I mean:
Say you have a task structure that is in 2 doubly linked list. One list
links all the structures together and the second list links structures
with the same internal state (running, sleeping, waiting, ...). In C you
would then have something like this:
struct task {
DLIST(task, all);
DLIST(task, state);
foo_t data;
}
The DLIST makro adds the prev/next pointers to the struct, one set
prefixed with all, the other with state. There would also be makros to
to init, insert, remove and iterate of the two lists.
The internal pointer needed for the DLIST are part of the struct
task. The big advantage of this (and why I ask) is that given a task one
can esily remove it from both lists.
On the other hand if the list is external to the struct and only
contains a pointer to the task then removing a task becomes
difficult. The task then needs pointers to each of the lists data
structures creating cycles. Not good for ocaml. It also would waste
memory for 2 pointers (per list).
So how would you design such greedy/inline data structures in ocaml?
Or how else would you design containers (list, doubly linked list,
queue, ...) so that things can be in multiple containers and removing
them is fast?
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Can one implement greedy/inline data structures in ocaml?
On 03/07/2012 09:41 AM, Goswin von Brederlow wrote: The task then needs pointers to each of the lists data structures creating cycles. Not good for ocaml. It also would waste memory for 2 pointers (per list). Cycles are fine for ocaml, pointers are pretty cheap, and I think the answer to your question is no - there's a regularity to values that's required by the garbage collector, and what you seem to want is the ability to inline nested structures without pointers, and OCaml's data representation doesn't allow this, mainly because of the tag word needed by the GC. Beware premature optimization. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] state of native dynlink on os x
On 7 mars 2012, at 11:55, Damien Doligez wrote: Hi Alan, OS X 10.7.3, ocaml 3.12.1-godi2. You need to apply the patch from this PR: http://caml.inria.fr/mantis/view.php?id=4863 From your configure output, I presume godi uses the patch from this PR: http://caml.inria.fr/mantis/view.php?id=5379 but it's incomplete. Thanks, it did work indeed (and I've reported this upstream to the godi list). Alan -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
Le mercredi, 7 mars 2012 à 15:37, Edgar Friendly a écrit : Not at the moment, but this is an interesting idea. The only support for remote packages is the querying of oasis-db. The protocol is nearly trivial, so you're welcome to make your own server (can be just a plain web server serving static text files) and set the odb repository URL to it. Okay. Would be nice to have the support in the tool and documentation on how to make your own package source (basically GET on a ~/.odb/packages file ?). Package distribution should be distributed. The other end of this is handled by odb's metadata that specifies things like where to get the source code, dependencies, installation requirements, and other useful information for installing. There are two sources for this metadata: 1) oasis-db by http 2) packages files locally. The packages files are parsed on startup, if odb needs info about a package not in this cache, it queries oasis-db for the metadata. By 2) you mean what is described in Local packages here : https://github.com/thelema/odb ? Because the syntax for specifiying deps is not documented. I like the idea of printing deps without installing, and it should be pretty easy to implement. It'd probably suffice to just print the whole metadata; it's quite readable. Maybe metadata + dependency check will satisfy your needs? Why not ? This is supported in two ways. First through environment variables that basically switch between different ocaml installations / ocamlfind root paths. Odb relies on findlib to manage libraries, and it supports this through tweaking install paths. The other way is to have packages batteries1 and batteres2 that both install different versions of batteries, and as long as they register in findlib with the names batteries1 and batteries2, odb will treat them as different. IMHO a package should be identified by a name and version. It's planned to be able to give a full package info on the command line, so this would be more like: odb tarball=package.tbz deps=odn,batteries That would be nice. The current way to do testing is to put a line in your local packages file (two locations that are scanned for one: ~/.odb and the odb script dir), and use the info there for testing. Okay but how do I specify deps ? I'm sure I can quickly find out but I want you to update the docs... Except I don't intend odb to scale. Pity. It's hovering right around 500 lines of code, and if I can keep it around that size, I'll be happy. That's indeed a good thing, aswell as no deep deps. But hey, setup.ml is around 10x more (which makes it unusable for dev. btw.) you still have some way to go. I don't intend odb to ever have a `odb remove foo` command, nor an `odb update`. Maybe I'll have an `odb upgrade`, but I'm happy leaving this as `odb --upgrade`. Odb's goal is to be an 80% solution, and it was that a while ago, I think. It's approaching 90%, and I'm going to try to avoid it feature creeping to 100%. Oddities should be handled by the package installers themselves or the metadata repository as much as possible, leaving pretty little work for odb. Pity. I like odb's down to earth approach. Best, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/07/2012 10:47 AM, Daniel Bünzli wrote: Okay. Would be nice to have the support in the tool and documentation on how to make your own package source (basically GET on a ~/.odb/packages file ?). Package distribution should be distributed. one file per package, filename is package name, contents are same format as rest of packages line but with \n between key=value pairs instead of space. By 2) you mean what is described in Local packages here : https://github.com/thelema/odb ? Because the syntax for specifiying deps is not documented. Deps are just a comma-separated list of package names, with optional version numbers in parentheses. I'll document this in the packages file now. IMHO a package should be identified by a name and version. I've been thinking about this for a long time, and the full consequences of this involve not only deep changes to odb internals, but also expose the code to a ton more edge cases that need to be handled, as well as possibly some NP-hard problems of resolving version dependencies. Odb may go this way if needed, but the current practice of having a single string as the package identifier is sufficient for my use, so... Pity. I like odb's down to earth approach. You're more than welcome to fork and build a better odb. I may even steal any good ideas you have and put them back in my odb. :) E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
Le mercredi, 7 mars 2012 à 16:58, Edgar Friendly a écrit : IMHO a package should be identified by a name and version. I've been thinking about this for a long time, and the full consequences of this involve not only deep changes to odb internals, but also expose the code to a ton more edge cases that need to be handled, as well as possibly some NP-hard problems of resolving version dependencies. Odb may go this way if needed, but the current practice of having a single string as the package identifier is sufficient for my use, so... Yes, I understand that. I fear there's dependency hell waiting around the corner, but maybe this can be mitigated by implementing that idea of being able to easily specify your own package source in ~/.odb/packages. Well, in fact you can already do that locally by crafting your own ~/.odb/packages file. So maybe your approach is the right balancing act between usability and complexity. You're more than welcome to fork and build a better odb. I may even steal any good ideas you have and put them back in my odb. :) If I get too annoyed with too much time on my hands (i.e. very unlikely) I may eventually do that. Thanks for the answers and the tool, Daniel -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Can one implement greedy/inline data structures in ocaml?
Edgar Friendly thelema...@gmail.com writes:
On 03/07/2012 09:41 AM, Goswin von Brederlow wrote:
The task then needs pointers to each of the lists data
structures creating cycles. Not good for ocaml. It also would waste
memory for 2 pointers (per list).
Cycles are fine for ocaml, pointers are pretty cheap, and I think the
answer to your question is no - there's a regularity to values that's
required by the garbage collector, and what you seem to want is the
ability to inline nested structures without pointers, and OCaml's data
representation doesn't allow this, mainly because of the tag word
needed by the GC.
Beware premature optimization.
E.
The problem with cycles is that you need to define all structures in a
cyled atomically as the same time. That means using let rec foo =
... and bar = ... and sometimes needing to lift function calls out of
the initialization.
For example and from memory you couldn't write this:
let rec task = {
all_list = all_list;
state_list = state_list;
foo = bar;
}
and all_list = DList.create_item all_list_head task
and state_list DList.create_item state_list_head task
At the time the DList.create_item is called the task binding is still
incomplete and you get an error that it can't be on the right-hand side.
So then you need mutable option types or mutables that you initialize
with dummy values and then overwrite with the real thing once all
members of a cycle are created. Or some other trickery to make it
work. Overall cycles are generally not good.
Inlining the DList wihtout another indirection like in C would be nice
but would certainly require some camlp4 code to pull off. But it would
certainly be enough to pull in a pointer to the list structure as long
as you don't also need a back pointer inside the list structure. The
cycle is the problem there, just one direction is fine.
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
On 03/07/2012 12:34 PM, Yaron Minsky wrote:
Are you familiar with type-conv and the family of syntax-extensions that
go along with it? You can do thinks like:
type t = { foo: int; bar: string }
with sexp, compare, bin_io
and automatically get sexp-conversion functions, a comparison function,
and binary protocol converters. And type-conv has been used to build
other type-directed functions by other people outside of Jane Street.
The latest version is available on bitbucket, and we'll have a new
blessed release in a few days.
https://bitbucket.org/yminsky/ocaml-core/
Note that this is done purely syntactically, and yet gets you there.
I have looked at bin_prot and sexplib previously.
They are very nice and useful.
I have found one (I guess unnecessary) disadvantage over `deriving'.
If you process your *.ml file with sexplib/bin_prot preprocessor, you
have to append with ... suffix to every type definition, otherwise you
will get a an error report from the preprocessor. `Deriving' does not
force you to do that. You can annotate only those type definitions,
which for you makes sense to annotate.
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
On 03/07/2012 12:31 PM, Gabriel Scherer wrote: You can inject the definition you want in the following way: module Meths = struct include Meths module Show_t = ... end type value_kind = ... deriving (Show) This works because deriving, being a Camlp4 extension, does not refer to the module Meths, but any module Meths that is in scope at the place of expansion. This could be seen as a defect of hygiene (indeed that makes camlp4 macro non-hygienic according to the Scheme notion of hygiene) but is also a feature, rather than a bug, of the syntactic macro system; because as a macro-writer you can give flexibility to the user by specifying the free variables you rely on. I have never used include construct myself but I always wanted it. Its cool that we have it :-) The above problem can indeed be solved, i.e. pretty-printer can be generated in this way. The tricky part is to figure out how to define the Show_t module definition, which is non-obvious. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] Can one implement greedy/inline data structures in ocaml?
So then you need mutable option types or mutables that you initialize
with dummy values and then overwrite with the real thing once all
members of a cycle are created. Or some other trickery to make it
work. Overall cycles are generally not good.
I believe the trick you need (either passing a dummy value of your
type, or Obj.magic) is less ugly that your Camlp4 solution for inline
access.
If I really needed absolute performance, I'd use the inline version
just like in C, with mutable fields, but without preprocessor sugar.
Preprocessing could avoid a bit of duplication (corresponding to
manual inlining) on the structure-definition side, but wouldn't
simplify the structure-using code much.
On Wed, Mar 7, 2012 at 5:32 PM, Goswin von Brederlow goswin-...@web.de wrote:
Edgar Friendly thelema...@gmail.com writes:
On 03/07/2012 09:41 AM, Goswin von Brederlow wrote:
The task then needs pointers to each of the lists data
structures creating cycles. Not good for ocaml. It also would waste
memory for 2 pointers (per list).
Cycles are fine for ocaml, pointers are pretty cheap, and I think the
answer to your question is no - there's a regularity to values that's
required by the garbage collector, and what you seem to want is the
ability to inline nested structures without pointers, and OCaml's data
representation doesn't allow this, mainly because of the tag word
needed by the GC.
Beware premature optimization.
E.
The problem with cycles is that you need to define all structures in a
cyled atomically as the same time. That means using let rec foo =
... and bar = ... and sometimes needing to lift function calls out of
the initialization.
For example and from memory you couldn't write this:
let rec task = {
all_list = all_list;
state_list = state_list;
foo = bar;
}
and all_list = DList.create_item all_list_head task
and state_list DList.create_item state_list_head task
At the time the DList.create_item is called the task binding is still
incomplete and you get an error that it can't be on the right-hand side.
So then you need mutable option types or mutables that you initialize
with dummy values and then overwrite with the real thing once all
members of a cycle are created. Or some other trickery to make it
work. Overall cycles are generally not good.
Inlining the DList wihtout another indirection like in C would be nice
but would certainly require some camlp4 code to pull off. But it would
certainly be enough to pull in a pointer to the list structure as long
as you don't also need a back pointer inside the list structure. The
cycle is the problem there, just one direction is fine.
MfG
Goswin
--
Caml-list mailing list. Subscription management and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
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 and archives:
https://sympa-roc.inria.fr/wws/info/caml-list
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
Le Wed, 07 Mar 2012 16:44:20 +, Matej Košík 5764c029b688c1c0d24a2e97cd7...@gmail.com a écrit : The above problem can indeed be solved, i.e. pretty-printer can be generated in this way. The tricky part is to figure out how to define the Show_t module definition, which is non-obvious. If you can modify the definition of Meths the easiest way is: module Meths = struct include Map.Make(OrderedString) module Show_t = Show.Show_map(OrderedString)(Show.Show_string) end -- Jérémie -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
On Wed, Mar 7, 2012 at 11:44, Matej Košík 5764c029b688c1c0d24a2e97cd7...@gmail.com wrote: I have found one (I guess unnecessary) disadvantage over `deriving'. If you process your *.ml file with sexplib/bin_prot preprocessor, you have to append with ... suffix to every type definition, otherwise you will get a an error report from the preprocessor. `Deriving' does not force you to do that. You can annotate only those type definitions, which for you makes sense to annotate. I'm not sure what the perceived problem is, but there should be no need to annotate all type definitions. It should suffice to annotate those for which converters are needed. This, of course, means that any types that a type definition is referring to will also need annotations (or hand-written conversion functions). Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mo...@gmail.com -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
Hi Markus, On 03/07/2012 05:10 PM, Markus Mottl wrote: On Wed, Mar 7, 2012 at 11:44, Matej Košík 5764c029b688c1c0d24a2e97cd7...@gmail.com wrote: I have found one (I guess unnecessary) disadvantage over `deriving'. If you process your *.ml file with sexplib/bin_prot preprocessor, you have to append with ... suffix to every type definition, otherwise you will get a an error report from the preprocessor. `Deriving' does not force you to do that. You can annotate only those type definitions, which for you makes sense to annotate. I'm not sure what the perceived problem is, but there should be no need to annotate all type definitions. It should suffice to annotate those for which converters are needed. The following artificial example: open Sexplib.Conv type foo = int * int with sexp type bar = float * float with sexp is compilable (e.g.: ocamlc -o main -pp camlp4of -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/sexplib -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/type-conv pa_type_conv.cma pa_sexp_conv.cma -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/sexplib -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/type-conv unix.cma nums.cma bigarray.cma sexplib.cma main.ml ) If you remove any of the with sexp clauses, you will get a preprocessor error: File main.ml, line 4, characters 18-23: Parse error: with expected after [type_declaration] (in [str_item]) File main.ml, line 1, characters 0-1: This is at least what I am experiencing. This, of course, means that any types that a type definition is referring to will also need annotations (or hand-written conversion functions). Regards, Matej Kosik -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
You are the wrong version of camlp4 (the different campl4 binaries load different libraries, syntaxes etc...). If you switch camlp4orf to camlp4o your code should compile fine. Also note that I would recommend using the excellent ocamlfind tool: ocamlfind c -linkpkg -package sexplib,sexplib.syntax -syntax camlp4o main.ml Till On Wed, Mar 7, 2012 at 12:28 PM, Matej Košík 5764c029b688c1c0d24a2e97cd7...@gmail.com wrote: Hi Markus, On 03/07/2012 05:10 PM, Markus Mottl wrote: On Wed, Mar 7, 2012 at 11:44, Matej Košík 5764c029b688c1c0d24a2e97cd7...@gmail.com wrote: I have found one (I guess unnecessary) disadvantage over `deriving'. If you process your *.ml file with sexplib/bin_prot preprocessor, you have to append with ... suffix to every type definition, otherwise you will get a an error report from the preprocessor. `Deriving' does not force you to do that. You can annotate only those type definitions, which for you makes sense to annotate. I'm not sure what the perceived problem is, but there should be no need to annotate all type definitions. It should suffice to annotate those for which converters are needed. The following artificial example: open Sexplib.Conv type foo = int * int with sexp type bar = float * float with sexp is compilable (e.g.: ocamlc -o main -pp camlp4of -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/sexplib -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/type-conv pa_type_conv.cma pa_sexp_conv.cma -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/sexplib -I /home/mkosik/lib/godi/lib/ocaml/std-lib/../pkg-lib/type-conv unix.cma nums.cma bigarray.cma sexplib.cma main.ml ) If you remove any of the with sexp clauses, you will get a preprocessor error: File main.ml, line 4, characters 18-23: Parse error: with expected after [type_declaration] (in [str_item]) File main.ml, line 1, characters 0-1: This is at least what I am experiencing. This, of course, means that any types that a type definition is referring to will also need annotations (or hand-written conversion functions). Regards, Matej Kosik -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list 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 and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
[Caml-list] oasis packaging questions
Hello, I'd like to support oasis in the various packages I distribute. Here are a few questions (using oasis v0.3.2~rc2). 1) All the packages I distribute are made of a single module. For now these were just installed as .cmo .cmx .cmxs. Now it seems oasis forces me to create a .mllib even if I have only one module. Is that correct ? 2) Will the change in 1) have any impact for downstream packagers and is setup.ml enough for them ? 3) The META plugin doesn't seem to generate the directives for plugins [1], is that right ? Does setup.ml support cmxs generation at all ? 4) I'm really not interested in oasis trying to generate my _tags and myocamlbuild.ml files. Is it ok to substitute my own or does setup.ml rely on these ? 5) One of the disadvantages of things like odb is that you may miss valuable information like a CHANGES file, proper documentation or sample programs. These are also things you actually would like to remove when you do a ocamlfind remove. Is there any general agreed on strategy for packages ? Best I think would be to install that along in the package directory with ocamlfind, it makes it relatively easy/evident to lookup. 6) Regarding 5) I tried to define documentation as follows : Document xmlm Title: Xmlm documentation and module reference Format: html Index: Xmlm.html Install: true InstallDir: $htmldir/xmlm DataFiles: README CHANGES doc/*.html, doc/*.css but ocaml setup -install doesn't seem to install it. Of course this is also certainly a wrong strategy since it would install it in some directory that wouldn't be removed by ocamlfind remove. So how do we achieve that ? 7) ocaml setup -install seems to install the modules' .mli, .cmi and .cmx by finding them in _build capitalizing the filenames even though they are not (cf. [2]). That works on my case insensitive filesystem, but it mustn't work on others, the original files are not capitalized !? Is that a bug ? Thanks, Daniel [1] http://groups.google.com/group/fa.caml/browse_thread/thread/460ba4d505e29c62 [2] ocaml setup.ml -install I: Installing findlib library 'xmlm' I: Running command '/usr/local/bin/ocamlfind install xmlm src/META _build/src/Xmlm.cmx _build/src/Xmlm.cmi _build/src/xmlm.a _build/src/xmlm.cmxa _build/src/xmlm.cma src/Xmlm.mli' Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.mli Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.cma Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.cmxa Installed /usr/local/lib/ocaml/site-lib/xmlm/xmlm.a Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.cmi Installed /usr/local/lib/ocaml/site-lib/xmlm/Xmlm.cmx Installed /usr/local/lib/ocaml/site-lib/xmlm/META -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] odb questions
On 03/07/2012 11:37 PM, Edgar Friendly wrote: [...] Except I don't intend odb to scale. It's hovering right around 500 lines of code, and if I can keep it around that size, I'll be happy. I don't intend odb to ever have a `odb remove foo` command Hi, Wouldn't it be possible to have 'odb remove foo' just call 'ocamlfind remove foo'? Regards, F. nor an `odb update`. Maybe I'll have an `odb upgrade`, but I'm happy leaving this as `odb --upgrade`. Odb's goal is to be an 80% solution, and it was that a while ago, I think. It's approaching 90%, and I'm going to try to avoid it feature creeping to 100%. Oddities should be handled by the package installers themselves or the metadata repository as much as possible, leaving pretty little work for odb. E. -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
Re: [Caml-list] concerning using of `deriving' syntactic plugin
On Wed, Mar 7, 2012 at 12:28, Matej Košík 5764c029b688c1c0d24a2e97cd7...@gmail.com wrote: If you remove any of the with sexp clauses, you will get a preprocessor error: File main.ml, line 4, characters 18-23: Parse error: with expected after [type_declaration] (in [str_item]) File main.ml, line 1, characters 0-1: Till's fix suggestion should work, you'll have to use camlp4o as preprocessor. Btw., you also may want to open Sexplib.Std instead of Sexplib.Conv, which is the standard way. Regards, Markus -- Markus Mottl http://www.ocaml.info markus.mo...@gmail.com -- Caml-list mailing list. Subscription management and archives: https://sympa-roc.inria.fr/wws/info/caml-list Beginner's list: http://groups.yahoo.com/group/ocaml_beginners Bug reports: http://caml.inria.fr/bin/caml-bugs
