RE: [Caml-list] Doubt about function delaration parameter

[David Allsopp]

sieira wrote:
> Thanks for your replies. I'm now having some issue with Raphael's
> suggestion of using (string * string) list;; as the menu type.
> 
> 
> type menu = (string*string) list;;
> 
> Results in a syntax error at the first parenthesis, while
> 
> type menu = string*string;;
> 
> fails too (at the asterisk)
> 
> It seems like I'm missing something. Since according to the
> http://caml.inria.fr/pub/docs/manual-caml-light/node3.5.html
> documentantion , this sintax should be right.
> 
> I'm using Camllight 0.81 by François Boisson running in Ubuntu lucid lynx

People on this list will reasonably assume you're using Objective Caml unless 
you say otherwise - this should have been at the top of your original post. I 
don't know and don't have access to an installation of caml light but looking 
at http://caml.inria.fr/pub/docs/manual-caml-light/node3.9.html it would appear 
to me as though type abbreviations (which is what you're doing) need == in Caml 
Light:

type menu == (string*string) list;;

... but I may well be wrong.


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] help with regular expression

[David Allsopp]

zaid Khalid wrote:
> Hi Folks
>
> I want some help in writing regular expressions in Ocaml, as I know how to 
> write it
> in informal way but in Ocaml syntax I can not. For example I want to write 
> "a* | (aba)* ".

This question would better be posted on the beginners' list - 
http://caml.inria.fr/resources/forums.en.html#id2267683

Regular Expressions can be done using the Standard Library with the Str module 
(as you've found) - see 
http://caml.inria.fr/pub/docs/manual-ocaml/libref/Str.html so your expression 
above (assuming you have loaded/linked str.cm[x]a) is Str.regexp 
"a*\\|\\(aba\\)*". The language of regexps is given in the docs for Str.regexp 
function. Remember to escape backslash characters as the regular expression is 
given in an OCaml string (so to escape a backslash in your regexp you have to 
write "").

> Another question if I want the string to be matched against the regular 
> expression
> to be matched as whole string not as substring what symbol I need to attach 
> to the
> substring, i.e if I want only concrete strings accepted (like (" ", a , aa , 
> aaa, 
> aba, abaaba), but not ab or not abaa).

Use ^ and $ at the beginning and end of your regexp to ensure that it matches 
the entire string only - "^\\(a*\\|\\(aba\\)*\\)$"

> Hint I am using (Str.regexp)

There are other libraries (e.g. pcre-ocaml) which provide different (I would 
say more powerful, rather than strictly better!) implementations.


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] zero-arity constructor

[David Allsopp]

Mark Adams wrote:
> Surely it's preferable to use a syntactically distinct mechanism for this
> subtly different concept.  Given that we're talking about patterns and not
> general expressions here, surely there's plenty of space in the syntax.
> Perhaps something like '*' to mean 0 or more.

Even accepting that _ is already "broken" (well, a special case) as bluestorm 
explained in terms of that lovely beginners' and not-so-beginners' trap [Foo of 
int * int] vs [Foo of (int * int)], allowing _ with 0-arity constructors does 
feel odd, and I don't really want to have to pepper my Makefile rules with -w 
+28. My personal preference would be that Warning 28 were on by default and 
that there were a compiler pragma available which camlp4 could use *in the 
generated ML code* to suppress it (I'm thinking of the MSVC-specific #pragma 
warning disable 28 - 
http://msdn.microsoft.com/en-us/library/441722ys(VS.80).aspx).

> Or is it already too late
> because '_' has already been incorporated and backwards compatibility
> dictates that this cannot be changed?

Presumably there are some camlp4 extensions already taking advantage of it or 
it wouldn't have been added. But there'd be no reason not to add something as 
you propose (so [Foo *] for type t = Foo) and set Warning 28 to be on by 
default for [Foo _] - that would simply mean that 3.11/3.12 code using that 
syntax would emit warnings in "3.13" rather than actually breaking (unless 
you've including -warn-error - but that's always seemed to me to be a 
development option, not a release option...)


David
 

> 
> type ty = A | B
> 
> let test = function
> | A * -> ()
> | B -> ()
> 
> Mark Adams
> 
> on 26/11/10 10:35 PM, bluestorm  wrote:
> 
> > A quick summary for those like me that didn't follow the change and
> > were baffled to find out that "it's not a bug, it's a feature".
> >
> > The change was asked for by Alain Frisch in 2006 (
> > http://caml.inria.fr/mantis/view.php?id=4052 ) and finally added in
> > ocaml 3.11. The rationale is to make it easy to mechanically -- think
> > camlp4 or another preprocessor -- generate pattern clauses to test for
> > the head constructor of a data type, ignoring it's parameter.
> > Before that change, (K _) would work for all constructors K of arity
> greater
> > than 1, but not for arity 0. After the change, (K _) work even for
> constant
> > constructors. Generating a match clause that says "looks if it's the
> > constructor K, I don't care about the arguments" is much easier as you
> don't
> > have to carry  arity information around.
> >
> > The downside of this behaviour is that the universal pattern _ has an
> > different meaning in this setting. It does not only matches any value
> > (as the manual says :
> > http://caml.inria.fr/pub/docs/manual-ocaml/patterns.html
> > ),
> > but also "matches any number of arguments, possibly 0". The nice
> > compositional interpretation of patterns -- K (p1, .., pN) matches a
> > value with constructor K and whose N arguments match p1..pN -- is lost.
> > Note that this was already the case before the change suggested by
> > Alain Frisch : _ would work for two-arguments constructors as well,
> > while a
> named
> > variable wouldn't -- this is well-known subtle difference between (Foo
> > of
> a
> > * b) and (Foo of (a * b)). The pattern _ ignored any non-zero number
> > of arguments.
> >
> > Note that since ocaml 3.12, there is a warning available for this very
> > error.
> >
> > $ ocaml -warn-help
> > [...]
> > 28 Wildcard pattern given as argument to a constant constructor.
> > [...]
> >
> > $ cat test.ml
> > type ty = A | B
> >
> > let test = function
> > | A _ -> ()
> > | B -> ()
> >
> > $ ocaml -w +28 test.ml
> > File "test.ml", line 4, characters 4-5:
> > Warning 28: wildcard pattern given as argument to a constant
> > constructor
> >
> > I think than, in the end, it's all a matter of compromise.
> >
> > Thanks to Julia and Mehdi for casting light on the dark corners of the
> ocaml
> > syntax!
> >
> > PS : I haven't found that behaviour documented anywhere. Maybe it
> > would be good to describe that special behaviour of _ on constructors
> > in the
> manual?
> >
> > On Fri, Nov 26, 2010 at 11:02 PM, Julia Lawall  wrote:
> >
> >> On Fri, 26 Nov 2010, Mehdi Dogguy wrote:
> >>
> >> > On 11/26/2010 10:46 PM, Julia Lawall wrote:
> >> > > The following code compiles in 3.12.0 but doesn't compile in
> 3.10.2.
> >> > > Is it a bug or a feature?
> >> > >
> >> >
> >> > It's a feature that was implemented in 3.11.0 (iirc).
> >> >
> >> > See: http://caml.inria.fr/mantis/view.php?id=4675 (and other
> >> > related bugreports).
> >>
> >> OK, thanks.  I agree wth those that don't like the change...
> >>
> >> julia
> >>
> >> ___
> >> 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

RE: [Caml-list] [Was: Is OCaml fast?] Not really sure...

[David Allsopp]

Isaac Gouy wrote:
> Ed Keith  yahoo.com> writes:
> 
> > > > I am not asking WHAT the rules are but a JUSTIFICATION
> > > for them (which you
> > > > have been incapable of providing so far).
> > >
> > > I feel no need to provide a JUSTIFICATION to you for anything.
> > >
> >
> > Am I to interpret this to mean that the rules are purely arbitrary and
> capricious with no though behind them?
> 
> Tendentious.
> 
> A great deal of thought has been given to all aspects of the benchmarks
> game.



Aw, come on - the suspense is worse than the crime thriller I'm reading at the 
moment!

Here, given the UK's austerity measures as applied to my imagination, is a 
logical rather than imaginative argument.

If a great deal of thought has been given to the benchmarks game (and I can 
well believe that it has) then it stands to reason that someone, hopefully you, 
knows the reasoning (justification is perhaps too strong or personal a word) 
behind the various rules and so could write it down. So please share it - not 
just with us but with the authors in all the languages represented by the 
shootout by updating the relevant page on its website. It seems safe to assume 
from the level of questioning (and lack of answering from anyone else) that the 
reasoning is not obvious so a point or two would help to clarify it and if not 
close the discussion, at least fairly and squarely move it to the shootout's 
forums...

Alternatively, if that's not the case, stop dancing around the point and just 
state that the rules are that way because you say that they are. Full stop. End 
discussion. On all lists.


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] Re: Is OCaml fast?

[David Allsopp]

Isaac Gouy wrote:
> David Allsopp  metastack.com> writes:
> 
> -snip-
> > Reducing an entire programming language's strengths (or
> > weaknesses!) to a single number is just not really realistic - the
> > truth is more complex than one single-precision floating point 
> > number (or even an array of them) can describe. (NB. The shootout
> > doesn't claim that the final ranking displayed is anything other than
> > a score of how well the languages did
> > at the various benchmarks given - but a graph like that is easy to
> > interpret erroneously in that way)
> -snip-
> 
> That summary page
> 
> > > (http://shootout.alioth.debian.org/u32/which-programming-languages-a
> > > re-
> > > fastest.php)
> 
> shows box plots (quartiles, outliers, median) of the normalized timing
> measurements for each of the tasks, for each of the language
> implementations.
> 
> A graph like that shows some of those language implementations are very
> fast for some benchmark programs and very slow for others.

I'm not sure I disputed that anywhere, in fact I think if anything implicitly 
agreed with it...

> To characterize that as "reducing an entire programming language's
> strengths (or weaknesses!) to a single number" seems kind-of misleading.

I'm not clear how you extracted that from what I said which was that reducing a 
programming language to a single number (or three numbers, if you want bars) is 
not a good summary of the *total* strengths of that programming language. I 
then went on to stress that the combined results from the shootout don't claim 
to do that, they simply show an interpretation of the combined results from the 
different benchmarks.

My attempt at a point was that ranking programming languages (that's just 
"programming languages" not "execution speed of programming languages") is a 
largely futile activity, because it's just too subjective and hard to quantify 
in a rigorous manner, and importantly that the shootout doesn't try to do that. 
The relevance and value of that point to Thanassis' original question is for 
him to decide...

> Especially when the question that page answers is stated 3 times - "Which
> programming language implementations have the fastest benchmark programs?"

Which part of my statement "The shootout doesn't claim that the final ranking 
displayed is anything other than a score of how well the languages did at the 
various benchmarks given" (prefixed with the Latin abbreviation for "Note 
well") caused you to need to write this?


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] Is OCaml fast?

[David Allsopp]

Thanassis Tsiodras wrote:
> I apologize beforehand if this is not the forum to ask.
> 
> I am on the fence about whether to learn OCaml or not, and while reading
> an article called "Why OCaml"
> (http://www.cs.ubc.ca/~murphyk/Software/Ocaml/why_ocaml.html), I saw that
> OCaml was praised for the speed of the executables it generates - and was
> referred to, speed-wise, as "second to none", except C and
> C++.

Do remember that speed isn't always everything - there are many applications 
where it's just not critical. Maintainability, readability, ease-of-use, 
availability of libraries are large concerns too.

> However, when I actually went to the Language Shootout page suggested in
> the article, I found out that OCaml is not 2nd, it is 13th, behind
> languages like Haskell and C#...
> (http://shootout.alioth.debian.org/u32/which-programming-languages-are-
> fastest.php)

As the kinda large number of messages in this thread suggests, benchmarks can 
be very subjective :o)

The Wiktionary definition of "to benchmark" is "To measure the performance of 
(an item) relative to another similar item in an impartial scientific manner". 
IMHO the problem benchmarking "programming languages" (note - "programming 
languages", not "problems solved in programming languages") lies in the word 
"similar" in that definition. Reducing an entire programming language's 
strengths (or weaknesses!) to a single number is just not really realistic - 
the truth is more complex than one single-precision floating point number (or 
even an array of them) can describe. (NB. The shootout doesn't claim that the 
final ranking displayed is anything other than a score of how well the 
languages did at the various benchmarks given - but a graph like that is easy 
to interpret erroneously in that way)

> Is it just hype, then? Or am I missing something?

OCaml's big strengths (by no means unique to OCaml, incidentally) for me are 
its ML legacy - automatic memory (de-)allocation, type inference, static 
type-checking (i.e. no BizarreRuntimeTypeException's here...) and polymorphism 
- all things which allow me to write less (and clearer) code to solve a given 
problem. I also find some of the more exotic features useful - private types 
and polymorphic variants, for example. I'm forced to program in a few less 
desirable languages from time to time and sorely miss the basic features of ML. 
I'd also echo Sylvain's point: I too find the time spent testing and debugging 
OCaml is much, much lower than, say, equivalent C(++) or Java code. 

Personally, I've found the best way to find out if you like a new programming 
language is to write a non-trivial program in it (maybe with the occasional 
assistance of skilled people in its community) and then see what happens when 
you go back to programming in something you used before.

And if speed really is worrying you, the big thing you may have noticed from 
the, ahem, slightly animated discussion that's followed is that there are 
plenty of people on this list who know how to help you identify what's causing 
the problem and then offer suggestions to tweak it. Personally, in six years of 
programming in OCaml for a variety of tasks I've never hit the brick wall where 
I felt the task I was carrying out would have been orders of magnitude faster 
in another language *and also easy to code in that language*!

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] SMP multithreading

[David Allsopp]

Edgar Friendly wrote:
> It looks like high-performance computing of the near future will be built
> out of many machines (message passing), each with many cores (SMP).  One
> could use message passing for all communication in such a system, but a
> hybrid approach might be best for this architecture, with use of shared
> memory within each box and message passing between.  Of course the best
> choice depends strongly on the particular task.

Absolutely - and the problem in OCaml seems to be that shared memory 
parallelism is just branded as evil and ignored...

> In the long run, it'll likely be a combination of a few large, powerful
> cores (Intel-CPU style w/ the capability to run a single thread as fast as
> possible) with many many smaller compute engines (GPGPUs or the like,
> optimized for power and area, closely coupled with memory) that provides
> the highest performance density.

I think the central thing that we can be utterly sure about is that desktops 
will always have *> 1* general purpose CPU. Maybe not be an ever-increasing 
number of cores but definitely more than one.

> The question of how to program such an architecture seems as if it's being
> answered without the functional community's input. What can we contribute?

It has often seemed to me when SMP has been discussed in the past on this list 
that it almost gets dismissed out of hand because it doesn't look future-proof 
or because we're worried about what's round the corner in technology terms.

To me the principal question is not about whether a parallel/thread-safe GC 
will scale to 12, 16 or even the 2048 cores on something like 
http://www.hpc.cam.ac.uk/services/darwin.html but whether it will hurt a 
single-threaded application - i.e. whether you will still be able to implement 
message passing libraries and other scalable techniques without the parallel GC 
getting in the way of what you're doing. A parallel/thread-safe GC should be 
aiming to provide the same sort of contract as the present one - it "just 
works" for most things and in a few borderline cases (like HPC - yes, it's a 
borderline case) you'll need to tune your code or tweak GC parameters because 
it's causing some problems or because in your particular application squeezing 
every cycle out of the CPU is important. As long as the GC isn't (hugely) 
slower than the present one in OCaml then we can continue to use libraries, 
frameworks and technologies-still-to-come on top of a parallel/thread-safe GC 
which simply ignores shared memory thread-level parallelism just by not 
instantiating threads.

The argument always seems to focus on utterly maxing out all possible available 
resources (CPU time, memory bandwidth, etc.) rather than on whether it's simply 
faster than what we're doing able to do at the moment on the same system. Of 
course, it may be that the only way to do that is to have different garbage 
collectors - one invoked when threads.cmxa is linked and then the normal one 
otherwise (that's so easy to type out as a sentence, summarising a vast amount 
of potential work!!)

Multithreading in OCaml seems to be focused on jumping the entire width of the 
river of concurrency in one go, rather than coming up with stepping stones to 
cross it in bits...


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] Option functions (or lack thereof) + operator for composition

[David Allsopp]

Serge Le Huitouze wrote:
> 1. Option type
> 
> It seems that there is no predefined function to test an "'a option" for
> being specifically "None" or "Some _". This seems to be confirmed by the
> very existence of:
> http://ocaml-lib.sourceforge.net/doc/Option.html
> which defines such functions ("is_none" and "is_some").
> I found it weird to be forced to use "match" expressions in my code for
> doing that, e.g.:
> *  let curSelectedRow = ref None in
> *  let updateButtonsStatus () =
> *  button_remove#misc#set_sensitive
> *  (match !curSelectedRow with None -> false | _ -> true)
> *  in
> *  ...
> 
> I could add the OCaml library mentioned above, but I don't know how to do
> it (and where to find it) and, since my code is supposed to go into some
> other code, I'd prefer avoiding adding yet another dependency to it...

ExtLib is well-worth having and it's very easy to install (just run ocaml 
install.ml in its source tree - findlib recommended but I've got a feeling that 
it can install without findlib as well). It's also very stable, feature-wise, 
so you're not really adding a tricky dependency. It's now hosted on Google Code 
at http://code.google.com/p/ocaml-extlib/downloads/list

You might also take a look at the batteries project 
(http://batteries.forge.ocamlcore.org) which I believe includes most if not all 
of ExtLib.



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] type inference problem with Printf.sprintf ?

[David Allsopp]

Emmanuel Dieul wrote:
> Hi everyone.
> 
> I've just noticed a type inference problem (or am I wrong ?). Here's my
> example :
> 
> let format_date =
>let format_valeur = function valeur ->
>  (if valeur < 10 then "0" else "") ^ (string_of_int valeur)

Your main problem has already been answered but it's worth noting that you can 
eliminate this function entirely by using "%02l" in your format specification 
and passing the integer values from your time structure directly to give:

Printf.sprintf "%02l/%02l/%l %02l:%02l:%02l" date.Unix.tm_mday 
(date.Unix.tm_mon + 1) (date.Unix.tm_year + 1900) date.Unix.tm_hour 
date.Unix.tm_min date.Unix.tm_sec

It's worth having a complete read of the top of the Printf page in the standard 
library reference just to see the things it can do. 


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] Code-execution (evaluation) time

[David Allsopp]

