ocaml/ocaml

The core OCaml system: compilers, runtime system, base libraries

⚠️ CAUTION

The developer team released OCaml 5.0.0 in December 2022. This release sports a full rewrite of its runtime system for shared-memory parallel programming using domains and native support for concurrent programming using effect handlers.

Owing to the large number of changes, the initial 5.0 release is more experimental than usual. It is recommended that all users wanting a stable release use the 4.14 release which will continue to be supported and updated while 5.x reaches feature and stability parity. Similarly, if you need one of the ports not yet supported in the 5.0 release you must use the 4.14 release.

The initial release of OCaml 5.0 only supports the native compiler under ARM64 and x86-64 architectures under Linux, macOS and the BSDs. On Windows, only the MinGW-w64 port is supported in OCaml 5.0 and the Cygwin port is restored in 5.1. On Linux, native code support for RISC-V and s390x/IBM Z is available in OCaml 5.1 and in 5.2 for Power.

❗ From OCaml 5.0 onwards, native compilation is available only on 64-bit systems. Native compilation on 32-bit systems is no longer available, nor are there plans to bring it back. The bytecode compiler will continue to work on all architectures.

Branch trunk	Branch 5.2	Branch 5.1	Branch 5.0	Branch 4.14

README

Overview

OCaml is a functional, statically-typed programming language from the ML family, offering a powerful module system extending that of Standard ML and a feature-rich, class-based object system.

OCaml comprises two compilers. One generates bytecode which is then interpreted by a C program. This compiler runs quickly, generates compact code with moderate memory requirements, and is portable to many 32 or 64 bit platforms. Performance of generated programs is quite good for a bytecoded implementation. This compiler can be used either as a standalone, batch-oriented compiler that produces standalone programs, or as an interactive REPL system.

The other compiler generates high-performance native code for a number of processors. Compilation takes longer and generates bigger code, but the generated programs deliver excellent performance, while retaining the moderate memory requirements of the bytecode compiler. The native-code compiler currently runs on the following platforms:

	Tier 1 (actively maintained)	Tier 2 (maintained when possible)
x86 64 bits	Linux, macOS, Windows, FreeBSD	NetBSD, OpenBSD, OmniOS (Solaris)
ARM 64 bits	Linux, macOS	FreeBSD, OpenBSD, NetBSD
Power 64 bits	Linux (little-endian, ABIv2)	Linux (big-endian, ABIv2)
RISC-V 64 bits	Linux
IBM Z (s390x)	Linux

Other operating systems for the processors above have not been tested, but the compiler may work under other operating systems with little work.

Copyright

All files marked "Copyright INRIA" in this distribution are Copyright © 1996-2023 Institut National de Recherche en Informatique et en Automatique (INRIA) and distributed under the conditions stated in file LICENSE.

Installation

See the file INSTALL.adoc for installation instructions on machines running Unix, Linux, macOS, WSL and Cygwin. For native Microsoft Windows, see README.win32.adoc.

Documentation

The OCaml manual is distributed in HTML, PDF, and Emacs Info files. It is available at

https://ocaml.org/releases/latest/manual.html

Availability

The complete OCaml distribution can be accessed at

https://ocaml.org/docs/install.html

Keeping in Touch with the Caml Community

There is an active and friendly discussion forum at

https://discuss.ocaml.org/

The OCaml mailing list is the longest-running forum for OCaml users. You can email it at

[email protected]

You can subscribe and access list archives via the Web interface at

https://sympa.inria.fr/sympa/subscribe/caml-list

There also exist other mailing lists, chat channels, and various other forums around the internet for getting in touch with the OCaml and ML family language community. These can be accessed at

https://ocaml.org/community/

In particular, the IRC channel #ocaml on Libera has a long history and welcomes questions.

Bug Reports and User Feedback

Please report bugs using the issue tracker at https://github.com/ocaml/ocaml/issues

To be effective, bug reports should include a complete program (preferably small) that exhibits the unexpected behavior, and the configuration you are using (machine type, etc).

For information on contributing to OCaml, see HACKING.adoc and CONTRIBUTING.md.

Separately maintained components

Some libraries and tools which used to be part of the OCaml distribution are now maintained separately and distributed as OPAM packages. Please use the issue trackers at their respective new homes:

Library	Removed since	OPAM package
The Stream and Genlex standard library modules	OCaml 5.0	camlp-streams
The Graphics library	OCaml 4.09	graphics
The Num library	OCaml 4.06	num
The OCamlbuild tool	OCaml 4.03	ocamlbuild
The camlp4 tool	OCaml 4.02	camlp4
The LablTk library	OCaml 4.02	labltk
The CamlDBM library	OCaml 4.00	dbm
The OCamlWinTop Windows toplevel	OCaml 4.00	none

ocaml's Issues

Documentation for size parameter of Hashtbl.create

Original bug ID: 7
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Norman Ramsey
Version: 2.03
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

The documentation for Hashtbl.create should indicate whether the initial
guess is for the size of the table or the number of elements. Since it
appears that the size of the table is managed automatically, I imagine
the hint should be the number of elements that is expected to put into
the table, but it is worth saying this explicitly.

type abbreviation hides constraints

Original bug ID: 3
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Hendrik Tews
Version: 2.02
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

Hi,

if I type

# class type ['a] cta = object val a_val : 'a method b : int end;;
# class ['a] ca (a:'a) : ['a] cta =
   object val a_val = a method b = a_val#get + 5 end;; 

into the toplevel, the system derives the type

class ['a] ca : 'a -> ['a] cta 

IMO this is wrong, because there must be a constraint for the type
parameter of class ca (the constraint becomes visible, if the
type annotation ['a] cta is left out). The problem becomes even
more apparent, when the system derives for

# module M = struct class ['a] ca (a:'a) : ['a] cta =
  object val a_val = a method b = a_val#get + 5 end end ;;

the type

  module M : sig class ['a] ca : 'a -> ['a] cta end

because

# module type MT = sig class ['a] ca : 'a -> ['a] cta end;;
# module M : MT = struct class ['a] ca (a:'a) : ['a] cta =
  object val a_val = a method b = a_val#get + 5 end end ;;

produces an error.

thread-safety and I/O

Original bug ID: 24
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Gerd Stolpmann
Version: 2.04 -with-pthread
OS: Linux-2.2.13 with glibc-6.1
Submission from: master.proxy.ision.net (195.180.208.40)

The following piece of code "q.ml", compiled with
ocamlopt -o q -thread unix.cmxa threads.cmxa q.ml -cclib -lunix -cclib
-lthreadsnat -cclib -pthread
does not work if "n" is less than 1024.

"q.data" is a file with contents "abcd\n".

If it works correctly, the program must not produce any output.

let n = 1023 in
for i = 1 to 50 do (* 50 threads doing I/O )
let id =
Thread.create
(fun () ->
for j = 1 to 100 do ( read the file 100 times *)
let ch = open_in "q.data" in
let u =
let s = String.create n in
ignore(input ch s 0 5);
String.sub s 0 5
in
close_in ch;
if u <> "abcd\n" then
let v =
Printf.sprintf "i=%d j=%d s=%s\n" i j u in
prerr_endline v;
done;
)
()
in
l := id :: !l
done;

List.iter
(fun id ->
Thread.join id)
!l
;;

Re: Garbage collection problem

Original bug ID: 34
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,

Thank you for your message to the Caml mailing list.

However your message seems to be a bug report; hence I send it to the
relevant mailing list

[email protected]

Thank again for your interest in Caml.

Pierre Weis

INRIA, Projet Cristal, [email protected], http://cristal.inria.fr/~weis/

The following piece of code will:

• Create a table in a database.

• Load the table with a list of rows.

• Select and print the contents of the table gIter times.

• Delete the contents of the table.

• Drop the table from the database.

  let main conn =
  ED.create conn; (* Create the table )
  List.iter (ED.put conn) data; ( Load the table )
  for i = 1 to !gIter do ( Select and print )
  EStrm.iter ED.printer conn ("select * from " ^ ED.tableName)
  done;
  ED.delete conn; ( Delete the contents )
  ED.drop conn ( Drop the table *)

The problem I'm having is that the code will fail with a segmentation
violation for sufficiently large values of gIter (> 10000). This occurs
under a variety of databases including Postgres, Mysql(IODBC), Sybase ASE
(Linux), and ODBC under Windows NT 4.0.

At first, I suspected that the problem must be in my foreign function
libraries. Further tests showed that there a appeared to be a memory
leak. Then I tried moving the loop outside:

let main conn =
for i = 1 to !gIter do
ED.create conn;
List.iter (ED.put conn) data;
EStrm.iter ED.printer conn ("select * from " ^ ED.tableName)
ED.delete conn;
ED.drop conn
done

This ran without any problems so I began to suspect the databases.

Then I tried adding a call to Gc.minor():

let main conn =
ED.create conn;
List.iter (ED.put conn) data;
for i = 1 to !gIter do
Gc.minor();
EStrm.iter ED.printer conn ("select * from " ^ ED.tableName)
done;
ED.delete conn;
ED.drop conn

This seemed to clear up all problems with the first version. The
memory consumed by the application remained constant for very
large values of gIter and no crashes occurred.

Are their situations where it's necessary to call Gc functions
or is this a bug? What are the costs associated with calling
Gc functions?

I'm running OCaml 2.04 under RedHat Linux 6.0 and Windows NT 4.0 SP5.

re: Objective Caml 2.99 released

Original bug ID: 14
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

This does not mean that we are aware of any bug, [...]

• labltk: another version of the ocamltk Tcl/Tk interface. It
  allows for a more natural syntax, using optional arguments.

Here's a patch and a bug report for labltk.

1. The link scripts contain a couple of typos:

--- ocaml-2.99/otherlibs/labltk/lib/Makefile~ Wed Dec 15 16:02:14 1999
+++ ocaml-2.99/otherlibs/labltk/lib/Makefile Tue Dec 21 13:11:19 1999
@@ -35,15 +35,15 @@
labltklink: Makefile $(TOPDIR)/config/Makefile
@echo Generate $@
@echo "#!/bin/sh" > $@

• @echo 'exec ocamlc -custom -I $(LABLTKDIR) tk41.cma "$$@"\' >> $@
• @echo ' -cclib "-L$(LABLTKDIR) -llabltk41 $(TK_LINK)"\' &gt;&gt; $@

• @echo 'exec ocamlc -custom -I $(LABLTKDIR) tk41.cma "$$@" ' >> $@
• @echo ' -cclib "-L$(LABLTKDIR) -llabltk41 $(TK_LINK)" ' &gt;&gt; $@
  @echo ' $(X11_LINK) -cclib "$(CCLIBS) $(DLLIB)"' &gt;&gt; $@

labltkopt: Makefile $(TOPDIR)/config/Makefile
@echo Generate $@
@echo "#!/bin/sh" > $@

• @echo 'exec ocamlopt -custom -I $(LABLTKDIR) tk41.cmxa "$$@"\' >> $@
• @echo ' -cclib "-L$(LABLTKDIR) -llabltk41 $(TK_LINK)"\' &gt;&gt; $@

• @echo 'exec ocamlopt -I $(LABLTKDIR) tk41.cmxa "$$@" ' >> $@
• @echo ' -cclib "-L$(LABLTKDIR) -llabltk41 $(TK_LINK)" ' &gt;&gt; $@
  @echo ' $(X11_LINK) -cclib "$(CCLIBS) $(DLLIB)"' &gt;&gt; $@

All .{ml,mli} files are generated in this directory

2. The colors of labltk applications coe out wrong with the native
   compiler on my Linux system (see below for the configuration,
   the bug is independent of whether I use native threads or not).
   E.g. ./eyes.opt has green eyes, while ./eyes is black on white.
   I haven't investigated this further yet.

** Configuration summary **

Directories where Objective Caml will be installed:
binaries.................. /home/ohl/ml/OCaml/bin
standard library.......... /home/ohl/ml/OCaml/lib/ocaml
manual pages.............. /home/ohl/ml/OCaml/man/man1 (with extension .1)
Configuration for the bytecode compiler:
C compiler used........... gcc
options for compiling..... -fno-defer-pop -Wall -Wno-unused -D_REENTRANT
options for linking....... -lm
Configuration for the native-code compiler:
hardware architecture..... i386
OS variant................ linux_elf
C compiler used........... gcc
options for compiling..... -Wall -Wno-unused -D_REENTRANT
options for linking....... -lm
assembler ................ $(AS)
preprocessed assembler ... gcc -c -DSYS_$(SYSTEM)
profiling with gprof ..... supported
Source-level replay debugger: supported
Configuration for the external libraries:
libraries supported....... unix str num dynlink systhreads graph dbm labltk
The "num" library:
target architecture ...... x86
The "graph" library:
options for compiling .... -I/usr/X11R6/include
options for linking ...... -cclib -L/usr/X11R6/lib -cclib -lX11
The "labltk" library:
use tcl/tk version ....... 7.6
options for compiling ....
options for linking ...... -ltcl7.6 -ltk4.2 -ldl

Season's Greetings,
-Thorsten

Thorsten Ohl, Physics Department, TU Darmstadt -- [email protected]
http://heplix.ikp.physik.tu-darmstadt.de/~ohl/ [<=== PGP public key here]

pbme installation numerix

Original bug ID: 40
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour.

J'essaie d'installer numerix.
J'utilise ocam 2.02

Machine : une sillicon graphics
uname -a ==> IRIX64 leger 6.2 06101031 IP28

La config fournit gnumake, mais pas gcc ...

Je ne peux compiler ni pour ocaml, ni pour caml.
J'ai tente les options les + basiques (Clong, etc).
J'ai l'impression que les messages d'erreur sont + clairs
pour le cas de caml. Je vous joins le Makefile, et la sortie
stdout/stderr de : gnumake lib (j'ai bien fait le gnumake clean avant)
En esperant que le bug vous paraitra evident.

===============

Qd je ne demande pas caml, mais seulement ocaml :
gnumake clean, gnumake lib se passent bien (enfin... memes
warnings qu'avant du preprocesseur), mais
lors de "gnumake exemples",
dans la compilation de numerix/exemples/cmp/ocaml/cmp.ml,
survient le message d'erreur: Unbound module type Int_type
ligne 10 : "module Main(E:Int_type) = struct "
La commande en cours est :

ocamlc -custom -o cmp-byte -I ../../../lib/ocaml nums.cma numerix.cmo
cmp.ml -ccopt -L../../../
lib/common -cclib -lmlnumx -cclib -lnums
et ../../../lib/ocaml contient bien numerix.cmi, .cmo, etc,
et le open Numerix qui precede n'a pas pose de problemes...

ocamlnumx a ete cree. Quand je le lance, la banniere est:
% ocamlnumx
Objective Caml version 2.02

il ne donne donc pas de liste de modules disponibles (contrairement
a la doc).

================

Any hint ?

--
Dominique Michelucci [email protected]
http://www.emse.fr/~micheluc
Ecole Nationale Superieure des Mines de St-Etienne
158 cours Fauriel, 42023 Saint Etienne cedex 2, France
Tel: [phone] from abroad, 04 77 42 01 73 from France
Fax: [phone] from abroad, 04 77 42 66 66 from France

---

+----------------------------------------------------------------------------+

| |

| Entiers de longueur arbitraire |

| Arbitrarily lengthy integers |

| |

| Règles de compilation |

| Compile rules |

| |

+----------------------------------------------------------------------------+

M. Quercia, 2 Feb 2000

Note : Utilisez GNU-make pour compiler, un make ordinaire ne marche pas

Use GNU-make to build the libraries, ordinary make doesn't work

               # +---------------------------+
               # |  taille d'un mot machine  |
               # |      machine word size    |
               # +---------------------------+

export BITS_64 = 0
export BITS_32 = 1

              # +-----------------------------+
              # |  bibliothèques à contruire  |
              # |     libraries to build      |
              # +-----------------------------+

code C portable, portable C code

export USE_CLONG = 1

code C avec les entiers long long (ne marche pas en 64 bits)

C code with gcc long long datatype (doesn't work on 64 bits platform)

export USE_DLONG = 0

Code assembleur x86, x86 assembly code

export USE_SLONG = 0

Si vous avez GMP-2.02, if you have GMP-2.02

#export USE_GMP = 1
export USE_GMP = 0

                    # +------------------+
                    # |   quoi faire ?   |
                    # | what to build ?  |
                    # +------------------+

bibliothèque pour programmation en C

build the C programming libraries

#export MAKE_C_LIB = 1
export MAKE_C_LIB = 0

bibliothèque pour programmation en Ocaml

build the Ocaml programming libraries

export MAKE_OCAML_LIB = 1

bibliothèque pour programmation en Caml-light

build the Caml-light programming libraries

export MAKE_CAML_LIB = 1
#export MAKE_CAML_LIB = 0

bibliothèque pour programmation en Pascal

build the Pascal programming libraries

export MAKE_PASCAL_LIB = 0

Versions de Ocaml et Camllight sans point décimal

Ocaml and Camllight versions without period

export OCAML_VERSION = 202
export CAML_VERSION = 074

                     # +---------------+
                     # |  Répertoires  |
                     # |  Directories  |
                     # +---------------+

où se trouvent les fichiers de Caml-Ocaml, where are Caml-Ocaml files ?

#export CAML_LIBDIR = /usr/local/lib/caml-light
export CAML_LIBDIR = /usr/share/local/Caml/lib
#export OCAML_LIBDIR = /usr/local/lib/ocaml
export OCAML_LIBDIR = $(HOME)/OCAML/lib

installation, installation

#export INSTALL_LIB = $(HOME)/test/lib
export INSTALL_LIB = $(HOME)/OCAML/lib
#export INSTALL_INCLUDE = $(HOME)/test/include
export INSTALL_INCLUDE = $(HOME)/OCAML/lib
#export INSTALL_BIN = $(HOME)/test/bin
export INSTALL_BIN = $(HOME)/OCAML/bin

#----------------------- Ne rien changer au delà -----------------------

Nothing to change below

                   # +-------------------+
                   # |  cibles, targets  |
                   # +-------------------+

.PHONY : all lib install exemples examples tests clean exclean

all: lib exemples

lib:
cd lib; $(MAKE) all

install:
cd lib; $(MAKE) install

exemples:
cd exemples; $(MAKE) all

examples: exemples

ex-%:
cd exemples; $(MAKE) $(patsubst ex-%,%,$@)

test:
cd exemples; $(MAKE) test

clean:
cd lib; $(MAKE) clean
cd exemples; $(MAKE) clean

       # +-------------------------------------------+
       # |  options de compilation, compile options  |
       # +-------------------------------------------+

initialisations inutiles pour éviter les avertissemens de gcc

useless initializations to avoid gcc warnings

export CFLAGS += -Duseless_init

pour déboguage, for debugging

#CFLAGS += -Ddebug_k -Ddebug_some

taille des mots machine, machine word size

ifeq ($(strip $(BITS_64)),1)
CFLAGS += -Dbits_64
endif
ifeq ($(strip $(BITS_32)),1)
CFLAGS += -Dbits_32
endif

     # +----------------------------------------------+
     # |  Commandes de compilation, compile commands  |
     # +----------------------------------------------+

export GCC = gcc -O2 -Wall $(CFLAGS)

export GCC = cc -mips3 -n32 -O2 $(CFLAGS)
#export CPP = cpp -P
export CPP = cc -P

export CAML = camlc
export CAMLLIBR = camllibr
export CAMLMKTOP = camlmktop

export OCAML = ocamlc
export OCAMLOPT = ocamlopt
export OCAMLMKTOP = ocamlmktop

export AR = ar -rcs

          # +-------------------------------------+
          # |  Numéro de version, version number  |
          # +-------------------------------------+

export NUMERIX_VERSION = '0.13 (2 Feb 2000)'

---

cd lib; gnumake all
gnumake[1]: Entering directory /tmp_mnt/hosts/picasso/usr/people/domi/ESSAI_CAML/numerix/lib' for dir in common ocaml camllight; do (cd $dir; gnumake all) || break; done gnumake[2]: Entering directory /tmp_mnt/hosts/picasso/usr/people/domi/ESSAI_CAML/numerix/lib/common'
cc -mips3 -n32 -O2 -Duseless_init -Dbits_32 -c chrono.c
cc -mips3 -n32 -O2 -Duseless_init -Dbits_32 -o long_int-c.o -c long_int.c
"long_int.h", line 142: warning(1011): unrecognized preprocessing directive
#warning "Taille des mots inconnue, definir l'un des symboles 'bits_64'"
^

"long_int.h", line 143: warning(1011): unrecognized preprocessing directive
#warning "ou 'bits_32' selon votre architecture."
^

"long_int.h", line 144: warning(1011): unrecognized preprocessing directive
#warning
^

"long_int.h", line 145: warning(1011): unrecognized preprocessing directive
#warning "Unknown word size, define one of the symbols 'bits_64'"
^

"long_int.h", line 146: warning(1011): unrecognized preprocessing directive
#warning "or 'bits_32' depending on your hardware."
^

"long_int.c", line 2308: warning(1183): pointless comparison of unsigned
integer with zero
if (a < 0) {
^

cc -mips3 -n32 -O2 -Duseless_init -Dbits_32 -DOCAML_VERSION=202 -I/usr/people/domi/OCAML/lib -o ml-long_int-c.o -c ml-long_int.c
"long_int.h", line 142: warning(1011): unrecognized preprocessing directive
#warning "Taille des mots inconnue, definir l'un des symboles 'bits_64'"
^

"long_int.h", line 143: warning(1011): unrecognized preprocessing directive
#warning "ou 'bits_32' selon votre architecture."
^

"long_int.h", line 144: warning(1011): unrecognized preprocessing directive
#warning
^

"long_int.h", line 145: warning(1011): unrecognized preprocessing directive
#warning "Unknown word size, define one of the symbols 'bits_64'"
^

"long_int.h", line 146: warning(1011): unrecognized preprocessing directive
#warning "or 'bits_32' depending on your hardware."
^

ar -rcs libmlnumx.a chrono.o long_int-c.o ml-long_int-c.o
cc -mips3 -n32 -O2 -Duseless_init -Dbits_32 -I/usr/share/local/Caml/lib -Duse_camllight -o cl-long_int-c.o -c ml-long_int.c
"long_int.h", line 142: warning(1011): unrecognized preprocessing directive
#warning "Taille des mots inconnue, definir l'un des symboles 'bits_64'"
^

"long_int.h", line 143: warning(1011): unrecognized preprocessing directive
#warning "ou 'bits_32' selon votre architecture."
^

"long_int.h", line 144: warning(1011): unrecognized preprocessing directive
#warning
^

"long_int.h", line 145: warning(1011): unrecognized preprocessing directive
#warning "Unknown word size, define one of the symbols 'bits_64'"
^

"long_int.h", line 146: warning(1011): unrecognized preprocessing directive
#warning "or 'bits_32' depending on your hardware."
^

"ml-long_int.c", line 64: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(a,x,l,b);
^

"ml-long_int.c", line 64: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(a,x,l,b);
^

"ml-long_int.c", line 71: error(1133): expression must be a modifiable lvalue
Alloc_1_1(b,la,a);
^

"ml-long_int.c", line 176: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,la,a);
^

"ml-long_int.c", line 185: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,la,a);
^

"ml-long_int.c", line 185: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,la,a);
^

"ml-long_int.c", line 193: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,la,a);
^

"ml-long_int.c", line 202: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,la,a);
^

"ml-long_int.c", line 202: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,la,a);
^

"ml-long_int.c", line 215: error(1133): expression must be a modifiable lvalue
Alloc_1_2(c,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 215: error(1133): expression must be a modifiable lvalue
Alloc_1_2(c,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 223: error(1133): expression must be a modifiable lvalue
Alloc_1_2(c,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 223: error(1133): expression must be a modifiable lvalue
Alloc_1_2(c,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 231: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 231: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 231: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 238: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 238: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 238: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,max(la,lb)+1,a,b);
^

"ml-long_int.c", line 255: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,lc,a);
^

"ml-long_int.c", line 271: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,lc,a);
^

"ml-long_int.c", line 287: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,lc,a);
^

"ml-long_int.c", line 287: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,lc,a);
^

"ml-long_int.c", line 301: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,lc,a);
^

"ml-long_int.c", line 301: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,lc,a);
^

"ml-long_int.c", line 318: error(1133): expression must be a modifiable lvalue
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 318: error(1133): expression must be a modifiable lvalue
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 318: error(1133): expression must be a modifiable lvalue
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 318: warning(1551): variable "c" is used before its
value is set
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 318: error(1133): expression must be a modifiable lvalue
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 318: warning(1551): variable "d" is used before its
value is set
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 318: error(1133): expression must be a modifiable lvalue
AllocN_2_1(res,2,c,lc,d,ld,a);
^

"ml-long_int.c", line 334: error(1133): expression must be a modifiable lvalue
Enlarge_2_1(c,x,lc,d,y,ld,a);
^

"ml-long_int.c", line 334: error(1133): expression must be a modifiable lvalue
Enlarge_2_1(c,x,lc,d,y,ld,a);
^

"ml-long_int.c", line 334: error(1133): expression must be a modifiable lvalue
Enlarge_2_1(c,x,lc,d,y,ld,a);
^

"ml-long_int.c", line 334: error(1133): expression must be a modifiable lvalue
Enlarge_2_1(c,x,lc,d,y,ld,a);
^

"ml-long_int.c", line 334: error(1133): expression must be a modifiable lvalue
Enlarge_2_1(c,x,lc,d,y,ld,a);
^

"ml-long_int.c", line 334: warning(1551): variable "c" is used before its
value is set
Enlarge_2_1(c,x,lc,d,y,ld,a);
^

"ml-long_int.c", line 345: error(1133): expression must be a modifiable lvalue
Alloc_1_2(d,ld,a,b);
^

"ml-long_int.c", line 345: error(1133): expression must be a modifiable lvalue
Alloc_1_2(d,ld,a,b);
^

"ml-long_int.c", line 357: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(d,x,ld,a,b);
^

"ml-long_int.c", line 357: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(d,x,ld,a,b);
^

"ml-long_int.c", line 357: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(d,x,ld,a,b);
^

"ml-long_int.c", line 370: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,la+2,a);
^

"ml-long_int.c", line 380: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,la+2,a);
^

"ml-long_int.c", line 380: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,la+2,a);
^

"ml-long_int.c", line 387: error(1133): expression must be a modifiable lvalue
Alloc_1_2(c,la+lb,a,b);
^

"ml-long_int.c", line 387: error(1133): expression must be a modifiable lvalue
Alloc_1_2(c,la+lb,a,b);
^

"ml-long_int.c", line 395: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,la+lb,a,b);
^

"ml-long_int.c", line 395: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,la+lb,a,b);
^

"ml-long_int.c", line 395: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(c,x,la+lb,a,b);
^

"ml-long_int.c", line 408: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,2*la,a);
^

"ml-long_int.c", line 417: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,2*la,a);
^

"ml-long_int.c", line 417: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,2*la,a);
^

"ml-long_int.c", line 434: error(1133): expression must be a modifiable lvalue
AllocN_1_1(res,2,q,max(la,2),a);
^

"ml-long_int.c", line 434: error(1133): expression must be a modifiable lvalue
AllocN_1_1(res,2,q,max(la,2),a);
^

"ml-long_int.c", line 434: warning(1551): variable "q" is used before its
value is set
AllocN_1_1(res,2,q,max(la,2),a);
^

"ml-long_int.c", line 434: error(1133): expression must be a modifiable lvalue
AllocN_1_1(res,2,q,max(la,2),a);
^

"ml-long_int.c", line 447: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(q,x,max(la,2),a);
^

"ml-long_int.c", line 447: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(q,x,max(la,2),a);
^

"ml-long_int.c", line 459: error(1133): expression must be a modifiable lvalue
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: error(1133): expression must be a modifiable lvalue
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: error(1133): expression must be a modifiable lvalue
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: warning(1551): variable "q" is used before its
value is set
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: error(1133): expression must be a modifiable lvalue
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: warning(1551): variable "r" is used before its
value is set
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: error(1133): expression must be a modifiable lvalue
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 459: error(1133): expression must be a modifiable lvalue
AllocN_2_2(res,2,q,lq,r,max(la+1,lb),a,b);
^

"ml-long_int.c", line 474: error(1133): expression must be a modifiable lvalue
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 474: error(1133): expression must be a modifiable lvalue
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 474: error(1133): expression must be a modifiable lvalue
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 474: error(1133): expression must be a modifiable lvalue
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 474: error(1133): expression must be a modifiable lvalue
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 474: error(1133): expression must be a modifiable lvalue
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 474: warning(1551): variable "q" is used before its
value is set
Enlarge_2_2(q,x,lq,r,y,lr,a,b);
^

"ml-long_int.c", line 483: error(1133): expression must be a modifiable lvalue
Alloc_1_2(q,lq,a,b);
^

"ml-long_int.c", line 483: error(1133): expression must be a modifiable lvalue
Alloc_1_2(q,lq,a,b);
^

"ml-long_int.c", line 494: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(q,x,lq,a,b);
^

"ml-long_int.c", line 494: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(q,x,lq,a,b);
^

"ml-long_int.c", line 494: error(1133): expression must be a modifiable lvalue
Enlarge_1_2(q,x,lq,a,b);
^

"ml-long_int.c", line 506: error(1133): expression must be a modifiable lvalue
Alloc_1_1(c,lc+1,a);
^

"ml-long_int.c", line 515: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,lc+1,a);
^

"ml-long_int.c", line 515: error(1133): expression must be a modifiable lvalue
Enlarge_1_1(c,x,lc+1,a);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: warning(1551): variable "p" is used before its
value is set
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: warning(1551): variable "q" is used before its
value is set
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: warning(1551): variable "u" is used before its
value is set
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: warning(1551): variable "v" is used before its
value is set
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: warning(1551): variable "d" is used before its
value is set
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 528: error(1133): expression must be a modifiable lvalue
AllocN_5_2(res,5,p,l,q,l,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: warning(1551): variable "u" is used before its
value is set
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: warning(1551): variable "v" is used before its
value is set
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: warning(1551): variable "d" is used before its
value is set
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 543: error(1133): expression must be a modifiable lvalue
AllocN_3_2(res,3,u,l,v,l,d,l,a,b);
^

"ml-long_int.c", line 562: error(1133): expression must be a modifiable lvalue
Alloc_1_2(d,l,a,b);
^

"ml-long_int.c", line 562: error(1133): expression must be a modifiable lvalue
Alloc_1_2(d,l,a,b);
^

"ml-long_int.c", line 576: error(1133): expression must be a modifiable lvalue
Enlarge_5_2(p,r,l,q,s,l,u,x,l,v,y,l,d,z,l,a,b);
^

"ml-long_int.c", line 576: error(1133): expression must be a modifiable lvalue
Enlarge_5_2(p,r,l,q,s,l,u,x,l,v,y,l,d,z,l,a,b);
^

Error limit reached.
100 errors detected in the compilation of "ml-long_int.c".
Compilation terminated.
gnumake[2]: *** [cl-long_int-c.o] Error 2
gnumake[2]: Leaving directory /tmp_mnt/hosts/picasso/usr/people/domi/ESSAI_CAML/numerix/lib/common' gnumake[1]: Leaving directory /tmp_mnt/hosts/picasso/usr/people/domi/ESSAI_CAML/numerix/lib'

---

---

ocamlyacc and $end

Original bug ID: 4
Reporter: administrator
Status: closed (set by @damiendoligez on 2005-12-15T14:48:34Z)
Resolution: won't fix
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Related to: #2823

Bug description

Full_Name: Judicael Courant
Version: 2.02
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

(re)Bonjour,

mes étudiants font très fort. Un autre binôme a trouvé (malgré lui et
sans oser m'en parler) ce qui me semble être un bug d'ocamlyacc. En
simplifié, ça donne :

lexer.mll

{
open Parser
}

rule token =
parse [ '\n' '\t' ' '] { token lexbuf}
| ['a'-'z']+ { IDENT(Lexing.lexeme lexbuf)}
| ['0'-'9']+ { INT(int_of_string (Lexing.lexeme lexbuf))}
| ['+'] { PLUS }
| ['('] { PARENG }
| [')'] { PAREND }
| eof { FIN }

{
let get_token l =
let t = token l in
(match t with
| IDENT s -> print_string "\nIDENT:" ; print_string s; print_newline()
| INT i -> print_string "\nINT" ; print_int i; print_newline ()
| PLUS -> print_string "\nPLUS\n" ; flush stdout
| FIN -> print_string "\nEOF\n" ; flush stdout
| PARENG -> print_string "\nPARENG\n"; flush stdout
| PAREND -> print_string "\nPAREND\n"; flush stdout);
t
}

parser.mly:

%{
%}

%token INT
%token IDENT
%token PLUS
%token PARENG PAREND
%token FIN

%left PLUS

%start main
%type main

%%

main:

    instruction {print_string "\ninstruction\n"; flush stdout}
    
;

expr:
/* Constantes de types simples. */
INT
{
print_string "\nINT:"; print_int $1;flush stdout
}
|expr PLUS expr
{
print_string "\nPlus"
}
;

instruction:
expr { print_string "\ninstruction\n" ; flush stdout }

|IDENT PARENG PAREND { print_string "\nCall" ; flush stdout}

;

pc87:/tmp/test> ocamlyacc parser.mly;ocamlc -c parser.mli;ocamlc -c
parser.ml;ocamllex lexer.mll;ocamlc -c lexer.ml
8 states, 283 transitions, table size 1180 bytes
pc87:/tmp/test>
pc87:~/tmp/test> ocaml
Objective Caml version 2.02

#load "lexer.cmo";;
#load "parser.cmo";;

# let f s =

let lexbuf = Lexing.from_string s in
Parser.main Lexer.get_token lexbuf
;;
val f : string -> unit =

f "f()+3";;

IDENT:f

PARENG

PAREND

Call
instruction

• : unit = ()

(* Ah ok : bien que la doc ne soit pas explicite là-dessus, il

semble que l'on n'échoue pas si un préfixe de la suite de token peut
être reconnu.
Essayons donc : *)

f " 3 4 5";;

INT3

INT:3
INT4
Uncaught exception: Parsing.Parse_error

Pourquoi donc cette différence ?

Si on regarde l'automate donné par ocamlyacc -v on a :

---

state 2
$accept : %entry% . $end (0)

$end  accept

[..]
state 7
expr : expr . PLUS expr (3)
instruction : expr . (4)

PLUS  shift 9
$end  reduce 4

---

je ne suis pas sûr de bien comprendre ce que représente $end. J'avais
l'impression que c'était EOF, mais alors que se passe t-il lorsque
l'on n'a pas $end dans le premier cas et ni $end ni PLUS dans le
second cas ?

BTW, le rôle particulier joué par "EOF" n'est pas documenté dans le
manuel. En particulier, on a :

f "2+4";;

INT2

INT:2
PLUS

INT4

INT:4
Plus
EOF
Uncaught exception: Parsing.Parse_error

Mais si on remplace "FIN" par "EOF" dans lexer.mll et parser.mly, on a
bien :

---

f "2+4";;

INT2

INT:2
PLUS

INT4

INT:4
Plus
EOF

instruction

instruction

• : unit = ()

---

En fait, il serait bien

• soit de dire dans la doc qu'il faut toujours que les non-terminaux
  axiomes soient constitués d'une production de la forme

x:
y T { .. }

où T est un token

• soit de dire qu'il n'est pas nécessaire d'écrire de symbole de fin, et
  que l'analyseur engendré par ocamlyacc reconnaît le flot de tokens
  analysé jusqu'au symbole EOF (qui serait un token toujours déclaré
  implicitement par ocamlyacc).

Judicaël.

[email protected], http://www.lri.fr/~jcourant/
[Computing timetable constraints..................done: 0 solution(s)]

Documentation of Pervasives.input

Original bug ID: 10
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Norman Ramsey
Version:
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

The documentation for input needs to be improved.
The existing documentation reads as follows:

val input : in_channel -> string -> int -> int -> int

 input chan buff ofs len attempts to read len characters from
 channel chan, storing them in string buff, starting at character
 number ofs. It returns the actual number of characters read,
 between 0 and len (inclusive). A return value of 0 means that the
 end of file was reached. A return value between 0 and len
 exclusive means that no more characters were available at that
 time; input must be called again to read the remaining
 characters, if desired. Exception Invalid_argument "input" is
 raised if ofs and len do not designate a valid substring of buff.

The key phrase is ``no more characters were available at that time.''
I interpreted this to mean if I read from an ordinary disk file, I
would be guaranteed to get as many characters as were available.
Boy, was I wrong. If I try to read 31 characters at offset 4092 from
a 120696-character file, I get only 4 characters. What a surprise!

I would prefer the following wording:

 input chan buff ofs len reads up to len characters from channel
 chan, storing them in string buff, starting at character number
 ofs.  It returns the actual number of characters read, between 0
 and len (inclusive). A return value of 0 means that the end of
 file was reached. A return value between 0 and len exclusive
 means that the implementation did not find it convenient to
 return len characters; input must be called again to read the
 remaining characters, if desired. Exception Invalid_argument
 "input" is raised if ofs and len do not designate a valid
 substring of buff.

I would have used really_input, except I didn't find a way to figure
out how many characters were read before the end of file.

ocamldep generates wrong dependencies on .cmo in native-code-only project

Original bug ID: 8
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Markus Mottl
Version:
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

This has worked OK so far, so I'd like to understand better the
problem those ".cmo dependencies" create in your example.

The problem is that I always use the corresponding compiler (native code or
byte code compiler) to generate the compiled interface files if there is no
.mli-file (if there is one, ocamlc will be used to compile the interface).

The intention is that I do not have to create superfluous .cmo-files when I
want to have native code only - i.e. I want to generate both the .cmi and
the .cmx-file in one step from the .ml-file to save compilation time.

This, of course, means that the way in which ocamldep prints dependencies
leads to problems, because the native code compiler will not emit a ".cmo"
file. This causes "make" to mistakenly recompile some files, because it
believes this will finally produce one.

Here part of an example "make"-run:

ocamlopt -c -I /hame/markusm/prog/ocaml/lib ocaml_str.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib directory_intf.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib directory_impl.ml
ocamlc -c
-I /hame/markusm/prog/ocaml/lib flow.mli
ocamlopt -c -I /hame/markusm/prog/ocaml/lib flow.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib semantics.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib ocaml_str.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib directory_intf.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib directory_impl.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib semantics.ml
ocamlc -c
-I /hame/markusm/prog/ocaml/lib parser.mli
ocamlopt -c -I /hame/markusm/prog/ocaml/lib parser.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib scanner.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib main.ml

As can be seen, "ocaml_str.ml directory_intf.ml directory_impl.ml and
semantics.ml" are compiled two times.

I have solved this problem by replacing every ".cmo"-occurrence by ".cmi"
in the output of ocamldep. This works for both byte code and native code.

The above example then compiles in the minimum number of steps (and time):

ocamlopt -c -I /hame/markusm/prog/ocaml/lib ocaml_str.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib directory_intf.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib directory_impl.ml
ocamlc -c
-I /hame/markusm/prog/ocaml/lib flow.mli
ocamlopt -c -I /hame/markusm/prog/ocaml/lib flow.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib semantics.ml
ocamlc -c
-I /hame/markusm/prog/ocaml/lib parser.mli
ocamlopt -c -I /hame/markusm/prog/ocaml/lib parser.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib scanner.ml
ocamlopt -c -I /hame/markusm/prog/ocaml/lib main.ml

Your solution is probably simpler to use in a Makefile, but is not optimal
for generating native code. My current solution seems to work, but "sed"ing
ocamldep output is definitely also not very elegant...

Thanks, however, for pointing out the intention of your approach. It
brought me to an idea how to improve my generic Makefile (OcamlMakefile)...

Best regards,
Markus Mottl

--
Markus Mottl, [email protected], http://miss.wu-wien.ac.at/~mottl

Re: ocaml float computation on NS3.3

Original bug ID: 28
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,

Thank you for your message to the Caml mailing list.

However your message seems to be a bug report; hence I send it to the
relevant mailing list

[email protected]

Thank again for your interest in Caml.

Pierre Weis

INRIA, Projet Cristal, [email protected], http://cristal.inria.fr/~weis/

Hello,
I'm using NeXTSTEP 3.3 and ocaml to run the GenWeb software. Although it
compiles easily enough, there is a problem with the math in ocaml

1 > ocaml
Objective Caml version 2.04

2. *. 3. ;;

• : float = 1.15348445456e+18

Anyone familiar with the origin of this problem?

---

Paul Buckley
515 W 59th St. #22K
New York, NY 10019

ocaml 2.99

Original bug ID: 52
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

two small bugs in the ocaml 2.99 distribution (version obtained
from the inria web site today, March 8)

1.) in otherlibs/labltk/jpf/Makefile, goal "install" :
the files *.cmo are missing

2.) in the script bin/labltklink :
lines are terminated by "\", should be ""

Ralf Treinen (with help from Judicael Courant)

--

Ralf Treinen, L.R.I. Bât. 490, Université Paris-Sud,
F91405 Orsay cedex, France. http://www.lri.fr/~treinen

ocamlyacc 2.04 bug report

Original bug ID: 44
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

le source suivant est accepte par ocamlyacc, malgre le `|' manquant en
debut de ligne 19.
Du coup, les # line-nb renvoient n'importe ou dans le fichier .mly

%{
%}

%token INT
%token VAR
%token PLUS MINUS TIMES DIV
%token LPAREN RPAREN
%token EOL
%left PLUS MINUS /* lowest precedence /
%left TIMES DIV / medium precedence /
%nonassoc UMINUS / highest precedence /
%start main / the entry point */
%type <Calc.expr> main
%%

main: expr EOL { $1 } ;
expr:
INT { Int($1) }
VAR { Var($1) }
| LPAREN expr RPAREN { $2 }
| expr PLUS expr { Bin(( + ),"+",1,$1,$3) }
| expr MINUS expr { Bin(( - ),"-",1,$1,$3) }
| expr TIMES expr { Bin(( * ),"*",2,$1,$3) }
| expr DIV expr { Bin(( / ),"/",2,$1,$3) }
| MINUS expr %prec UMINUS { Un((fun x->-x),"-",$2 }
;

---

---

CVS OCaml

Original bug ID: 48
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Wolfram Kahl
Version: 2.99+7
OS: Solaris 7 and 2.6, Tru64Unix
Submission from: aspirateur.inria.fr (128.93.8.116)
Submitted by: doligez

Date: 1 Mar 2000 14:26:04 -0000
Message-ID: [email protected]
From: Wolfram Kahl [email protected]
To: [email protected]
Subject: CVS OCaml

Furthermore, my big stream parser xmlParse.ml does not want to be compiled
with -inline 2 or bigger --- ocamlopt then raises an uncaught
Array.get exception (on Solaris 7 and 2.6).
It works for -inline 1 and without -inline.
I include the source below --- I hope I didn't forget any utilities.

[source not included -- Damien]

ocaml-2.99 on AIX4.3 (32bit)

Original bug ID: 16
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Daniel Ortmann
Version: 2.99
OS: AIX 4.3
Submission from: aspirateur.inria.fr (128.93.8.116)
Submitted by: doligez

I get this message in ocaml-2.99/byterun/minor_gc.c at line 145:
"minor_gc.c", line 145.3: 1506-196 (S)Initialization between types "void*"
and "int" is not allowed.
It also happens in alloc.c at line 106 and in lots of other places.

I if cc is used instead of c89 then it compiles. I finally added (void *)
to the left hand side of various defines such as 'CAMLxparam1' in memory.h

Installation sur Linux

Original bug ID: 49
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

j'ai installé sans problèmes plusieurs versions d'OCaml sur différentes
plates-formes sans jamais rencontrer aucun problème. Bizarrement, je
n'arrive pas à compiler (version 2.04 et 2.99) sur certaines machines
Linux (les nouvelles machines élèves Linux de l'ENS; pas de problèmes
sur d'autres Linux).

make world se bloque sur:
../boot/ocamlrun ../ocamlc -g -nopervasives -c pervasives.mli
à cause d'une exception "End_of_file" non rattrapée par le compilateur.

Il s'avère que si on lance cette ligne manuellement, on obtient une fois
sur deux un succès et une fois sur deux un échec (avec une vraie
periodicité de periode 2).

strace montre que l'echec est provoqué par un read de 4096 octets
sur pervasives.cmi, après la fin du fichier. Voici la fin de la sortie de
strace lors d'un echec:

open("pervasives.cmi", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
brk(0x808f000) = 0x808f000
brk(0x806d000) = 0x806d000
write(3, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
write(3, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
write(3, "\341\0\1\0031\2\5\365\341\0\1\003"..., 3297) = 3297
open("pervasives.cmi", O_RDONLY) = 4
lseek(4, 0, SEEK_END) = 11540
lseek(4, 0, SEEK_SET) = 0
read(4, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
read(4, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
read(4, "\341\0\1\0031\2\5\365\341\0\1\003"..., 4096) = 3297
read(4, "", 4096) = 0
write(2, "Uncaught exception: End_of_file\n"..., 32Uncaught exception:
End_of_file
) = 32
_exit(2) = ?

et lors d'un succès:

open("pervasives.cmi", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
brk(0x808f000) = 0x808f000
brk(0x806d000) = 0x806d000
write(3, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
write(3, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
write(3, "\341\0\1\0031\2\5\365\341\0\1\003"..., 3297) = 3297
open("pervasives.cmi", O_RDONLY) = 4
lseek(4, 0, SEEK_END) = 11489
lseek(4, 0, SEEK_SET) = 0
read(4, "Caml1999I005\204\225\246\276\0\0"..., 4096) = 4096
read(4, "\365\341\0\1\1\256\260\262\4\367"..., 4096) = 4096
read(4, "\341\0\1\0031\2\5\365\341\0\1\003"..., 4096) = 3297
close(4) = 0
brk(0x8071000) = 0x8071000
write(3, "\204\225\246\276\0\0\0\37\0\0\0\4"..., 51) = 51
close(3) = 0
_exit(0) = ?

Je précise que l'on travaille en NFS (le serveur NFS est un Sun sous
Solaris).

Avez-vous une idée d'où cela peut venir ?

Merci de votre aide

--
Alain Frisch

Scheduling problem with Posix threads

Original bug ID: 22
Reporter: administrator
Status: closed (set by @xavierleroy on 2006-06-17T09:54:06Z)
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Jerome Vouillon
Version:
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

Dans l'exemple suivant, le programme utilisant les threads est
complètement bloqué par celui ne les utilisant pas...

-- Jérôme

mistral-jerome:/tmp > cat > essai.ml
let _ = let x = ref 0. in for i = 0 to 10000000 do x := !x *. 1.1 done
mistral-jerome:/tmp > ocamlc -o essai essai.ml
mistral-jerome:/tmp > cat essai2.ml
let _ = Thread.create
let _ = let x = ref 0. in for i = 0 to 10000000 do x := !x *. 1.1 done
mistral-jerome:/tmp > ocamlc -custom -thread -o essai2 unix.cma
threads.cma essai2.ml -cclib "-lunix -lthreads -lpthread"
mistral-jerome:~/tmp > time ./essai & time ./essai2
[1] 1292
./essai 13,21s user 0,01s system 98% cpu 13,470 total
[1] + done time ./essai
./essai2 12,97s user 0,02s system 49% cpu 26,415 total

[Damien Doligez:]
Pas reproductible sur Tru64. Feature de Linux Threads ?

[Jerome Vouillon:]
Voilà ce qui se passe :
Il y a un thread qui signale toutes les 50ms au thread s'exécutant à
ce moment là de laisser la place à un autre thread. Ce thread appelle
pour celà sched_yield. Comme il y a un autre processus qui peut
s'exécuter le thread ne reprend la main qu'après plus de 50ms... et
rappelle immédiatement sched_yield, car le thread horloge s'est
exécuté entre temps. Le thread principal n'a donc jamais l'occasion de
s'exécuter.

-- Jérôme

Dynlink and -output-obj do not work together

Original bug ID: 54
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Gerd Stolpmann
Version: 2.04
OS:
Submission from: master.proxy.ision.net (195.180.208.40)

Hi,

I have a OCaml program which is embedded in another (C) program; I did
this by using the -output-obj option of the (bytecode) compiler. This
alone works fine; but if I try to initialize the Dynlink library (calling
Dynlink.init), the runtime system wants to read the bytecode executable
again to get the symbol table. The code in Symtable.init_toplevel reads
the file in argv.(0) and interprets it as bytecode executable. Of course,
in my program it is impossible to read such an executable because there
is not any.

I use currently a hack to get around this limitation: I wrote a shell script
that outputs the list of primitives to stdout; I built a "pseudo executable"
using ocamlc -use-runtime /name/of/shellscript. That way, the produced bytecode
should be identical, and the executable contains a symbol table. Finally,
I set Sys.argv.(0) to the path of the pseudo executable before invoking
Dynlink.init.

I think it is much better to repair the runtime system; the -output-obj
option could also force the compiler to put a symbol table into the generated
object file, and Dynlink.init should be able to read this symbol table.

initializer element for `jumptable[0]' is not computable at load time (Solaris, gcc)

Original bug ID: 12
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Vincent Poirriez
Version: 2.99
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

more log.world
cd byterun; make all
sed -n -e '/^ /s/ ([A-Z])/ &&lbl_\1/gp'
-e '/^}/q' instruct.h > jumptbl.h
gcc -O -fno-defer-pop -Wall -Wno-unused -D_REENTRANT -c interp.c
jumptbl.h: In function interprete': In file included from interp.c:185: jumptbl.h:1: initializer element for jumptable[0]' is not computable at
load time
....

interp.c:186: initializer element for jumptable[133]' is not computable at load time *** Error code 1 make: Fatal error: Command failed for target interp.o'
Current working directory /prof/poirriez/OcamlStuff/ocaml-2.99/byterun
*** Error code 1
make: Fatal error: Command failed for target `coldstart

ultraistv1% gcc -v
Reading specs from
/usr/local/gantsou/3.12p/install/lib/gcc-lib/sparc-sun-solaris2.5.1/2.8.1/specs
gcc version 2.8.1

1/16 = 0.625

Original bug ID: 41
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonsoir.

J'utilise ocaml, avec la librairie num (pas numerix).
Je tombe sur une erreur flagrante :

leger 535% myOcaml
Objective Caml version 2.02

open Num;;

float_of_num (Int 1//Int 16);;

• : float = 0.625

Bon, je prefererai 0.0625 (comme me l'indique camlnum, mais
qui contient un autre bug...)

Ce bug se produit il chez vous aussi ?

--
Dominique Michelucci [email protected]
http://www.emse.fr/~micheluc
Ecole Nationale Superieure des Mines de St-Etienne
158 cours Fauriel, 42023 Saint Etienne cedex 2, France
Tel: [phone] from abroad, 04 77 42 01 73 from France
Fax: [phone] from abroad, 04 77 42 66 66 from France

labltk

Original bug ID: 19
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Jean-Marc Alliot
Version: 2.99
OS:
Submission from: tet.kurims.kyoto-u.ac.jp (130.54.16.184)
Submitted by: garrigue

Deux petits bugs a vous signaler:

a) le script labltkopt est faux (il y a une option -custom assez
malheureuse et une erreur de syntaxe)
b) l'exemple tetris.ml marche parfaitement avec labltk, mais en
revanche, quand on compile avec labltkopt, le programme fait des choses
qui n'ont pas grand rapport voir avec ce que l'on a vu avec labltk :-)
(la fenetre est deux fois moins large et deux fois plus haute, le haut
de la montagne est dcale vers le bas, le haut de la fenetre etant
rempli par du vert, la pice suivante, qui doit etre affiche sur fond
noir est affiche sur fond vert).

JM Alliot

ocamldebug ignores # linenum "filename"

Original bug ID: 9
Reporter: administrator
Assigned to: @xclerc
Status: closed (set by @xavierleroy on 2012-09-25T18:07:21Z)
Resolution: fixed
Priority: normal
Severity: feature
Fixed in version: 3.11+dev
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Norman Ramsey
Version: 2.04
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

I'm running ocamldebug on a file that is litted with directives like

176 "rsync.nw"

Unfortunately, the debugger does not direct emacs to source file rsync.nw,
but uses lines in rsync.ml (the actual source file). Am I correct in
thinking that this behavior represents a bug?

Re: initializer element for `jumptable[0]' is not computable at load time (Solaris, gcc) (PR#12)

Original bug ID: 13
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Xavier Leroy wrote:

jumptbl.h: In function interprete': In file included from interp.c:185: jumptbl.h:1: initializer element for jumptable[0]' is not computable at
load time

Est-ce que tu compiles en mode 32 bits ou en mode 64 bits? Qu'est-ce que
./configure affiche? Et que contiennent les fichiers config/m.h et
config/s.h generes?

Bon, je suis desole pour le message precedent, j'ai recommencé de scratch
depuis l'archive et c'est passé
sans pb sur solaris avec gcc.
Je pensais avoir tout nettoyé avant, surement pas.

Vincent

• Xavier

--
Vincent Poirriez ISTV// LAMIH - UMR CNRS 8530 - GT RO Informatique
Université de Valenciennes - Le Mont Houy
F-59313 Valenciennes Cedex 9 - FRANCE

Toploop does not complain about missing cmi files

Original bug ID: 26
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Gerd Stolpmann
Version: 2.04
OS: Linux-2.2.13 with glibc-6.1
Submission from: master.proxy.ision.net (195.180.208.40)

If I have a module M as a compilation unit, and a module M' that uses M in the
interface, e.g.

M:
type t = string
val f : t -> t

M':
val g : M.t -> M.t

and if I have a toploop with loaded cmo files of M and M', but
the cmi file of M is missing (not in the search path), I get
misleading error messages:

g "abc";;

This expression has type string but is here used with type M.t

It would be better if the toploop warns about missing interfaces,
for example at startup for all loaded modules, or after an expression
has been entered (it can simply scan all occurring symbols, here "g",
and check whether all interfaces (direct and indirect) are present).

bug(?) ocamldep

Original bug ID: 50
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

La sortie generee par ocamldep marque les dependences par rapport aux
fichiers .cmo, mais pas .cmi, si bien que si un fichier .cmi manque, il
ne peut pas etre regenere. C'est facile a verifier avec un rm *.cmi;make.

Je soupconne ce manque d'etre la cause de certains `makefile bugs', mais
je n'en suis pas certain dans la mesure ou j'avais moi-meme un bug dans
mes regles pour ocamlyacc/ocamllex.

A ce sujet, il serait sans doute interessant d'orienter les gens vers la
syntaxe GNUMakefile, qui est moins portable mais est beaucoup lus pratique
pour decrire les regles generant plusieurs fichiers (ml -> cmi cmo).

