[Caml-list] OCaml 3.05 released

[Caml-list] OCaml 3.05 released

[Xavier Leroy]

Version 3.05 of the Objective Caml system is now available from

        http://caml.inria.fr/ocaml/distrib.html

The main novelty in this release is the addition of first-class
polymorphism for methods and record fields.  Also, the ocamldoc
documentation generator is now included in the release, and the
modules Complex and Scanf were added to the standard library.  This
comes in addition to the usual amount of bug fixes, which are
described in more details below.

For general info on Objective Caml, see http://caml.inria.fr.  Bug
reports go to caml-bugs@inria.fr, messages for the implementors to
caml@inria.fr, and general discussions to the mailing-list
caml-list@inria.fr, or the comp.lang.ml or comp.lang.functional
newsgroups.

Enjoy,

- Xavier Leroy, for the Objective Caml team.


Objective Caml 3.05:
--------------------

Language features:
- Support for polymorphic methods and record fields.
- Allows _ separators in integer and float literals, e.g. 1_000_000.

Type-checker:
- New flag -principal to enforce principality of type inference.
- Fixed subtle typing bug with higher-order functors.
- Fixed several complexity problems; changed (again) the  behaviour of
  simple coercions.
- Fixed various bugs with objects and polymorphic variants.
- Improved some error messages.

Both compilers:
- Added option "-pack" to assemble several compilation units as one unit
  having the given units as sub-modules.
- More precise detection of unused sub-patterns in "or" patterns.
- Warnings for ill-formed \ escapes in string and character literals.
- Protect against spaces and other special characters in directory names.
- Added interface consistency check when building a .cma or .cmxa library.
- Minor reduction in code size for class initialization code.
- Added option "-nostdlib" to ignore standard library entirely.

Bytecode compiler:
- Fixed issue with ocamlc.opt and dynamic linking.

Native-code compiler:
- Added link-time check for multiply-defined module names.
- Fixed GC bug related to constant constructors of polymorphic variant types.
- Fixed compilation bug for top-level "include" statements.
- PowerPC port: work around limited range for relative branches,
  thus removing assembler failures on large functions.
- IA64 port: fixed code generation bug for 3-way constructor matching.

Toplevel interactive system:
- Can load object files given on command line before starting up.
- ocamlmktop: minimized possibility of name clashes with user-provided modules.

Run-time system:
- Minor garbage collector no longer recursive.
- Better support for lazy data in the garbage collector.
- Fixed issues with the heap compactor.
- Fixed issues with finalized Caml values.
- The type "int64" is now supported on all platforms: we use software 
  emulation if the C compiler doesn't support 64-bit integers.
- Support for float formats that are neither big-endian nor little-endian
  (one known example: the ARM).
- Fixed bug in callback*_exn functions in the exception-catching case.
- Work around gcc 2.96 bug on RedHat 7.2 and Mandrake 8.0, 8.1 among others.
- Stub DLLs now installed in subdir stublibs/ of standard library dir.

Standard library:
- Protect against integer overflow in sub-string and sub-array bound checks.
- New module Complex implementing arithmetic over complex numbers.
- New module Scanf implementing format-based scanning a la scanf() in C.
- Module Arg: added alternate entry point Arg.parse_argv.
- Modules Char, Int32, Int64, Nativeint, String: added type "t" and function
  "compare" so that these modules can be used directly with e.g. Set.Make.
- Module Digest: fixed issue with Digest.file on large files (>= 1Gb);
    added Digest.to_hex.
- Module Filename: added Filename.open_temp_file to atomically create and
    open the temp file; improved security of Filename.temp_file.
- Module Genlex: allow _ as first character of an identifier.
- Module Lazy: more efficient implementation.
- Module Lexing: improved performances for very large tokens.
- Module List: faster implementation of sorting functions.
- Module Printf:
    added %S and %C formats (quoted, escaped strings and characters);
    added kprintf (calls user-specified continuation on formatted string).
- Module Queue: faster implementation (courtesy of François Pottier).
- Module Random: added Random.bool.
- Module Stack: added Stack.is_empty.
- Module Pervasives:
    added sub-module LargeFile to support files larger than 1Gb
      (file offsets are int64 rather than int);
    opening in "append" mode automatically sets "write" mode;
    files are now opened in close-on-exec mode;
    string_of_float distinguishes its output from a plain integer;
    faster implementation of input_line for long lines.
- Module Sys:
     added Sys.ocaml_version containing the OCaml version number;
     added Sys.executable_name containing the (exact) path of the
       file being executable;
     Sys.argv.(0) is now unchanged w.r.t. what was provided as 0-th argument
       by the shell.
- Module Weak: added weak hash tables.

Other libraries:
- Bigarray:
    support for bigarrays of complex numbers; 
    added functions Genarray.dims,
      {Genarray,Array1,Array2,Array3}.{kind,layout}.
