(no subject)

[Stéphane Payrard]

Hi,

I am an ocaml beginner and I try to compile the last snapshot of
camelon. I am using mandrake with the following rpms:
   ocaml-lablgtk-1.2.7-1mdk
   ocaml-3.08.2-1mdk

I get the following message when trying to compile:

Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
and /usr/lib/ocaml/threads/threads.cmxa
make inconsistent assumptions over implementation Thread

Should I use different versiosn of either lablgtk or ocaml?
The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
Or is there an easy way to tweak cameleon to get it to compile
with the ocaml and lablgtk versions I have.



--
 stef

Re: [Caml-list] (no subject)

[Jon Harrop]

On Tuesday 18 January 2005 07:33, Stéphane Payrard wrote:
> Hi,
>
> I am an ocaml beginner and I try to compile the last snapshot of
> camelon. I am using mandrake with the following rpms:
>    ocaml-lablgtk-1.2.7-1mdk
>    ocaml-3.08.2-1mdk
>
> I get the following message when trying to compile:
>
> Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
> and /usr/lib/ocaml/threads/threads.cmxa
> make inconsistent assumptions over implementation Thread
>
> Should I use different versiosn of either lablgtk or ocaml?
> The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
> Or is there an easy way to tweak cameleon to get it to compile
> with the ocaml and lablgtk versions I have.

I think this problem is due to different ocaml versions being used to generate 
lablgtk and threads.

Interfaces between OCaml compilation units are *very* brittle. This is being 
discussed on the list at the moment, as even a minor version change of the 
compiler (e.g. 3.08.2 -> 3.08.3) breaks compatibility.

The good news is that this binary incompatibility is because the compiler is 
very pedantic about interfaces and guarantees that everything will work.

Your best bet is either to compile all of the packages yourself or to use 
someone else's packages. I find Debian to be excellent in this respect.

Cheers,
Jon.

PS: 3.08 has some useful additions which you may well find that people use in 
their code now (e.g. immediate objects).

dependancy problems?

[Stéphane Payrard]

Hi,

note to pixel: you are in copy because you may be interested.


On Tue, Jan 18, 2005 at 08:09:14AM +0000, Jon Harrop wrote:
> On Tuesday 18 January 2005 07:33, Stéphane Payrard wrote:
> > Hi,
> >
> > I am an ocaml beginner and I try to compile the last snapshot of
> > cameleon. I am using mandrake with the following rpms:
> >    ocaml-lablgtk-1.2.7-1mdk
> >    ocaml-3.08.2-1mdk
> >
> > I get the following message when trying to compile:
> >
> > Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
> > and /usr/lib/ocaml/threads/threads.cmxa
> > make inconsistent assumptions over implementation Thread
> >
> > Should I use different versiosn of either lablgtk or ocaml?
> > The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
> > Or is there an easy way to tweak cameleon to get it to compile
> > with the ocaml and lablgtk versions I have.
> 
> I think this problem is due to different ocaml versions being used to generate 
> lablgtk and threads.

Does this mean that the mandrake people have not done a proper job
about dependancies?  I have installed unison that also uses
lablgtk. There is no problem there. So I am puzzled.


> 
> Interfaces between OCaml compilation units are *very* brittle. This is being 
> discussed on the list at the moment, as even a minor version change of the 
> compiler (e.g. 3.08.2 -> 3.08.3) breaks compatibility.

Naive question: is this due to some internal layout of compiled structures like
classe vtables in C++? Or is this just because modules are updated and
their signature change?

> 
> The good news is that this binary incompatibility is because the compiler is 
> very pedantic about interfaces and guarantees that everything will work.
> 
> Your best bet is either to compile all of the packages yourself or to use 
> someone else's packages. I find Debian to be excellent in this
> respect.
> 
> Cheers,
> Jon.
> 
> PS: 3.08 has some useful additions which you may well find that people use in 
> their code now (e.g. immediate objects).
> 

Thx for you help.

--
  stef

Re: [Caml-list] dependancy problems?

[Sven Luther]

On Tue, Jan 18, 2005 at 09:25:22AM +0100, Stéphane Payrard wrote:
> Hi,
> 
> note to pixel: you are in copy because you may be interested.
> 
> 
> On Tue, Jan 18, 2005 at 08:09:14AM +0000, Jon Harrop wrote:
> > On Tuesday 18 January 2005 07:33, Stéphane Payrard wrote:
> > > Hi,
> > >
> > > I am an ocaml beginner and I try to compile the last snapshot of
> > > cameleon. I am using mandrake with the following rpms:
> > >    ocaml-lablgtk-1.2.7-1mdk
> > >    ocaml-3.08.2-1mdk
> > >
> > > I get the following message when trying to compile:
> > >
> > > Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
> > > and /usr/lib/ocaml/threads/threads.cmxa
> > > make inconsistent assumptions over implementation Thread
> > >
> > > Should I use different versiosn of either lablgtk or ocaml?
> > > The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
> > > Or is there an easy way to tweak cameleon to get it to compile
> > > with the ocaml and lablgtk versions I have.
> > 
> > I think this problem is due to different ocaml versions being used to generate 
> > lablgtk and threads.
> 
> Does this mean that the mandrake people have not done a proper job
> about dependancies?  I have installed unison that also uses
> lablgtk. There is no problem there. So I am puzzled.

Probably yes. Or maybe just the binary compatibility problem with 3.08.1 ro
3.08.2 migration, so it did not hit only debian.

You should fill a bug report about this to mandrake so they fix it.