keywords and polymorphic variants

Original bug ID: 18
Reporter: administrator
Status: closed
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Markus Mottl
Version: 2.99
OS: SunOS 5.6
Submission from: alford.dai.ed.ac.uk (129.215.25.74)

Hello,

I am not sure whether this is a feature wish or a bug report:

It seems that OCaml parses polymorphic variants in such a
way that it is not possible to use keywords as variant names.

E.g.:

type t = [ `true ]

will lead to a syntax error. This is possibly too strict.
The preceding ` should allow the scanner to know that a
variant name follows immediately.

The current implementation allows whitespace and even
comments (!) between the and the name of the variant. This "freedom" is rather confusing. I propose that the and the variant name should stay together.

Best regards,
Markus Mottl

Camllight: ca float entre 2 os

Original bug ID: 55
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour,

Desolee de vous deranger si ce qui suit (qui me semble etre un bug) est
deja repertorie.
Je suis en cls74 sur Mac et les floats ont un comportement bizarre (cf
ci-dessous).
En esperant vous etre utile,
Marie-Catherine Daniel-Vatonne

#let pp =((0.24 -.0.27)*. 1000.);;

let mm=((0.27 -.0.3)*. 1000.);;

pp : float = -30.0
#mm : float = -30.0
#pp = mm;;

• : bool = false
  #pp < mm;;
• : bool = true
  #(int_of_float pp);;
• : int = -30
  #(int_of_float mm);;
• : int = -29
  #abs_float pp;;
• : float = 30.0
  #abs_float mm;;
• : float = 30.0
  #abs_float pp =abs_float mm;;
• : bool = false

(remarque le *1000 n'est la que pour pouvoir faire int_of_float)

---

Marie-Catherine DANIEL-VATONNE
Maitre de Conf. en Informatique
Assistant Professor in Computer Science
IREMIA, Universite de la Reunion
15 rue R. Cassin -BP7151-
97 715 St Denis Messag 9
Phone :
Foreign countries: +262+93-82-79 fax:93-82-60
Metropole: 0262+93-82-79 fax:93-82-60
Url: http://www.univ-reunion.fr/~mcdv

bug num, normalize_ratio

Original bug ID: 39
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonne nouvelle ! ou en tout cas un indice :
j'ai transfere mon programme sous ocam version 2.02,
et tout fonctionne correctement (qqs mega operations avec Num).
Ou peut etre que l'erreur, visible sous caml, reste vicieusement
masquee sous ocaml ?

Nota: Le transfert ne s'est pas fait sans mal, car je suis
novice en ocaml. J'ai cru comprendre qu'il ne faut pas faire
de #directory ".." dans un fichier (on peut en caml...),
mais cela m'a pris un temps... certain : le #use "monfichier.ml"
me diagnostiquait de "fausses erreurs", et quand j'entrais mon source
au clavier (copier-coller, etc), tout etait correct :
o rage o desespoir...

Bref :

• directory, load, open, use...etc pourraient ils figurer dans l'index
  de la documentation ?

• pourrait elle indiquer que #directory est interdit ds les fichiers et
  qu'il faut utiliser -I a la place ?

bon week end

Dominique Michelucci [email protected]
http://www.emse.fr/~micheluc
Ecole Nationale Superieure des Mines de St-Etienne
158 cours Fauriel, 42023 Saint Etienne cedex 2, France
Tel: [phone] from abroad, 04 77 42 01 73 from France
Fax: [phone] from abroad, 04 77 42 66 66 from France

aliasing exceptions with a let ?

Original bug ID: 46
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Ralf Treinen
Version:
OS:
Submission from: aspirateur.inria.fr (128.93.8.116)
Submitted by: doligez

To: [email protected]
Subject: aliasing exceptions with a let ?
Date: Wed, 01 Mar 2000 17:22:08 +0100
From: Ralf Treinen [email protected]

Is it possible to alias an exception as with functions or type definitions?
I would like to write a module that is a "virtual module" in the sense
that it just regroups identifiers that are defined in other modules.
This works fine for types and functions:

type running_prog = Programs.running_prog;;
let is_finished = Programs.is_finished;;

Apparently, I cannot do the same thing with exceptions (and hence
with functions that raise an exception). The obvious solution is to
write a wrapper as in

exception Erreur_load of string;;
let load s =
try
Analyse_program.load s
with
Analyse_program.Erreur_load s -> raise (Erreur_load s)
;;

which is quite awkward. It would be nice to have a way to define an alias
for an exception in the same way as for identifiers and types.

Ralf Treinen.

--

Ralf Treinen, L.R.I. Bât. 490, Université Paris-Sud,
F91405 Orsay cedex, France. http://www.lri.fr/~treinen

Subtle functor application bug

Original bug ID: 51
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Related to: #6651 #7192

Bug description

Hello!

I've been looking at Ocaml module system implementation recently and I
discovered a little subtle bug, which appears when you try to apply a
functor which is a component of a larger structure and whose type is a
"module type" defined in the same structure.....

Well, to be more explicit, here is an example of a functor F with the
caracteristics as described above, and the bug that is produced:

    Objective Caml version 2.04

module X=struct

module type SIG=sig type t=int val x:t end;;
module F(Y:SIG) : SIG = struct type t=Y.t let x=Y.x end;;

end;;
module X :
sig
module type SIG = sig type t = int val x : t end
module F : functor(Y : SIG) -> SIG
end

module DUMMY=struct type t=int let x=2 end;;

module DUMMY : sig type t = int val x : int end

(3 : X.F(DUMMY).t);;

Unbound type constructor X.F(DUMMY).t

Apparenly the type system does not know that there is a type
component "t" in the result of the application of X.F to DUMMY.
The same thing works perfectly well if SIG and F are defined at
toplevel:

    Objective Caml version 2.04

module type SIG=sig type t=int val x:t end;;

module type SIG = sig type t = int val x : t end

module F(Y:SIG) : SIG = struct type t=Y.t let x=Y.x end;;

module F : functor(Y : SIG) -> SIG

module DUMMY=struct type t=int let x=2 end;;

module DUMMY : sig type t = int val x : int end

(3 : F(DUMMY).t);;

• : F(DUMMY).t = 3

I haven't checked with the recent version of Ocaml, but I looked at
the CVS server and I think that the error will persist...

My guess is that the functor components evaluated for X.F in the
function "components_of_module", correspond to:
fcomp_param = "Y"
fcomp_arg = "X.SIG"
fcomp_res = "X.SIG"
fcomp_env = {... SIG -> sig...end ... }
And since there is no "X.SIG" in fcomp_env but only SIG, the function
"components_of_module_application" computes empty components structure
for X.F(DUMMY).

Best regards

Jacek Chrzaszcz

--
Laboratoire de Recherche en Informatique (LRI) - Equipe DEMONS
batiment 490, bureau 153, Universite Paris-Sud 91405 ORSAY (FRANCE)
tel:[phone] - fax:[phone] - http://www.lri.fr/~jacek

ocamlyacc loops

Original bug ID: 17
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Markus Mottl
Version: 2.99
OS: SunOS 5.6
Submission from: alford.dai.ed.ac.uk (129.215.25.74)

Hello,

I have just found a bug in ocamlyacc which makes it loop
forever while eating up memory. The following short file
demonstrates this:

file: foo.mly

%type < int
> t

The intention was to split up somewhat longer declarations
over several lines for readability. Obviously, ocamlyacc
cannot handle multi-line type declarations.

A workaround is to declare the type separately elsewhere
and then refer to the corresponding name in the type
declaration for the parser entry point.

Best regards,
Markus Mottl

"ocamlmktop -v" creates a.out

Original bug ID: 6
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Alexey Nogin
Version: 2.03
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

Hi,

When I run "ocamlmktop -v", it creates a.out with Ocaml toploop. I think
this should be considered a bug...

Alexey

Home Page: http://www.cs.cornell.edu/nogin/
E-Mail: [email protected] (office), [email protected] (home)
Office: Upson 4139, tel: [phone]

Re: Broken Sort Code in StdLib

Original bug ID: 33
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hi,

Thank you for your message to the Caml mailing list.

However your message seems to be a bug report; hence I send it to the
relevant mailing list

[email protected]

Thank again for your interest in Caml.

Pierre Weis

INRIA, Projet Cristal, [email protected], http://cristal.inria.fr/~weis/

Dear Caml Crowd...

There still appears to be a problem with the Standard Library Sort.array
routine. Violation of boundary conditions occur on some occaisions that
manifest an invalid page fault runtime error.

I have copied the code from the source, modified to explicitly check for
boundary violations and this appears to fix the problem. My fix is probably
non-optimal.

The original code fragment is

...
  let pivot = unsafe_get arr mid in
  let i = ref (lo + 1) and j = ref (hi - 1) in
  while !i < !j do
    while not (cmp pivot (unsafe_get arr !i)) do incr i done;
    while not (cmp (unsafe_get arr !j) pivot) do decr j done;
    if !i < !j then swap arr !i !j;
    incr i; decr j
  done;
...

The modified code fragment is:
(Note the explicit checks in the innermost while loops.)

  let pivot = unsafe_get arr hi in
  let i = ref lo and j = ref hi in
  while !i < !j do
    while !i < hi && order (unsafe_get arr !i) pivot do incr i done;
    while !j > lo && order pivot (unsafe_get arr !j) do decr j done;
    if !i < !j then swap arr !i !j
  done;

This problem was first noticed in OCaml 2.03 and has been verified to exist
in OCaml 2.99.

David McClain, Sr. Scientist
Raytheon Systems Co.
Tucson, AZ

Variant pattern matching compilation

Original bug ID: 20
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Jerome Vouillon
Version: 2.99
OS:
Submission from: tet.kurims.kyoto-u.ac.jp (130.54.16.184)
Submitted by: garrigue

Il y a galement quelques problmes au niveau de la compilation du
pattern matching :
mistral-jerome:~> ocaml
...
# let f x y = match x, y with A, (B v) -> v;;
# f A (B 10);;
zsh: segmentation fault ocaml

mistral-jerome:~> ocaml
...
# let f `A = ();;
# let rec h x = g x; f x and g x = match x with `A -> () | `B -> ();;
Uncaught exception: Not_found

feature wish: uninitialized unboxed arrays

Original bug ID: 37
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Markus Mottl
Version: 2.99
OS:
Submission from: ballater.dai.ed.ac.uk (129.215.25.79)

Hello,

would it be easily possible to provide for functions in the
"Array"-module which allocate unboxed integer- and float-arrays
without initializing them (similar to "String.create")?

This would allow twice as fast reallocations when implementing
resizable arrays for such data types.

Because this might lead to illegal representations of the numbers,
these functions should probably be in the "unsafe" part.

Best regards,
Markus Mottl

alias du type float

Original bug ID: 35
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Pascal Brisset
Version: 2.99
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

[Xavier Leroy: bug report submitted 2000-01-03, fixed in 3.00,
put here for the record]

Un petit problème pour le code suivant

---8<------------------------------------------
module B = struct
type t = float
type p = { x : t }
let f = { x = 1000. }
end

module type S = sig
type t = float
type p = { x : float }
val f : p
end

module BS = (B:S)

let _ =
Printf.printf "%f %f\n" B.f.B.x BS.f.BS.x;;
---8<------------------------------------------

On obtient:

sepia[123]% ./a.out
1000.000000 0.000000

C'est apparemment l'erreur dans la déclaration du type p (float pour
t) dans la signature qui est responsable. Une histoire de flottant
boxé/non boxé dans la structure ?

--Pascal

Bug in List.rev_map2

Original bug ID: 32
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Benjamin Pierce
Version:
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

I believe the third [] should be accu.

B

bug in polymorphic variants

Original bug ID: 42
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

The following interaction with the environment manifests a bug in Ocaml 2.99
on Windows NT :

let f : unit -> [A|B] = function () -> `A;;

val f : unit -> [A|B] =

let x = match f() with A->2 | B->3 | `C->4;;

Uncaught exception: Not_found

I was expecting to get a warning about the useless match clause (`C) and for
x to be bound to 2. Instead, I get the weird exception and I get kicked out
of the Ocaml environment and back to the shell prompt.

---

The following interaction with the environment manifests a bug in Ocaml 2.99 on Windows NT :

 

# let f : unit -> [`A|`B] = function () -> `A;;
val f : unit -> [`A|`B] = <fun>
# let x = match f() with `A->2 | `B->3 | `C->4;;
Uncaught exception: Not_found

I was expecting to get a warning about the useless match clause (`C) and for x to be bound to 2. Instead, I get the weird exception and I get kicked out of the Ocaml environment and back to the shell prompt.

 

---

---

packages

Original bug ID: 5
Reporter: administrator
Status: closed
Resolution: won't fix
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: John Skaller
Version:
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

Please correct me if I'm wrong, but my understanding is that
ocaml only searches for modules referenced like:

    open X
    ..
    Y.x

in the path given to the compiler. A recent addition to Python
has helped reduce module clutter; a related idea for ocaml is
as follows: given a module name:

    X.Y.Z

X must be on the path, as before, however, if it is a directory,
it is taken to be a module containing all modules contained
in the directory: say the files are Y.cmx, Y2.cmx, then it is
as if Y and Y2 were nested in X like

    (* X.ml *) 
    module Y = ..
    module Y2 = .. 

Given this construction, multimodule packages can be distributed
so they unpack into a single directory, reducing name clashes,
making upgrading and removal easier, and without needing
to continually fiddle with the search path. This feature works
well in Python. It requires no changes to the language (only
some changes to the compilation model).

By default, contributed packages with install options tend to
install themselves in the same place as the standard library.
This is unfortunate, because it is useful to totally wipe out
the whole ocaml distribution and rebuild it, which clobbers
any such contributed modules.

With the package system, a symbolic link could be used to
what Python calls 'site-packages', which is where contributed
modules are installed by default. In this case, the nice feature
is that a fresh ocaml would not contain contributed packages,
but they can be reinstated by reinstalling the old symbolic link.

--
John Skaller, mailto:[email protected]
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850

problem with -with-pthread under Digital Unix 4.0

Original bug ID: 11
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Vincent Poirriez
Version: 2.99
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

pour info, lors de l'installation de la 2.99 sur dec alpha avec egcs
options de config: -with-pthread

Vincent

../../boot/ocamlrun ../../boot/ocamlc -I ../../stdlib -I ../../utils -I
../../ty
ping -I ../../bytecomp -o extract_crc dynlink.cma extract_crc.cmo
gcc -O -I../../byterun -fno-defer-pop -Wall -Wno-unused -D_REENTRANT -c
posix.c
In file included from
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0b/egcs-2.91.57/
include/excpt.h:85,
from
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0b/egcs-2.91.57/
include/pthread_exception.h:147,
from /usr/local/include/pthread.h:282,
from posix.c:19:
/usr/include/pdsc.h:506: warning: /*' within comment In file included from /usr/local/include/pthread.h:290, from posix.c:19: /usr/include/c_asm.h:193: parse error before asm'
posix.c: In function caml_mutex_finalize': posix.c:454: warning: passing arg 1 of stat_free' discards volatile' from poin ter target type posix.c: In function caml_condition_finalize':
ter target type
*** Exit 1
Stop.
*** Exit 1

subscribe

Original bug ID: 29
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

subscribe [email protected]

bug in num

Original bug ID: 38
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Bonjour.

Avec caml 0.74, et utilisant la librairie num,
un appel de fonction (purement fonctionel...)
ne rend pas le meme resultat selon que les rationnels sont
systematiquement reduits ou non.

J'ai extrait un source de 60 lignes du programme initial
20 fois plus gros (normalize_ratio_when_printing false est
VRAIMENT INDISPENSABLE :) ...) Il est en attachement.

la variable hf (normalize_ratio=false) vaut chez moi :

• : nombre * nombre =
  Interval {vmin = -264/40; vmax = -146/40},
  Interval {vmin = -12/10; vmax = -9/10}

la variable ht (=hf, mais normalize_ratio a true) vaut chez moi :

• : nombre * nombre =
  Interval {vmin = -33/5; vmax = -1/2},
  Interval {vmin = -6/5; vmax = -9/10}

et -146/40 <>/ -1/2

Cordialement,

Dominique Michelucci [email protected]
http://www.emse.fr/~micheluc
Ecole Nationale Superieure des Mines de St-Etienne
158 cours Fauriel, 42023 Saint Etienne cedex 2, France
Tel: [phone] from abroad, 04 77 42 01 73 from France
Fax: [phone] from abroad, 04 77 42 66 66 from France

Inline expansion of transcendentals

Original bug ID: 21
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: David McClain
Version:
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

Since I do a great deal of bluk math processing, it would sure be nice if
many of the simpler transcendental functions could be inlined by OCAMLOPT.
I'm speaking primarily of round_to_int, sin, cos, tan, asin, acos, atan,
atan2, log, exp, sqrt, etc.

I modified the 2.02 compiler to support these and found that the necessary
changes were really quite easy to make. But I don't look forward to making
these same mods every time a new compiler is released.

Of course I am working on Pentium class machines which have these functions
available in hardware. Other arhitectures might not be so kind in this
regard...

David McClain

[Added in a later message]

I can appreciate the desire to keep the language pure and proper, but I must
say that in nearly 30 years of experience I have never been tempted to take
the sin of 2^64. I would suggest that an inline version of the basic
transcendentals be made available along the same lines that unsafe_get and
unsafe_set are made available for array access. They are inlined for speed,
and provide little or no error checking. Their use is flagged by the
prominent "unsafe" prefix in the source text, and the option is available to
the end user as to when to use them....

PRIVATE: exceptions

Original bug ID: 23
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Bruno MORVAN
Version: Caml light 0.74
OS: W 95
Submission from: proxy.nordnet.fr (194.206.126.190)

Une sesssion entiere.

  Caml Light version 0.74

#try 1/0 with foo->1 | bar -> 0;;
Entrée interactive:

try 1/0 with foo->1 | bar -> 0;;
^^^
Attention: ce cas de filtrage est inutile.

• : int = 1

me laisse perplexe.

les exceptions ne semble même pas testées.

threads and marshalling with I/O

Original bug ID: 25
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Gerd Stolpmann
Version: 2.04 -with-pthread
OS: Linux-2.2.13 with glibc-6.1
Submission from: master.proxy.ision.net (195.180.208.40)

Marshalling, including the input/output_value functions in Pervasives, is not
reentrant at all. This very clear from the C source code in byterun/extern.c
and
intern.c:

extern.c: There is a static variable extern_block which is actually the buffer
that is written in do_write; writing happens in a "blocking section" and so
concurrent Marshal.to_channel calls can lead to situations where more than one
thread is executing the code within this section with the same extern_block
buffer.

intern.c: The same problems with the buffer intern_input which is also filled
in a blocking section.

This piece of code often segfaults with Marshal.to_channel:

let l = ref [] in
let s = String.make 10000 'x' in
for i = 1 to 50 do
let id =
Thread.create
(fun () ->
for j = 1 to 100 do
let ch = open_out "/dev/null" in
Marshal.to_channel ch s [];
close_out ch;
done;
)
()
in
l := id :: !l
done;

List.iter
(fun id ->
Thread.join id)
!l
;;

The same with Marshal.from_channel:

let s = String.make 10000 'x' in
let out = open_out "r.data" in
Marshal.to_channel out s [];
close_out out;
let l = ref [] in
for i = 1 to 50 do
let id =
Thread.create
(fun () ->
for j = 1 to 100 do
let ch = open_in "r.data" in
ignore(Marshal.from_channel ch);
close_in ch;
done;
)
()
in
l := id :: !l
done;

List.iter
(fun id ->
Thread.join id)
!l
;;

bytecode threads in Ocaml-2.04 / 2.02 / 1.05

Original bug ID: 15
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Pawel Wojciechowski
Version: 2.04
OS:
Submission from: estephe.inria.fr (128.93.11.95)
Submitted by: xleroy

Hello!

Just to ask if all is fine with bytecode threads in OCaml version 2.04?

In the program below I create two threads, one is doing some computation
(counter), second thread is executing a wait function. In the main program
I wait until the second thread terminates and then I print a current state
of the computation being done by the first thread. I checked three kinds
of wait function: a blocking input from console, a non-blocking low-level
input from ThreadUnix module and a simple recursive loop.

For each function "wait":

In Ocaml 1.05 the counter thread is never blocked

In Ocaml 2.02 the counter thread is never blocked but.. if we change
the program so as we don't create a separate thread for a function
wait then if wait executes read_line() or read() the program prints
0 as a result (thus it seems like I/O operation blocks the thread
counter?)

In Ocaml 2.04 The program behaves abnormally and suspends execution in
every case.

I installed Ocaml* on i686 Linux and I'm compiling the program using:

ocamlc -thread -custom unix.cma threads.cma -cclib -lunix -cclib -lthreads
$1 -o $2

best regards, -
Pawel Wojciechowski

open Unix
open ThreadUnix

let res = ref 0
let s = Mutex.create()

let rec counter i =
Mutex.lock s; res := i; Mutex.unlock s;
counter (i + 1)

(*
let wait () = let _ = read_line () in ()
)
(
let wait () =
let line = String.create 60 in
let len = read stdin line 0 60 in
print_string (String.sub line 0 len)
*)
let wait () =
let rec loop i =
if i < 3000000 then loop (i + 1) else i
in loop 0

(* VERSION 1: two threads *)

let main () =
let _ = Thread.create counter 0 in
let t = Thread.create wait () in
Thread.join t;
Mutex.lock s; print_int !res; Mutex.unlock s

let _ = main ()

(* VERSION 2: one thread *)

let main () =
let _ = Thread.create counter 0 in
wait();
Mutex.lock s; print_int !res; Mutex.unlock s

let _ = main ()

---

Pawel T. Wojciechowski, Computer Lab., University of Cambridge
www.cl.cam.ac.uk/users/ptw20, office [phone], fax 335 908

Problem compiling large sources using native-code compiler

Original bug ID: 47
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Vincent Zammit
Version: 2.01
OS: HP/UX
Submission from: aspirateur.inria.fr (128.93.8.116)
Submitted by: doligez

Date: Tue, 29 Feb 2000 17:40:28 GMT
From: [email protected] (Vincent Zammit)
Message-Id: [email protected]
To: [email protected]
Subject: Problem compiling large sources using native-code compiler

Dear Caml maintainers,

We are using ocaml in some large program development, and the
native-code compiler fails (during linking) on compiling a
particular file giving several of the following error messages:

collect2: ld returned 1 exit status
/usr/ccs/bin/ld: Target of unconditional branch is out of range
Reference from: .o(0x3fb5c)
/usr/ccs/bin/ld: Target of unconditional branch is out of range
Reference from: .o(0x3fb8c)
/usr/ccs/bin/ld: Target of unconditional branch is out of range
Reference from: .o(0x3fbc0)
.
.
.

Where .o is quite a large object file --- more than
800K in size.

This occurs only on HP/UX machines; the same files compile on
Sparc architectures, but in these cases the generated object
file is slightly less than 800K.

I wonder whether this is a limitation or a bug, and whether it
has already been fixed in recent versions. We are currently using
ocaml version 2.01; I had a look at the What's New page but I could
find nothing that suggests that this problem is fixed.

Many thanks,

Vince Zammit
Sharp Laboratories of Europe

probleme avec ocamlopt.opt

Original bug ID: 45
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: jean-marc alliot
Version: 2.99+5
OS: debian-linux/potato
Submission from: aspirateur.inria.fr (128.93.8.116)
Submitted by: doligez

(*
From [email protected] Wed Feb 23 12:12:52 2000
X-Authentication-Warning: rouge.recherche.enac.fr: Host alliot@localhost
[127.0.0.1] claimed to be recherche.ena
c.fr
From: jean-marc alliot [email protected]
X-Accept-Language: fr-FR
To: [email protected]
Subject: Bug report: probleme avec ocamlopt.opt

Bug report (vérifié) d'un de mes étudiants.

Version récupérée sur le serveur CVS de l'INRIA à 11h00. Machine utilisée :
Pentium-III/500, système debian-linux/potato.

ocamlopt -v
The Objective Caml native-code compiler, version 2.99+5 (2000/02/22)
Standard library directory: /usr/local/lib/ocaml

ocamlopt.opt -v
The Objective Caml native-code compiler, version 2.99+5 (2000/02/22)
Standard library directory: /usr/local/lib/ocaml

David Gianazza wrote:

Ci-joint le fichier isitabug.ml

En compilant avec ocamlopt, ce programme renvoie 30.556696 qui est le bon

resultat.

Apres compilation avec ocamlopt.opt, il renvoie un "Segmentation fault".

Si l'on met la fonction "f4" qui ne sert a rien en commentaire, cela
renvoie 76054.571421 qui n'est pas le bon resultat.

-- David Gianazza

*)
let fvint= 1.66

let rec f3 n k =
match (n,k) with
(_, 1) -> 1.0
| (n,k) ->
if n>=k
then (f3 (n-1) k)*.fvint +. (f3 (n-1) (k-1))
else (float 0);;

let g3 n =
let rec h n k =
if k=n
then 1.0
else (f3 n k) +. (h n (k+1)) in
h n 1;;
(*
let rec f4 n =
let q= n/2 and r= n mod 2 in
match (q,r) with
(1,0) -> 1
| (q,0) -> (q-1)n + q
| (q,1) -> qn
| _ -> failwith "f4";;
)
( TESTS *)

Printf.printf "%f\n" (g3 5);;
exit 0;;

Linking problems in otherlibs/str

Original bug ID: 53
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Full_Name: Gerd Stolpmann
Version: 2.04/Current CVS version
OS: Solaris
Submission from: master.proxy.ision.net (195.180.208.40)

Hi,

I recently detected a problem with otherlibs/str. The GNU regex library defines
the function regfree, which is a POSIX.2 function. Under Solaris, I observed
that the call of regfree in strstubs.c actually invoked the regfree function
defined in libc, and not the regfree function defined in regex. This caused
a core dump every time a regexp value was finalized.

Fortunately, regfree is the only regexp function which conflicts with POSIX
functions; the other calls of regexp functions are not affected.

I have a patch which avoids to call regfree at all (by simply copying the
"free"
invocations into the stub function):
http://people.darmstadt.netsurf.de/Gerd.Stolpmann/ocaml/str-2.04.patch

Gerd

Insufficient CRC checking in interactive system

Original bug ID: 43
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hello!

I know that Ocaml checks consistency of interface files but I found
the way to overcome this check in the interactive system, version 2.04

The steps which leads to the error are the following:

1. in the empty directory create file "m.ml" with contents
   let x=17
2. compile your code "m.ml" -> "m.cmo", "m.cmi"
3. create the interface "m.mli" with contents
   val x:string
4. compile the interface "m.mli" -> "m.cmi"
5. run ocaml -I .
   Objective Caml version 2.04

#load "m.cmo";;

M.x;;

Bus error

Best regards

Jacek

better FreeBSD-support for O'Caml 2.04

Original bug ID: 36
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Hello,

I just want to send you some patches that improve the
FreeBSD-support of O'Caml 2.04. Those patches are part
of the changes done in the FreeBSD ports collection
(/usr/ports/lang/ocaml on FreeBSD-systems).

Main additions are the support for the profiler and the
x86 bignum lib.

Regards,
Ronald

--- configure.orig Fri Feb 11 16:15:25 2000
+++ configure Fri Feb 11 16:27:37 2000
@@ -290,6 +290,7 @@
case "$host" in
alpha--osf) arch=alpha; system=digital;;
alpha--linux) arch=alpha; system=linux;;

• alpha--freebsd) arch=alpha; system=freebsd;;
  alpha--netbsd) arch=alpha; system=netbsd;;
  alpha--openbsd) arch=alpha; system=openbsd;;
  sparc--sunos4.) arch=sparc; system=sunos;;
  @@ -340,6 +341,7 @@
  alpha,,digital) asflags='-O2'; asppflags='-O2 -DSYS_$(SYSTEM)';
  asppprofflags='-pg -DPROFILING';;
  alpha,,linux) aspp='gcc'; asppflags='-c -DSYS_$(SYSTEM)';;
• alpha,,freebsd) aspp='gcc'; asppflags='-c -DSYS_$(SYSTEM)';;
  alpha,,netbsd) aspp='gcc'; asppflags='-c -DSYS_$(SYSTEM)';;
  alpha,,openbsd) aspp='gcc'; asppflags='-c -DSYS_$(SYSTEM)';;
  mips,,irix) asflags='-n32 -O2'; asppflags="$asflags";;
  @@ -365,6 +367,7 @@
  case "$arch,$model,$system" in
  alpha,,digital) profiling='prof';;
  i386,,linux_elf) profiling='prof';;
• i386,*,bsd) profiling='prof';;
  *) profiling='noprof';;
  esac

@@ -649,6 +652,7 @@
alpha--osf) bignum_arch=alpha;;
i[3456]86--linux) bignum_arch=x86;;
i[3456]86--beos) bignum_arch=x86;;

• i[3456]86--bsd) bignum_arch=x86;;
  sparc--sunos*) bignum_arch=supersparc;;
  sparc--solaris) bignum_arch=supersparc-solaris;;
  sparc-*-bsd) bignum_arch=sparc;;

--- asmcomp/i386/emit.mlp.orig Fri Feb 11 16:33:42 2000
+++ asmcomp/i386/emit.mlp Fri Feb 11 16:53:31 2000
@@ -713,6 +713,15 @@
popl %edx\n;
popl %ecx\n;
popl %eax\n

• | "bsd_elf" ->

•  `	pushl	%eax\n`;
  

•  `	movl	%esp, %ebp\n`;
  

•  `	pushl	%ecx\n`;
  

•  `	pushl	%edx\n`;
  

•  `	call	.mcount\n`;
  

•  `	popl	%edx\n`;
  

•  `	popl	%ecx\n`;
  

•  `	popl	%eax\n`
  

  | _ -> () (unsupported yet)

(* Emission of a function declaration *)

--- asmrun/i386.S.orig Wed Nov 17 19:56:48 1999
+++ asmrun/i386.S Fri Feb 11 16:51:35 2000
@@ -35,13 +35,22 @@
#define FUNCTION_ALIGN 2
#endif

-#if defined(PROFILING) && defined(SYS_linux_elf)
+#if defined(PROFILING)
+#if defined(SYS_linux_elf)
#define PROFILE_CAML
pushl %ebp; movl %esp, %ebp; pushl %eax; pushl %ecx; pushl %edx;
call mcount;
popl %edx; popl %ecx; popl %eax; popl %ebp
#define PROFILE_C
pushl %ebp; movl %esp, %ebp; call mcount; popl %ebp
+#elif defined(SYS_bsd_elf)
+#define PROFILE_CAML \

•    pushl %ebp; movl %esp, %ebp; pushl %eax; pushl %ecx; pushl %edx; \
  

•    call .mcount; \
  

•    popl %edx; popl %ecx; popl %eax; popl %ebp
  

+#define PROFILE_C \

•    pushl %ebp; movl %esp, %ebp; call .mcount; popl %ebp
  

+#endif
#else
#define PROFILE_CAML
#define PROFILE_C

--- otherlibs/num/bignum/Makefile.orig Thu Dec 4 19:07:35 1997
+++ otherlibs/num/bignum/Makefile Fri Feb 11 16:54:51 2000
@@ -73,7 +73,7 @@
$(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)" all

alpha: scratch

• as -O s/alphaKerN.s -o o/KerN.o

• as s/alphaKerN.s -o o/KerN.o
  $(MAKE) CC="$(CC)" CFLAGS="$(CFLAGS)" all

pyramid: scratch

--- asmcomp/alpha/emit.mlp.orig Fri Feb 11 16:55:21 2000
+++ asmcomp/alpha/emit.mlp Fri Feb 11 16:56:28 2000
@@ -274,7 +274,7 @@
let rdata_section =
match Config.system with
"digital" | "openbsd" -> ".rdata"

• | "linux" | "netbsd" -> ".section .rodata"

• | "linux" | "netbsd" "freebsd" -> ".section .rodata"
  | _ -> assert false

(* Names of various instructions *)

--- otherlibs/graph/open.c.orig Fri Feb 11 18:00:12 2000
+++ otherlibs/graph/open.c Fri Feb 11 17:59:18 2000
@@ -13,6 +13,7 @@
/* $Id: open.c,v 1.12 1999/11/18 13:33:53 xleroy Exp $ */

#include <fcntl.h>
+#include <unistd.h>
#include <signal.h>
#include "libgraph.h"
#include <alloc.h>

--- byterun/config.h.orig Fri Feb 11 18:34:29 2000
+++ byterun/config.h Fri Feb 11 18:34:06 2000
@@ -27,6 +27,7 @@

#ifdef HAS_MEMMOVE
#undef bcopy
+#include <string.h>
#define bcopy(src,dst,len) memmove((dst), (src), (len))
#else
#ifdef HAS_BCOPY

--
Give a man a fish, and you feed him for a day.
Tell him he should learn how to fish himself,
and he'll hate you for a lifetime.