[Caml-list] OCaml-announcements

[Caml-list] OCaml-announcements

[Oliver Bandel]

Hello Gurus ;-)

wouldn't it be a good idea to announce new Ocaml-releases
via freshmeat?

A lot of people then suddenly had informations on this
interesting programming language they never heard of
before.

I grepped the freshmeat-mails on Ocaml but did not found
any entry. So I think that it never was announced there.

Ciao,
   Oliver

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

Re: [Caml-list] OCaml-announcements

[Xavier Leroy]

> wouldn't it be a good idea to announce new Ocaml-releases
> via freshmeat?
> 
> A lot of people then suddenly had informations on this
> interesting programming language they never heard of
> before.

Sure, there are plenty of announcement sites and Webzines where
regular mention of OCaml might help.  But there are so many of them
that we (the Caml *development* team) can't deal with this and have to
rely on volunteers.  For instance, Alan Schmitt writes a column for
Linux Weekly News.  Anyone is most welcome to write columns,
announcements, etc, for their favorite sites; that's an excellent way
to contribute to the OCaml project.

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

Re: [Caml-list] OCaml-announcements

[Remi VANICAT]

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

> > wouldn't it be a good idea to announce new Ocaml-releases
> > via freshmeat?
> > 
> > A lot of people then suddenly had informations on this
> > interesting programming language they never heard of
> > before.
> 
> Sure, there are plenty of announcement sites and Webzines where
> regular mention of OCaml might help.  But there are so many of them
> that we (the Caml *development* team) can't deal with this and have to
> rely on volunteers.  For instance, Alan Schmitt writes a column for
> Linux Weekly News.  Anyone is most welcome to write columns,
> announcements, etc, for their favorite sites; that's an excellent way
> to contribute to the OCaml project.

By the way, there was announcements see : 
http://freshmeat.net/projects/ocaml/


-- 
Rémi Vanicat
vanicat@labri.u-bordeaux.fr
http://dept-info.labri.u-bordeaux.fr/~vanicat
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

Re: [Caml-list] OCaml-announcements

[Matt Armstrong]

Remi VANICAT <vanicat@labri.u-bordeaux.fr> writes:

> Xavier Leroy <xavier.leroy@inria.fr> writes:
>
>> > wouldn't it be a good idea to announce new Ocaml-releases
>> > via freshmeat?
>> > 
>> > A lot of people then suddenly had informations on this
>> > interesting programming language they never heard of
>> > before.
>> 
>> Sure, there are plenty of announcement sites and Webzines where
>> regular mention of OCaml might help.  But there are so many of them
>> that we (the Caml *development* team) can't deal with this and have
>> to rely on volunteers.  For instance, Alan Schmitt writes a column
>> for Linux Weekly News.  Anyone is most welcome to write columns,
>> announcements, etc, for their favorite sites; that's an excellent
>> way to contribute to the OCaml project.
>
> By the way, there was announcements see : 
> http://freshmeat.net/projects/ocaml/

There is no current owner of the ocaml project on freshmeat.net.  It
was last updated for version 3.0.1.

Because there is currently an ocaml project there, changing the owner
requires going through an editor approval process.

I volunteer to update freshmeat.net with announcements of new ocaml
versions.  Any objections?

-- 
Don't send mail to Dwight.Quinn@hole.lickey.com
The address is there for spammers to harvest.
-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners

[Caml-list] Weird bug

[John Max Skaller]

I've just produced some strange behaviour in my program.
I get "Not_found" exception.. when I turn on my programs
debug tracing, the program works.

Some trivial input that previously worked now causes my
program to core dump. [Heh .. some test input
to the compiler works fine .. but when I add

print "Hello world\n";

to the end, my compiler core dumps ..
the same statement compiles find in other places,
and it compiles fine with debug tracing on]

So .. this sounds like memory corruption to me.
But the only way a "nice" ocaml program should
be able to corrupt memory is by a stack overflow.

[My code is "nice" NO arrays, NO magic, NO C routines
called .. its a compiler, all list and hashtable stuff --
the only nasty thing is that I have ocamlopt.opt --rectypes]

Previously I noticed that this was trapped
(an actual infinite recursion gracefully exited
with a stack overflow message .. nice!!)

I find it hard to believe my program has exceeded
any sensible limitations (some of the typing
in the parser is really flogging the ocaml compiler
.. 20 second compilation .. was 1 second ..
but the generated code should be small).

Question: any known bugs in ocaml that could cause this?

Question: I previously found a serious bug with polymorphic
variants in Ocaml 3.02.  The code that triggered the bug
works fine with 3.01 and with 3.04. Has that bug been
identified and fixed (or was I just lucky ..and now unlucky again)?

Question: is stack overflow always trapped?

It seems unlikely that I have an infinite recursion .. since
turning on debug output shouldn't change the flow
of control [though it is possible .. since the output
is controlled by a flag ..]

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] Weird bug

[John Max Skaller]

John Max Skaller wrote:

>
> Question: I previously found a serious bug with polymorphic
> variants in Ocaml 3.02.  The code that triggered the bug
> works fine with 3.01 and with 3.04. Has that bug been
> identified and fixed (or was I just lucky ..and now unlucky again)? 

Hmmm. That is bug #491 in the bug tracker,
and its categorized "not a bug" which it clearly is.
The note says "need full source code to investigate".
Great. Someone could have contacted me by email:
the source is all online at sourceforge and has been
for two years.

In any case, it seems the bug wasn't fixed, and now I may
be bitten by it again..but it is hard to be sure.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

[Caml-list] Bug in typing polymorphic variants found

[John Max Skaller]

>
>
>> Question: I previously found a serious bug with polymorphic
>> variants in Ocaml 3.02.  The code that triggered the bug
>> works fine with 3.01 and with 3.04. Has that bug been
>> identified and fixed (or was I just lucky ..and now unlucky again)? 
>
>
> Hmmm. That is bug #491 in the bug tracker,
> and its categorized "not a bug" which it clearly is. 

OK. I think I have found it. Heh. Or rather, Ocaml 3.01
found it for me. There is a bug in the typing of polymophic variants.

What happens: Ocaml 3.01 reports a type error.
Ocaml 3.04 does not, it crashes at run time instead.
[.. this is confusing but, I think it crashes even when the bug
in my code is fixed .. this is definitely the same problem I
had before and reported in bug #491]

The offending lines of code are:

       match dcl with

        | `DCL_val_typeof e ->
          Hashtbl.add dfns n (id,sr,parent,`SYMDEF_dcl dcl)

The match is matching on values of type dcl_t

The value `DCL_val_typeof _ is NOT a member of the type dcl_t,
so this code will never be executed.

The type of the Hashtable being used here requires the fourth
component of the data part to be of a type which includes
constructor `SYMDEF_dcl of dcl_t.