> > Interfaces between OCaml compilation units are *very* brittle. This is being 
> > discussed on the list at the moment, as even a minor version change of the 
> > compiler (e.g. 3.08.2 -> 3.08.3) breaks compatibility.
> 
> Naive question: is this due to some internal layout of compiled structures like
> classe vtables in C++? Or is this just because modules are updated and
> their signature change?

See a previous thread about this where i participated (last week and sunday i
think) for answers on this.

Friendly,

Sven Luther

Re: [Caml-list] dependancy problems?

[Pixel]

Sven Luther <sven.luther@wanadoo.fr> writes:

> On Tue, Jan 18, 2005 at 09:25:22AM +0100, Stéphane Payrard wrote:

[...]

> > > > I get the following message when trying to compile:
> > > >
> > > > Files /usr/lib/ocaml/lablgtk/gtkThread.cmx
> > > > and /usr/lib/ocaml/threads/threads.cmxa
> > > > make inconsistent assumptions over implementation Thread
> > > >
> > > > Should I use different versiosn of either lablgtk or ocaml?
> > > > The INSTALL file suggest OCaml 3.07  and LablGtk 1.2.6 .
> > > > Or is there an easy way to tweak cameleon to get it to compile
> > > > with the ocaml and lablgtk versions I have.
> > > 
> > > I think this problem is due to different ocaml versions being used to generate 
> > > lablgtk and threads.
> > 
> > Does this mean that the mandrake people have not done a proper job
> > about dependancies?  I have installed unison that also uses
> > lablgtk. There is no problem there. So I am puzzled.
> 
> Probably yes. Or maybe just the binary compatibility problem with 3.08.1 ro
> 3.08.2 migration, so it did not hit only debian.

right, i've rebuilt LablGtk and now it works.

(sorry for the answer time)

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

Re: [Caml-list] (no subject)

[Alain Frisch]

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?

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

Re: [Caml-list] (no subject)

[skaller]

On Mon, 2006-01-23 at 11:37 -0800, Kathleen Fisher wrote:
> As part of our work on Moby, John Reppy and I are collecting
> experiences people have had using the object-oriented features of
> Ocaml, as it has been available long enough for people to use it "for
> real."
> 
> We are interested in understanding what people use the object- 
> oriented features for.  What works really well?  What doesn't work so  
> smoothly?  How do you decide when to use the object-oriented  
> features?  Do you have other observations you'd like to share?

OO features provide dynamic binding, which is more powerful
than polymorphism provided by any other feature other than
higher order polymorphism (which doesn't work properly in Ocaml).

However, the utility is heavily constrained by the variance
requirements.

The effect is that OO is often the best solution for
sources and sinks, and cannot be used for most relationships
(since they're usually covariant).

Thus, I am using Ocaml OO as sources and
for relationships where one type is invariant. In particular,
I am using it in the lexer phase of my compiler, with classes
to handle and factorise the state of the preprocessor/lexer,
parameterising Ocamllex action code.

Secondly, it is used to manage the inputs supplied to the
Ocamlyacc parser mainly to feed a stream of tokens to it.

In both cases the type of a token is invariant, and so
amenable to an OO solution. In both cases the technology
being leveraged -- Ocamllex and Ocamlyacc -- forces me
to control invert my logic and program reactively instead
of actively -- user actions of both tools are callbacks
driven by tool generated logic which provide no or very
limited ability to interact actively.

These uses are not intended to provide any abstraction,
they're just a convenient way to package up the functionality
and pass it around as a single value.

My back end would also benefit from use of classes.
The output data type involved -- strings -- is invariant.
Classes would provide abstraction which may assist in
making the code generator pluggable: at present it can
only generate ISO C++, it would be useful to generate C,
C--, Ocaml, or some other languages too.

This is not done at the moment, because using classes
requires knowing in advance what your abstractions are:
classes break badly with design changes. Algebraic data
structures are more flexible, adapt more easily, but it
is harder to reason about correctness when operating
directly on low level representations.

In fact, in the lexer classes, the enforced abstraction
(variables can't be accessed, you have to write get/set
methods) is actually a pain. As the system developed
I've had to add more variables and get/set methods ..
and declare separately the types in *.mli files ..
because much of the time I'm *really* working directly
with the representation. Refactoring would be a nightmare ;(

In another project I used classes much more heavily.
That project (Vyper) was an Ocaml program which implemented
the Python programming language. This was not only convenient
to model the Python objects as classes, it was also useful for
constructing lookup scopes, with methods representing the various
lookup rules.

There I used abstraction heavily, as a way of separating my
Ocaml implementation from the semantics, and this was tenable
because the semantics were well specified (by the Python language),
which itself is object based.

One final comment: classes would be MUCH more useful if, as
in C++, one had dynamically loadable code. In that case
algorithms can work with class types instantiated at run time,
the dynamic binding is fundamental, and the enforced abstraction
vital. I exploit this heavily in Felix, which generates shared
libraries which are dynamically loaded by a driver program,
which runs the code using C++ abstract base methods.

In Ocaml you have to link all the instances in anyhow..
so the dynamic binding isn't nearly as useful. For Vyper this
was one of the major factors killing the project: there
was a need to model all the C extension to Python -- and there
are a LOT of them -- the same way Python does: by dynamic loading.
The Ocaml emulation had to statically link every extension,
which apart from being a pain, introduces the possibility that
the intended bindings are not fully abstracted.

-- 
John Skaller <skaller at users dot sf dot net>
Felix, successor to C++: http://felix.sf.net

[Caml-list] (no subject)

[Nicolas Tacheny]

auth 4125c0d1 subscribe caml-list nicolas.tacheny@umh.ac.be

-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners