3.09.3 release candidate 1

3.09.3 release candidate 1

[Damien Doligez]

Hello,

We have a release candidate for 3.09.3.  It is available from the CVS
repository < http://camlcvs.inria.fr/cvsserver-eng.html > under the
tag "ocaml3093rc1".

We would appreciate the help of any user who wants to test this
version and report any problem encountered (as usual, through the
BTS: < http://caml.inria.fr/mantis/main_page.php >).

It will become a full release in one or two weeks unless some serious
bug is reported in the meantime.

-- the OCaml team.

Re: [Caml-list] 3.09.3 release candidate 1

[Olivier Andrieu]

 Damien Doligez [Wednesday 30 August 2006] :
 >
 > Hello,
 > 
 > We have a release candidate for 3.09.3.  It is available from the CVS
 > repository < http://camlcvs.inria.fr/cvsserver-eng.html > under the
 > tag "ocaml3093rc1".

I get this:
,----
| $ cvs up -r ocaml3093rc1
| cvs [update aborted]: no such tag ocaml3093rc1
`----
-- 
   Olivier

Re: [Caml-list] 3.09.3 release candidate 1

[skaller]

On Wed, 2006-08-30 at 14:18 +0200, Olivier Andrieu wrote:
>  Damien Doligez [Wednesday 30 August 2006] :
>  >
>  > Hello,
>  > 
>  > We have a release candidate for 3.09.3.  It is available from the CVS
>  > repository < http://camlcvs.inria.fr/cvsserver-eng.html > under the
>  > tag "ocaml3093rc1".
> 
> I get this:
> ,----
> | $ cvs up -r ocaml3093rc1
> | cvs [update aborted]: no such tag ocaml3093rc1
> `----


skaller@rosella:/work/ocaml$ cvs update -r ocaml3093rc1
? asmcomp/arch.cmi
? asmcomp/arch.cmo
..

Seems to work here ..

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

Re: [Caml-list] 3.09.3 release candidate 1

[Olivier Andrieu]

 skaller [Wednesday 30 August 2006] :
 >
 > On Wed, 2006-08-30 at 14:18 +0200, Olivier Andrieu wrote:
 > >  Damien Doligez [Wednesday 30 August 2006] :
 > >  >
 > >  > Hello,
 > >  > 
 > >  > We have a release candidate for 3.09.3.  It is available from the CVS
 > >  > repository < http://camlcvs.inria.fr/cvsserver-eng.html > under the
 > >  > tag "ocaml3093rc1".
 > > 
 > > I get this:
 > > ,----
 > > | $ cvs up -r ocaml3093rc1
 > > | cvs [update aborted]: no such tag ocaml3093rc1
 > > `----
 > 
 > 
 > skaller@rosella:/work/ocaml$ cvs update -r ocaml3093rc1
 > ? asmcomp/arch.cmi
 > ? asmcomp/arch.cmo
 > ..
 > 
 > Seems to work here ..

It works for me too now. I guess it was an issue with the public
repository being only periodically synched with the development
repository or something.

Here's the Changelog by the way:

,----[ Changes ]
| Objective Caml 3.09.3:
| ----------------------
| 
| Bug fixes:
| - ocamldoc: -using modtype constraint to filter module elements displayed
|     in doc PR#4016
| - ocamldoc: error in merging of top dependencies of modules PR#4007
| - ocamldoc: -dot-colors has no effect PR#3981
| - ocamdloc: missing crossref in text from intro files PR#4066
| - compilers: segfault with recursive modules PR#4008
| - compilers: infinite loop when compiling objects PR#4018
| - compilers: bad error message when signature mismatch PR#4001
| - compilers: infinite loop with -rectypes PR#3999
| - compilers: contravariance bug in private rows
| - compilers: unsafe cast with polymorphic exception PR#4002
| - native compiler: bad assembly code generated for AMD64 PR#4067
| - native compiler: stack alignment problems on MacOSX/i386 PR#4036
| - stdlib: crash in marshalling PR#4030
| - stdlib: crash when closing a channel twice PR#4039
| - stdlib: memory leak in Sys.readdir PR#4093
| - C interface: better definition of CAMLreturn PR#4068
| - otherlibs/unix: crash in gethostbyname PR#3043
| - tools: subtle problem with unset in makefile PR#4048
| 
| New features:
| - ocamldoc: name resolution in cross-referencing {!name}: if name is not
|     found, then it is searched in the parent module/class, and in the parent
|     of the parent, and so on until it is found.
| - ocamldoc: new option -short-functors to use a short form to display
|     functors in html generator PR#4017
| - ocamlprof: added "-version" option
`----

-- 
   Olivier

Re: [Caml-list] 3.09.3 release candidate 1

[Jean-Marie Gaillourdet]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hello,

On 30.08.2006, at 13:21, Damien Doligez wrote:

> Hello,
>
> We have a release candidate for 3.09.3.  It is available from the CVS
> repository < http://camlcvs.inria.fr/cvsserver-eng.html > under the
> tag "ocaml3093rc1".
>
> We would appreciate the help of any user who wants to test this
> version and report any problem encountered (as usual, through the
> BTS: < http://caml.inria.fr/mantis/main_page.php >).
>
> It will become a full release in one or two weeks unless some serious
> bug is reported in the meantime.

I do use OCaml on MacOS X on x86 architecture. There were simple  
posted on this mailing list that enable shared library and gprof  
support. Why aren't they in that release candidate? They worked fine  
for me in the past.

Best regards,
   Jean-Marie

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFE+VSNNIUNP/I5YOgRAkETAJ9ly+e2JAJy9cgmWwjFaD73hpermQCgyMUa
hFzl7qJNQOMwQnr5RZR+BlM=
=Wrkl
-----END PGP SIGNATURE-----

Re: [Caml-list] 3.09.3 release candidate 1

[Damien Doligez]

[-- Attachment #1: Type: text/plain, Size: 404 bytes --]


On 2006-09-02, at 11:53, Jean-Marie Gaillourdet wrote:

> I do use OCaml on MacOS X on x86 architecture. There were simple  
> posted on this mailing list that enable shared library and gprof  
> support. Why aren't they in that release candidate? They worked  
> fine for me in the past.

This is a bug-fix release.  Almost all new features go into 3.10.0,  
which
will be released "soon".

-- Damien


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 186 bytes --]

3.09.3 release candidate 2

[Damien Doligez]

Hello OCaml users,

We have decided to make a second release candidate for 3.09.3.
The only changes between rc1 and rc2 are camlp4-related:

- camlp4: install pa_o_fast.o PR#3812
- camlp4: install more modules PR#3689

We would appreciate if camlp4 users (and particularly Hendrik) could
test this version and report any problems found with it.

Other users are still encouraged to try this one if they haven't
tried 3.09.3+rc1.

Like the previous one, this version is available from the CVS
repository < http://camlcvs.inria.fr/cvsserver-eng.html >, but under
the tag "ocaml3093rc2".

Thanks for your cooperation,

-- Damien

Re: [Caml-list] 3.09.3 release candidate 2

[Aleksey Nogin]

On 08.09.2006 07:47, Damien Doligez wrote:

> We have decided to make a second release candidate for 3.09.3.
> The only changes between rc1 and rc2 are camlp4-related:
> 
> - camlp4: install pa_o_fast.o PR#3812
> - camlp4: install more modules PR#3689
> 
> We would appreciate if camlp4 users (and particularly Hendrik) could
> test this version and report any problems found with it.

I was able to compile the MetaPRL theorem prover and run the regression
test without any issues. I was using natively compiled MetaPRL that
links against the natively compiled camlp4.

Aleksey

Re: [Caml-list] 3.09.3 release candidate 2

[Hendrik Tews]

Damien Doligez <damien.doligez@inria.fr> writes:

   - camlp4: install more modules PR#3689

No. Please check again carefully. At least plexer and grammar are
not properly installed:

tandem tews 25> ls -1 install/lib/ocaml/camlp4/{plexer,grammar}.*
install/lib/ocaml/camlp4/grammar.cmi
install/lib/ocaml/camlp4/grammar.cmx
install/lib/ocaml/camlp4/grammar.mli
install/lib/ocaml/camlp4/grammar.o
install/lib/ocaml/camlp4/plexer.cmi
install/lib/ocaml/camlp4/plexer.cmx
install/lib/ocaml/camlp4/plexer.mli
install/lib/ocaml/camlp4/plexer.o

(hint: *.cmo is needed to link a module)

Hendrik

Re: [Caml-list] 3.09.3 release candidate 2

[Nicolas Pouillard]

On 9/13/06, Hendrik Tews <tews@cs.ru.nl> wrote:
> Damien Doligez <damien.doligez@inria.fr> writes:
>
>    - camlp4: install more modules PR#3689
>
> No. Please check again carefully. At least plexer and grammar are
> not properly installed:
>
> tandem tews 25> ls -1 install/lib/ocaml/camlp4/{plexer,grammar}.*
> install/lib/ocaml/camlp4/grammar.cmi
> install/lib/ocaml/camlp4/grammar.cmx
> install/lib/ocaml/camlp4/grammar.mli
> install/lib/ocaml/camlp4/grammar.o
> install/lib/ocaml/camlp4/plexer.cmi
> install/lib/ocaml/camlp4/plexer.cmx
> install/lib/ocaml/camlp4/plexer.mli
> install/lib/ocaml/camlp4/plexer.o
>
> (hint: *.cmo is needed to link a module)
>

I do not understand why you do need .cmo files when you have a library
(gramlib.cma or camlp4.cma) that includes these modules (note that .a
and .cmxa are also available for native linking).

-- 
Nicolas Pouillard

Re: [Caml-list] 3.09.3 release candidate 2

[skaller]

On Wed, 2006-09-13 at 17:05 +0200, Nicolas Pouillard wrote:
> On 9/13/06, Hendrik Tews <tews@cs.ru.nl> wrote:
> > Damien Doligez <damien.doligez@inria.fr> writes:
> >
> >    - camlp4: install more modules PR#3689
> >
> > No. Please check again carefully. At least plexer and grammar are
> > not properly installed:
> >
> > tandem tews 25> ls -1 install/lib/ocaml/camlp4/{plexer,grammar}.*
> > install/lib/ocaml/camlp4/grammar.cmi
> > install/lib/ocaml/camlp4/grammar.cmx
> > install/lib/ocaml/camlp4/grammar.mli
> > install/lib/ocaml/camlp4/grammar.o
> > install/lib/ocaml/camlp4/plexer.cmi
> > install/lib/ocaml/camlp4/plexer.cmx
> > install/lib/ocaml/camlp4/plexer.mli
> > install/lib/ocaml/camlp4/plexer.o
> >
> > (hint: *.cmo is needed to link a module)
> >
> 
> I do not understand why you do need .cmo files when you have a library
> (gramlib.cma or camlp4.cma) that includes these modules (note that .a
> and .cmxa are also available for native linking).

because these are *camlp4* modules, camlp4 loads bytecode
(only) dynamically from a single cmo file (only).


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

Re: [Caml-list] 3.09.3 release candidate 2

[Hendrik Tews]

   > I do not understand why you do need .cmo files when you have a library
   > (gramlib.cma or camlp4.cma) that includes these modules (note that .a
   > and .cmxa are also available for native linking).

But with this line of reasoning, plexer.{o,cmx} should not be
installed either, shouln't it?

   because these are *camlp4* modules, camlp4 loads bytecode
   (only) dynamically from a single cmo file (only).

No, for me it was like that:
- first I didn't know, there is library with these modules 
  (how to find out what library contains a given module without
  grepping through the build log?)
- linking gramlib does not work, because the module is not
  explicitely referenced (only during runtime the program does a
  dynlink on something else that needs the given module)

I could fix that with adding an artificial reference like

module XXX = Plexer


(I could still imagine some camlp4 application szenario, where
you need to use -linkall, but don't want to link all of
gramlib.cma. Then you would need the cmo itself, right? However,
this was not the case in my application.)

Bye,

Hendrik

Re: [Caml-list] 3.09.3 release candidate 2

[Nicolas Pouillard]

On 9/13/06, Hendrik Tews <tews@cs.ru.nl> wrote:
>
>    > I do not understand why you do need .cmo files when you have a library
>    > (gramlib.cma or camlp4.cma) that includes these modules (note that .a
>    > and .cmxa are also available for native linking).
>
> But with this line of reasoning, plexer.{o,cmx} should not be
> installed either, shouln't it?

Yes, but if I remember correctly it's you that request for these files
to be installed?

So in order to be consistent either one do not expose at all the
content of a library or one install all components (.cmo, .cmi, .cmx,
.o). I tend to prefer the first one.

>
>    because these are *camlp4* modules, camlp4 loads bytecode
>    (only) dynamically from a single cmo file (only).
>
> No, for me it was like that:
> - first I didn't know, there is library with these modules
>   (how to find out what library contains a given module without
>   grepping through the build log?)
Yes not se easy, documentation job...

> - linking gramlib does not work, because the module is not
>   explicitely referenced (only during runtime the program does a
>   dynlink on something else that needs the given module)

> I could fix that with adding an artificial reference like
>
> module XXX = Plexer
>

Yes it's artificial, you can also use -linkall.

>
> (I could still imagine some camlp4 application szenario, where
> you need to use -linkall, but don't want to link all of
> gramlib.cma. Then you would need the cmo itself, right? However,
> this was not the case in my application.)

Yes but it's a choice made by the library designer.

-- 
Nicolas Pouillard

Re: [Caml-list] 3.09.3 release candidate 2

[skaller]

On Wed, 2006-09-13 at 17:55 +0200, Hendrik Tews wrote:
>    > I do not understand why you do need .cmo files when you have a library
>    > (gramlib.cma or camlp4.cma) that includes these modules (note that .a
>    > and .cmxa are also available for native linking).
> 
> But with this line of reasoning, plexer.{o,cmx} should not be
> installed either, shouln't it?
> 
>    because these are *camlp4* modules, camlp4 loads bytecode
>    (only) dynamically from a single cmo file (only).
> 
> No, for me it was like that:
> - first I didn't know, there is library with these modules 
>   (how to find out what library contains a given module without
>   grepping through the build log?)
> - linking gramlib does not work, because the module is not
>   explicitely referenced (only during runtime the program does a
>   dynlink on something else that needs the given module)

IMHO the real problem is that Ocaml doesn't provide a standard
build model. It's a set of tools you have to couple together
yourself in an ad-hoc way, which makes it very hard to build
and distribute third party add-ons.

Some 'standardisation' is provided by findlib architecture
with meta-file descriptions.

The problem propagates when upgrading: you have no idea
where all the stuff is that requires recompilation to satisfy
the new ABI.

We need to compare this with Python, Perl, Java, or even Felix, 
to see that much better can be done: these systems find stuff more
or less automatically, have specified layouts, and know when
recompilation is required. This level of automation does not
prevent fiddling with manual builds for special effects,
but it eliminates the need to do so for many applications
and libraries.

In my view, there is no need for Inria to implement such
technology: it can be developed by third parties.

However to be really acceptable

(a) Inria would need to participate in the development
   of the specification
(b) modify the tools to support it if necessary
(c) package the final solution with the standard distro
(d) take over responsibility 

Similar to camlp4: tools like findlib are nice but you
can't write build scripts that depend on them because
not everyone has it, and even installing it won't help
with already installed packages, or packages that
don't themselves support it. If it were in the standard
distro everyone WOULD support it (except for the
special fiddles eg using patched Ocamls etc).

I would note that 'Debian' or 'Godi' still only provide
partial solutions -- they won't rebuild USER code bases
automatically.

The rule I use for Felix is: to run a program you say:

	flx source-code-filename arguments

and everything else must be done by the system.
The result of execution is defined in terms of SOURCE code,
not binaries, so it is the system's responsibility --
not the users -- to locate all the required dependent
sources, compile and link as required if cached copies
aren't up to date, and run the code.

In turn, the user is told how to make this work properly
even for user components (and it is their responsibility
to install the required meta-information).

Not everyone will agree with this particular model
and therein lies the real problem. Inria provides several
ways to participate:

(a) Join Inria
(b) Join Caml Consortium
(c) Put stuff on Humps

none of which really give the community as a whole a political
resolution process such as a Standards committee might,
for the formation of a consensus.

Most of us would agree to defer to Inria on issues such as
the type system -- and most of us probably believe Inria
would like to defer to the community on industrial issues
such as building and distribution models -- but we have
no 'forum' suitable for doing so.

The Python community has a process involving PEPs
(Python Extension Proposals) including web interfaces
to track them, and processes to decide whether or not
to accept them.

I suggest the Ocaml Consortium consider opening up to a class of
members 'ordinary user'. Such people join FREE,
and are admitted if a couple of existing members or
nominated persons vouch for them as bona fide interested
parties. Such members can't spend consortium money,
but they're free to contribute directly to it.
The Consortium, in turn, will provide some resources
to this body of people as it sees fit (eg some
space on a web server, a Wiki, etc).

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

Re: 3.09.3 release candidate 2

[Chris King]

On 9/13/06, Nicolas Pouillard <nicolas.pouillard@gmail.com> wrote:
> On 9/13/06, Hendrik Tews <tews@cs.ru.nl> wrote:
> >
> > But with this line of reasoning, plexer.{o,cmx} should not be
> > installed either, shouln't it?
>
> So in order to be consistent either one do not expose at all the
> content of a library or one install all components (.cmo, .cmi, .cmx,
> .o). I tend to prefer the first one.

I remember hearing somewhere that by exposing .cmx files, the compiler
is able to inline across module boundaries, and thus distributing .cmx
files is desirable.  Is this just a myth?  It seems redundant since
the .cmx files are included in the .cmxa anyway.

- Chris King

Re: [Caml-list] Re: 3.09.3 release candidate 2

[Jacques Garrigue]

From: "Chris King" <colanderman@gmail.com>

> I remember hearing somewhere that by exposing .cmx files, the compiler
> is able to inline across module boundaries, and thus distributing .cmx
> files is desirable.  Is this just a myth?  It seems redundant since
> the .cmx files are included in the .cmxa anyway.

This is a frequent confusion. The .cmxa does not contain all the
information from the .cmx, in particular not the inlining
information. This is natural if you think of it: when you compile a
module, you have no way to know in which library are its dependencies,
so you can only look for .cmx's, not for .cmxa's. The .cmxa's are only
used at link time.
You can still compile without the .cmx's, but you loose the
optimizations.

Jacques Garrigue

Re: [Caml-list] 3.09.3 release candidate 2

[Hendrik Tews]

"Nicolas Pouillard" <nicolas.pouillard@gmail.com> writes:

   On 9/13/06, Hendrik Tews <tews@cs.ru.nl> wrote:
   >
   >    > I do not understand why you do need .cmo files when you have a library
   >    > (gramlib.cma or camlp4.cma) that includes these modules (note that .a
   >    > and .cmxa are also available for native linking).
   >
   > But with this line of reasoning, plexer.{o,cmx} should not be
   > installed either, shouln't it?

   Yes, but if I remember correctly it's you that request for these files
   to be installed?

Sure, but I didn't knew about the library, when I filed the bug
report. 

   So in order to be consistent either one do not expose at all the
   content of a library or one install all components (.cmo, .cmi, .cmx,
   .o). I tend to prefer the first one.

OK, Jacques clarified this, you need to install the .cmi .cmx
together with the library. .cmo and .o are in the library.

   > (I could still imagine some camlp4 application szenario, where
   > you need to use -linkall, but don't want to link all of
   > gramlib.cma. Then you would need the cmo itself, right? However,
   > this was not the case in my application.)

   Yes but it's a choice made by the library designer.

The library designer can hardly forsee all the possible usages of
the modules in his library. Therefore, in my opinion, one should
install all .cmi .cmo .cmx .o and have the libraries available
for convenience. The additional space needed is negligible (less
than 1M for both gramlib and plexer). Cases where users needed a
uncleaned ocaml source directory to compile certain features of
an application would then belong to the past.

Bye,

Hendrik