- Dynlink: fixed bug with loading of mixed-mode Caml/C libraries.
- LablTK:
    now supports also the CamlTK API (no labels); 
    support for Activate and Deactivate events;
    support for virtual events;
    added UTF conversion;
    export the tcl interpreter as caml value, to avoid DLL dependencies.
- Unix:
    added sub-module LargeFile to support files larger than 1Gb
      (file offsets are int64 rather than int);
    added POSIX opening flags (O_NOCTTY, O_*SYNC);
    use reentrant functions for gethostbyname and gethostbyaddr when available;
    fixed bug in Unix.close_process and Unix.close_process_full;
    removed some overhead in Unix.select.

Tools:
- ocamldoc (the documentation generator) is now part of the distribution.
- Debugger: now supports the option -I +dir.
- ocamllex: supports the same identifiers as ocamlc; warns for
  bad \ escapes in strings and characters.
- ocamlbrowser:
    recenter the module boxes when showing a cross-reference;
    include the current directory in the ocaml path.

Windows port:
- Can now compile with Mingw (the GNU compilers without the Cygwin
  runtime library) in addition to MSVC.
- Toplevel GUI: wrong filenames were given to #use and #load commands;
  read_line() was buggy for short lines (2 characters or less).
- OCamlBrowser: now fully functional.
- Graphics library: fixed several bugs in event handling.
- Threads library: fixed preemption bug.
- Unix library: better handling of the underlying differences between
  sockets and regular file descriptors; 
  added Unix.lockf and a better Unix.rename (thanks to Tracy Camp).
- LablTk library: fixed a bug in Fileinput.
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Nicolas Cannasse]

> Version 3.05 of the Objective Caml system is now available from
>
>         http://caml.inria.fr/ocaml/distrib.html
>

Download & Installation done

All my sources & libs have been recompiled without any problem.
I also get and compiled the sources from the CVS and got some errors due to
the file "tcl.h" or sthing like this ( i don't have Tcl/Tk installed ).
And finally I build "ocamlc.opt" and "ocamlopt.opt" : all is working fine
under Win32/MSVC.

A lot of thanks to the entire OCaml team for that new release !

Nicolas Cannasse

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

Re: [Caml-list] OCaml 3.05 released

[Shawn Wagner]

On Mon, Jul 29, 2002 at 02:45:27PM +0200, Xavier Leroy wrote:
> 
> Objective Caml 3.05:
> --------------------
> 
> Language features:
> - Support for polymorphic methods and record fields.
> - Allows _ separators in integer and float literals, e.g. 1_000_000.

Something I've been wanting for a while (And vaguely remember being
discussed on the list a while back) is being able to have literal int32 and
int64 and nativeint values in source files. For example, I have code that
has int32 constants that are too large to fit in a normal caml int, so I'm
stuck doing things like let some_value = Int32.of_string "123456789" at the
moment, which seems icky. For some reason, I was under the impression that
this was going to be in .05. Any chance of it for .06?

> - Unix:
>     use reentrant functions for gethostbyname and gethostbyaddr when available;

Nifty. In a vaguely related note, I'm working off and on on adding support
for IPv6 sockets to the Unix library. I think I just need to finish the
interface code for the C getnameinfo() and getaddrinfo() functions, and do a
merge with the 05 code instead of 04. Is there any interest in making this
part of a future release?

-- 
Shawn Wagner
shawnw@speakeasy.org
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Scott J.]

What is meant by first first-class polymorphism?

Another question do we really need MSVC 6.0 or is Jacob's Navia's win32 lcc
also a good alternative.

Can Olabl be used with windows?

Regards

Scott
----- Original Message -----
From: "Xavier Leroy" <xavier.leroy@inria.fr>
To: <caml-announce@inria.fr>
Sent: Monday, July 29, 2002 2:45 PM
Subject: [Caml-list] OCaml 3.05 released