Oliver Bandel wrote:
> Hello,
> 
> I want to refresh my OCaml knowledge after I (again) paused for a while.
> 
> I want to know, when certain parts of the code are executed,
> for example if I have more than one   let _ = ...
> statement in my code (for example in different comp0ilaion units each one
> of them).

Expressions (as in, things listed in 
http://caml.inria.fr/pub/docs/manual-ocaml/expr.html) are evaluated in the 
order in which they appear in a source file. If you have two files A.ml and 
B.ml which contain top-level statements, the order in which they execute will 
depend on the order in which you link the resulting .cmo or .cmx files (which 
should be left-to-right as passed to ocamlc/ocamlopt - don't know where that's 
specified).

As far as I can see, in pretty much all contexts within an expression where 
order of evaluation could matter including, but probably not limited to:

* Record initialisation (e.g. let i = ref 0 in {a = (incr i; !i); b = (incr i; 
!i)})
* Function application (similarly)
* let foo = _ and bar = _ in _

are intentionally left as unspecified (in practice, application and record 
initialisation are right-to-left and let x = _ and y = _ is left-to-right but 
the point is that you are never supposed to rely on that).

> I also found an old code snippet with the following parts:
> 
> ==
> let fnames = List.tl(Array.to_list Sys.argv)
> 
> (* some more code *)
> 
> let _ =
>List.iter print_days_old fnames
> ==
> 
> So, the value fnames contains the args from the command line and can be
> used in the first statement of the code.

[let fnames = ..] is a complete expression so it's evaluated before the [let _] 
further down.


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] Marshalling question

[David Allsopp]

Jean Krivine wrote:
> Dear ocaml users,
> 
> A simple question: is it safe to marshalize a data structure that contains
> imperative elements (like arrays or hashtbl) ?

Simple answer: yes. Marshal works on the runtime representation of data which 
is imperative (immutability is enforced by the type system, not the runtime).

> I found the documentation of the Marshal module rather obscure to me.
> In particular it is not clear whether I should use the No_sharing flag.

Unless you know how the data structures you are marshalling work, you should 
never use this flag (i.e. if you're working with an abstract data type like 
Hashtbl.t then you certainly shouldn't be using this flag). The obvious reason 
is that if the data contain a cycle that you're not aware of then your program 
will not terminate. Less obvious reasons include structures (e.g. for 
memoizing) which rely on value sharing so that they can use physical, rather 
than structural equality for speed. The worst thing that can happen when this 
flag isn't given is that the operation might be a teensy bit slower than it 
strictly needs to be.



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] Windows filenames and Unicode

[David Allsopp]

Paul Steckler wrote:
> On Wed, Sep 29, 2010 at 4:23 PM, David Allsopp 
> wrote:
> > A way (but not foolproof on Windows 7 and Windows 2008 R2 because you
> > can disable it) would be to wrap the GetShortPathName Windows API
> > function[1] which will convert the pathname to its DOS 8.3 format which
> > will not contain Unicode characters. Another way might be to wrap the
> > Unicode version of CreateFileEx and convert the result into a handle
> > compatible with the standard library functions but I reckon that could be
> > tricky!
> 
> For Linux, I was planning on enforcing the invariant that all strings
> inside my program are UTF-8.
> For Windows, I could use the same invariant, and modify the OCaml runtime
> so that all calls to Windows file primitives have those strings translated
> to UTF-16 (and return values translated back to UTF-8).  That is, I'd have
> to build a custom version of OCaml and wrap CreateFile, etc. with such
> Unicode translation functions.

Rather than hacking the OCaml runtime (the relevant code is 
{byte,asm}run/sys.c, btw) personally I'd produce a separate module of my own 
with two implementations - one for Linux which just uses the built-in 
primitives and then one for Windows using WinAPI functions directly. A cursory 
glance at the runtime code suggests that hacking wide support onto the runtime 
is not a "one-liner".

> All this is made slightly more complicated by the fact that I'm using the
> MinGW version of OCaml.

Shouldn't make it (too much) harder - I use the MinGW build of OCaml without 
issue for C stubs, after a slightly steep learning-curve. The w32api package in 
Cygwin provides all of the headers and link libraries for Windows libraries 
(it's installed by default with the gcc-mingw). If you ever have to link with 
more exotic libraries, dlltool is (sort of) your friend (it with a little bit 
of help allows you to generate the .a files needed for the DLL you're linking 
with - 3rd party libraries on Windows tend only to ship the MSVC .lib files)

> Hmmm, I shouldn't have to do this.  Are there plans afoot to modernize
> OCaml's string-handling?

Can o' worms, I expect! Windows (by which I mean Windows NT) took the simplest 
route of 16-bit wchars for Unicode but it's not necessarily the best way of 
programming in general... the problem with going Unicode is *how* you go 
Unicode.


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] Windows filenames and Unicode

[David Allsopp]

Paul Steckler wrote:
> In Windows, NTFS filenames are specified in Unicode (UTF-16).  Am I right
> in thinking that OCaml file primitives, like open_in, readdir, etc. cannot
> handle NTFS filenames containing characters with codepoints greater than
> 255?

Given that the WinAPI "wide" functions use UTF-16, you can of course fake 
UTF-16 on top of normal OCaml strings but I think that you'll hit a brick wall 
because the I/O primitives are based on the underlying C library functions 
which at the end of the day will be using the ANSI versions of the Windows API 
functions, not the Unicode ones.

> I'm aware of the Camomile library, which gives the ability to manipulate
> UTF-16 strings inside of OCaml.  But it looks like crucial points of
> OCaml's I/O, like Sys.argv and file primitives are strictly limited to 8-
> bit characters.
> 
> Is there a way around this limitation, other than rewriting the file I/O
> primitives?

A way (but not foolproof on Windows 7 and Windows 2008 R2 because you can 
disable it) would be to wrap the GetShortPathName Windows API function[1] which 
will convert the pathname to its DOS 8.3 format which will not contain Unicode 
characters. Another way might be to wrap the Unicode version of CreateFileEx 
and convert the result into a handle compatible with the standard library 
functions but I reckon that could be tricky!


David

[1] http://msdn.microsoft.com/en-us/library/aa364989(v=VS.85).aspx


> 
> -- Paul
> 
> ___
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] quotations inside comments?

[David Allsopp]

> Hi,
> 
> why does camlp4 parse quotations inside comments? Eg

I don't know for certain, but I guess it might be for the same reason as the 
compiler which checks string literals (amongst other things) inside comments 
e.g.

(* This will not compile " *)

File "foo.ml", line 1, characters 0-2:
Error: This comment contains an unterminated string literal

The compiler does this to ensure that you can consistently nest comments (i.e. 
that commenting out a block actually comments the entire block out), without it 
you could write:

(*
let foo = "*)" in ()
*)

which wouldn't behave as you'd expect (and the syntax error could be a lot 
further down the file!) 


David

> 
> echo "(* << *)" | camlp4o -impl -
> 
> gives
> 
> File "-", line 1, characters 3-9 (end at line 2, character 0):
> Quotation not terminated
> 
> Quotation parsing/lexing seems to be controlled by context.quotations. How
> can I switch this off?
> 
> Wouldn't it make more sense to have quotations and antiquotation
> parsing/lexing switched off in freshly created parsers/lexers and switch
> them only on when a syntax extension with quotations is installed (eg,
> inside Camlp4QuotationCommon.Make)?
> 
> Bye,
> 
> Hendrik
> 
> ___
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Dynlink native library for ocaml-mingw32

[David Allsopp]

Paul Steckler wrote:
> I have a Fedora 11 instance where I've installed
> mingw32-ocaml-3.11.0-0.16.beta1.fc11.noarch to create Windows
> executables.  I've mentioned issues with the native-code threading
> libraries in that distribution before on this list.
> 
> Recently, I added calls into the dynlink library in my code (see my
> recent posts about dynlink-induced/revealed segfaults -- I'll discuss
> progress in resolving these in a future post).  When compiling with
> ocaml-mingw32, I first had to change the dynlink/META file to look for
> dynlink.cmxa to link against native code.  The link failed, though,
> because options -Wl and -E were being passed to FlexDLL.  I have
> mingw32-flexdll-0.11-9.fc11.i386 installed.
> 
> The file Makefile.config, found in the ocaml-mingw32 library
> directory, contains the line:
> 
>   NATDYNLINKOPTS=-Wl,-E

Makefile.config on an actual 3.11 MinGW installation does not contain 
NATDYNLINKOPTS, so this is incorrect. That's technically also a linker option 
wrapped in a gcc option...

> which options seem to get baked into dynlink.cmxa.  I hacked the
> library file to change those options to spaces, and the link proceeds
> normally.  That works, but my sleep patterns have become disturbed.
> :-)
> 
> Is this issue particular to my installation, or should dynlink.cmxa
> have been built not to invoke these flags?  Why does FlexDLL get
> invoked as the linker, rather than i686-pc-mingw32-ld (which would
> have accepted those flags)?

All linking is done using flexlink for Windows distributions of ocaml - in a 
highly simplified nutshell, flexlink builds some wrapper files which implement 
dynamic linking (not to be confused with dynlink - flexlink does this for all 
Windows executables) and then calls the correct compiler and linker to produce 
the final program/library. You can either use ocamlopt -verbose to see the 
flexlink call and then run it manually or use ocamlopt -verbose -ccopt -v to 
have flexlink display the programs it's invoking. Alain's website 
(http://alain.frisch.fr/flexdll.html) has more info on how it works...


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] More re GC hanging

[David Allsopp]

Adrien wrote:
> Hi,



> Also, on my computer, I have the following behaviour:
> 11:44 ~ % sudo echo 0 > /proc/sys/kernel/randomize_va_space
> zsh: permission denied: /proc/sys/kernel/randomize_va_space
> r...@jarjar:~# echo 0 > /proc/sys/kernel/randomize_va_space
> r...@jarjar:~#
> I can't use sudo to write to most files in /proc or /sys: I have to log in
> as root ('su -' does the job just fine).

The redirection (> /proc/sys...) is not part of the sudo invocation, it's a 
separate instruction to the *shell* to redirect output of the previous part of 
the command to a file and so it runs with *your* uid. There are two ways to 
achieve what you're after - one verbose one described in the sudo man page 
(essentially you pass the whole command line to sudo quoted) or the easier way:

echo 0| sudo tee /proc/sys/kernel/randomize_va_space

You can add > /dev/null if tee's outputting of the 0 to stdout is for some 
reason annoying.


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] Distinguish between osx and linux programmatically

[David Allsopp]

Oliver Bandel wrote: 
> On Thu, Jul 08, 2010 at 06:01:24PM +0100, Richard Jones wrote:
> > On Thu, Jul 08, 2010 at 10:42:40AM -0500, Romain Beauxis wrote:
> > > Le jeudi 8 juillet 2010 06:44:34, Richard Jones a écrit :
> > > > Stdlib could bind the uname(2) syscall, but it's legendary in its
> > > > complexity.  Seems more likely to cause problems than just calling
> > > > out to the external program.
> > >
> > > I fail to see the complexity.. Where is it ?
> >
> > Actually *I* misunderstood the link I posted
> > (http://www.kernel.org/doc/man-pages/online/pages/man2/uname.2.html#NO
> > TES) thinking it meant that the string fields in the structure could
> > have variable width.  Reading it again, they don't.
> >
> > Nevertheless I still think this is not a useful addition to stdlib,
> > but for different reasons:
> >
> > (1) You'd have to emulate it on non-Unix platforms, but it's unclear
> > what you'd emulate it with.  Windows has a completely different and
> > much richer concept of OS version.  This sort of version probing
> > complexity doesn't belong in the core library, but in an external "OS
> > version" library where detection rules can be frequently updated.
> [...]
> 
> 
> $ uname -a
> 
> If it's not Unix, what will uname(2) or uname(1) give you?
> 
> What will be reported on Windows with MinGW

C:\Users\DRA>uname -a
windows32 Tenor 2.6.1 7600 i686-pc Intel unknown MinGW

(using GnuWin32 which is a MinGW build of the Unix tools)

> or Cygwin?

d...@tenor ~
$ uname -a
CYGWIN_NT-6.1-WOW64 Tenor 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin

But of course in both instances that requires uname.exe to be installed which 
it won't be on most normal end-user systems.


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] Re: adding a scripting language to an ocaml program

[David Allsopp]

Martin DeMello wrote:
> On Sun, Jul 4, 2010 at 12:13 AM, Michael Ekstrand 
> wrote:
> > The authors of C-- have implemented a Lua engine in OCaml, with a
> > good, high-level, type-safe interface for embedding it.  Look for 'lua-
> ml'.
> > There is also an OCaml implementation of Scheme called 'ocs'; I do not
> > have experience with it, so I cannot speak to its API style.  Finally,
> > there are OCaml bindings to the SpiderMonkey JavaScript engine.
> 
> Both lua-ml and ocs seem dead (their homepages are gone) :(

> Can't tell if spidercaml is active or not; the page has a download link for
> version 0.2 and no date.

SpiderCaml is alive and well - I submitted patches (which are in SVN) to Alain 
a few months ago for 0.2 but I don't think he's time to wrap it all into 
another release. I haven't tested against Mozilla's latest offering but I have 
it working very nicely with SpiderMonkey 1.7.0 on Windows 7. It's only because 
compiling MinGW builds of SpiderMonkey is non-trivial that I haven't tried it 
against the a 1.8 engine - on Linux (or possibly using the MSVC Windows branch) 
I expect it would be easy to do.


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] Calling OCaml from C - nothing shown on stdout

[David Allsopp]

Andreas Sommer wrote:
> Hi everybody,
>
> I'm trying to call a OCaml function from C code. This is the OCaml file:
> open Printf
>
> let hello () =
>    Printf.fprintf stdout "%s" "test"
>    
> let () =
>    let oc = open_out "/tmp/testfile" in
>    Printf.fprintf oc "test";
>    close_out oc;
>    
>    Printf.fprintf stdout "Caml main function\n";
>    
>    Callback.register "Hello callback" hello;
>    
>    Printf.fprintf stdout "%s" "Finished with OCaml initialization"
>;;

A couple of observations on your coding style - you open Printf and then 
proceed to use qualified Printf.fprintf calls. There's no need for the open 
statement. Printf.printf is a shorthand for "Printf.fprintf stdout" which makes 
the code a bit clearer if you're skimming through it (as Printf.fprintf at a 
glance looks like actual file I/O rather than channel I/O).

> and this is the C file:


As far as I can tell from the manual, there's no particular difference in 
native code between using caml_main and caml_startup. Your problem is the 
buffering of stdout in the OCaml runtime. There are two ways of working around 
this:

1. Allow the runtime to exit using Pervasives.exit at some point on the ML side 
(or call caml_sys_exit directly in your C code but I haven't tried that...). 
For example, if I added [; exit 0] to the end of your hello ML function then I 
get the lines from the Printf calls on the ML side, but out of order (all of 
the OCaml ones come at the end after the C ones)

2. Insert a flush stdout statement after each Printf.printf call. Better, 
create another function using Printf.kprintf which flushes stdout each time:
let flushed_printf x = Printf.kprintf (fun s -> print_string s; flush 
stdout) in
flushed_printf "%s" "Finished with..."


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] OCaml 3.12.0+beta1

[David Allsopp]

bluestorm wrote:
> Here is a small Camlp4 filter removing exhaustive patterns. It obviously 
> depends on 3.12.
>

> 
>
> Notes :
> - that the OCaml printer expand sugared { a; b } patters into { a = a; b = b 
> } is necessary 
> for printing backward-compatible code; I'm not sure it's a good idea to rely 
> on this.

If *your* code has to be *backwards*-compatible with the OCaml 3.11.x compiler 
then you shouldn't be using that shorthand at all - the point with the {; _} 
syntax is that it's necessary to suppress a warning in OCaml 3.12 which isn't 
present in 3.11 (in other words, that syntax has to be used in 3.12 as I'm sure 
we all agree that any well-written piece of code should never emit compiler 
warnings). Any features in 3.12 shouldn't be being used at all *if* 3.11 
compatibility is your goal.

> - as with every camlp4 filters, the code is parsed then pretty-printed; do 
> not expect indentation
>  to stay as is. Comment placement is also going to do weird things (know and 
> nearly-unfixable camlp4 defect)

Seems fine.

>  : ocamldoc may not work properly on the output code.

Sounds like a showstopper for most packages as that would break doc/docs 
Makefile targets (shame, because a camlp4 script seems the obvious way to do 
it). Presumably any package that's going to be written for 3.12 but aim to 
compile on 3.11.x is going to have to .311.ml files (or some such scheme) 
generated for the sources tarball and then have those selected by a configure 
script when it detects OCaml 3.11.x or earlier (similar scheme to supporting 
3.09- camlp4 and 3.10+ camlp4). If camlp4 sadly can't do it reliably, how about 
combining the sed suggestion you made:

sed -e "s/; *_ *}/}/g"

with a test compilation in OCaml 3.11 to pick up any instances where 
line-breaking has been a problem (in other words, change your coding 
conventions and use the compiler to check that they've been adhered to)? It's 
not a particularly hard sed[*] script to read a few lines at a time and change 
the regexp to "s/;[ \t\n]*_[ \t\n]*}/}/g" to handle different line breaking 
conventions as well (and you could insert an additional regexp to handle 
non-nested comments in that gap as well). That would have the benefit of not 
messing up ocamldoc comments.

As an aside, while it seems fair enough that a pre-processor such as camlp4 may 
mess up *comments* it seems to me a bug that it messes up ocamldoc 
*instructions* (which are reasonably viewable as a functional part of your 
code). But is that a well-rehearsed argument about a really unfixable problem?


David


[*] or substitute your favourite text processor here!

___
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] Unix.send blocks

[David Allsopp]

k/Paul Steckler wrote:
> I've written a wee Web server in OCaml that's compiled using the ocamlopt
> from the Fedora MinGW distribution of ocaml.  I'm running the server in
> Windows 7.
> 
> Sometimes after receiving several requests, the Unix.send call that sends
> a response back to a Web client just blocks.

Sounds like terminology may be getting in the way of a solution - do you
mean that the call *blocks* for a longer time than you expect then carries
on working (the usual meaning of "block" - i.e. the call to send doesn't
return until it's actually finished) or do you mean *freezes* - i.e. the
call seemingly *never* returns and so your application hangs. When this
happens on a given connection, does that prevent further connections from
working - i.e. is the entire server dead or just that one connection? 

Additionally, just applying the usual debugging principle of "simplify,
simplify and then simplify some more", why not eliminate the cross-compiler
and instead use ocamlopt directly on Windows?


David

PS Although it's not your question, why are you writing a web server?
CGI+IIS (if Windows is your target) is dead easy and if you do strictly want
your own webserver then there's one in ocamlnet (although I'm not sure if
that part works under Windows - my default compiled version of ocamlnet
2.2.9 doesn't seem to have it but that may be because by default it's not
compiled rather than that it's not possible to compile it). Given that
you've hit problems, reinventing the wheel seems potentially questionable.

___
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] Converting variants with only constant constructors to integers