Were the above code ever executed, a bad variant would be
glued into the hash table, since the type of dcl is infered to
include `DCL_val_typeof _.

The *problem* is that the type of the constructor argument
influences its run-time hash? And so the following code,
which IS executed

        | `DCL_val t ->
          Hashtbl.add dfns n (id,sr,parent,`SYMDEF_dcl dcl)
          ;

is producing the *wrong* hash for the variant `SYMDEF_dcl dcl,
because the inference engine thinks the type of dcl is something
other than dcl_t. When I do a lookup of the hash table later in another 
module,
I get a bad value out, since in *that* module, the correct type of the dcl
is calculated. At least, thats my guess.

I'll try to make a small example,
my initial attempts have failed. Otherwise, I'll have to post the
bogus code to sourceforge where
the developers can download it.

Here is the Ocaml 3.01 error which
Ocaml 3.04 does not report:

This pattern matches values of type
  [< `DCL_module_binding of 'a
   | `DCL_typed_functor of 'b * 'c * 'd
   | `DCL_untyped_functor of 'e * 'f
   | `DCL_function of 'g * 'h * 'i
   | `DCL_match_check of 'j * 'k
   | `DCL_header of 'l
   | `DCL_module of 'm
   | `DCL_interface of 'n
   | `DCL_lazy of 'o
   | `DCL_procedure of 'p * 'q
   | `DCL_if_fun of 'r
   | `DCL_if_proc of 's
   | `DCL_type
   | `DCL_val of 't
   | `DCL_val_typeof of 'u
   | `DCL_var of 'v
   | `DCL_var_typeof of 'w
   | `DCL_type_alias of 'x
   | `DCL_abs of 'y
   | `DCL_const of 'z * 'a1
   | `DCL_fun of 'b1 * 'c1 * 'd1
   | `DCL_proc of 'e1 * 'f1
   | `DCL_union of 'g1
   | `DCL_struct of 'h1]
but is here used to match values of type
  Flx_types.dcl_t =
    [ `DCL_header of string
    | `DCL_function of
        Flx_types.parameter_t list * Flx_types.typecode_t *
        Flx_types.asm_t list
    | `DCL_lazy of Flx_types.expr_t
    | `DCL_procedure of Flx_types.parameter_t list * Flx_types.asm_t list
    | `DCL_union of (Flx_types.id_t * Flx_types.typecode_t) list
    | `DCL_struct of (Flx_types.id_t * Flx_types.typecode_t) list
    | `DCL_match_check of Flx_types.pattern_t * string
    | `DCL_val of Flx_types.typecode_t
    | `DCL_var of Flx_types.typecode_t
    | `DCL_type_alias of Flx_types.typecode_t
    | `DCL_module of Flx_types.asm_t list
    | `DCL_typed_functor of
        Flx_types.parameter_t list * Flx_types.typecode_t *
        Flx_types.asm_t list
    | `DCL_untyped_functor of
        Flx_types.parameter_t list * Flx_types.asm_t list
    | `DCL_module_binding of Flx_types.expr_t
    | `DCL_interface of Flx_types.asm_t list
    | `DCL_if_proc of Flx_types.typecode_t
    | `DCL_if_fun of Flx_types.typecode_t
    | `DCL_type
    | `DCL_abs of Flx_types.c_t
    | `DCL_const of Flx_types.typecode_t * Flx_types.c_t
    | `DCL_fun of
        Flx_types.typecode_t list * Flx_types.typecode_t * Flx_types.c_t
    | `DCL_proc of Flx_types.typecode_t list * Flx_types.c_t]


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] Bug in typing polymorphic variants found

[Luc Maranget]

> > Hmmm. That is bug #491 in the bug tracker,
> > and its categorized "not a bug" which it clearly is. 
> 
> OK. I think I have found it. Heh. Or rather, Ocaml 3.01
> found it for me. There is a bug in the typing of polymophic variants.
> 
> What happens: Ocaml 3.01 reports a type error.
> Ocaml 3.04 does not, it crashes at run time instead.
> [.. this is confusing but, I think it crashes even when the bug
> in my code is fixed .. this is definitely the same problem I
> had before and reported in bug #491]
> 
> The offending lines of code are:
> 
>        match dcl with
> 
>         | `DCL_val_typeof e ->
>           Hashtbl.add dfns n (id,sr,parent,`SYMDEF_dcl dcl)
> 

> The match is matching on values of type dcl_t
> 
> The value `DCL_val_typeof _ is NOT a member of the type dcl_t,
> so this code will never be executed.
> 
> The type of the Hashtable being used here requires the fourth
> component of the data part to be of a type which includes
> constructor `SYMDEF_dcl of dcl_t.
> 
> Were the above code ever executed, a bad variant would be
> glued into the hash table, since the type of dcl is infered to
> include `DCL_val_typeof _.
> 
> The *problem* is that the type of the constructor argument
> influences its run-time hash? And so the following code,
> which IS executed
> 
>         | `DCL_val t ->
>           Hashtbl.add dfns n (id,sr,parent,`SYMDEF_dcl dcl)
>           ;
> 
> is producing the *wrong* hash for the variant `SYMDEF_dcl dcl,
> because the inference engine thinks the type of dcl is something
> other than dcl_t. When I do a lookup of the hash table later in another 
> module,
> I get a bad value out, since in *that* module, the correct type of the dcl
> is calculated. At least, thats my guess.
> 
> I'll try to make a small example,
> my initial attempts have failed. Otherwise, I'll have to post the
> bogus code to sourceforge where
> the developers can download it.

Hello,

Typing of polymorphic variants has much changed in 3.XX versions.

Pattern matching compilation of polymorphic variants included a
serious bug in 3.01 (or in 3.02, 3.03 I do not remember) version, and the
effect of this bug would be what you describe.
[If you are interested, this is bug number 359, fixed]

This PM bug is corrected in version 3.04.

Please consider that we do need running code that shows the erroneous
behavior w .r. t. the current version of the compiler.
Making assumpsions based upon the previous versions of the compiler
is a bit delicate here, since two parts that look critical to your
report underwent important modifications.

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

Re: [Caml-list] Bug in typing polymorphic variants found

[John Max Skaller]

[This is a bug report, please ignore if you are not interested,
apologies in advance ..]

Luc Maranget wrote:

>
>Hello,
>
>Typing of polymorphic variants has much changed in 3.XX versions.
>
>Pattern matching compilation of polymorphic variants included a
>serious bug in 3.01 (or in 3.02, 3.03 I do not remember) version, and the
>effect of this bug would be what you describe.
>[If you are interested, this is bug number 359, fixed]
>
>This PM bug is corrected in version 3.04.
>
I'll check the database. I can report that the specific bug  I had
in Ocaml 3.02 did NOT occur in 3.04. I know this because
I actually checked the code with both versions.

>
>Please consider that we do need running code that shows the erroneous
>behavior w .r. t. the current version of the compiler.
>Making assumpsions based upon the previous versions of the compiler
>is a bit delicate here, since two parts that look critical to your
>report underwent important modifications.
>
I must apologise for the delay responding, I had a serious ISP
problem (got cut off from the Internet entirely).

The complete source of my program is available from

    http://felix.sourceforge.net/felix_src.tgz

See the web site:

  http://felix.sourceforge.net/download.html

for information on building.

To use the included build scripts, you must have Python installed.
After unpacking the tarball, type

     python script/maker noiscr test

and it should build the compiler and then crash running
some of the tests. If you try the whole process again,
using Ocaml 3.01 it should work.

I have commented out the lines that cause Ocaml 3.01 to
give a diagnostic message. If you wish to generate the
Ocaml 3.01 errors that Ocaml 3.04 does not report,
you will need to uncomment those lines.
Grep for

 `DCL_val_typeof

in the files

  src/symtab.ml
  src/bbind.ml

Would you please email me privately when you have the tarball,
as I may wish to upload a new version in  which the code has
been substantially changed.

I am running Ocaml 3.04 on Linux RH 7.2
built with gc 2.96 after applying the patch to correct
a gcc 2.96 bug.

I will do everything I can to help resolve this problem,
I'd like to use new ocaml features .. and of I am already
depending on

    #variant_type

syntax in matches, which will not be supported in Ocaml 3.05.
I can't backtrack for that easily, and I'd hate to upgrade the syntax
only to find I can't compile my code under 3.05.

Thanks for your time, and of course, the excellent Ocaml system.


-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] Bug in typing polymorphic variants found

[Jacques Garrigue]

From: John Max Skaller <skaller@ozemail.com.au>

> [This is a bug report, please ignore if you are not interested,
> apologies in advance ..]

> The *problem* is that the type of the constructor argument
> influences its run-time hash? And so the following code,
> which IS executed
> 
>         | `DCL_val t ->
>           Hashtbl.add dfns n (id,sr,parent,`SYMDEF_dcl dcl)
>           ;
> 
> is producing the *wrong* hash for the variant `SYMDEF_dcl dcl,
> because the inference engine thinks the type of dcl is something
> other than dcl_t. When I do a lookup of the hash table later in another 
> module,
> I get a bad value out, since in *that* module, the correct type of the dcl
> is calculated. At least, thats my guess.

Well, your guess has to be wrong, because the type of a constructor
arguments _does not_ influence the run-time hash of this constructor.

> The complete source of my program is available from
> 
>     http://felix.sourceforge.net/felix_src.tgz
> 
> See the web site:
> 
>   http://felix.sourceforge.net/download.html
> 
> for information on building.
> 
> To use the included build scripts, you must have Python installed.
> After unpacking the tarball, type
> 
>      python script/maker noiscr test
> 
> and it should build the compiler and then crash running
> some of the tests. If you try the whole process again,
> using Ocaml 3.01 it should work.

I didn't try with 3.01, only with 3.04+10, and I get a segmentation
fault on the first example.
Since you use ocamlopt, I couldn't get any debugging information, so I
tried again with ocamlc -g, and the error I get is a stack overflow.
I expect there is a bug somewhere in your program...

It is a good idea to make your makefiles to work with both ocamlc and
ocamlopt, because ocamlc gives you much more debugging information.
Some segmentation faults with ocamlopt give actually informative
errors with ocamlc.

By the way, I got errors trying to compile felix, because there was an
old src/flx_parse.ml, which should not be there.

> I have commented out the lines that cause Ocaml 3.01 to
> give a diagnostic message. If you wish to generate the
> Ocaml 3.01 errors that Ocaml 3.04 does not report,
> you will need to uncomment those lines.

Parts of the specification of polymorphic variants have changed since
3.01, so it is very possible than some code refused by 3.01 is now
accepted. I would expect this code to be sound.

> I will do everything I can to help resolve this problem,
> I'd like to use new ocaml features .. and of I am already
> depending on
> 
>     #variant_type
> 
> syntax in matches, which will not be supported in Ocaml 3.05.

Where did you get this idea? Of course #variant_type will stay, this
is a main feature of polymorphic variants!
The only change is that I would prefer people to move from the
#variant_type to [< variant_type] in _types_, since the previous
notation is overloaded with the one for objects in a not so nice way.
But there is no reason to hurry: both syntax will still be supported
in 3.05.

Cheers,

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

Re: [Caml-list] Bug in typing polymorphic variants found

[Luc Maranget]

> I expect there is a bug somewhere in your program...
> 
> It is a good idea to make your makefiles to work with both ocamlc and
> ocamlopt, because ocamlc gives you much more debugging information.
> Some segmentation faults with ocamlopt give actually informative
> errors with ocamlc.
> 
> By the way, I got errors trying to compile felix, because there was an
> old src/flx_parse.ml, which should not be there.
> 

I did the same thing, and even ran felix under ocamldebug
(another reason to use both bytecode and native compilation)

1. I has to alter Flx_lex to compile
  (suppress a self reference to the Flx_lex module)

2. By running the example (run), until it crashed
   going back (back) in execution a little, and looking at the
   call stack (backtrace), I found the loop :


#52327  Pc : 242856  Flx_pretok char 6183
#52328  Pc : 242856  Flx_pretok char 6183
#52329  Pc : 242856  Flx_pretok char 6183
#52330  Pc : 242856  Flx_pretok char 6183
#52331  Pc : 242856  Flx_pretok char 6183
#52332  Pc : 242856  Flx_pretok char 6183
#52333  Pc : 242856  Flx_pretok char 6183

etc...


Apparently the loop is in module Flx_pretok :


let pre_tokens_of_lexbuf buf state =
  let lex_it() = Flx_lex.pre_flx_lex buf state in
  let run = ref true in
  let rec get () =
    if !run
    then let t = lex_it () in
      match t with
      | [Flx_parse.ENDMARKER] ->
        run := false;
        [Flx_parse.ENDMARKER]
      | _ -> t @ get() <------- HERE is the recursive call                 
    else [Flx_parse.ENDMARKER]
  in get ()


Hope it helps,


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

Re: [Caml-list] Bug in typing polymorphic variants found

[John Max Skaller]

Jacques Garrigue wrote:

>I didn't try with 3.01, only with 3.04+10, and I get a segmentation
>fault on the first example.
>Since you use ocamlopt, I couldn't get any debugging information, so I
>tried again with ocamlc -g, and the error I get is a stack overflow.
>I expect there is a bug somewhere in your program...
>
All 30 or so regression tests and tutorial examples work correctly
with Ocaml 3.01.

When I add debuging print statements,
the bug doesn't always happen!

It crashes long before the first debugging print
if it crashes, and not at all if it executes even one of them.
There is no way I can try to find an infinite recursion
that doesn't happen when I add print statements.

I'm a very experienced programmer.  My code has some
exceptionally nasty recursions in it. I wouldn't be surprised
if some of them could go infinite .. but I'd expect Ocaml 3.01
to segfault then too. It doesn't. It generates exactly the expected
output, which compiles under g++ correctly, and executes correctly.

My code is pure ocaml, except for Big_num module.

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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

Re: [Caml-list] Bug in typing polymorphic variants found

[John Max Skaller]

Luc Maranget wrote:

>
>I did the same thing, and even ran felix under ocamldebug
>(another reason to use both bytecode and native compilation)
>
>1. I has to alter Flx_lex to compile
>  (suppress a self reference to the Flx_lex module)
>
Funny. Must be CVS change. It compiles on my system.
[Yes, I see the self reference ..]

>
>2. By running the example (run), until it crashed
>   going back (back) in execution a little, and looking at the
>   call stack (backtrace), I found the loop :
>
>
>#52327  Pc : 242856  Flx_pretok char 6183
>#52328  Pc : 242856  Flx_pretok char 6183
>#52329  Pc : 242856  Flx_pretok char 6183
>#52330  Pc : 242856  Flx_pretok char 6183
>#52331  Pc : 242856  Flx_pretok char 6183
>#52332  Pc : 242856  Flx_pretok char 6183
>#52333  Pc : 242856  Flx_pretok char 6183
>
>etc...
>
>
>Apparently the loop is in module Flx_pretok :
>
>
>let pre_tokens_of_lexbuf buf state =
>  let lex_it() = Flx_lex.pre_flx_lex buf state in
>  let run = ref true in
>  let rec get () =
>    if !run
>    then let t = lex_it () in
>      match t with
>      | [Flx_parse.ENDMARKER] ->
>        run := false;
>        [Flx_parse.ENDMARKER]
>      | _ -> t @ get() <------- HERE is the recursive call                 
>    else [Flx_parse.ENDMARKER]
>  in get ()
>


The above code has been working
for 2 years. It hasn't been changed in 2 years.  It is an infinite loop,
which is terminated by finding an ENDMARKER token in the code.
This token is generated by the lexer at end of file.

| eof { fun state -> [ENDMARKER] }

The parser creates a lot of polymorphic
variants. It also takes *ages* to compile
since a recent change I made: that change
contains several 3 step type coercions:

	(a : t1 :> t2)


Perhaps the parser is overflowing some
table limit?

-- 
John Max Skaller, mailto:skaller@ozemail.com.au
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850




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