> Version 3.05 of the Objective Caml system is now available from
>
>         http://caml.inria.fr/ocaml/distrib.html
>
> The main novelty in this release is the addition of first-class
> polymorphism for methods and record fields.  Also, the ocamldoc
> documentation generator is now included in the release, and the
> modules Complex and Scanf were added to the standard library.  This
> comes in addition to the usual amount of bug fixes, which are
> described in more details below.
>
> For general info on Objective Caml, see http://caml.inria.fr.  Bug
> reports go to caml-bugs@inria.fr, messages for the implementors to
> caml@inria.fr, and general discussions to the mailing-list
> caml-list@inria.fr, or the comp.lang.ml or comp.lang.functional
> newsgroups.
>
> Enjoy,
>
> - Xavier Leroy, for the Objective Caml team.
>
>
> Objective Caml 3.05:
> --------------------
>
> Language features:
> - Support for polymorphic methods and record fields.
> - Allows _ separators in integer and float literals, e.g. 1_000_000.
>
> Type-checker:
> - New flag -principal to enforce principality of type inference.
> - Fixed subtle typing bug with higher-order functors.
> - Fixed several complexity problems; changed (again) the  behaviour of
>   simple coercions.
> - Fixed various bugs with objects and polymorphic variants.
> - Improved some error messages.
>
> Both compilers:
> - Added option "-pack" to assemble several compilation units as one unit
>   having the given units as sub-modules.
> - More precise detection of unused sub-patterns in "or" patterns.
> - Warnings for ill-formed \ escapes in string and character literals.
> - Protect against spaces and other special characters in directory names.
> - Added interface consistency check when building a .cma or .cmxa library.
> - Minor reduction in code size for class initialization code.
> - Added option "-nostdlib" to ignore standard library entirely.
>
> Bytecode compiler:
> - Fixed issue with ocamlc.opt and dynamic linking.
>
> Native-code compiler:
> - Added link-time check for multiply-defined module names.
> - Fixed GC bug related to constant constructors of polymorphic variant
types.
> - Fixed compilation bug for top-level "include" statements.
> - PowerPC port: work around limited range for relative branches,
>   thus removing assembler failures on large functions.
> - IA64 port: fixed code generation bug for 3-way constructor matching.
>
> Toplevel interactive system:
> - Can load object files given on command line before starting up.
> - ocamlmktop: minimized possibility of name clashes with user-provided
modules.
>
> Run-time system:
> - Minor garbage collector no longer recursive.
> - Better support for lazy data in the garbage collector.
> - Fixed issues with the heap compactor.
> - Fixed issues with finalized Caml values.
> - The type "int64" is now supported on all platforms: we use software
>   emulation if the C compiler doesn't support 64-bit integers.
> - Support for float formats that are neither big-endian nor little-endian
>   (one known example: the ARM).
> - Fixed bug in callback*_exn functions in the exception-catching case.
> - Work around gcc 2.96 bug on RedHat 7.2 and Mandrake 8.0, 8.1 among
others.
> - Stub DLLs now installed in subdir stublibs/ of standard library dir.
>
> Standard library:
> - Protect against integer overflow in sub-string and sub-array bound
checks.
> - New module Complex implementing arithmetic over complex numbers.
> - New module Scanf implementing format-based scanning a la scanf() in C.
> - Module Arg: added alternate entry point Arg.parse_argv.
> - Modules Char, Int32, Int64, Nativeint, String: added type "t" and
function
>   "compare" so that these modules can be used directly with e.g. Set.Make.
> - Module Digest: fixed issue with Digest.file on large files (>= 1Gb);
>     added Digest.to_hex.
> - Module Filename: added Filename.open_temp_file to atomically create and
>     open the temp file; improved security of Filename.temp_file.
> - Module Genlex: allow _ as first character of an identifier.
> - Module Lazy: more efficient implementation.
> - Module Lexing: improved performances for very large tokens.
> - Module List: faster implementation of sorting functions.
> - Module Printf:
>     added %S and %C formats (quoted, escaped strings and characters);
>     added kprintf (calls user-specified continuation on formatted string).
> - Module Queue: faster implementation (courtesy of François Pottier).
> - Module Random: added Random.bool.
> - Module Stack: added Stack.is_empty.
> - Module Pervasives:
>     added sub-module LargeFile to support files larger than 1Gb
>       (file offsets are int64 rather than int);
>     opening in "append" mode automatically sets "write" mode;
>     files are now opened in close-on-exec mode;
>     string_of_float distinguishes its output from a plain integer;
>     faster implementation of input_line for long lines.
> - Module Sys:
>      added Sys.ocaml_version containing the OCaml version number;
>      added Sys.executable_name containing the (exact) path of the
>        file being executable;
>      Sys.argv.(0) is now unchanged w.r.t. what was provided as 0-th
argument
>        by the shell.
> - Module Weak: added weak hash tables.
>
> Other libraries:
> - Bigarray:
>     support for bigarrays of complex numbers;
>     added functions Genarray.dims,
>       {Genarray,Array1,Array2,Array3}.{kind,layout}.
> - Dynlink: fixed bug with loading of mixed-mode Caml/C libraries.
> - LablTK:
>     now supports also the CamlTK API (no labels);
>     support for Activate and Deactivate events;
>     support for virtual events;
>     added UTF conversion;
>     export the tcl interpreter as caml value, to avoid DLL dependencies.
> - Unix:
>     added sub-module LargeFile to support files larger than 1Gb
>       (file offsets are int64 rather than int);
>     added POSIX opening flags (O_NOCTTY, O_*SYNC);
>     use reentrant functions for gethostbyname and gethostbyaddr when
available;
>     fixed bug in Unix.close_process and Unix.close_process_full;
>     removed some overhead in Unix.select.
>
> Tools:
> - ocamldoc (the documentation generator) is now part of the distribution.
> - Debugger: now supports the option -I +dir.
> - ocamllex: supports the same identifiers as ocamlc; warns for
>   bad \ escapes in strings and characters.
> - ocamlbrowser:
>     recenter the module boxes when showing a cross-reference;
>     include the current directory in the ocaml path.
>
> Windows port:
> - Can now compile with Mingw (the GNU compilers without the Cygwin
>   runtime library) in addition to MSVC.
> - Toplevel GUI: wrong filenames were given to #use and #load commands;
>   read_line() was buggy for short lines (2 characters or less).
> - OCamlBrowser: now fully functional.
> - Graphics library: fixed several bugs in event handling.
> - Threads library: fixed preemption bug.
> - Unix library: better handling of the underlying differences between
>   sockets and regular file descriptors;
>   added Unix.lockf and a better Unix.rename (thanks to Tracy Camp).
> - LablTk library: fixed a bug in Fileinput.
> -------------------
> 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
>

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