[David Allsopp]

Luc Maranget wrote:
> > Luc Maranget wrote:
> > > Of course, if you have the following:
> > > >
> > > > type t = A | B | C
> > > > let int_of_t = function
> > > >   A -> 0
> > > > | B -> 1
> > > > | C -> 2
> > > >
> > > > Then in fact I believe that the compiler already converts that to
> > > > a hashtable lookup instead of a sequence of jumps..
> > >
> > > The compiler does not convert the above code to 'hashtable lookup'.
> >
> > Is there a point where the compiler does do a table lookup for matches
> > rather than jumps or have I clearly just dreamt that? :o)
> >
> >
> > David
> 
> As far as I know the compiler always output jumps for matches.
> 
> Those jumps can be conditional jumps, or indirect jumps.
> For instance in the case of your code, ther will be two condional jumps
> (ocamlopt)
> 
> With a bigger example, say
> | A -> 0
> ...
> 
> | Z -> 25
> 
> It is likely that you get a table of addresses indexed by constructor
> numbers.

I think that's probably what I was getting muddled with - I didn't realise
that the compiler doesn't do that all the time for constant constructors,
though.


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] Converting variants with only constant constructors to integers

[David Allsopp]

Luc Maranget wrote:
> Of course, if you have the following:
> >
> > type t = A | B | C
> > let int_of_t = function
> >   A -> 0
> > | B -> 1
> > | C -> 2
> >
> > Then in fact I believe that the compiler already converts that to a
> > hashtable lookup instead of a sequence of jumps..
> 
> The compiler does not convert the above code to 'hashtable lookup'.

Is there a point where the compiler does do a table lookup for matches
rather than jumps or have I clearly just dreamt that? :o)


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] Converting variants with only constant constructors to integers

[David Allsopp]

Gabriel Scherer wrote:
> Incidentally, the general function for getting a unique integer for a
> variant type with non-constant constructors isn't that bad either:
>
> let int_of_gen x =
> let x = Obj.repr x
> in
>   if Obj.is_block x
>   then -1 * Obj.tag x - 1
>   else (Obj.magic x : int)
>
> I consider that version much better. You could also write it in a more
restrictive way :
>
> let to_int x =
>   let repr = Obj.repr x in
>   if Obj.is_int repr
>   then (Obj.obj repr : int)
>   else invalid_arg "to_int";;

(that doesn't quite do the same thing but I don't think that was your point)

My "problem" is that for each specific case where it's only constant
constructors, I can't help but feel guilty that code will execute for the
conversion of a value to the same value (%identity is a no-op most of the
time). It's not that everything has to be pointlessly micro-optimised, but
you know what I mean?

> The good point about those is that they check that the memory
representation is compatible 
> before casting (while the "%identity" does not). They're safer. Of course,
they still break 
> parametricity if used polymorphically, so as you said type should be
constrained.

> I still would prefer the more direct pattern-matching definition : it may
require code 
> generation not to be tedious, but the generated code is an honourable
OCaml citizen.

Of course, if you have the following:

type t = A | B | C
let int_of_t = function
  A -> 0
| B -> 1
| C -> 2

Then in fact I believe that the compiler already converts that to a
hashtable lookup instead of a sequence of jumps so it would be fairly
reasonable (and easy) to have the compiler spot that the match is exactly a
conversion to the tag value and so remove the match completely (and given
that the compiler already has two different strategies for match clauses,
it's not even that inconsistent). camlp4 of course solves the generation
problem (but there's no need to tell you that!!)


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] Converting variants with only constant constructors to integers

[David Allsopp]

W Dan Meyer wrote:
> bluestorm  writes:
> 
> > Beware that "%identity" is an unsafe feature that breaks all safety
> > guarantees if used badly.
> 
> Yes %identity is another solution. Although as safe as Obj.magic.

It's a bit pedantic but the %identity *primitive* is not the evil thing -
what is evil about Obj.magic is that it has an illegal type, namely 'a ->
'b. %identity constrained to a type like foo -> int is a safe use of it
(obviously with the side-condition that foo only has constant constructors,
as noted - but that's a local check, i.e. in your code, not your callers').

Incidentally, the general function for getting a unique integer for a
variant type with non-constant constructors isn't that bad either:

let int_of_gen x =
  let x = Obj.repr x
  in
if Obj.is_block x
then -1 * Obj.tag x - 1
else (Obj.magic x : int) 

Naturally, any specific use should constrain the type of this function
beyond 'a -> int


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] Converting variants with only constant constructors to integers

[David Allsopp]

Török Edwin wrote:
> What is the recommended way to convert a variant that has only constant
> constructors to an integer? (an integer that is unique for each constant
> constructor, preferably sequential in the order in which they are
> declared).

type foo = A | B;;
external int_of_foo : foo -> int = "%identity";;

Which is another way of saying Obj.magic - but %identity is an OCaml
primitive, where Obj.magic is part of a restricted module so there is a
small semantic difference in terms of future support. The internal
representation of variants won't change until at least OCaml 4.0.0 -
there're simply far too many C bindings out there! foo_of_int obviously
can't be done quite so trivially written although having checked that the
int represents a valid constructor you can then use %identity in the same
way.


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] Static exception analysis or alternative to using exceptions

[David Allsopp]

Goswin von Brederlow wrote:

> > However if the exception is, say, an I/O error reading a disk file,
> > these should be thrown, and caught somewhere central where you can
> > display an error message to the user (for GUI programs) or abort the
> > current transaction (for server programs).  Recovering from such
> > exceptions properly is still tricky though.  Since OCaml lacks
> > 'finally', you either have to use a 'finally' impl from a library, or
> > modify your code to not need it (eg. turning calls to 'open_in' and
> > 'open_out' into a kind of continuation-passing style).  Or for small
> > programs, abort the program and don't deal with recovery at all.
> >
> > All in all, this is not ideal for writing correct programs.  Some sort
> > of exception analysis would be most welcome.
> 
> It would be nice if the possible exceptions of a function would be part of
> the type. E.g.
> 
> let f1 () = raise Not_found
> val f1 : unit -> 'a [ Not_found ]
> 
> let f2 () = try f1 () with Not_found -> () val f2 : unit -> unit
> 
> let f3 f = try f () with Not_found -> () val f3: (unit -> 'a [< Not_found
> | 'B ]) -> 'a [ 'B ]
> 
> and so on.
> 
> 
> Someone would have to write a new type system for that though.

Would it be more practical to have that analysis as part of the .annot file?
Presumably a patch which merged and updated the codebase of ocamlexc to
produce exception-annotations in that manner might have a chance of making
it into the OCaml compiler itself. I'm guessing that what you're getting at
is the ability to see from your code that an exception could escape at any
given point rather than trying to add Java-style "checked exceptions" to
OCaml?


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] OCaml compilation

[David Allsopp]

Matthieu Dubuget wrote:
> Hello,
> 
> I'm trying to compile ocaml (mingw) on XP.
> 
> I did not succeed, and could reproduce the very same behaviour on two
> computers (a real one, and in a virtual machine).
> 
> On my main development system, the compilation does not fail. The
> difference may be that I don't touch at my currently working cygwin
> installation. During the two failing installs, I did install a fresh
> cygwin. Is this a known problem?

Don't think it's Cygwin - looks from the error like it's your ActiveTcl
parameters.



> > 5/ ActiveTcl installation
> >
> > #!/bin/bash
> > activetcl=ActiveTcl8.5.8.0.291595-win32-ix86-threaded.exe
> > activetcldownload=http://downloads.activestate.com/ActiveTcl/Windows/8
> > .5.8/${activetcl}

Installs Tcl 8.5

> > tkroot=C:/tcl
> > tkdll=tk85.dll
> > tcldll=tcl85.dll
> > download_file ${activetcl} ${activetcldownload} chmod +x
> > ${downloaddir}/${activetcl} ${downloaddir}/${activetcl} --directory
> > ${tkroot}



> > 9/ OCaml building
> >
> > #!/bin/bash
> > ocaml=ocaml-3.11.2
> > ocamlarchive=${ocaml}.tar.bz2
> > ocamldownload=http://caml.inria.fr/pub/distrib/ocaml-3.11/${ocamlarchi
> > ve}
> >
> > download_file ${ocamlarchive} ${ocamldownload}
> >
> > #Extract
> > extract_archive ${downloaddir}/${ocamlarchive} ${extractdir} ${ocaml}
> >
> > #Configure
> > cp ${extractdir}/${ocaml}/config/s-nt.h
> > ${extractdir}/${ocaml}/config/s.h cp
> > ${extractdir}/${ocaml}/config/m-nt.h ${extractdir}/${ocaml}/config/m.h
> > cp ${extractdir}/${ocaml}/config/Makefile.mingw
> > ${extractdir}/${ocaml}/config/Makefile
> >
> > tklink='$(TK_ROOT)'
> > cmd1="s|PREFIX=C:/ocamlmgw|PREFIX=$ocamldirwin|"
> > cmd2="s|TK_ROOT=c:/tcl|TK_ROOT=$tkroot|"
> > cmd3="s|TK_LINK=$tklink/bin/tk84.dll $tklink/bin/tcl84.dll
> > -lws2_32|TK_LINK=${tklink}/bin/${tkdll} ${tklink}/bin/${tcldll}
> > -lws2_32|"
> > sed -i.bak \
> > -e "$cmd1" \
> > -e "$cmd2" \
> > -e "$cmd3" \
> > ${extractdir}/${ocaml}/config/Makefile

Does this definitely build the correct Makefile - you're searching for
tcl84.dll but out-of-the-box OCaml 3.11.2 uses references tcl85.dll. Your
sed instruction would be better if it was TK_ROOT=.* rather than assuming
the value that the OCaml Dev team will have left there. You shouldn't need
to update TK_LINK.


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] Static exception analysis or alternative to using exceptions

[David Allsopp]

Mark Shinwell wrote:
> On Thu, May 27, 2010 at 09:54:29AM +0100, David Allsopp wrote:
> > Florent Ouchet wrote:
> > > Same here, specially to avoid the Not_found exception.
> > > The optional return values gives the oportunity to have a clear view
> > > of what is being done if the result is not available.
> >
> > Agreed - though [find] is one of the examples where you do need find
> > and find_exc - because often there are occasions where before calling
> > {Map,Set,Hashtbl}.find you already know that the key exists and so
> > won't fail at which point the 'a option boxing is a waste of time and
> > space and Not_found would be a truly exceptional situation so passes
> > the previously mentioned test.
> 
> I don't think I agree with this.  I would argue that for the majority of
> programs it is likely that the extra overhead is in fact negligible.  In
> the cases where it should be impossible to get the None return value, I
> think that should probably be annotated as such in the code with "assert
> false", which would seem to be more appropriate than a random Not_found
> popping up at some much higher level.

assert false is just a way of renaming the exception and relies on the
rather dirty (but necessary) hack in the compiler that, as a special case,
assert false is not optimised out of a program compiled without debugging
checks.



> Whilst I agree that there are arguments relating to verbosity of the use
> of option types, I think the strongest argument for keeping the *_exn
> variants may actually be that they're just a lot more convenient for quick
> hacks.

Unnecessary verbosity = unreadable IMHO, that's one of the reasons we use
clear, functional languages in the first place. That overhead also isn't
negligible as soon as you've got a Hashtbl/Set/Map which is queried a lot
(i.e. just about any form of data processing). Code where you know a priori
that the keys exist becomes unnecessarily peppered with pointless match
clauses (or calls like ExtLib's Option.get which... would raise an exception
if faced with None!). The interest to me is not that the overhead is
negligible, but that it can be trivially removed by using a *better*
function in that instance. Obviously, in the perfect world, your call to the
_exc version would in reality carry a proof that the key will be found (and
so no exception would be necessary). I simply don't see that the overarching
reason to have the _exc version of the function would be simply for hacking
a quick solution to a problem where you can't be bothered to handle the
Not_found case.


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] Static exception analysis or alternative to using exceptions

[David Allsopp]

Daniel Bünzli wrote:
> > Agreed - though [find] is one of the examples where you do need find
> > and find_exc - because often there are occasions where before calling
> > {Map,Set,Hashtbl}.find you already know that the key exists and so
> > won't fail at which point the 'a option boxing is a waste of time and
> > space and Not_found would be a truly exceptional situation so passes
> > the previously mentioned test.
> 
> In that case what you want is an alternate function "really_find" that
> doesn't raise Not_found but Invalid_argument if the key cannot be found.

Absolutely - but the point is that there is an obvious need to have the 
exception vs 'a option versions of the function. Appropriate naming of 
exceptions in the standard library is a well-rehearsed discussion :o)


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] Static exception analysis or alternative to using exceptions

[David Allsopp]

Florent Ouchet wrote:
> Same here, specially to avoid the Not_found exception.
> The optional return values gives the oportunity to have a clear view of
> what is being done if the result is not available.

Agreed - though [find] is one of the examples where you do need find and
find_exc - because often there are occasions where before calling
{Map,Set,Hashtbl}.find you already know that the key exists and so won't
fail at which point the 'a option boxing is a waste of time and space and
Not_found would be a truly exceptional situation so passes the previously
mentioned test.


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] A Tutorial on GNU Make with OCaml

[David Allsopp]

Michael Grünewald wrote:
> Dear Jeff,
> 
> Jeff Shaw wrote:
> >
> > Dear OCamlers,
> > I spent quite a lot of time today getting better acquainted with GNU
> > make and decided I to share my experience and results. It's a bit on
> > the newbie friendly side of instruction.
> >
> > http://shawjeff.blogspot.com/2010/05/this-is-storytutorial-about-how-i
> > _20.html
> 
> ten years ago I learned GNU Make and found it awful to program. I had the
> feeling that it is nit meant to write complex (or mildly complex)
> makefiles.

I could be wrong about the way it's constructed, but I think you'll find
that the Linux kernel build system is *written* (rather than generated) in
GNU make cf. Managing Projects with GNU Make 3rd Ed pp. 218--228.

> Instead makefiles should be written by another program. I may
> be wrong but I think that GNU Make shines when it is used as part of the
> auto-tools chain, that you may also need to learn.

IMO users of auto-tools fall into two categories - users who need Makefiles
that work cross-platform (so package maintainers) and programmers who don't
regard the build system of their code as worth spending any time on. I
similarly 10 years ago (nearly) learned GNU make but my reaction was the
opposite to yours - I now have handwritten Makefiles for quite large
projects which build projects containing only OCaml but C, JavaScript, XHTML
templates and various other text files, maintain patches against 3rd party
libraries. The Makefile for my website is written in GNU make, runs
cross-platform and uses a parallel and distributed build system (distributed
only because it has to compile some programs on BSD and then pull them back
to Windows before uploading) with not an auto-tool in sight (assuming that
we're allowed dependency generators, of course). Granted, I spent a day
writing it but to me that's the divide - are you willing to spend the time
handcrafting a fully optimised (and possibly therefore faster) build system
or stick with something that takes a few seconds in an auto-tool.

> My personal taste goes rather to BSD Make (make in FreeBSD, bsdmake in OS-
> X and bmake in some other places): I found it much mor eeasy to program,
> and the FreeBSD build toolchain and ports collection provide a significant
> amount of Makefile techniques one can draws its inspiration from. I wrote
> my own macros for my OCaml projects.

So essentially you dislike make in general (bmake and gmake aren't *that*
different - though that said on BSD I always use gmake) - simply that on BSD
there are a large number of pre-written Makefiles and Makefile fragments
which allow you to produce your Makefiles more quickly.


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] Re: about OcamIL

[David Allsopp]

Eray Ozkural wrote:
> On Wed, May 19, 2010 at 2:29 PM, Michael Ekstrand 
> wrote:
> >
> > Yes, Python's hash tables are particularly optimized due to their wide
> > pervasive usage.  When you're testing Python hash tables, you're
> > really testing a carefully-written, thoroughly-tuned C implementation
> > of hash tables.



> That being said, I think getting anything to run on JVM is a remarkable
> achievement! It would have been so cool to be able to run ocaml code
> inside a web browser. :) There are unfortunately few alternatives for
> running code inside a browser.

There are two pretty viable alternatives for running OCaml code in a web
browser - ocamljs[1] is a JavaScript backend for ocamlopt and O'Browser[2]
which is a JavaScript implementation of the OCaml bytecode interpreter (or
VM, as it's been called in this thread).


David

[1] http://code.google.com/p/ocamljs
[2] http://www.pps.jussieu.fr/~canou/obrowser/tutorial

___
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] SHA1 => stdlib ?!

[David Allsopp]

Oliver Bandel wrote:
> Zitat von "Eric Cooper" :
> 
> > On Sat, Apr 24, 2010 at 02:27:47PM +0200, Oliver Bandel wrote:
> >> is it planned, to also include SHA1-Hash into stdlib?
> >
> > I don't know about stdlib, but the ocaml-sha library
> > (http://tab.snarc.org/projects/ocaml_sha/) provides Sha1 (and 256 and
> > 512) modules with the same interface as stdlib's Digest, so they can
> > easily be plugged into functors, etc.
> [...]
> 
> OK, thanks.
> 
> I can try this.
> 
> But easy installation via normal OCaml-diustribution would also be fine.
> :)

Yeah, but we all know from (too many) previous discussions on this list that
that's very unlikely to happen! The OCaml standard library happens to
support MD5 digests because the compiler uses them (they're an integral part
of the linker and dynamic loader as digests are used in .cmi files).


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] Lazy modules

[David Allsopp]

Dario Teixeira wrote:
> Hi,
> 
> > AFAIK local modules is a syntax extension not a compiler extension - I
> > expect (not looked at it) that the syntax extension simply alpha
> > renames all the local module declarations to make them unique and puts
> > them globally... a very useful extension but no expressive power
> > added.
> 
> But if that were true, wouldn't the functor instantiation happen at
> initialisation time, thus preventing the delayed instantiation that is
> key for this solution to work?

Yup, somewhat embarrassingly I seemed to be barking in the wrong forest there, 
let alone up the wrong tree!!

