[Caml-list] 3.09.3 release candidate 1
Damien Doligez
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.
_______________________________________________
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
Olivier Andrieu
>
> 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
skaller
> 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
Olivier Andrieu
>
> 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
Jean-Marie Gaillourdet
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-----
Damien Doligez
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
Aleksey Nogin
> 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
Hendrik Tews
- 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
Nicolas Pouillard
> Damien Doligez <damien....@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
skaller
> On 9/13/06, Hendrik Tews <te...@cs.ru.nl> wrote:
> > Damien Doligez <damien....@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
_______________________________________________
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
Nicolas Pouillard
> > (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
skaller
> > 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
_______________________________________________
Chris King
> On 9/13/06, Hendrik Tews <te...@cs.ru.nl> wrote:
> >
> > But with this line of reasoning, plexer.{o,cmx} should not be
> > installed either, shouln't it?
>
> content of a library or one install all components (.cmo, .cmi, .cmx,
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
Jacques Garrigue
> 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
Hendrik Tews
"Nicolas Pouillard" <nicolas....@gmail.com> writes:
On 9/13/06, Hendrik Tews <te...@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