Re: [Caml-list] OCaml 3.05 released

[John Prevost]

>>>>> "sj" == Scott J <jscott@planetinternet.be> writes:

    sj> What is meant by first first-class polymorphism?

First class polymorphism in this case lets you define values with
polymorphic types at levels other than the top level, like so:

type foo = { test : 'a 'b . ('a -> 'b) -> 'a list -> 'b list }
let a = { test = List.map }

# a.test;;
- : ('a -> 'b) -> 'a list -> 'b list = <fun>
# a.test ((+) 1) [3; 5; 7];;
- : int list = [4; 6; 8]
# a.test ((^) "a") ["a"; "b"; "c"];;
- : string list = ["aa"; "ab"; "ac"]

For objects, this allows you to define a list type, complete with map
method, as an object.  For example:

class ['a] clist x =
  object
    method map : 'b . ('a -> 'b) -> 'b list = fun f -> List.map f x
  end
let a = new clist [1;2;3]
let b = new clist ["a";"b";"c"]

# a #map (fun x -> x + 1);;
- : int list = [2; 3; 4]
# b #map (fun x -> x ^ "-");;
- : string list = ["a-"; "b-"; "c-"]

(Note: this is a very uninteresting definition if a list class, but it
should show you the kind of thing you can now do.)

John.
-------------------
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

[Caml-list] Serious typechecking error involving new polymorphism (crash)

[John Prevost]

I've discovered a fairly serious typechecking bug in 3.05.  I'm
reporting it on the webpage, but also want to mention it here so that
people are aware.

You can do the following:

# type bad = { x : 'a . 'a option ref };;
type bad = { x : 'a. 'a option ref; } 
# let bv = { x = ref None };;
val bv : bad = {x = {contents = None}}
# bv.x := Some 5;;
- : unit = ()
# let extra_bad = !(bv.x);;
val extra_bad : '_a option = Some <poly>
# f extra_bad;;

***CRASH***

It looks like mutable fields are handled correctly and catch that the
value is not, in fact, general enough.  But when the mutable field is
part of the value (in this case, part of the ref), the check is not
done.


To be safe, I recommend being very wary of using field types like:

'a . <type expression involving 'a>

In which values of the type involve mutable portions of type 'a.  As
long as any mutable portion is not also polymorphic, things are fine.

Mutable fields are fine as well, as long as you are careful as
described above.

As an example, Using

mutable x : 'a . 'a option

instead of

x : 'a . 'a option ref

in the above example prevents any poorly typed expressions from
appearing.  No value may be put in the "good" example except None,
since None is the only fully polymorphic option value.

John.
-------------------
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

[Caml-list] Record with one non mutable filed

[Christophe Raffalli]

How are compiled record with only one non mutable field ? are they
removed ?

In Ocaml 3.05, record with only one non mutable field may be used in the
following way:

type 'a foo = 
  A of int
| B of 'a

type bar = { value : 'a.'a foo }

this means that type bar is somehow a subtype of type foo (constructor B
being removed.

then I think (but may be wrong) that an expression as

let b = { value = A 3 } could be compiled as 
let b = A 3

Is this optimization performed ? (I know this is not very important for
efficiency ... but I am just curious)
-- 
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex

tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christophe.Raffalli@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Dmitry Bely]

"Scott J." <jscott@planetinternet.be> writes:

> Another question do we really need MSVC 6.0 or is Jacob's Navia's win32 lcc
> also a good alternative.

Don't know anything about win32 lcc, but other native Win32 gcc port
(Mingw, see www.mingw.org) can now be used to build Ocaml.

- Dmitry Bely


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

Re: [Caml-list] Serious typechecking error involving new polymorphism (crash)

[Xavier Leroy]

> I've discovered a fairly serious typechecking bug in 3.05.  I'm
> reporting it on the webpage, but also want to mention it here so that
> people are aware.

Yes, this is a serious bug with polymorphic methods and fields.
Expect a 3.06 release as soon as it is fixed.  In the meantime, you're
welcome to experiment with polymorphic methods and fields, but don't
bet the farm on them...

- Xavier Leroy
-------------------
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

Re: [Caml-list] Serious typechecking error involving new polymorphism (crash)

[John Prevost]

>>>>> "xl" == Xavier Leroy <xavier.leroy@inria.fr> writes:

    xl> Yes, this is a serious bug with polymorphic methods and
    xl> fields.  Expect a 3.06 release as soon as it is fixed.  In the
    xl> meantime, you're welcome to experiment with polymorphic
    xl> methods and fields, but don't bet the farm on them...

Polymorphic methods should be safe, as far as I can tell, since method
calls provide natural points of polymorphism, and storage in the class
is not allowed to be polymorphic.  (That is, you can't pull the same
trick with an object because you can't store a polymorphic value to be
shared across multiple results from a method call, and any
insufficiently polymorphic value returned from a polymorphic method
call is caught.)

Can you share any plans for polymorphic records?  I can see no way to
make them safe except to restrict the contents to function values
(which prevents the use of abstract types which are safe, but is
survivable) or to extend the system so that any value may be
polymorphic.  (Which would then allow for the two argument types of :=
to be checked to see if they're equally polymorphic.)

I presume this second option might complicate typechecking
dramatically, though.  Otherwise, why avoid it?  (You can always use a
struct wrapper on the value at the moment to get the desired
effect--to make a list of map-type functions, for example.)

John.

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

Re: [Caml-list] Serious typechecking error involving new polymorphism (crash)

[Sven LUTHER]

On Tue, Jul 30, 2002 at 09:58:33AM +0200, Xavier Leroy wrote:
> > I've discovered a fairly serious typechecking bug in 3.05.  I'm
> > reporting it on the webpage, but also want to mention it here so that
> > people are aware.
> 
> Yes, this is a serious bug with polymorphic methods and fields.
> Expect a 3.06 release as soon as it is fixed.  In the meantime, you're
> welcome to experiment with polymorphic methods and fields, but don't
> bet the farm on them...

Xavier, don't you think it would be a good time for going with a dual cvs
branch scheme or something like that, where you have a released branch
(3.05, and bugfix releases : 3.05.1, 3.05.2, etc) and a development
branch (which will become 3.06).

I suppose it is easy now to do a 3.06 bufix release, but what will
happen when you encouter such a serious bug which needs fixing, when you
are in the middle of developpment of the next version, and the cvs tree
is not really in a releasable state ?

In this case, will you revert all your changes and reapply after having
released the bugfix version, hurry the developpment so you can ship the
new version fixing the bug, or just let the bug stay until the next
version is released ?

None of these solutions appear satisfactory.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] Serious typechecking error involving new polymorphism (crash)

[Xavier Leroy]

> Polymorphic methods should be safe, as far as I can tell, since method
> calls provide natural points of polymorphism

You're right, the implicit function abstraction performed by methods
obviate the problem.  So, polymorphic methods are safe, it's "only"
polymorphic record fields that are broken.

> Can you share any plans for polymorphic records?  I can see no way to
> make them safe except to restrict the contents to function values

We'll need to discuss that within the Caml team, of which a
significant part is on vacations :-)  However, a natural solution is
indeed to apply the same generalization criterion as for polymorphic
"let": only expressions that are syntactic values (function
abstractions, identifiers, construction of non-mutable data
structures) can be put in a polymorphic record field.