> > I believe that the module system due for OCaml 3.12.0 will allow this
> > kind of runtime application of functors as modules are first class
> > values.
> 
> Again, I'm under the impression that functor application can already
> (with 3.11 at least) occur at runtime when local modules are used.
> (Or are you talking about different things?).  For example:
> 
> # module Foo (S: sig end) = struct let () = print_endline "foo!" end;;
> module Foo : functor (S : sig  end) -> sig  end
> 
> # let hello () = let module F = Foo (struct end) in ();; val hello :
> unit -> unit = 
> 
> # hello ();;
> foo!
> - : unit = ()
> 
> 
> > Hope that's helpful - the inability to do what you're wanting to do is
> > one of the reasons that I've never delved deeply into the module
> > system - powerful as it may be, it didn't seem to be able to help
> > performing a simple task (similar to yours) that I wanted it to do (I
> > have also in the past wanted to exactly what you're doing - i.e. a
> > module of loaded configuration values).
> 
> Yep, Alain confirmed that modules as first-class values are indeed
> coming for 3.12.  Ocaml's module system just got more interesting...

Definitely!


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] Lazy modules

[David Allsopp]

Alain Frisch wrote:
> On 3/17/2010 6:42 PM, David Allsopp wrote:
> > AFAIK local modules is a syntax extension not a compiler extension - I
> > expect (not looked at it) that the syntax extension simply alpha
> > renames all the local module declarations to make them unique and puts
> > them globally... a very useful extension but no expressive power
> > added.
> 
> This is not true. Local modules are not lifted in any way. This is not
> simply a syntax extension. For instance, if the local module has
> toplevel side-effects (e.g. a structure item like: let () =
> print_endline "Hello"), then the side effect will occur every time the
> local module is evaluated.

I've muddled this with something else! I seem to have muddled a lot in my 
post... :$

> At runtime, a structure is represented simply by a block with GC tag 0,
> exactly as a record or a tuple. The block contains dynamic components of
> the structure (values, sub-modules, exceptions, classes) in the order
> given by its signature. Evaluating a structure simply evaluates its
> runtime components a build the block.
> 
> A functor is represented as a function.
> 
> >The module system at present is a compile time feature (I think that's
> >universally true - even with weird things like recursive modules) -
> >functors are simply a way of introducing more modules so there is no
> >runtime overhead in using a functor.
> 
> Modules and functors are much more dynamic than what you believe. The
> introduction of first-class module did not require any change in the way
> modules are compiled.
> 
> A local module which is a functor application really applies the functor
> at runtime and evaluates the functor body every time the local module
> expression is evaluated.

Live 'n learn - thanks for the correction!


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] Lazy modules

[David Allsopp]

Dario Teixeira wrote:
> I've come across a problem which though novel to me, I presume must be
> familiar to those with more ML baggage.  Namely, I need a module whose
> values are not known at the initialisation stage, since they can only be
> determined after reading a configuration file.  If this were a lone
> value, I would declare it as a lazy value which when forced would read
> from the configuration file.  But how can I achieve similar semantics
> with a whole module?

I've hit this similarly with databases - if for example you have a signature DB 
and modules, say, OracleDB, MSSQLDB, PostgresDB. What I'd wanted in the past is 
a module DB which is one of those three but determined at runtime when a 
configuration file is loaded. I couldn't find a satisfactory solution with 
OCaml 3.09 at the time which didn't involve recompiling on each change.

> I do have a solution which though hackish and relying on a language
> extension (local modules) seems to work: I create the module on demand
> via a functor parameterised over an empty sig:

AFAIK local modules is a syntax extension not a compiler extension - I expect 
(not looked at it) that the syntax extension simply alpha renames all the local 
module declarations to make them unique and puts them globally... a very useful 
extension but no expressive power added. 

> module Socket_maker (S: sig end) : Client.SOCKET = struct
> let sockaddr = !Config.sockaddr
> let sockdomain = !Config.sockdomain
> let socktype = !Config.socktype
> let sockproto = !Config.sockproto
> end
> 
> let foo =
> let module Socket = Socket_maker (struct end) in
> ...
> 
> But I wonder a) what's the penalty associated with the runtime
> application of the functor, and

The module system at present is a compile time feature (I think that's 
universally true - even with weird things like recursive modules) - functors 
are simply a way of introducing more modules so there is no runtime overhead in 
using a functor. There are I believe some performance overheads in using 
modules if you care about speed as some optimisations in ocamlopt can't happen 
across module boundaries. My impression has been that if you're that worried 
about these slight performance hits then maybe OCaml is the wrong language for 
you :o)

> b) if there's some better way of doing this.  Any thoughts?

I believe that the module system due for OCaml 3.12.0 will allow this kind of 
runtime application of functors as modules are first class values.

Hope that's helpful - the inability to do what you're wanting to do is one of 
the reasons that I've never delved deeply into the module system - powerful as 
it may be, it didn't seem to be able to help performing a simple task (similar 
to yours) that I wanted it to do (I have also in the past wanted to exactly 
what you're doing - i.e. a module of loaded configuration values).


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] camelia on windows config problem

[David Allsopp]

Michael Hicks wrote:
> I've just been playing with using camelia on Windows, since some
> students in my class are using it.
> 
> My problem is that I can't figure out how to configure Camelia to run a
> non-Cygwin Ocaml.  My installation puts the executables in C:\Program
> Files\Objective Caml\bin, and I can redirect the configuration to look
> here.  But when Camelia tries to run the ocaml toplevel, it complains
> that it cannot find pervasives.cmi.  This is true when I also configure
> the libraries to be in C:\Program Files\Objective Caml\lib\.  When I run
> ocaml from the terminal, it runs fine (i.e., it's able to find the .cmi
> file).
> 
> Any camelia users with ideas about what is going on?  Thanks in advance!

I don't use Camelia but have you set OCAMLLIB correctly? OCaml itself falls
back on configured values if it's missing which might be masking an error?
Have a look at the output of ocamlc -where.


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] Recursive subtyping issue

[David Allsopp]

Guillaume Yziquel wrote:
> David Allsopp a écrit :

> >
> > external foo_of_bar : bar -> foo = "%identity"
> >
> > in *both* the .ml and .mli file for the module in question. I'm
> virtually certain that ocamlopt eliminates calls to the %identity
> primitive.
> 
> yziq...@seldon:~$ grep magic /usr/lib/ocaml/obj.mli external magic : 'a
> -> 'b = "%identity"
> 
> So far so good.

I don't follow...?



> > This is tremendously clean - as long as the types are clearly
> documented! The problem is that ocamldoc doesn't let you "document"
> coercions (by which I mean that having a conversion function provides
> means for the documentation of that particular usage).
> 
> Thank you. The ocamldoc problem isn't really a problem, I believe. You
> just have to write it cleanly in bold letters.
> 
> What is more a problem is the fact that inferred .mli files tend to
> leave out the contravariance on tau:
> 
>   http://caml.inria.fr/mantis/view.php?id=4988
> 
> And hence drops part of the subtyping facility.

Though that's another good reason for never, ever, ever, ever using inferred 
.mli files - the signature is part of your code! ocamlc -i is useful only for 
generating the first cut of the file so that you can double-check (and probably 
constrain) the inferred type annotations and add ocamldoc comments...


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] Recursive subtyping issue

[David Allsopp]

Goswin von Brederlow wrote:
> "David Allsopp"  writes:
> 
> > external foo_of_bar : bar -> foo = "%identity"
> >
> > in *both* the .ml and .mli file for the module in question. I'm
> virtually certain that ocamlopt eliminates calls to the %identity
> primitive.
> 
> Where is that documented?

The use of external and its benefit in exported signatures is documented in
Chapter 18 of the manual.

I believe I became aware of the %identity special handling as a side-effect
of the discussion in
http://caml.inria.fr/pub/ml-archives/caml-list/2007/04/200afc54d9796dbb7a8d7
5bef70f2496.en.html.

If you look in asmcomp/cmmgen.ml you'll see what I think is the elimination
of Pidentity calls in the code generator.

> I would have written
> 
> let foo_of_bar (x : bar) = (x :> foo)

We're solving two different problems, I think (as you're assuming that bar
can be constrained to type foo) - I'm assuming that all type constraining is
done in the signature of the interface so, without %identity I would simply
have put [let foo_of_bar x = x] of type 'a -> 'a in my module... and then
constrained it as [val foo_of_bar : bar -> foo] in the signature.

It is possible that ocamlopt can recognise (obvious) identity functions as
well, but that's just speculation on my part as I haven't looked.


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] [newbie] miscellaneous on installation and web site

[David Allsopp]

Marco Maggi wrote:
> Ciao,
> 
>   I am a  True Beginner taking a look at  O'Caml; I hope not to  be
> abusing  by posting  here rather  than  the beginners list.

Building OCaml from source is definitely not a beginners' question! :o)

>   I  think  I   successfully  compiled  ocaml-3.11.2  on  my
> i686-pc-linux-gnu, but  there seems to be no  way to install the package
> in  a temporary location via the  Linux de facto standard DESTDIR
> environment variable;  is there a way to do it?  (I am used to build
> custom packages.)

I've not come across that way before (by which I mean "you learn a new thing
every day"!), the more usual way, which will work with OCaml, is to specify
a different root for the -prefix option when you run configure. make install
will then install OCaml there. I used to use that when compiling uses OCaml
on a machine for which I didn't have root and I used it just the other day
to compile OCaml 3.12.0 on Maemo so the switch definitely works.

All that said, what distro are you using? Debian and Fedora (and *BSD) all
have native packages for OCaml.

>   The  web site[1]  is beautiful  (no  irony) but  a lot  of
> informations look outdated, 4/5 years old; I see many O'Caml related
> sites on  the Net.  Is there one that  I can take as reference  for  the
> latest  news,  for  example about  still maintained library packages?

The Caml Hump I believe has up-to-date information as long as it's
submitted. I'm quite lazy and tend only to look for updates to libraries I
use when either I hit a bug or am installing on a new machine ...
www.ocamlcore.org is a pretty good place to start, I think.


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] Recursive subtyping issue

[David Allsopp]

Guillaume Yziquel wrote:
> Stéphane Glondu a écrit :
> > Guillaume Yziquel a écrit :
> >>> # type untyped;;
> >>> type untyped
> >>> # type 'a typed = private untyped;;
> >>> type 'a typed = private untyped
> >>> # type -'typing tau = private obj
> >>>   and 'a t = 'a typed tau
> >>>   and obj = private untyped tau;;
> >>> type 'a tau = private obj
> >>> and 'a t = 'a typed tau
> >>> and obj = private untyped tau
> >>> # let f : 'a t -> obj = fun x -> (x : 'a t :> obj);; val f : 'a t ->
> >>> obj =  # let g : obj -> 'a t = fun x -> (x : obj :> 'a t);; val
> >>> g : obj -> 'a t =  #
> >
> > Why don't you just declare 'a t to be synonym for obj in the
> > implementation of your module, declare them as abstract in its
> > interface, and export the specially typed identities f and g?
> 
> Because subtyping seems more efficient than applying a noop function.

I wholeheartedly agree that doing this in the type system is much cleaner than 
using noop/coercion functions but I don't think that there's any difference in 
terms of efficiency. If the noop/coercion functions are correctly coded then 
they will be of the form:

external foo_of_bar : bar -> foo = "%identity"

in *both* the .ml and .mli file for the module in question. I'm virtually 
certain that ocamlopt eliminates calls to the %identity primitive.

> And this code might run really often, so I do not like very much the
> idea of having noop functions running really often.

See previous; I don't think it makes a difference (to runtime performance, 
anyway).

> Moreover, having conversion functions is not really handy, from a
> syntactic point of view: It's quite convenient to write something like
> 
> let f : string -> obj :> string -> float t = blah blah blah...
> 
> than doing the explicit, runtime, casting in the definition of f.

Agreed - this is where your approach is really neat!



> I then tried to go the whole way, and get rid of conversion functions
> altogether.

Being pedantic, what you mean is getting rid of *coercion* functions; 
*conversion* functions could never eliminated because by their nature they are 
"doing" something (for example, int_of_string constructs a new integer value 
based on the string value given to it - you could never just trick the type 
system into using the same value for both in a meaningful way).

This is tremendously clean - as long as the types are clearly documented! The 
problem is that ocamldoc doesn't let you "document" coercions (by which I mean 
that having a conversion function provides means for the documentation of that 
particular usage).


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] Recursive subtyping issue

[David Allsopp]

Stéphane Glondu wrote:
> Guillaume Yziquel a écrit :
> > Because subtyping seems more efficient than applying a noop function.
> > And this code might run really often, so I do not like very much the
> > idea of having noop functions running really often.
> 
> FWIW, I don't think you have any penalty if you declare your identities
> as externals like Obj.{repr,obj,magic}. Yuk, some might say... but we
> are in the context of bindings to other languages anyway.
> 
> > Moreover, having conversion functions is not really handy, from a
> > syntactic point of view: It's quite convenient to write something like
> >
> > let f : string -> obj :> string -> float t = blah blah blah...
> >
> > than doing the explicit, runtime, casting in the definition of f.
> 
> It's more convenient for me write letters and parentheses than the
> symbol ":>" :-)

Then you can write a camlp4 syntax extension to convert the casts to x_of_y 
function calls :o)

___
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 on Maemo

[David Allsopp]

Sebastian Mondet wrote:
> On my N810, thanks to the "easy debian" technique:
> http://wiki.maemo.org/Easy_Debian
>
> I got access to all the ocaml packages which are available on debian-ARM.
Everything I tried
> worked perfectly (but I only tried "text mode" apps).

That seemed a little heavy for the first day of having it but I've
bookmarked the link for the future!

Gerd Stolpmann wrote:
> Yes, I've tried similar years ago on the N800 (Maemo 4, however). I ran
into this problem at
> that time: http://caml.inria.fr/mantis/view.php?id=3746. The ARM code
generator was changed
> since then (will be released in Ocaml 3.12). Haven't tried that yet,
though.
>
> So far I remember the byte code compiler was no problem at all. Only the
native-code compiler had > these problems with FP instructions.

I had the same experience with 3.11.2 - the error message from configure
could be better, but that won't matter once it's fixed in 3.12.0 (as you
say).

Martin DeMello wrote:
> On Wed, Feb 24, 2010 at 9:44 PM, David Allsopp 
wrote:
> > My shiny new Nokia N900 has finally arrived so, of course, having got
> > bash, vim and texlive successfully installed I naturally need a
> > compiler!
> >
> > Before I dig into trying to compile OCaml on Maemo 5, can I ask if
> > anyone else out there has already tried (and hopefully succeeded)?
> 
> No, I've mostly been playing with Vala since I got mine, but I'd love to
> hear how you manage with it. It's definitely on my to-do list.

Enabling the SDK repository allowed me to install bash, make, gcc,
libc6-dev, tcl8.5-dev, tk8.5-dev and libx11-dev.

(aside, which probably demonstrates my ignorance more than a bug/problem in
anything: I've never used aptitude before - I was amused that installing gcc
doesn't automatically upgrade glibc to the dev version as you end up with a
C compiler which can't link. Couldn't quite imagine a situation where that's
handy but hey ho!)

OCaml 3.12.0+dev17 compiles out of the box (using -prefix /opt/maemo) -
ocamlbrowser works (i.e. labltk) and ocamlopt is fine. The reference run of
a command line app of mine takes 5 mins 20 sec (impressive as it takes 31
seconds on my Intel P8600 laptop and used to take about 4:30 on the machine
on which it was originally developed). 


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

[Caml-list] OCaml on Maemo

[David Allsopp]

My shiny new Nokia N900 has finally arrived so, of course, having got bash,
vim and texlive successfully installed I naturally need a compiler!

Before I dig into trying to compile OCaml on Maemo 5, can I ask if anyone
else out there has already tried (and hopefully succeeded)?


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] free, open-source version of OCaml grammar?

[David Allsopp]

IANAL!

Yitzhak Mendelbaum wrote:
> I'd like to port the OCaml grammar to another parser generator.

What *exactly* do you mean by port? A line-by-line conversion of
parsing/parser.mly to a your new parser generator's syntax or a brand new
file which exactly parses the same grammar as parsing/parser.mly?

> However, the grammar is covered under the Q Public License, and the
> terms of the license seem to require that the ported version only be
> distributed as a patch to the current YACC grammar.

If you're doing a line-by-line conversion then that might reasonably be
regarded as derivative but if you produce a brand new source file for your
new parser generator for the OCaml language then I would not expect that to
be covered by any aspect of OCaml's licence because the licence covers the
source code of Inria's OCaml (i.e. Copyright) and not the idea of the OCaml
language (i.e. Patent). I have no idea whether the OCaml grammar is
patented, though I'd be surprised if it were as you would have expected
Microsoft to have steered clear when developing F#.

> Given that I'm
> porting the grammar to serve as an example for a new parser generator,
> distributing it as an unreadable patch is quite impractical.

If you're using it as a demo, then I expect you'll find that the benevolent
OCaml team may well be happy to exempt the licence for that use anyway!

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] define incompatible type

[David Allsopp]

David Rajchenbach-Teller wrote:
>      Hi Grégoire,
> It's not directly possible in OCaml, but there are at least three methods
for doing what you
> want.
>
> The first one is to wrap your integers behind a constructor, e.g.



You can also use (post OCaml 3.11.0) private types if you want to be able to
use the ID values as integers but only explicitly. While I'm sure that the
ocaml compiler eliminates calls to the identity function, I like the
elegance that the conversion from id to int is a type coercion instead of a
function call. In real world uses, chances are that of_int is a useful
function doing actual work and not the identity function!

module User :
  sig
type id = private int
val of_int : int -> id
  end =
  struct
type id = int
let of_int x = x
  end;;

let a = User.of_int 57
and b = User.of_int 57;;

a = b;;   (* true *)
a = 57;;  (* type error *)
(a :> int) = 57;; (* true *)


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] Problem with try_lock on win32.

[David Allsopp]

Romain Beauxis:
> I have a problem with the following code under win32:
> 
> let m = Mutex.create ()
> 
> let () =
>   Mutex.lock m;
>   if Mutex.try_lock m then
> Printf.printf "locked !\n"
>   else
> Printf.printf "could not lock!\n"

This code is behaving correctly for a Windows mutex (AFAIK - I can't find
the relevant bit in the Synchronisation on MSDN atm) - once a thread has
locked a Windows mutex, WaitForSingleObject will return WAIT_OBJECT_0 (i.e.
success) because for that thread the mutex is signalled (it's only other
threads which will see the object as non-signalled). I guess it's a
philosophical discussion for whether it's useful for a thread to be able to
block itself permanently by trying to lock a mutex which it has already
locked (the POSIX way).

One possible fix to make it behave like POSIX would be to patch
otherlibs/systhreads/win32.c so that caml_mutex_lock records the thread ID
of the thread when it locks the mutex. Some trick would be required to block
the thread (permanently) if it calls Mutex.lock twice (to match the POSIX
behaviour). caml_mutex_try_lock can check the thread ID before using
WaitForSingleObject and return false if it shows that it's locked and
caml_mutex_unlock would clear the thread ID to null on a successful release.
Two potential problems (which I'm guessing other Windows users on the list
may comment on, if relevant):

a) The representation of a mutex internally (the abstract value) changes
which means that any Windows C stubs which interoperate with OCaml mutexes
would break.
b) The behaviour of Mutex.lock and Mutex.try_lock under Windows would be
altered to be non-Windows-like behaviour which may affect existing
Windows-only programs which rely on it.

But you could raise it as a bug in Mantis just for cross-platform
consistency of the Mutex module (another option would be to have a separate
module PosixMutex with the guaranteed consistent semantics and leave the
Mutex module as behaving in an OS-specific way)


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] 2147483648l < 2147483647l

[David Allsopp]

Goswin von Brederlow wrote:
> "David Allsopp"  writes:
> 
> > Matej Kosik wrote:
> >> I am sorry, I have a stupid question.
> >> I would like to ask if this:
> >>
> >># 2147483648l < 2147483647l;;
> >>- : bool = true
> >
> > The bug is in fact:
> >
> > # 2147483648l;;
> > - : int32 = -2147483648l
> >
> > and given that behaviour, the above result makes sense! But...
> 
> Isn't that documented properly? I think in the docs I saw at least that
> ocaml will silently overflow ints.

Arithmetic operations are allowed to overflow silently but at no point do
you end up with an illegal constant which is the bug here.

i.e. Int32.add 2147483647l 1l correctly evaluates to -2147483648l but
-2147483648l is a valid int32. The evaluation of a constant by the compiler
in your ML source is supposed to follow the same rules as Int32.of_string
(which would raise an exception if given "-2147483648l") hence 2147483648l
which is not a valid int32 should be a "syntax" error.


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] Queue.fold give wrong order?

[David Allsopp]

Tom Wilkie wrote:
> Dear all
> 
> Is Queue.fold going over items in the wrong order?  It says "equivalent
> to List.fold_left" but I would expect the behaviour to be, when
> inserting items 1, then 2, then 3 a fold would be given items in that
> order?
> 
> Is there a good reason for this?  Could be have a rev_fold for the
> opposite order please?
> 
> Thanks
> 
> Tom
> 
> # ocaml
> Objective Caml version 3.10.2
> 
> # open Queue;;
> # let q = Queue.create ();;
> val q : '_a Queue.t = 
> # Queue.add 1 q;;
> - : unit = ()
> # Queue.add 2 q;;
> - : unit = ()
> # Queue.add 3 q;;
> - : unit = ()
> # Queue.fold (fun acc a -> a::acc) [] q;;
> - : int list = [3; 2; 1]
> # Queue.iter (fun a -> print_endline (string_of_int a)) q;;
> 1
> 2
> 3
> - : unit = ()

List.fold_left (fun acc a -> a::acc) [] [1; 2; 3];;
List.iter (fun a -> print_endline (string_of_int a)) [1; 2; 3];;

If that still puzzles you then please, with respect, re-post to the
beginners' list.


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] Compatibility 3.11.1 and 3.09.3

[David Allsopp]

Michel Levy wrote:
> I have byte-code produced by ocamlc  version 3.11.1 which does not work
> with ocamlrun version 3.09.3.
> Is this situation normal ?

Afraid so.

> Must I have exactly the same version for the compiler producing the
> byte-code and the ocamlrun executing this code ?

Yes - even releases within the same minor version number are not guaranteed
to have binary compatibility. 

> Sincerely yours.
> 
> PS : this problem occurs to me because I compile on my machine (ocaml
> 3.11.1) and I send the byte code
> to a web server with an other version (ocaml 3.09.3) and I am not in
> charge of this server.

It is (reasonably) easy to compile a local copy of OCaml 3.09.3 and switch
to that for bytecode compilation on your server
(http://caml.inria.fr/pub/distrib/ocaml-3.09/). If you're using camlp4, then
you'll need a slightly screwy Makefile to ensure that you pre-process using
camlp4 from 3.11.1 and compile using ocamlc from 3.09.3 but that's far from
impossible...

Hope that helps inasmuch as it confirms your fears!



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] problem creating .cma library

[David Allsopp]

Guillaume Yziquel:
> Basile STARYNKEVITCH a écrit :
> >>
> >> Why do these functions not follow the usual CAMLparam/CAMLreturn
> >> macro stuff?
> >
> > Because they are written by the Ocaml guys (Damien knows really well
> > the Ocaml garbage collector; he wrote it). And also, because these
> > particular functions do not do any allocation of Ocaml values (either
> > directly or indirectly).
> 
> So, no allocation of OCaml values (or in place modification, either, I
> guess) implies no need for CAMLparam/CAMLreturn stuff?

Chapter 18 of the manual in Section 18.5 describes pretty much everything you 
need to know about writing safe stubs that work with the garbage collector. 

> 
> > My advice for people coding C code for ocaml is the following:
> >
> > 1. *always* use the CAMLparam/CAMLreturn/... macros.
> >
> > 2. if you dare not using them for some very few functions (because
> > they don't allocate, ...) add a big fat comment with a warning inside.
> >
> > Regards
> 
> I want to understand them so that I can abstract away in some other file
> / .so, some rather usual constructs involving OCaml structures. I think
> it is smarter to take some time doing this, with detailed comments all
> over, than repeating the same mistakes over and over (or worse:
> wondering if you made mistakes) when doing C bindings.

Having written a few C stubs myself, I'd also highly recommend just following 
the manual and not worrying about what the macros do - if you want/need to 
improve allocation performance then you can use the lower-level interface for 
allocation (but that still involves CAMLparamn/CAMLreturn). I usually find that 
tricks like this (think Obj.magic) mean that when something goes wrong, there's 
always a niggling thought in the back of your mind that it's the trick which 
has broken everything when in fact it's something blindly obvious but you waste 
hours double-checking the tricks!

In the ideal world, the C written for C stubs would be parsed by a camlp4-like 
pre-processor which would automatically insert the expansion of those macros 
where required. If you have CAMLparamn and CAMLreturn on functions which don't 
strictly need them then you're only creating a few more local roots than are 
strictly necessary which isn't likely to hurt that much...


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] 2147483648l < 2147483647l

[David Allsopp]

Matej Kosik wrote:
> I am sorry, I have a stupid question.
> I would like to ask if this:
> 
>   # 2147483648l < 2147483647l;;
>   - : bool = true

The bug is in fact:

# 2147483648l;;
- : int32 = -2147483648l

and given that behaviour, the above result makes sense! But...

> it cannot be encoded to 32-bit
> signed integer encoded with 2's complement representation.

and it's outside the range [Int32.min_int, Int32.max_int]

However, it's a known bug - http://caml.inria.fr/mantis/view.php?id=4210

According to Mantis, it's fixed in 3.12 - I'm sure there's a reason that
it's not been fixed in 3.11.2+rc1


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] [ANN] Release Candidate: 3.11.2+rc1

[David Allsopp]

Damien Doligez wrote:
> It is our pleasure to announce that the release of 3.11.2 is imminent.
> What we need now is your cooperation for testing the release candidate,
> especially on Windows.

I've managed to compile this RC on Windows 7 x64 using the MinGW 32-bit port
(with ocaml-calendar 2.02, ocaml-csv 1.1.7, extlib 1.5.1, findlib 1.2.5,
json-static 0.9.8, json-wheel 1.0.6, ocamlnet 2.2.9, ocamlsha 1.5,
ocaml-pcre 6.0.1, pgocaml 1.4 and spiderCaml 0.2).

OCaml seems fine, but.

The latest version of Cygwin seems to contain a questionable change to the
handling of symlinks which created more trouble building OCaml than previous
versions (as flexlink runs "natively" and not within Cygwin) - although I've
built OCaml and these libraries successfully within bash, I'm having trouble
with ocamlopt when run outside bash (my usual setup is cmd + GnuWin32).

Has anyone else got ocamlopt working properly with non-trivial code (C stubs
and so on) on Windows outside Cygwin? I'm getting errors from gcc trying to
run cc1 which I think is to do with symlink misery and also I can't link
anything with ocamlopt unless running in bash. The Cygwin team's decision to
revert to the default to their own internal symlink format is almost as
questionable as Microsoft's making the API for creating NTFS symlinks in
Vista/2008 require administrator privileges but unlike Microsoft I'm sure
they actually have some good reason for it...


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] Module abbreviation

[David Allsopp]

Ashish Agarwal wrote:
> If you only have a file ast.mli, you should not be able to write Ast.Sig
because you do not have a module named Ast.

This isn't true - the include statement works at a type system level
(because you're dealing with a signature) and therefore only a .cmi file is
required. It does not generate any work for the linker so a module called
Ast is not actually needed when linking.

> Please double check your example. It cannot be working as you describe.

I'm afraid you should have checked - the example given compiles (try ocamlc
-o foo ast.mli toto.ml with suitable substitutions for the "..."s)

Romain Bardou wrote:

> I have a file ast.mli. It has no .ml implementation as it contains only
> type definitions.

This is fine

> I have a file toto.ml, which contains simply:
> 
> module A = Ast

But as this involves a linker instruction you need an actual module - hence
the error you're seeing. I guess you could argue that the module statement
could check to see if Ast only contains type definitions and relax the need
for an actual module but in the general case Ast could contain values and so
you need a module to link against.

> I found a workaround, which is to change ast.mli to put all type
> definitions in a signature, such as:

This workaround works because you take the whole thing back to the type
system so module implementations are not required by the linker.


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] How to write a CUDA kernel in ocaml?

[David Allsopp]

Basile Starynkevitch wrote: 
> Eray Ozkural wrote:
> 
> Compiling Ocaml to efficient C is not easy and probably impossible (or
> extremely difficult) in the general case. In
> particular, tail recursive calls are essential in Ocaml, and are not
> available in C in most compilers.

What's this based on (out of interest)? Most C compilers don't necessarily
identify tail recursion in *C* code but if you're emitting C as an OCaml
backend then there's no reason not to convert tail recursive *OCaml*
functions to C code based on goto or similar looping constructs (yes, you'd
almost-always-virtually-never use goto in a hand-crafted C program without
apologising profusely at Dijkstra's grave but if you're using C as an
intermediate language then that's a different matter). If I recall correctly
from an old post on this list, this is how Felix handles tail recursion when
translating Felix to C++


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] Same name fields

[David Allsopp]

Mykola Stryebkov wrote:
> I'm trying to declare to record types with fields having the same name
> but different types.

This is not possible with record types (at the same module scope) - when you
declare the second type you obscure the previous type.



> If I declare type ta second - everything works fine.
> Is it a bug?

No :o)

> If not, what is an appropriate workaround here?

Either put types ta and tb in separate modules (then you can use qualified
field names) or use different field names. The Unix module in the Standard
Library is a good example of how to do all this in practice - the record
types there all have standard prefixes on the field names.

The other alternative is to use objects but this is heavier in terms of
memory and field access and the type errors messages are more confusing than
with records (but neither of these reasons are necessarily bars to using
them!!).


David


PS Not that it I think it generally offends people on this list, but this
question would have been more appropriate for the Beginners' List -
http://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] The lexer hack

[David Allsopp]

> I'm creating a parser for a LaTeX-ish language that features verbatim blocks.

Out of interest, how LaTeX-ish do you mean? I would hazard a guess that it's 
impossible to parse an unrestricted TeX file using an LR grammar (or at least 
no more clear than a hand-coded automaton) because you have to execute the 
macro expander in order to parse the file *completely* correctly. However, if 
you only mean LaTeX-ish in syntax (i.e. the files aren't actually TeX files) 
then you don't have to worry about TeX's elegant (by which I mean terrifying) 
\catcode mechanism and macro language!


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] compiling C library wrapper

[David Allsopp]

Aaron Bohannon wrote: 
> I am quite confused by the whole process of compiling and installing
> wrappers for C libraries.  It seems like I can get things to work OK
> without really knowing what I'm doing if everything is put and built
> in a single directory.  The hard part seems to be putting the right
> files in the right places and getting the path arguments correct.
> Then things stop working, and I have to really understand what's going
> on, but the manual doesn't explain this part of the process in any
> detail.

Have a look at ocamlmklib in the manual - if it's available on your platform
then it nicely hides away a lot of this.


> 5) Write "foo.ml" and use it to build "foo.cmxa" by running
> 
> ocamlopt -a -o foo.cmxa foo.ml
>   -ccopt -L/opt/local/lib -cclib -lfoo
>   -ccopt -L/usr/local/lib/ocaml/stubs -cclib -lfoo_stubs

This command will also build foo.cmx, foo.a and foo.o

> 6) Copy "foo.cmi" and "foo.cmxa" to their permanent location, let's
> say "/usr/local/lib/ocaml/foo/"

You should also copy foo.a to this directory which should fix the problem.
foo.cmxa contains information required by OCaml but the actual code is in
foo.a (as it's been natively compiled). Similarly, .cmx files contain
information which ocamlopt needs but the actual code is in .o (or .obj)
files. For native code, it's a code idea to copy the .cmx files too as it
allows ocamlopt to do some inlining (I think that's right...)

> 7) Write my file "bar.ml" that needs to use the library, and compile
> it by running
> 
> ocamlopt -I /usr/local/lib/ocaml/foo -o bar foo.cmxa bar.ml

This should now work without error.


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] Howto execute a command without the "cmd" windows opening?

[David Allsopp]

> If i find a way to read the exit status of the process…

Pass a PROCESS_INFORMATION structure to CreateProcess (in order to get the 
hProcess for the process you created) and then use GetExitCodeProcess[1]. You 
can use WaitForSingleObject passing hProcess to it if you need to block until 
the process has actually terminated or you can loop on GetExitCodeProcess until 
the result is not equal to STILL_ACTIVE.


David 


[1] http://msdn.microsoft.com/en-us/library/ms683189(VS.85).aspx
[2] http://msdn.microsoft.com/en-us/library/ms687032(VS.85).aspx

___
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] Howto execute a command without the "cmd" windows opening?

[David Allsopp]

> The problem is that a "c:\windows\system32\cmd.exe" windows pops up:
> I'd like to avoid this.

Both Sys.command and Unix.system use cmd in order to provide command line
parsing (it gives the closest equivalent to the Unix version - except for
the usual quoting weirdness of cmd as compared to bash!)

> I tried Sys.command and Unix.system without success.
> 
> Is there any way to run a program and get the process status without
> using cmd.exe ?

It's been on my todo list to wrap the CreateProcess Win32 API function[1] in
a C stub function - someone else may have done this (possibly in
ocaml-win32[2] or something like that), though. The API is very simple (most
parameters will be NULL) so the stub would not take long to write.


David

[1] http://msdn.microsoft.com/en-us/library/ms682425(VS.85).aspx
[2] http://caml.inria.fr/cgi-bin/hump.en.cgi?contrib=371

___
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] Improving OCaml's choice of type to display

[David Allsopp]

> Le 9 oct. 09 à 16:18, Damien Guichard a écrit :
>
>
> Imagine my code is:
> 
>  type color = int
> 
>  let black : color = 0 
> 
> Then, following your proposition, evaluating black should give me
an int rather than a color because int is shorter and therefore nicer.

Hmm, I'd say that having OCaml respond "val black : int = 0" is indeed the
more useful answer (but not because int is shorter)... there are quite often
times where you get complex looking types (for good reason) which are in
fact aliases of much simpler types where it would (IMO) be much nicer for
OCaml to "call a spade a spade" and just tell you it's an int (Set.Make and
Map.Make being obvious cases[1]). Perhaps OCaml could make us both happy by
responding "val black : color = int = 0" (i.e. show the inferred and
possibly aliased type and also the principal base type, if it's different
from the inferred type)

The "unnecessary" complexity of the type names can also arise quite easily
if you're using with functors so need to present a particular type to
satisfy a signature - at which point having Foo.Bar.Other.Module.t (which is
in fact an int) may create irritatingly long type messages but the structure
being that way is probably hugely useful when it gets applied to
Magic.Make(Foo) elsewhere...


David


[1] Consider, somewhat obtusely, [let x : Map.Make(String).key = ""] (which
in real code is inferred rather more trivially from anything manipulating
sets and maps)

___
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] Constructors are not functions

[David Allsopp]

Goswin von Brederlow wrote:

> Then what about
> 
> type t1 = Bar of int * int
> type t2 = Foo of (int * int)
> 
> If you treat constructors as functions taking one argument then

But why (so arbitrarily) do this?

> t1: int * int -> t1
> t2: int * int -> t2

If you look at each type definition and choose those most appropriate, then:

t1: int -> int -> t1
t2: int * int -> t2

I don't see your point (but this is pre-coffee!)? The fact that you write
[Bar(1, 2)] for a two-constructor variant tag and [bar 1 2] for a "2
argument" function is just an (occasionally irritating) oddity of the OCaml
syntax - it wouldn't have to affect any derived constructor functions here.

However, the impracticality of importing the types from other interfaces
(see Richard Jones post in this thread) has already revealed that this
couldn't be done transparently in the way I'd initially thought so it's
become a bit of a thought experiment anyway :o)


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] Constructors are not functions

[David Allsopp]

Jon Harrop wrote:
> David Allsopp wrote:
> > I think it would be possible to simulate the SML behaviour in OCaml
> > using camlp4 (if you assume that for [type foo = Bar of int] that future
> > unbound references to [bar] are interpreted as [fun x -> bar x] instead of 
> > an
> > error)
> 
> Only if you turned multi-argument type constructors into single-
> argument ones
> taking a tuple, i.e. type definitions like:
> 
>   type t = Bar of int * int
> 
> must become:
> 
>   type t = Bar of (int * int)

That's not the case at all - there'd be no reason not to interpret [bar] as 
[fun x y -> Bar(x, y)] for [Bar of int * int]. What would be hairy in camlp4 
would be having to read .cmi files to deal with types defined outside your 
source file, but that's still not impossible...


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] Constructors are not functions

[David Allsopp]

David Allsopp wrote:
> > Is there a reason for constructors not to behave like functions?
> > For instance, one cannot make a partial application from a constructor:
> 
> This is how SML handles constructors, Xavier explained the reasons he
> chose to depart from this in:
> 
> http://caml.inria.fr/pub/ml-archives/caml-
> list/2001/08/47db53a4b42529708647c9e81183598b.en.html
> 
> I think it would be possible to simulate the SML behaviour in OCaml
> using camlp4 (if you assume that for [type foo = Bar of int] that
> future unbound references to [bar] are interpreted as [fun x -> bar x]
> instead of an error)

Tsk - [fun x -> bar x] should of course be [fun x -> Bar x]