- Xavier Leroy
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Yaron M. Minsky]

On Mon, 2002-07-29 at 08:45, Xavier Leroy wrote:
> Language features:
> - Support for polymorphic methods and record fields.
> - Allows _ separators in integer and float literals, e.g. 1_000_000.

I've found a bit of a problem with the _ separators in literals, which
is that they're not supported under camlp4.  This gets annoying when you
need to use streams...

-- 
|--------/            Yaron M. Minsky              \--------|
|--------\ http://www.cs.cornell.edu/home/yminsky/ /--------|

Open PGP --- KeyID B1FFD916 (new key as of Dec 4th)
Fingerprint: 5BF6 83E1 0CE3 1043 95D8 F8D5 9F12 B3A9 B1FF D916

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

Re: [Caml-list] bug-fix branches

[Xavier Leroy]

> Xavier, don't you think it would be a good time for going with a dual cvs
> branch scheme or something like that, where you have a released branch
> (3.05, and bugfix releases : 3.05.1, 3.05.2, etc) and a development
> branch (which will become 3.06).

The need for this isn't apparent yet: we haven't yet encountered a
situation where a show-stopper bug appears, but the main CVS branch is
far from a releasable state.  One reason for this is that major
evolutions of the system, e.g. polymorphic methods or dynamic loading
of C libraries, are carried on separate branches, and merged back only
when they are in a usable state.  

> In this case, will you revert all your changes and reapply after having
> released the bugfix version, hurry the developpment so you can ship the
> new version fixing the bug, or just let the bug stay until the next
> version is released ?

If that happens, we'll do what works best, and that might very well be
a bugfix branch.  But, frankly, this is our internal "cuisine", and I
don't see why you and other users should care.

- Xavier Leroy
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Scott J.]

Unfortunately I have the windows XP Professional OS installed.

Scott J.

----- Original Message -----
From: "Dmitry Bely" <dbely@mail.ru>
To: <caml-list@inria.fr>
Sent: Tuesday, July 30, 2002 9:51 AM
Subject: Re: [Caml-list] OCaml 3.05 released