___
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] Constructors are not functions

[David Allsopp]

>   Is there a reason for constructors not to behave like functions? For
> instance, one cannot make a partial application from a constructor:

This is how SML handles constructors, Xavier explained the reasons he chose to 
depart from this in:

http://caml.inria.fr/pub/ml-archives/caml-list/2001/08/47db53a4b42529708647c9e81183598b.en.html

I think it would be possible to simulate the SML behaviour in OCaml using 
camlp4 (if you assume that for [type foo = Bar of int] that future unbound 
references to [bar] are interpreted as [fun x -> bar x] instead of an error)


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] Dynlink and ocamlfind for camlp4 3.11?

[David Allsopp]

Conglun Yao wrote:
> Thanks for all of your help. 
>
> Unfortunately, it still does not work. It is really nightmare to use camp4
in a windows machine.

In this instance, it's very much Cygwin that's causing the problem, rather
than Windows! I didn't realise that Cygwin's Dynlink only extended to pure
bytecode (it used not to have Dynlink at all).

> I try to reinstall plain OCaml without using GODI, if the same error
happens, I have to go back to Ubuntu.

You could try using the -w32port mingw flag for GODI to build the MinGW
version of OCaml - you can still use it from Cygwin's bash prompt but you
will definitely have a fully functional dynamic loading version.
Alternatively, if you want I can email you the instructions change log I use
for building MinGW & MSVC OCaml on Windows (one day I'll have the time to
put it online ).

Try GODI/MinGW first - building PCRE is not trivial and AFAIK GODI has full
build-support for ocaml-pcre on Windows.


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] Dynlink and ocamlfind for camlp4 3.11?

[David Allsopp]

> I tried, and it works fine until the require of "json-static". It breaks
when loading "pcre.cma". 
>
> Now we can say that pcre package has some problem, but dynlink is loaded
successfully.

Hmm - a few other things to check:

1. Are you definitely using Cygwin's PCRE and which version (run pcre-config
--prefix and pcre-config --version)
2. Which version of ocaml-pcre is findlib trying to load (#use "topfind";;
#list;; from within ocaml)
3. Did you install the (very out-of-date) OCaml package which comes with
Cygwin?
4. Did you install plain GODI or did you pass -w32port mingw to the first
script?

I'm using pcre-ocaml 6.0.1 / PCRE 7.9 with no problems with the MinGW port
of OCaml 3.11.1 (not via GODI, though)


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] Dynlink and ocamlfind for camlp4 3.11?

[David Allsopp]

> Ah but wait, your META file has that patch incorporated already!
> 
> I don't know -- the cygwin distribution of OCaml is broken somehow.

What happens if you run ocaml and then enter #load "dynlink.cma";; ??


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] Missing the cmi files required to use toplevellib.cma

[David Allsopp]

> The problem is : most of the usefull types and functions are installed
> in the toplevellib.cma but I can't use this without the proper cmi
> files (I need config.cmi for cmi_magic_number, printtyp.cmi and
> typemod.cmi for printing signatures, but env.cmi would be nice to have
> as well for read_signature).

You could add them to http://caml.inria.fr/mantis/view.php?id=4653 ... but
as that was requested for 3.11.0 and didn't make it to 3.11.1, I wouldn't
hold your breath!


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] Generation of Java code from OCaml

[David Allsopp]

Mykola Stryebkov wrote: 
> Hi, Richard.
> 
> On 23 Вер 2009, at 22:57, Richard Jones wrote:



> I'm going to use stringing bits of text together. But text generating
> is not an issue here. The issue is how to make this stringing driven by
> description of ocaml records.

camlp4 would be the neatest, most stable way of doing this - as it sounds so 
similar in operation (if not function) to json-static, why not use its code as 
a reference/starting point? The alternative if you're happier with text 
processing and want to avoid the learning-curve for camlp4 would be to parse 
the output of `ocamlc -i` which is, in syntactic terms, canonical (where a 
source file is not)


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] External DLL call with mingw OCaml

[David Allsopp]

Matthieu Dubuget wrote:
> Hello,
> 
> recently, I had to call a third-party DLL (Windows, mingw flavour of
> OCaml).
> It was not easy, because of symbol names decorations (I think).

It is indeed not easy - fortunately, it's a once-only thing (for each DLL)

> I'd like to know if there is a more simple way?

Not as far as I'm aware - no site I've ever seen gives a reasonable
explanation for why the "@nn" decorations are necessary (gcc or any other
compiler should be able to infer it from the header at link time, but
neither gcc nor the MS compilers provide a way to do this)



> 3/ Import lib generation
> dlltool --input-def visa.def --dllname Visa32.dll --output-lib
> libvisa.a -k

The irony is that the -k (--kill-at) removes the @nn from the symbols :o)



> The main problem is that it is a trial error process in order to find
> the @nn to add into visa.def.

This shouldn't be trial and error - you can work out the numbers from the C
definitions (which presumably you know as you're writing stubs). For the
most part for 32-bit code, it'll be 4 x the number of parameters to the
function but in more exact terms it's the number of bytes occupied by the
parameters (so sizeof the *type* of each arg) which you can deduce from the
.h file. Alternatively, you can just put them all as @0 initially and use
the error messages - it'll always give you the correct one (provided that
your headers are correct)

Hope this reassures, even if it doesn't offer an easier way!


David


PS This is the site I used originally -
http://www.emmestech.com/moron_guides/moron1.html though I'm not sure you'd
ever find a moron who wanted/needed to do this kind of thing!!

___
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] Sets and home-made ordered types

[David Allsopp]

Matthias Puech wrote:
> David Allsopp a écrit :
> > Is it not possible to model your requirement using Map.Make instead -
> > where the keys represent the equivalence classes and the values whatever
> > data you're associating with them?
> 
> Yes, that's exactly the workaround I ended up using, although I'm not
> very happy with it because, among other things, these keys/class
> disciminant get duplicated (once inside the key, once inside the
> element). I'm getting more concrete below.

While I agree that the duplication is unfortunate, it is only one word (the
number needed in each instance to store the Constructor value for the key -
you get the Constructor "for free" with a tuple as it's "stored" in the tag
of the block allocated to hold the tuple.)

> > In terms of a strictly pure implementation of a functional Set, it
> > would be odd to have a "find" function - you'll also get some
interesting
> > undefined behaviour with these sets if you try to operations like union
and
> > intersection but I guess you're already happy with that!



> For union and inter, I don't see how their behavior would be undefined,
> since neither the datastructure nor the functions are changed.

The element put into the sets on intersection and union is undefined. Say
you have the trivial case with just one equivalence class 

type u = A of int
module MySet = Set.Make(struct type t = u let compare x y = 0 end)

So your sets will all be singletons. What is the result of:

MySet.inter (MySet.singleton (A 1)) (MySet.singleton (A 2))

In 3.11.1, it's the singleton set containing [A 2] but the definition
intersection reasonably allows for it to be [A 1] instead. However, this of
itself isn't an argument against having [find] - it's just that what you're
doing already isn't really a set.



> Besides, I'm responsible for making sure that the pair e.g. (G', F(A)) is
not added.

Jacques Garrigue has a syntax extension (PolyMap, I think is its name) which
may help you here - it allows you to enforce this invariant automatically
(and provides neater syntax for it). But I agree that for your case adding a
"find" method to a custom (i.e. copied) version of Set is probably the way
forward - I'm just not sure that you'll convince the guys at Inria to add
the method to the standard library's version of Set.Make!


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

[David Allsopp]

> > 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] Why don't you use batteries?

[David Allsopp]

Rakotomandimby Mihamina wrote:
> 09/04/2009 09:37 PM, Gaius Hammond:
> > I am after a language that has the rapid-development of Python or Tcl
> > but with type safety; OCaml is right now the best bet, but it is
> > *very* rough around the edges. The way you install ActivePython is you
> > download it and run the installer and a few minutes later you're ready
to go
> > with everything you need. I'm just reading the release notes for
Batteries
> > now and it starts, you will need .
> 
> I must insist on the fact this is probably specific to some OS.
> On debian and Ubuntu, adding one line to sources.list and issuing one
> command line does the trick.
> That is easy, espacially for those already using them.

Using a very simple analysis from
http://en.wikipedia.org/wiki/Usage_share_of_desktop_operating_systems,
97.14%[1] of the computers in the world run an OS which does not have a
"Linux"-style package manager (very sad, but true). Therefore a one-click
installer should be a higher priority than supporting package managers *if*
you want wider adoption of the system at all. Many developers will be using
Windows whether they want to or not (or OS X - though I apologise if OS X
does in fact have a package manager; please subtract 4.59% the previous
number if it does) because they'll be in companies whose IT infrastructure
is Windows, even if they have a few *nix boxes in the machine room "for
those weird developers".

I'm not sure that one is allowed to redistribute the Microsoft C compilers
directly without a license, but packaging MSYS or the relevant parts of
Cygwin along with OCaml and Batteries would create an installer somewhere
between 150-300MB which compared to the 16GB of trial software I downloaded
from the Microsoft website the other day is not that bad. You could even
throw an editor in with it. Microsoft Installer is a command line compiler
which reads text files so it can be targeted from make just like anything
else and the script would pretty much only have to be written once and then
someone would occasionally have to use a Windows box just to build it (and
virtualisation means you can pretend that your Linux PC isn't even running
Windows really). It would also not be too much work to have an MSVC version
which simply explained that you must install the Windows SDK to get the C
compiler (but, just like OCaml's own binary win32 files, you'd still get
bytecode for nothing).

Personally, I compile everything from sources with OCaml - but when I
started out with it (as an undergraduate) I used the mingw installer from
the OCaml website and was up and running in a matter of minutes. If I'd had
multi-step instructions to deal with at that point, I'd have probably ended
up sticking with Moscow ML! My point is that the one-click installer at the
start of the process allowed me to get hooked and then later, when the
benefits were very clear, I was happy to go down the slightly more complex
route of doing it properly. So, for example, once our
batteries-single-click-installer-beginners realise that OCaml is cool and
they want to use other libraries and tools as well then they may well
realise that Cygwin isn't that hard to install and so therefore
GODI-on-Windows isn't really that scary and so they can get Batteries and
lots of other goodies using that instead of the megalithic installer.

Also personally, when I come across a piece of software that offers a
live-CD or virtual appliance as a means of demonstration it makes me look
elsewhere as to me it implies that installation and maintenance is so
complicated that it's made the developers go to the trouble of building a
demo PC (albeit virtual!) just to guarantee that it works properly first
time... but that's probably "just me".

There's an old saying: "If you can't beat them, join them". Standing ranting
on a soap-box doesn't tend to achieve much... 

In vain hope of not starting a flame war,


David (who, by the way, is a realist rather than a Microsoft-apologist)




[1] 4 s.f. seems a tad optimistic on an estimate like that - but rounding to
the more sensible 1 s.f. would mean 100% which might be considered as
over-egging my point ;o) 

___
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] Windows Vista/7 specific functions

[David Allsopp]

Hi Reed,

 

Having hacked away with the Win64 port before I thought I’d 
have a go. The first thing I noticed is that Microsoft have finally released 
the x86 and x64 compilers in the same package (this was a pain if you wanted to 
build MSVC and MSVC64 ports as you needed two SDKs to do it...) – though I 
haven’t tried building the 32-bit MSVC port from this SDK yet.

 

Here’s what I did (you’ll have to excuse my idiosyncratic way 
of copying binary files into the OCaml tree – these can be replaced with PATH 
changes if you want. I copy things around so that ocamlopt always works without 
needing a special build environment or vast compiler suites permanently in my 
PATH).

 

The build is slightly complicated because you need to build 
flexdll directly. 

 

Make sure you have Cygwin base with with Devel\make and 
Devel\subversion added

 

I installed the Win7 SDK to C:\Dev\WinSDK (though it still 
irritatingly puts the compilers in C:\Program Files (x86)\Microsoft Visual 
Studio 9.0\VC). I didn’t bother installing Documentation, Samples or the IA64 
libraries.

 

Add the following to your LIB environment variable:

C:\Program Files (x86)\Microsoft Visual Studio 
9.0\VC\lib\amd64;C:\Dev\WinSDK\lib\x64

 

Add the following to your INCLUDE environment variable:

C:\Program Files (x86)\Microsoft Visual Studio 
9.0\vc\include;C:\Dev\WinSDK\Include

 

Set OCAMLLIB to C:\Dev\OCaml-MSVC64\lib

 

A whole load of files now get copied to C:\Dev\OCaml-MSVC64\bin:

From C:\Cygwin\bin, copy cygpath.exe and cygwin1.dll (needed by 
flexlink)

Extract flexdll.h, default.manifest and flexlink.exe from the 
flexdll 0.19 x86 binaries (latest flexlink tool – doesn’t need to be x64)

From C:\Program Files (x86)\Microsoft Visual 
Studio\9.0\VC\bin\amd64, copy:

1033\clui.dll (this needs to be in 
C:\Dev\OCaml-MSVC64\bin\1033)

ml64.exe, cl.exe, c1.dll, c2.dll, cvtres.exe, 
link.exe and mspdb80.dll

From C:\Dev\WinSDK\Bin\x64, copy mt.exe



Or workaround that stupidity by having C:\Cygwin\bin and the 
other directories in your PATH

 

Start Bash (possibly as Administrator depending on permissions 
set on C:\Dev)

I placed the ocaml 3.11.1 tarball in C:\Dev\Src-MSVC64

 

Note that the sed instruction not only sets PREFIX but it also 
removes bufferoverflowu.lib from EXTRALIBS – apparently this is no longer 
needed in this version of the SDK (presumably the compiler has started to 
include all the required support natively or perhaps the runtime now has it).

 

$ cd /cygdrive/c/Dev/Src-MSVC64

$ svn co svn://frisch.fr/flexdll/trunk flexdll-dev

$ cd flexdll-dev

$ make CHAINS=msvc flexdll_msvc.obj flexdll_initer_msvc.obj

$ cp *.obj /cygdrive/c/Dev/OCaml-MSVC64/bin

$ cd ..

$ tar -xzf ocaml-3.11.tar.gz

$ cd ocaml-3.11

$ cp config/m-nt.h config/m.h

$ cp config/s-nt.h config/s.h

$ sed -e '20s/=.*$/=C:\/Dev\/OCaml-MSVC64/' -e '92s/=.*/=/' 
config/Makefile.msvc64 > config/Makefile

$ make -f Makefile.nt world opt opt.opt install

 

And you should have a fully working MSVC64 build with the Win7 
SDK Compilers (and therefore be able to link against the newer libraries). If 
you wish, quite reasonably, to be a purist and have everything 64-bit you can 
now go back to flexdll-dev and say:

 

$ sed -i -e 's/"afxres.h"//' version.rc

$ rc version.rc

$ cvtres /nologo /machine:amd64 /out:version_res.obj version.res

$ make version.ml

$ ocamlopt -o flexlink.exe -ccopt "-link version_res.obj" 
version.ml coff.ml cmdline.ml create_dll.ml reloc.ml

$ cp flexlink.exe /cygdrive/c/Dev/OCaml-MSVC64/bin

 

And you’ll have flexlink.exe as a 64-bit executable as well.

 

Best,

 

 

David

 

 

From: caml-list-boun...@yquem.inria.fr 
[mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of Reed Wilson
Sent: 02 September 2009 05:44
To: caml-list@yquem.inria.fr
Subject: [Caml-list] Windows Vista/7 specific functions

 

Hi all,

 

I am going to be writing a native-code 64-bit program which takes advantage of 
some Windows Vista-only features (transactional NTFS), and I was wondering how 
to get it working in OCaml. I have made numerous interfaces to Windows XP 
functions, but the problem is that the NTFS transactional functions are only 
available through MSVS 2008 and the Vista/7 SDKs, which OCaml seems to n

RE: [Caml-list] lazy vs fun

[David Allsopp]

ri...@happyleptic.org wrote:
> > Oops.
> > The following makes it possible for f to be garbage-collected:
> 
> ...?
> Because the fact that the fun calls f does not count as a reference ?

The anonymous function in the second version of Martin's function doesn't
"call" [f] (at least directly): imagine if the `None case had been written
with [g]s instead:

let lz f =
  let result = ref (`None f) in
  fun () ->