> "Scott J." <jscott@planetinternet.be> writes:
>
> > Another question do we really need MSVC 6.0 or is Jacob's Navia's win32
lcc
> > also a good alternative.
>
> Don't know anything about win32 lcc, but other native Win32 gcc port
> (Mingw, see www.mingw.org) can now be used to build Ocaml.
>
> - Dmitry Bely
>
>
> -------------------
> 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
>

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

Re: [Caml-list] OCaml 3.05 released

[Dmitry Bely]

"Scott J." <jscott@planetinternet.be> writes:

> Unfortunately I have the windows XP Professional OS installed.

Why "unfortunately"? I am using Windows 2000 Prof (don't think XP is really
different), and have no problem with Mingw gcc and Ocaml...

>> > Another question do we really need MSVC 6.0 or is Jacob's Navia's win32
>> > lcc also a good alternative.
>>
>> Don't know anything about win32 lcc, but other native Win32 gcc port
>> (Mingw, see www.mingw.org) can now be used to build Ocaml.

- Dmitry Bely


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

Re: [Caml-list] bug-fix branches

[Sven LUTHER]

On Tue, Jul 30, 2002 at 04:11:29PM +0200, Xavier Leroy wrote:
> > Xavier, don't you think it would be a good time for going with a dual cvs
> > branch scheme or something like that, where you have a released branch
> > (3.05, and bugfix releases : 3.05.1, 3.05.2, etc) and a development
> > branch (which will become 3.06).
> 
> The need for this isn't apparent yet: we haven't yet encountered a
> situation where a show-stopper bug appears, but the main CVS branch is
> far from a releasable state.  One reason for this is that major
> evolutions of the system, e.g. polymorphic methods or dynamic loading
> of C libraries, are carried on separate branches, and merged back only
> when they are in a usable state.  

Ok, i didn't know that.

> > In this case, will you revert all your changes and reapply after having
> > released the bugfix version, hurry the developpment so you can ship the
> > new version fixing the bug, or just let the bug stay until the next
> > version is released ?
> 
> If that happens, we'll do what works best, and that might very well be
> a bugfix branch.  But, frankly, this is our internal "cuisine", and I
> don't see why you and other users should care.

Because it is easier to simply get a cvs version out of the bugfix
branch than having to look at the current cvs branch and extract from it
a bugfix patch, which may, or may not easily apply to the current
released version.

You know i did this for the powerpc fix for 3.04, and this doesn't apply
so much to big errors, which are often discovered early and were you do
a bugfix release, but for smaller problems for which you don't
necessarily think they would need a bugfix release.

Anyway, i was just asking, and i didn't know about the separate branches
for major evolutions, i guess this means that it will always be easy to
get a patch i need out of cvs and apply it to the released version.

But then, i know that you don't like for distributors to have versions
of ocaml which differ from the official releases, and having minor patch
number would help in identifying what the user is running exactly,
without having to remember that he is running debian and that i had to
apply this or that patch.

Anyway, i was just asking, if you feel it is your internal "cuisine" and
we should not meddle with it, i will understand.

Friendly,

Sven Luther
-------------------
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

[Caml-list] 3.05 and future 3.06 binary compatibility ?

[root]

Hello, ...

I know there will be a 3.06 release soon to fix the few bugs found in
3.05.

Will this 3.06 release be compatible with 3.05, or will we have to
rebuild all the libraries that were built with 3.05 for 3.06 ?

I know you strongly recommend that libraries are rebuilt for each new
ocaml version, but a parsing bug hardly seem to affect binary
compatibility.

Friendly,

Sven Luther
-------------------
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

[Caml-list] Re: 3.05 and future 3.06 binary compatibility ?

[Xavier Leroy]

> Will this 3.06 release be compatible with 3.05, or will we have to
> rebuild all the libraries that were built with 3.05 for 3.06 ?
> 
> I know you strongly recommend that libraries are rebuilt for each new
> ocaml version, but a parsing bug hardly seem to affect binary
> compatibility.

It's a type-checking bug, not a parsing bug.  You're correct that
fixing it is likely not to break binary compatibility.  

However, I have bad news for you: it turns out that the .cmi files for
3.05 have a different format than those for 3.04, and we forgot to
change the magic number in .cmi files whose purpose is precisely to
guard against using a .cmi file in an old format.  (The segfault
reported by Alexander Voinov on this list was tracked down to such an
undetected use of an old .cmi file.)  Hence, the magic number will be
bumped in 3.06, causing 3.05-compiled files to be rejected.

I know you will hate me for this, but I really don't see any better
solution.

- Xavier Leroy, who also spent a while rebuilding all his libs

PS.  Your mail had an invalid From address "root@iliana".  






> 
> Friendly,
> 
> Sven Luther
-------------------
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

[Caml-list] Re: 3.05 and future 3.06 binary compatibility ?

[Sven LUTHER]