match !result with
`None g ->
  (try
 let y = g () in
 result := `Result y;
 y
   with e ->
 result := `Exn e;
 raise e
  )
  | `Result y -> y
  | `Exn e -> raise e

The [fun] only "calls" (uses) [result]. In the first version, [f] could only
be collected after the [fun] had been collected (i.e. when the lazy value
itself is collected - not good). In the second version, [f] can be garbage
collected if the lazy value has already been forced (meaning that "[result =
`Result y | `Exn e]" so there will be no more references to [f]) - a clear
optimisation with no performance penalty in terms of space. 

The optimisation would be irrelevant if the ocaml compiler was lazy and just
included all of the scope in the closure for [fun], but minimising (and
eliminating, where possible) closures is a critical part of ML compilers
(I'd be amazed if it's not covered in all of the books you've mentioned
previously and I wish I could remember the name usually given to the
problem... but I'm sure someone will chip in with it!)


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] Re: ocaml sefault in bytecode: unanswered questions

[David Allsopp]

Ivan Chollet wrote:
> See the following snippet:
>
> # let q = Queue.create () in
>  Queue.push 0 q;
>  q == q;;
> - : bool = true
>
> Standard behavior.
> Now let see this:
>
> # let q = Queue.create () in
>  Queue.push 0 q;
>  q = q;;
>  
>  which hangs for ever...

Internally, Queues are a cyclic data structure (see stdlib/queue.ml in the
sources). The documentation for Pervasives.(=) notes "Equality between
cyclic data structures may not terminate". If you want to compare two queues
for structural equality you'd have to fold the two Queues to a list and then
compare those. Perhaps a Queue isn't the most appropriate data structure for
what you're doing, therefore (functional queues wouldn't suffer from this
problem but note that their performance characteristic is subtly different
from an imperative queue)? Alternatively, if Queue.compare would be a handy
function, you could try raising a feature-request for it in Mantis.

> I would have thought physical equality implies structural equality, but it
doesn't seem like it.
> Can you please explain to me what’s wrong there?

"It does" - but only with the given caveat that comparison of cyclic
structures may not terminate. Pervasives.compare has a similar restriction,
although note that [compare q q] in your example does return 0 (which is
lucky or it would be a bug as the docs for Pervasives.(==) state that [x ==
y] => [compare x y = 0]).

The notes in http://caml.inria.fr/mantis/view.php?id=3322 may be of interest
too...
 


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] Re: ocaml sefault in bytecode: unanswered questions

[David Allsopp]

When you pass a value to a function, you create a pointer to that value in
the OCaml runtime - the GC can't collect the old value until List.iter
completes because the value is still live (internally, it's part of a local
root but, in practice, as List.iter is implemented in OCaml directly it's
because an OCaml function parameter references the value). Note that in this
example:

 

let a = [1; 2; 3]

and b = [4; 5; 6]

and c = [7; 8; 9] in

let myref = ref a in

(* No allocations are done after here *)

  myref := a;

  myref := b;

  myref := c;;

 

the assignments to [myref] do not result in any memory being allocated at
all (my point is that action of assigning to a reference does not implicitly
result in an allocation).

 

 

David

 

From: caml-list-boun...@yquem.inria.fr
[mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of ivan chollet
Sent: 08 August 2009 18:10
To: ivan.chol...@free.fr
Cc: caml-list@yquem.inria.fr
Subject: [Caml-list] Re: ocaml sefault in bytecode: unanswered questions

 

Yes it was a freebsd 6.4 with ocaml 3.10.2

I'll run the program on linux later and see how it goes.

 

Thanks for your advices regarding debugging. I pretty much tried all of
these though. the thing is my error is not an ocaml error at runtime but an
error of the ocaml runtime. And to analyze a core dump of ocamlrun, I just
thought my best bet was gdb. Whatever.

 

OK I'll try to provide you with a minimal ocaml code that produce an
ocamlrun error. Might take a little while as I'm not free.

In the meantime, I've got a newbie question regarding ocaml garbage
collector and the same List.iter stuff:

Say you do a "List.iter myfun !myref", where !myref is a list (hehe.), and
where myfun is a function that does reallocations of myref (that is
affectations like myref := [some new or old objects]). The pointers myref
that are generated through this process are destroyed each time a new
reallocation of myref is done. Of course the underlying linked lists that
are not referenced anymore shouldn't be collected by the GC before the end
of the main "List.iter", otherwise it's iterating through a linked list that
has been garbage collected.

My question is: does the GC know that it cannot collect the unreferenced
myref pointers before the end of the List.iter? 

Sorry, I just wanted to ask this question to rule it out.

 

Thanks again.

 

 

 

 

On 07-08-2009, ivan chollet  wrote:

> 

> This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols

> found)...

> 

> Not very informative. So here are my questions:

 

I suppose you are running freebsd ? Which version of freebsd, of ocaml ? 

 

> 

>  

> 

> -  What is the best way to produce and analyze core dumps in
ocaml?

> Should I compile in bytecode or native? Is there any special gdb "trick"

> that gives you more information? Is there any special "trick" while

> compiling the ocaml runtime to make it throw more information?

> 

 

gdb is not the perfect tool to debug ocaml program. You should give a

try to ocamldebug which is a better option for bytecode (see below for

options). Bytecode is more informative when coming to reporting

backtrace (at least with old version of ocaml). 

 

Compile every program with "-g" option (just like gcc). 

 

If you have compiled everything with "-g" option, you can also use the

environment variable OCAMLRUNPARAM="b" to get a backtrace for your

exception, at runtime.

 

> -  Then, my main question is actually: in bytecode, what can
produce

> segfaults? My ocaml code is completely standard, excepted that I use the

> Marshal module. So my question is rather: outside the Marshal module, what

> can cause segfault?

 

Some part of the bytecode are just standard C, everything can cause a

segfault just as C. These errors are not very common but it is possible

that some case are not well handled on freebsd. Most probably a porting

issue.

 

Marshal module can easily trigger a segfault when you map the loaded data

to a type which doesn't match the dumped data.

 

Example: 

List.length (Marshal.from_string (Marshal.to_string 1234 []) 0);;

 

Here the integer value is marshalled and then unmarshalled as a list ->

segfault.

 

> 

> -  Slightly unrelated question: I have been able to generate

> segfaults by running ocaml code that: 1) iterates recursively through a
list

> reference 2) changes the reference while still iterating on it. For
example,

> you just do a "List.iter myfun !myref", and within the function myfun, you

> do stuff like "myref := List.filter somefilterfunction !myref". It is not

> good to program like this, but for some reason I thought ocaml would not

> segfault on that. Is this expected behavior? If it's not, I'll be happy to

> provide some simple source code that illustrates it. (nevermind I have

> actually cleaned all my code base from these dirty uses of references)

> 

 

Could you provide a minimal example code for this error ? I don't thi

RE: [Caml-list] ocaml sefault in bytecode: unanswered questions

[David Allsopp]

Apologies if I'm missing something obvious (I had a good lunch)...

Ivan Chollet wrote:
> Yes, makes sense. But it would mean that "List.iter myfun !myref" is
> not semantically equivalent to "List.iter myfun (let l=!myref in l)",

How does this follow from Edgar's explanation? (below)

> therefore the expressions "let l=!myref in l" and "!myref" are not
> semantically equivalent.

These expressions are semantically equivalent: the former merely (locally) 
aliases the name [l] to the result [!myref] before returning it. Aliasing a 
value is not the same as allocating memory. For example:

let a = "1" in
let b = a;;

Results in one allocation (a value containing the string "1") and one aliasing 
of the name [b] to represent the same value.

So, considering your example, observe:

let myref = ref [1; 2] in
let l = !myref in
l == !myref;;

which is [true]. [l] and [!myref] are physically the same value - i.e. the [let 
l] expression did not result in an allocation.

Ivan Chollet previously wrote:
> Why? It would mean that doing "let l = !myref" creates a brand new OCaml 
> entity, l, ie a brand new 
> allocation on the heap, and then, messing around with !myref inside myfun 
> would be of course 100% safe. 

Two problems: firstly, let l = !myref does not result in an allocation (because 
[l] is simply an alias for the contents of myref at the time of the [let]). 
Secondly, you cannot mess around with !myref - the content of a reference is 
immutable, it is only the reference itself which can be changed 
(notwithstanding 'a ref ref and so on). Once you said [List.iter myfun !myref], 
you pass the contents of [myref] to [List.iter] and [myfun] can do whatever it 
likes with the *reference* [myref] without affecting those contents at that 
point and so the processing of [List.iter].

Do you have an actual case which segfaults?

HTH,


David 

> 
> That would be very strange!
> 
> 
> -Original Message-
> From: Edgar Friendly [mailto:thelema...@gmail.com]
> Sent: samedi 8 août 2009 15:29
> To: ivan chollet
> Cc: 'Cedric Auger'; caml-list@yquem.inria.fr
> Subject: Re: [Caml-list] ocaml sefault in bytecode: unanswered
> questions
> 
> ivan chollet wrote:
> > You basically state that stuff like “let l = !myref in List.iter
> myfun l”
> > (where myfun modifies !myref) wouldn't produce segfault.
> > Why? It would mean that doing "let l = !myref" creates a brand new
> OCaml
> > entity, l, ie a brand new allocation on the heap, and then, messing
> around
> > with !myref inside myfun would be of course 100% safe. Is that what
> OCaml
> > runtime does?
> 
> when you have [myref : list ref = ref [1;2]], this is in memory as:
> 
> myref -> {contents: _a}
> _a -> (1,_b)
> _b -> (2,0)
> 
> I've given names to the intermediate pointers -- the notation above
> shows names as pointers to data structures.  [myref] is a pointer to a
> record, whose contents point to the head of the list [1;2].  So there's
> already two levels of indirection.
> 
> When you do [let l = !myref], [l] gets assigned [_a], so it points to
> the head of the list.  List.iter traverses the list not even knowing
> that [myref] exists, so if the function [myfun] modifies [myref], it
> won't affect List.iter.
> 
> Does this make sense?
> 
> 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

___
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] windows, threads and sockets

[David Allsopp]

Christoph Bauer wrote:

> I'm not quite sure what is going on, but my best bet is this: the main
> loop waits for the sockets with
> 
> Unix.select listOfSockets [] [] timeout
> 
> One socket is the listener socket on which new connections
> are made. Unix.select returns a list of sockets. Initially
> it must be the listener socket. This is checked with a compare
> 
>   socket = listenSocket
> 
> and this seems to be suddenly wrong (just in the thread case).
> 
> Any ideas?

I can't tell you explicitly why it has failed, but Unix.select was
completely rewritten for OCaml 3.11.0 based on a big contribution from
Sylvain Le Gall (see otherlibs/win32unix/select.c). The principal aim was to
make the semantics of Unix.select the same between *NIX and Windows so if it
works on Linux then it sounds like you've hit a bug...


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] Callbacks from C to OCaml

[David Allsopp]

ygrek wrote:
> On Fri, 10 Jul 2009 12:16:17 +0100
> "David Allsopp"  wrote:
> 
> > Now, at any time, the SCM may invoke the ServiceCtrlHandler function
> > registered with it. This also needs to callback to an OCaml function
> > to work out what to do (the closure was registered in the initial call).
> >
> > What happens at this point with regard to OCaml's global lock and
> > being in the correct threading context? I must confess that I don't
> > fully understand how the callback works at all in the single-threaded
> > context - presumably when SCM calls the function, it simply executes
> > code in its own thread context (so it can presumably introduce a form
> > of multi-threading to a program which isn't expecting it?).
> 
> Yes, SCM creates new thread for the callback.

That's handy to know - I was going to do some further experimentation in C
to check that so that hassle is saved, thanks!

> And this thread is not registered with OCaml runtime, and so you can't
> do any allocation on it. I used windows services in the same setup and
> just set a boolean flag when SCM signalled service to stop, while
> periodically checking this flag in ocaml thread..

Following this, and an off-list exchange with Philippe Wang, I'd arrived at
the same conclusion. I'd tried to model the whole procedure essentially on
how'd you'd write it in C with callbacks and that was clearly the wrong
decision!

> See also http://caml.inria.fr/mantis/view.php?id=4702

Presumably if this patch is eventually incorporated, that would allow the C
version of ServiceCtrlHandler to register its thread with the OCaml runtime
and therefore safely callback into OCaml code? I shall watch the issue -
although having to create a couple of message-passing helper threads to
accomplish this task is hardly going to slow anything down.

> Hope it helps.

Thank you! It's good to know for definite that I've been barking up the
wrong tree - especially as it tantalising almost worked.


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

[Caml-list] Callbacks from C to OCaml

[David Allsopp]

I'm having some trouble with a library wrapping Windows Services - I'm
wondering if anyone can shed some light on possible pitfalls with the
mechanism for C callbacks while I continue to scratch my head! Although my
problem is with a Windows-based solution my overall question is about
C-callbacks interacting with OCaml so please don't be put off by the Win32
aspect of it :o)

The overall layout is this: the main program is OCaml (i.e. it's an OCaml
program using C-stubs rather than a C-program calling OCaml). The flow of
execution is as follows:

The OCaml program invokes a C-stub which calls the Win32 API function
StartServiceCtrlDespatcher which, amongst other things, takes a pointer to a
C function called ServiceMain. This pointer will be invoked during
StartServiceCtrlDespatcher (synchronously - StartServiceCtrlDespatcher does
not return until the service is stopped) and carries out the following
tasks:

1. It registers a C function with the Windows Service Control Manager (SCM)
called ServiceCtrlHandler which the SCM may callback to *at any time*
2. It does some housekeeping to initialise the service which includes a
call-back to an OCaml function registered by the initial C-stub
3. Assuming success, a call-back is made to another OCaml function. This may
block or it may return immediately.
4. ServiceMain then waits on an event which will only be signalled when the
SCM instructs the service to stop (because ServiceMain is not supposed to
terminate until instructed to). The call to this code is wrapped with
caml_enter_blocking_section and caml_leave_blocking_section (but note that a
particular service may choose to block in the OCaml-land function called in
step 3 instead - the event is just in place to ensure that this is the case)

Now, at any time, the SCM may invoke the ServiceCtrlHandler function
registered with it. This also needs to callback to an OCaml function to work
out what to do (the closure was registered in the initial call).

What happens at this point with regard to OCaml's global lock and being in
the correct threading context? I must confess that I don't fully understand
how the callback works at all in the single-threaded context - presumably
when SCM calls the function, it simply executes code in its own thread
context (so it can presumably introduce a form of multi-threading to a
program which isn't expecting it?).

Should ServiceCtrlHandler (which is only ever invoked from Windows - i.e.
from C-land) be wrapped in the reverse of a blocking construct... i.e.

void WINAPI ServiceCtrlHandler(DWORD Opcode) {
  CAMLparam0(); // The function does allocate...

  caml_leave_blocking_section();

  /* code including caml_callback and caml_alloc_tuple calls */

  caml_enter_blocking_section();

  CAMLreturn0();
}

Can the *_blocking_section functions be used in this way or is there
something else which should be done? My current implementation is flaky - it
works for some services and not for others (and it's very unreliable when
compiled with threading enabled - my current implementation actually cheats
and provides a single-threaded stub application which communicates with a
threaded application via standard input and output to avoid this problem)
which leads to me think that the services which work are probably lucky on
the allocation front and so get away with it and the others essentially
corrupt the runtime and segfault.

Any pointers much appreciated - the manual on C stubs doesn't even mention
the caml_enter_blocking_section/caml_leave_blocking_section functions so
it's sort of a difficult area on which to get information. I'm at this stage
definitely more convinced that it's an error somewhere in my code rather
than the OCaml runtime :o)

Are there any other libraries which contains C stubs handling callbacks in a
similar fashion which I could look at?

Many thanks,


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] ocamlgraph

[David Allsopp]

You need to say

 

#directory "ocamlgraph";;

 

Before you #use your file so that the toploop can find graph.cmi

 

 

David

 

From: caml-list-boun...@yquem.inria.fr
[mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of Ligia Nistor
Sent: 25 June 2009 18:00
To: caml-list@yquem.inria.fr
Subject: [Caml-list] ocamlgraph

 

Hi,

I am trying to use ocamlgraph, but I am getting the  error "Unbound module
Graph". I have the file demo.ml  (from the site
http://ocamlgraph.lri.fr/) which contains the line "open Graph". I write in
the interpreter "#load ocamlgraph/graph.cmo" and it finds it. But then when
I write #use "demo.ml  ", I get the above error. 

I copied the content of the folder \usr\lib\ocaml\3.10.2\ocamlgraph  (which
includes the graph files) to \usr\lib\ocaml\3.10.2\ ,where all the other
implemented modules are( such as List, Printf).After I did this, the error
"unbound module Graph" disappeared. But I want to leave the graph files in
the folder usr\lib\ocaml\3.10.2\ocamlgraph  and show to the interpreter
where to find Graph module.

How can I do this?

Thanks,
Ligia

___
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] Width subtyping

[David Allsopp]

Dario Teixeira wrote:
> Thanks -- that is also an interesting solution.  I'm guessing it will
> be faster, though it might consume more memory in cases where only one
> field is actually used.  I'll have to try it side-by-side with the
> object based solution to see how they compare in the real world with my
actual
> problem..

So as I wouldn't immediately be told "the overhead is irrelevant", I ran a
"quick" benchmark before my last post. I compared summing 7 million
3-int-field records and 7 million 3-int-field objects using names a, b, c.
On my machine, averaged out and with enough RAM that neither paging nor the
GC get in the way, objects were nearly 3 times slower. I then tried with
10-int-field records and objects - in this case, objects were just over 4
times slower (read on). This was in bytecode - I didn't bother with native
code.


> 
> Which might turn out to be not that big a deal.  After all, the object
> based solution also adds some default overhead per object created,
> right?

The overhead of an object is 2 words (one contains tracking information
about the actual class of the object and the other is a unique identifier) +
(I think) 1 extra word for every field (because each int is boxed in a
1-tuple so that its tag can be recorded). Importantly, accessing fields in a
record is an O(1) operation but for objects it's O(log n) for the number of
fields because a binary search is done to locate the field with the correct
tag. ocamlopt may of course optimise this search by caching the absolute
index of the field in a "recognised" object layout; I didn't look in the
compiler. My test between 3 and 10 fields would suggest that this
optimisation does not apply in bytecode.


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

[Caml-list] OCaml MinGW 64-bit Port

[David Allsopp]

Has anyone had a go at building OCaml using the 64-bit beta of the MSYS
tools[1]?


David

[1] http://sourceforge.net/projects/mingw-w64/

___
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] Width subtyping

[David Allsopp]

> Dario Teixeira wrote:
> > You are right.  I was probably too fixated on the OOP way of doing this,
> > translating record fields into object fields and the functions acting on
> > records into object methods.  Your solution, where record fields become 
> > object
> > methods and external functions act on objects that match a certain 
> > structure,
> > does solve the inconveniences I mentioned before.  But objects are still
> > a somewhat heavier solution, right?
> 
> Heavier in terms of efficiency, or syntax?

My concern is the former. The extra two fields per "record" and the heavier 
runtime calls make them so systemically slower that (to me, at least) it just 
feels "wrong" to use objects just to achieve a little syntactic clarity and a 
small reduction in the amount of code written. Polymorphic variants (which use 
only slightly more memory than regular variant values) otherwise perform at the 
same speed as their normal counterparts.


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] Width subtyping

[David Allsopp]

> Though it is probably been-there-done-that material for the veterans in
> this list, for the sake of the not-so-veterans I have to ask: how do you guys
> typically model width subtyping in Ocaml?

Definitely not a veteran, but might private types help a little?

> Consider for example three record types that share some of their fields:
> 
> type t1 = {a: int; b: int; c: int;}
> type t2 = {a: int; b: int; c: int; d: int;}
> type t3 = {b: int; c: int; d: int;}

Modelled as...

module M : sig
  type t' = {a: int; b: int; c: int; d: int}
  type t = private T1 of t' | T2 of t' | T3 of t'
  val makeT1 : int -> int -> int -> t
  val makeT2 : int -> int -> int -> int -> t
  val makeT3 : int -> int -> int -> t
end = struct
  type t' = {a: int; b: int; c: int; d: int}

  type t = T1 of t' | T2 of t' | T3 of t'

  let makeT1 a b c = T1 {a = a; b = b; c = c; d = 0}
  let makeT2 a b c d = T2 {a = a; b = b; c = c; d = d}
  let makeT3 b c d = T3 {a = 0; b = b; c = c; d = d}
end

This way you're always dealing with the same product type, but the sum type 
tells you which fields are actually valid. Of course, it relies on there being 
an obvious sentinel value for unused fields (otherwise you just end up with 'a 
option everywhere) and I still don't think it's that neat as you can still 
match against fields which aren't valid but at least the type system prevents 
you from being handed an illegal value. The benefit is that you don't need 
special "get" functions (just a match on type t to extract the t' value from 
each constructor). I can't get my head around how private polymorphic variants 
work to see if they can refine this further...


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] findlib with MinGW

[David Allsopp]

I built OCaml 3.11.0/MinGW with findlib on Windows 7 RC a few days ago. I
found that while my Cygwin installer doesn't install its own OCaml on
Windows Vista by default, for some reason on Windows 7 it installs loads
more software in the default install!

Is Cygwin's OCaml definitely not installed?


David 

> -Original Message-
> From: caml-list-boun...@yquem.inria.fr [mailto:caml-list-
> boun...@yquem.inria.fr] On Behalf Of Paul Steckler
> Sent: 19 May 2009 09:29
> To: caml-list@yquem.inria.fr
> Subject: [Caml-list] findlib with MinGW
> 
> Does anyone have clear instructions on how to build
> findlib with the MinGW port of OCaml?
> 
> For me, the `configure' script with the option `-system mingw'
> fails when it tries to build tools/extract_args.  I'm using the Windows
> 7
> RC.
> 
> -- Paul
> --
> Paul Steckler
> National ICT Australia
> paul DOT steckler AT nicta.com.au
> ___
> Caml-list mailing list. Subscription management:
> http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
> Archives: http://caml.inria.fr
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Call for translators of the Unix system programming course

[David Allsopp]

Mihamina Rakotomandimby wrote:
> I am volunteer to be reviewer.
> However, I think it should not be a criteria to be a mother tongue
> english for many reason: "Non mother tongue english" people use 
> "simple" english and does not understand very advanced english.
> Mother tongue english are tempted to fully use english.
> I think a reviewer with just basic english would be "very good"...

A technical text written in "advanced" English reads badly to a
native-English speaker as well - complex English constructions belong in
novels! Good reviewing, by either a native or non-native English speaker,
should simplify grammar and vocabulary where necessary anyway. Given
Xavier's (and presumably Didier's) level of English, I think it would be a
terrible disservice to produce an English translation containing bad
grammar.

Loup Vaillant wrote:
> I think *accurate* English is more difficult for a non native than
> *basic* English is for a native, hence their preference. As an
> anecdotal evidence, the easiest papers I've read on functional
> programming happen to be written by native English speakers (I'm
> french).
>
> Moreover, a good translation should also translate the tone of the
> authors. Any distortion would be very difficult to recover from. It
> may even be important to choose between British and American, and be
> consistent with that choice. I consider myself fluent, yet *this* is
> completely out of my reach.

Given that both of the authors of the original text speak fluent English,
might it be easiest just to ask them to read and comment on the reviewed
translation?


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] Re: Ocamlopt code generator question

[David Allsopp]

Sylvain Le Gall wrote:
> Maybe this point can be discussed. I think 3 ports for windows is a bit
> too much... I don't know Dimitry point of view, but maybe INRIA can
> just consider MSVC (or mingw). If this is a way to free INRIA resources,
it
> is a good option.

There are actually 4 Windows ports if you include MSVC64! I'm not sure at
this stage that it's possible to reduce the number - I think you'll find
that there are enough users on both sides with enough
hard/impossible-to-work-around requirements (probably to do with external
libraries) such that you'd never be able to decide between just MinGW or
just MSVC. The Cygwin port, although obviously requiring extra work and
support, is more like supporting a separate flavour of UNIX than a separate
Windows port, I think.

> I would like to say "go on", but SSE2 will limit OCaml to P4 on i386.
> In Debian, this is the "low limit" of our build daemon. I think it is
> quite dangerous not having the option of the older code generator...

+1 I've still got a few quite useable Pentium 3 machines knocking around...
it would seem a shame if a lack of compiler rather than OS support ever
caused them to be retired. That said, the power and noise will probably be
what retires them first...



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] Building pcre-ocaml on OCaml 3.11.0 on MinGW

[David Allsopp]

> Hi David,
> 
> David Allsopp wrote:
> > I've just had an enlightening few hours getting pcre-ocaml to compile
> under
> > Windows
>  >...
> > The main thing that's got me puzzled is the renaming of libpcre.dll.a
> and
> > libpcre.a that I have to do to get the thing to link.
> 
> Thanks for investigating this issue!  The current SVN version of
> flexlink prefers XXX.dll.a over XXX.a.  We will see whether it solves
> more problems than it creates...  Of course, it is always possible to
> pass explicitly the complete file name instead of -lXXX.

Marvellous - I'll have a play when I have a spare minute 

> To build and use ocaml-pcre, I've had to remove the "-I /usr/include"
> from this line in OCamlMakefile:
> 
>CFLAGS_WIN32 := -mno-cygwin -I /usr/include
> Otherwise, Cygwin's headers are used instead of mingw's ones (in
> /usr/include/mingw), and we get a dependency e.g. to the Cygwin symbol
> _ctype_ which is not available on mingw. Have you had to do something
> similar?

I last built with 5.15.1 which didn't have this line (just -mno-cygwin) but
I see that I'm behind (and Gerd's confirmed the problem, anyhow...)


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] Threads?

[David Allsopp]

> It's been about 5 years since I faced this situation. I'm trying to link
my program against the Thread module. Things go well until I do the ocamlopt
compilation, then it aborts the make with the message:
>
> ocamlfind ocamlopt -thread -o sdsp.opt   -package camlp4 -package threads
-package unix -I ../src -I /usr/local/lib/ocaml/threads  \
>   -thread -cclib threads.a  nums.cmxa sdsp.cmxa threads/threads.cmxa  
\
>   readline.cmx scmMain.cmx 

You're missing -linkpkg. It looks like your command should be

ocamlfind ocamlopt -thread -o sdsp.opt -package camlp4,threads,unix,num
-linkpkg -I ../src sdsp.cmxa readline.cmx scmMain.cmx

Notes:
-I /usr/local/lib/ocaml/threads ==> will be added by ocamlfind
-cclib threads.a ==> I think will be added automatically by
threads.cmxa
nums.cmxa ==> is better included by having num in your list of
findlib packages
threads/threads.cmxa ==> will be included by ocamlfind (when
-linkpkg is given and -package threads)

AFAIK, ocamlfind always puts libraries first when linking (and they will be
in the correct order because findlib understands inter-library
dependencies).

Incidentally, when hitting problems like this with ocamlfind, passing
-verbose is really useful - because it causes ocamlfind (as well as
ocamlopt) to display precise information on what's being called so you can
diagnose the problem. When using ocamlfind, you should never have to use -I
or specify the name of a .cmxa/.cma file (if it's part of a findlib package)

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] pattern matching and records vs tuples

[David Allsopp]

Goswin von Brederlow wrote: 
> I would actually like to propose that to work on a type
> level. Currently we have:
> 
> I propose that records can be subtyped if their prefix matches and
> ".." would be used to denote the subtype of any record with this
> prefix:
> 

> One could also declare get_x to accept supertypes:
> 
> # let get_x (r : { x : int; .. }) = r.x;
> val get_x : { x : int; .. } -> int = 
> 
> # get_x { x=1; y=2; };;
> - : int = 1

Bear in mind that for this work the label must be at the same ordinal
position within both record types for this to work (which I think could
potentially be irritating). For example, given:

# type base = { x : int }
  let get_x r = r.x
  type more = { y : int; x : int };;

# get_x ({ y=2; x=1; } :> base);;

You would have to get a type coercion error message.

> I think there is only one thing that would need to be changed for the
> compiled code with record subtypes like the above. Copying and
> modifying a record would need allocate a block matching the size of
> the input record and not the size of the subtype. Think about this
> code:
> 
> # let change_x (r : { x : int; .. }) x = { r with x = x }
> val change_x : { x : int; .. } as 'a -> int -> 'a = 
> # change_x { x=1; y=2; } 2;;
> - : more = {x = 2; y = 2}

I imagine that it's a reasonably rare thing to do, but any C bindings which
manipulate record types in this way would break (and probably segfault the
runtime) if this behaviour were required. The other worry in the back of my
mind is that despite having considerably more flexible records in SML (you
don't have to declare the types in advance and label sharing is possible), a
function in SML still has the restriction of only being over a fixed record
type ... and when SML has odd restrictions, they're usually to do with the
more "obvious" type system feature being undecideable. For example, you
can't say in SML:

fun get_x r = #x r;

as the equivalent of the OCaml get_x you propose.


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

[Caml-list] Using Dynlink in the top level

[David Allsopp]

Is there any way to allow modules loaded with Dynlink in the top-level to
have access to modules loaded using #load?

For example, suppose I have bar.cmo which depends on foo.cmo. If I say:

Objective Caml version 3.11.0
# #load "dynlink.cma";;
# #load "foo.cmo";;
# Dynlink.openfile "bar.cmo";;

then I get:

Exception:
Dynlink.Error
 (Dynlink.Linking_error ("bar.cma", Dynlink.Undefined_global "Foo")).

I can work around this by either:

a) Using Dynlink.openfile instead of #load to load foo.cmo
b) Using ocamlmktop and pre-linking foo.cmo into a new top-level

Method a) would be fine except that Dynlink cannot load libraries like
unix.cma so ocamlmktop becomes the only (slightly tedious) alternative if
libs like unix.cma is required. Presumably the code for the top-level uses
for #load and Dynlink must be almost the same thing so it seems long-winded
to have use ocamlmktop all the time...


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] RE: flexlink + lacaml (lapack)

[David Allsopp]

Bertrand Desmons wrote: 
> I followed your trick and now compilation is OK.

Excellent - good to know that the trick is consistent for other libraries
too!

> Just a remark however (maybe it's the key for the porblem): when
> renaming
> the old 'liblapack.a', Windows asked me a confirmation, arguing that
> the
> file is a system file.

I don't think it is - I think it's to do with abstractions in libtool. Try
resetting the permissions on the files in C:\cygwin\lib using Windows
Explorer (though note that may upset Cygwin!!!).

I expect that problem with your .a files is Cygwin's interaction with NTFS
permissions - if you only use Cygwin to build OCaml and related things then
I'd suggest having the environment variable CYGWIN=nontsec set (which,
counter-intuitively, means "use NT native file permissions instead of
POSIX-over-NTFS"). I expect that your installation of the libraries
inherited weird permissions when you installed them because Cygwin by
default emulates Unix's user-group-other permissions rather than NT's
inherited ACLs which is fine if you spend your entire life in Cygwin's bash
but is a pain if you use Windows on the same files as well (it's OK under XP
but under Vista manipulation of any files touched by Cygwin becomes
virtually impossible owing, admittedly, to clear bugs in Vista's crappy
explorer making any operations hideously slow...)


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] (no subject)

[David Allsopp]

Alain Frisch wrote:
> DESMONS Bertrand wrote:
> > It is really strange for me... 'ls' recognizes liblapack.a, but I
> don't
> > see it using 'dir' ... ? There is also no liblapack.a.lnk, but isn't
> that
> > due to the fact that liblapack.a is a symbolic link?

Try dir /a - perhaps the attributes on the .lnk file are weird... which
might also be the cause of the problem if it's got hidden or system
attributes set for some reason.
 
> As far as I understand Cygwin, if liblapack.a is a Cygwin symlink,
> there
> should really be a file liblapack.a.lnk in the directory. I don't
> understand what is going on.
> 
> -- Alain

Could be a longshot - but might this be related to an issue I reported
building MinGW PCRE a month or so ago. In order to get PCRE to link, I had
to rename the actual libpcre.a to libpcre.a.old (i.e. get rid of it) and
then rename libpcre.dll.a to libpcre.a. I can't remember what the error
message was.

I think that the problem is something to do with GNU libtool - which gcc's
linker presumably understands but flexlink doesn't... but I didn't get a
related answer to
http://groups.google.com/group/fa.caml/browse_thread/thread/e9ff1f8ef73181d0
?pli=1



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

[Caml-list] Using camlp4 syntax extensions in the top-level

[David Allsopp]

I'm trying to use json-static in the toplevel (OCaml 3.11.0 / MinGW /
findlib 1.2.4) but I'm getting an error message:

# #camlp4o;;
C:\Dev\OCaml\lib\dynlink.cma: loaded
C:\Dev\OCaml\lib\camlp4: added to search path
C:\Dev\OCaml\lib\camlp4\camlp4o.cma: loaded
Camlp4 Parsing version 3.11.0

# #require "json-static";;
c:\Dev\OCaml\lib\site-lib\pcre: added to search path
c:\Dev\OCaml\lib\site-lib\pcre\pcre.cma: loaded
c:\Dev\OCaml\lib\site-lib\netsys: added to search path
c:\Dev\OCaml\lib\site-lib\netsys\netsys.cma: loaded
c:\Dev\OCaml\lib\site-lib\netstring: added to search path
c:\Dev\OCaml\lib\site-lib\netstring\netstring.cma: loaded
c:\Dev\OCaml\lib\site-lib\netstring\netstring_top.cmo: loaded
c:\Dev\OCaml\lib\site-lib\netstring\netaccel.cma: loaded
c:\Dev\OCaml\lib\site-lib\netstring\netaccel_link.cmo: loaded
c:\Dev\OCaml\lib\site-lib\json-wheel: added to search path
c:\Dev\OCaml\lib\site-lib\json-wheel\jsonwheel.cma: loaded
c:\Dev\OCaml\lib\site-lib\json-static: added to search path
c:\Dev\OCaml\lib\site-lib\json-static\pa_json_static.cmo: loaded
# type json point = < x: number; y: number >
  and coords = point array;;
Assertion failed, file "camlp4/Camlp4/Struct/Camlp4Ast2OCamlAst.ml", line
795, char 11

I can build the example using ocamlc with no problems - I just don't seem to
be able to do it interactively in the toplevel. Should I be able to?

TIA,


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

[Caml-list] Building pcre-ocaml on OCaml 3.11.0 on MinGW

[David Allsopp]

I've just had an enlightening few hours getting pcre-ocaml to compile under
Windows (I tried a few years ago and, very lazily, just gave up). I've
managed to get it to work but I'm wondering whether anyone else has done
this and, if so, whether they can explain/confirm/correct a couple of the
steps involved. I'm very much indebted to Alain Frisch's instructions for
building PCRE under OCaml 3.10.0 which are part of the CDuce distribution or
I would've been completely at sea with this!

The main thing that's got me puzzled is the renaming of libpcre.dll.a and
libpcre.a that I have to do to get the thing to link.

Note that I'm building the "official" way - so MinGW running within Cygwin.


+++
Building pcre for MinGW
  (Ensure that Cygwin's PCRE libraries are *not* installed)
  Unpacked PCRE 7.8
  ./configure --prefix="C:/Dev/OCaml" \  # set to install PCRE
  --includedir="C:/Dev/OCaml/lib" \  # to my OCaml tree.
  --disable-cpp \# from Alain's
instructions.
  --enable-utf8 \# Similarly.
  --build=mingw32 \  # MinGW, not Cygwin build
  CC="gcc -mno-cygwin"   # Necessary to ensure that
 # autoconf detects the
correct
 # library and include dirs 
 # when querying gcc (CFLAGS
 # won't work here)
  make
  make install


+++
Building pcre-ocaml
  (Note that with older (< 0.14) versions of flexlink, the linker errors
noted doesn't show up and the resulting library is broken)
  Unpacked pcre-ocaml 5.15.1
  Edit pcre-ocaml-release-5.15.1/Makefile.conf to contain:
export LIBDIRS := C:/Dev/OCaml/lib # Location of PCRE
export MINGW=1 # MinGW build
export CC=gcc  # Or you get lots of errors!
  patch -p0 -i pcre-ocaml-release-5.15.1.patch # (attached)

  The patch "fixes" two things in OCamlMakefile
a) It causes the ocamlc -where check to pass the result through cygpath.
My OCAMLLIB variable is correctly set (for Windows) as C:\Dev\OCaml\lib and
Cygwin configure scripts should generally respect that (build in Cygwin, run
in Windows so OCAMLLIB is a Windows environment variable...). I've been lazy
though and not done the same thing for the camlp4 -where test...
b) It adds a simple check for OCaml 3.11 (it would be better if it did a
>= 3.11 check but I haven't bothered to bring up the GNU make info pages to
check the syntax for doing that!) and uses ocamlmklib instead of manually
building the stub libraries if OCaml 3.11 is found - the manual build
instructions included in OCamlMakefile are for 3.10 and earlier and so don't
work (i.e. non-flexlink linking)

  OK, so at this stage it looks as though we should be ready to build. But
if I run make (with flexlink 0.14 or later) then I get the following errors
(compiling with flexlink 0.13 works, but the resulting library is broken):

ocamlmklib -LC:/Dev/OCaml/lib -o pcre_stubs  pcre_stubs.o -lpcre
c:\Users\DRA\AppData\Local\Temp\dyndll8e6a10.o:pcre_stubs.c:(.text+0x205):
undefined reference to `__imp__pcre_callout'
[and several more missing __imp__pcre_... messages]

  The problem is in C:\Dev\OCaml\lib, it appears. In there are libpcre.a,
libpcre.dll.a and libpcre.la. If I rename libpcre.a to libpcre.old.a and
then libpcre.dll.a to libpcre.a then the build works and the resulting
library builds. As far as I can tell, this is something to do with libtool
but I know very little about this - is the inability of the library to link
without renaming these files something to do with using flexlink as the
linker? If I link a test program in C using -lpcre then it works - but is
that because gcc knows how to read .la files and looks for the libpcre.dll.a
file correctly?

  However, once this is followed through, the library does correctly build
and install - and the examples all seem to be working. So, finally, it's
cheerio to the Str module for me :o)

  Any pointers appreciated!


David


pcre-ocaml-release-5.15.1.patch
Description: Binary data
___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

RE: [Caml-list] Threads performance issue.

[David Allsopp]

Which OS (and port, if applicable) are you using?

 

From: caml-list-boun...@yquem.inria.fr 
[mailto:caml-list-boun...@yquem.inria.fr] On Behalf Of Rémi Dewitte
Sent: 16 February 2009 15:33
To: Michał Maciejewski
Cc: caml-l...@inria.fr
Subject: Re: [Caml-list] Threads performance issue.

 

 

On Mon, Feb 16, 2009 at 16:28, Michał Maciejewski  wrote:

Hi,

2009/2/16 Rémi Dewitte :

> I guess it might come from GC slowing down thinks here, doesn't it ?

I don't think so. Why do you think it's GC?

Bad guess :) !
Any hint why just linking makes things slow ?
 


> Can ocaml use multiple cores ?

No and as far as I know it's because of GC. ;-)

Ok that's a shame but I will live with :)


regards
Miichal

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs

 

___
Caml-list mailing list. Subscription management:
http://yquem.inria.fr/cgi-bin/mailman/listinfo/caml-list
Archives: http://caml.inria.fr
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
Bug reports: http://caml.inria.fr/bin/caml-bugs