On Thu, Aug 01, 2002 at 02:09:39PM +0200, Xavier Leroy wrote:
> > Will this 3.06 release be compatible with 3.05, or will we have to
> > rebuild all the libraries that were built with 3.05 for 3.06 ?
> > 
> > I know you strongly recommend that libraries are rebuilt for each new
> > ocaml version, but a parsing bug hardly seem to affect binary
> > compatibility.
> 
> It's a type-checking bug, not a parsing bug.  You're correct that
> fixing it is likely not to break binary compatibility.  

And would be versioned 3.05.1 or something such if we had three level
version numbers.

> However, I have bad news for you: it turns out that the .cmi files for
> 3.05 have a different format than those for 3.04, and we forgot to
> change the magic number in .cmi files whose purpose is precisely to
> guard against using a .cmi file in an old format.  (The segfault
> reported by Alexander Voinov on this list was tracked down to such an
> undetected use of an old .cmi file.)  Hence, the magic number will be
> bumped in 3.06, causing 3.05-compiled files to be rejected.

Ok, so this is the reason for the segfault during compile, while using
libraries built with 3.04 ?

I checked the .cm* magic number, and did not find them changed, so i
wondered.

Mmm, if the .cm* magic number is not changed (not because it was
forgotten), does this mean we don't need to rebuild the libraries ?

> I know you will hate me for this, but I really don't see any better
> solution.

Well, no problem for us, debian ocaml packaging policy mandate that each
library be compiled with exactly the same version of the ocaml suite
that is currently used anyway, so we will never be bitten by this.
We use the dependencies to make sure that this never cause problem (for
debian packaged libraries).

BTW, after some discution, we feel that for distributions, a scheme with
two camllib directories would be best, the first being the standard
camllib directoty (/usr/lib/ocaml) where we will put distribution
related stuff (packaged libraries), and the second being
/usr/local/lib/ocaml, or even better /usr/local/lib/ocaml/3.05, where
user installed stuff goes.

I already support this somewhat by putting /usr/lib/ocaml/stublibs and
/usr/local/lib/ocaml/stublibs in ld.conf, but i guess more support from
ocaml would be needed to have this work transparently with the -I +dir
options and other.

What do you think about this ?

> - Xavier Leroy, who also spent a while rebuilding all his libs

Well, the autobuilder handle that for us, but we have to bump the
version number and upgrade the dependencies (which could be automated
with something like the --version patch i sent to you).

> PS.  Your mail had an invalid From address "root@iliana".  

Yes, i was root at my homebox when i wrote this mail, and the address
translation did not kick in.

Friendly,

Sven Luther
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Jacques Garrigue]

From: "Scott J." <jscott@planetinternet.be>

> What is meant by first first-class polymorphism?

The ability to pass values with polymorphic types around.
This is mostly useful for objects, and lets you write type safe
visitor patterns for instance.

> Another question do we really need MSVC 6.0 or is Jacob's Navia's win32 lcc
> also a good alternative.

If you're happy with bytecode, you don't need any of these.
You can actually compile and link applications without a C compiler.
By the way, I've heard that a non-optimizing version of MSVC is
available for free in the .NET sdk. This may do if you really need to
do some custom linking or use native code.

> Can Olabl be used with windows?

O'Labl is now dead. All of its features (and more) have been included
in O'Caml. (But yes, olabl did work on windows)

   Jacques Garrigue
-------------------
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

Re: [Caml-list] OCaml 3.05 released

[Tim Freeman]

From: "Scott J." <jscott@planetinternet.be>
> What is meant by first first-class polymorphism?

From: Jacques Garrigue <garrigue@kurims.kyoto-u.ac.jp>
>The ability to pass values with polymorphic types around.
>This is mostly useful for objects, and lets you write type safe
>visitor patterns for instance.

Do you have any examples of a use for this?
-- 
Tim Freeman       
tim@fungible.com
GPG public key fingerprint ECDF 46F8 3B80 BB9E 575D  7180 76DF FE00 34B1 5C78 
-------------------
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

[Caml-list] Re: 3.05 and future 3.06 binary compatibility ?

[Sven LUTHER]

On Thu, Aug 01, 2002 at 02:09:39PM +0200, Xavier Leroy wrote:
> > Will this 3.06 release be compatible with 3.05, or will we have to
> > rebuild all the libraries that were built with 3.05 for 3.06 ?
> > 
> > I know you strongly recommend that libraries are rebuilt for each new
> > ocaml version, but a parsing bug hardly seem to affect binary
> > compatibility.
> 
> It's a type-checking bug, not a parsing bug.  You're correct that
> fixing it is likely not to break binary compatibility.  
> 
> However, I have bad news for you: it turns out that the .cmi files for
> 3.05 have a different format than those for 3.04, and we forgot to
> change the magic number in .cmi files whose purpose is precisely to
> guard against using a .cmi file in an old format.  (The segfault
> reported by Alexander Voinov on this list was tracked down to such an
> undetected use of an old .cmi file.)  Hence, the magic number will be
> bumped in 3.06, causing 3.05-compiled files to be rejected.

Hello Xavier ...

I face a problem with the 3.05 debian package :

  o I had thought to wait for the 3.06 release, before all the libraries
    get rebuilt for ocaml 3.05/3.06.

  o In the meantime, i released a ocaml 3.05 package to debian/unstable,
    but by doing so the autobuilder try to build new versions of
    libraries against ocaml 3.05, which does not work, because of the
    build dependencies.

So, i face a problem, which can be solved by :

  o removing the 3.05 ocaml package (and upload it to
  debian/experimental) and keep the 3.04 package in unstable for now
  (note that experimental is not a propper debian distribution, just a
  place to put packages that cannot go into unstable/testing), and wait
  for the 3.06 release.

  o bump the .cmi magic numbers (i suppose you have a patch for that in
  CVS that i can use), and release a new ocaml package (3.05-2), then
  rebuild the libraries with build dependency on ocaml >= 3.05-2 and
  < 3.07, so that they will work with the current ocaml 3.05 and the
  future ocaml 3.06 when it is released. In this second case, i need to
  be sure that there will be no binary incompatibility between ocaml
  3.05 and 3.06, like you implied in your previous mail.

Anyway, it would be nice to know what the timeframe of the 3.06 release
is going to be, and if my assumption on binary compatibility is not
going to cause problems.

Friendly,

Sven Luther
> 
> I know you will hate me for this, but I really don't see any better
> solution.
> 
> - Xavier Leroy, who also spent a while rebuilding all his libs
> 
> PS.  Your mail had an invalid From address "root@iliana".  
> 
> 
> 
> 
> 
> 
> > 
> > Friendly,
> > 
> > Sven Luther
-------------------
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

[Caml-list] Re: 3.05 and future 3.06 binary compatibility ?

[Xavier Leroy]

> So, i face a problem, which can be solved by :
> 
>   o removing the 3.05 ocaml package (and upload it to
>   debian/experimental) and keep the 3.04 package in unstable for now
>   (note that experimental is not a propper debian distribution, just a
>   place to put packages that cannot go into unstable/testing), and wait
>   for the 3.06 release.
>
>   o bump the .cmi magic numbers [...]

I would recommend the first approach.  The second is (1) more work,
(2) a bit of a hack, and (3) not guaranteed to save you work in the end.

> Anyway, it would be nice to know what the timeframe of the 3.06 release
> is going to be

Well, it was scheduled for this week, but a couple of last-minute bug
report had to be investigated.  The current estimate is aug 19-23,
assuming (of course) no more bugs pop up.

- Xavier Leroy
-------------------
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

[Caml-list] Re: 3.05 and future 3.06 binary compatibility ?

[Sven LUTHER]

On Fri, Aug 09, 2002 at 02:25:46PM +0200, Xavier Leroy wrote:
> > So, i face a problem, which can be solved by :
> > 
> >   o removing the 3.05 ocaml package (and upload it to
> >   debian/experimental) and keep the 3.04 package in unstable for now
> >   (note that experimental is not a propper debian distribution, just a
> >   place to put packages that cannot go into unstable/testing), and wait
> >   for the 3.06 release.
> >
> >   o bump the .cmi magic numbers [...]
> 
> I would recommend the first approach.  The second is (1) more work,
> (2) a bit of a hack, and (3) not guaranteed to save you work in the end.

Yes, i think most people would prefer this also, but then, the 3.05-1
package is already in unstable, and cannot be removed, thus i will have
to either use epochs in version numbers (a thing i will have to keep
forever after, which is not nice and not really needed), or release a
package versioned something like 3.05_is_really_3.04, which is not
really nice also.

I think i will probably go with this second solution for now, expecially
since ...

> > Anyway, it would be nice to know what the timeframe of the 3.06 release
> > is going to be
> 
> Well, it was scheduled for this week, but a couple of last-minute bug
> report had to be investigated.  The current estimate is aug 19-23,
> assuming (of course) no more bugs pop up.

... 3.06 will be released RSN.

So if all agree, i will release a ocaml 3.05.is_really.3.04-1 package
which will go back to the older 3.04-13 package, and keep 3.04 built
libraries around, and switch to 3.06 in the begining of september or
something such, and we can start rebuilding the libraries.

After that, i could even manage two things :

  o Build regular cvs snapshot packages of ocaml and upload them to
    experimental. The same could be done for some of the libraries also,
    particularly at times were the binary compatibility is broken, if i
    know about it. These could even be built to install in a parallel
    way to the normal ocaml packages. For this having the debian
    directory in CVS would be nice, i think.

  o When the next ocaml release happens, build the packages and put them
    in experimental, or in another debian temporary staging areas (i
    have to figure how this works), and upload the whole of it into
    unstable/testing once we are somewhat sure that the release is
    really stable.

How do you all feel about this ?

Friendly,

Sven Luther
> 
> - Xavier Leroy
-------------------
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