Mantis Bug Tracker

View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0001799OCamlOCaml generalpublic2003-08-26 14:402013-08-30 22:36
Reporteradministrator 
Assigned To 
PrioritynormalSeverityfeatureReproducibilityalways
StatusacknowledgedResolutionopen 
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0001799: 3.07 beta 2 test build/run results
Description
This is a forward of my beta1 mailing to caml@inria.fr. Did that original
mail not get through (I got no response)? None of these issues have
changed in beta2, which I just tested (including the exception runtime bug
and the _local_roots bugs below).

Chris


>Date: Tue, 22 Jul 2003 23:15:00 -0700
>To: caml@inria.fr
>From: Chris Hecker <checker@d6.com>
>Subject: 3.07 beta 1 test build/run results
>
>
>Environment:
>
>- msvc, cygwin installed, binutils installed
>- followed steps in readme.win32 "recompiling"
>- also built opt.opt after opt
>- test program is my video game, 0000411:0000040 .ml files, 6 .cpp files, some libs, etc.
>
>Results (in chronological order, skip to the bottom for the big ones):
>
>- opt.opt binaries not installed with make -f Makefile.nt install
>
>- no camlp4 opt.opt built with opt.opt (useful if you just want fast
>streams and don't care about loading other syntax extensions)
>
>- camlp4 opt.opt build broken if called from root
> - compile.sh: no /dev/null on windows, use NUL (or have an empty
> file in the dist)
> - then it breaks on something with pa_o_fast.ml interf0
> - make clean in camlp4/compile and then make && make opt seems to
> fix it
>
>- is there any way to include the patch below for toplevel/topdirs.ml? It
>makes an #init;; command that allows you to clear the environment, so you
>don't have to restart the toplevel if you've #load'ed a module you need to
>edit, it's very useful
>
>- tk83.lib link error when building if not in lib path...README.win32 has
>a mention of this in the "installing" section but not in the
>"recompilation" section, so it should probably be duplicated in the
>checklist/algorithm there so lazy people like me don't miss it. (isn't it
>possible to add an /L $(TK_PATH)/lib on the link command line in the
>labltk makefiles and get the same results without requiring setting LIB,
>or set LIB in the makefile?)
>
>- was there a -cclib and -ccopt change or fix? I had to change a makefile
>to use -ccopt instead of -cclib, but I'm vaguely remembering reporting a
>bug about this in 3.06, so maybe it got fixed and that explains the
>behavior change
>
>- Running the newly built game (native) has a problem where a try with _
>block around a scanf doesn't catch the exception, using either _ or
>Scanf.Scan_failure...I can try to make a small repro case if you don't
>already know about this
>
>- I can't build my game for bytecode because linking one of the library
>thunk DLLs bombs on an unresolved _local_roots, even though ocamlrun.lib
>is being linked (and it works fine on 3.06)...again, let me know if you
>need a repro case
>
>Chris
>
>diff -ur ../../original/1/toplevel/topdirs.ml ./topdirs.ml
>--- ../../original/1/toplevel/topdirs.ml 2002-06-18
>23:11:22.000000000 -0700
>+++ ./topdirs.ml 2002-10-14 18:20:36.000000000 -0700
>@@ -26,6 +26,12 @@
> (* The standard output formatter *)
> let std_out = std_formatter
>
>+(* To init the toplevel env *)
>+
>+let _ = Hashtbl.add directive_table "init" (Directive_none
>+ (fun () -> Env.reset_cache ();
>+ toplevel_env :=
>Compile.initial_env()))
>+
> (* To quit *)
>
> let dir_quit () = exit 0

Tagspatch
Attached Files

- Relationships

-  Notes
(0000162)
administrator (administrator)
2003-08-27 11:53


>(Sorry for addressing only one problem at a time :-)

Likewise, sorry for putting them all in the same mail, but I had already
spent too much time on the mail as it was on beta1 to caml@inria.fr, so I
figured it was better to send it in all glommed together than to not get
around to sending it in to caml-bugs correctly broken up. :)

>I may miss something, but I don't see why camlp4o.opt (or camlp4r.opt)
>doesn't fit your need here? Didn't they get installed during your
>test?

Those are the files I want, but this set of makes (from README.win32)
doesn't install any *.opt in the target/bin directory:

         make -f Makefile.nt world
         make -f Makefile.nt bootstrap
         make -f Makefile.nt opt
         make -f Makefile.nt install

And, the camlp4[or].exe's installed by these makes are bytecode files. Am
I missing something? As I say in my mail, doing an opt.opt from the root
also doesn't build camlp4 *.opt. I have to go build camlp4 opt.opt to get
them, and that's slightly broken like I describe in the original mail.

>Am I missing something here?

One of us is, but I'm not sure which one! :) Are you saying the makes
above should build camlp4o.opt? They don't on msvc/win32, I can say that
much for sure.

Let me know if you want me to try something else,
Chris


(0000163)
administrator (administrator)
2003-08-27 19:21

Chris,

(Sorry for addressing only one problem at a time :-)

checker@d6.com wrote/écrivait (Tue, Aug 26, 2003 at 11:40:27PM +0200):

> >Results (in chronological order, skip to the bottom for the big ones):
> >
> >- no camlp4 opt.opt built with opt.opt (useful if you just want fast
> >streams and don't care about loading other syntax extensions)

I may miss something, but I don't see why camlp4o.opt (or camlp4r.opt)
doesn't fit your need here? Didn't they get installed during your
test?

If they were, then there is nothing more to expect than a camlp4 with,
preloaded, an OCaml parser extended with streams, all this compiler
with ocamlopt. This is exactly what is provided by camlp4[or].opt

In particular, "opt.opt" means nothing more that "opt" for camlp4
(not really a compiler).

Am I missing something here?

-- Michel

(0000164)
administrator (administrator)
2003-08-28 13:49


>As usual, the windows makefiles lags a bit behind, but I'll try to
>update them before the release.

Cool, thanks.

>I believe this command can break type safety...
>At this point, the system will believe that x is of type string,
>and crash.

Not in my test, it works fine (I change foo.ml in the middle, like you
suggest):

# let x = (1 : Foo.t);;
val x : Foo.t = 1
# x;;
- : Foo.t = 1
# #init;;
# x ^ "hello";;
Characters 0-1:
   x ^ "hello";;
   ^
Unbound value x

The #init;; makes it so x is no longer bound, like it's supposed to. Am I
missing something? Obviously, I wrote #init by groveling around in the
source and not completely understanding everything, so a more experienced
eye on it would be great because there might be problems, but I've
definitely used it a bunch, and given it to others who have as well. It's
very useful for workflow.

>There is a comment to this effect in config/Makefile.msvc. You can do
>that in the config file, but then the Tcl/Tk location is hard-wired in
>labltk.cma and camltk.cma, which is not adequate for a binary
>distribution of OCaml (but might be adequate if you install from sources).

Yeah, I saw the comment, but I didn't understand why a command to the msvc
linker would necessarily find its way into the cma files (although I guess
it's just that -cclib gets stored in the cma verbatim).

The other option is to have the makefile set LIB directly, which does the
right thing for subprocesses. This might be the easiest way to fix it
(have a TK_LIBPATH that's set in Makefile.msvc, then do a LIB :=
$(LIB);$(TK_LIBPATH) at the top of the labltk makefiles, and still have
TK_LINK be the bare lib files). Yep, I just tested this and it works fine
(no hard coded paths in the cmas, no need for the env var). There's a
context diff below of config/Makefile.msvc and
otherlibs/labltk/Makefile.nt. Now you can remove the comment about the env
var stuff, and just tell people they need to change PREFIX and TK_LIBPATH
in config/Makefile.msvc and it'll just work.

 >> cclib/ccopt
>it looked innocuous enough. Sorry if it broke something.

No big deal, it was an easy fix.

> >- Running the newly built game (native) has a problem where a try with _
> >block around a scanf doesn't catch the exception, using either _ or
> >Scanf.Scan_failure...I can try to make a small repro case if you don't
> >already know about this
>No, we don't, and you're welcome to send a program that shows the
>behavior.

Okay, I'll see if I can get something together today.

>In the second case, you may
>have to add -DCAML_DLL when creating the C object files that will go
>in the DLL.

Yes, this fixed that problem (was there an issue with just looking for
#define DLL, like before?). That then turned up needing to link with
dllbigarray.lib instead of libbigarray.lib to get
__imp__alloc_bigarray_dims, and then fixing that got me a binary that
couldn't find alloc_bigarray_dims in dllbigarray.dll, even though link
-dump -exports shows it in there (the exe is finding the dll, just not the
function).

I can look into this one more, or maybe you already have an idea that would
save me the time since obviously some stuff changed in this area?

Thanks, and I'll try to isolate the exn thing now,
Chris

------TK_LINK changes--------

--- ..\..\..\ocaml-3.07beta2\config\Makefile 2003-08-26
14:01:06.000000000 -0
700
+++ Makefile 2003-08-28 13:26:17.000000000 -0700
@@ -118,6 +118,7 @@
  # produced by OCaml, and is therefore required for binary distribution
  # of these libraries. However, $(TK_ROOT) must be added to the LIB
  # environment variable, as described in README.win32.
+TK_LIBPATH=c:/apps/tcl/lib
  TK_LINK=tk83.lib tcl83.lib
  # An alternative definition that avoids mucking with the LIB variable,
  # but hard-wires the Tcl/Tk location in the binaries

.\..\..\ocaml-3.07beta2\otherlibs\labltk\Makefile.nt Makefile.nt
--- ..\..\..\..\ocaml-3.07beta2\otherlibs\labltk\Makefile.nt 2002-06-07
02:49
:38.000000000 -0700
+++ Makefile.nt 2003-08-28 13:26:29.000000000 -0700
@@ -1,6 +1,7 @@
  # Top Makefile for LablTk

  include ../../config/Makefile
+LIB:=$(LIB);$(TK_LIBPATH)

  SUBDIRS=compiler support lib labltk camltk jpf frx tkanim examples_labltk
examp
les_camltk browser

(0000165)
administrator (administrator)
2003-08-28 14:29


Hi Pierre, I only saw your mail when checking the bug report online, I
think you forgot to cc me on your reply to Xavier's mail. :)

>My guess is that you may have either a partial application of scanf
>(hence no exception is raised) or a bad use of kscanf ?

Nope, neither of these. I looked into it in more detail, and it was a
combination of me being an idiot (and thinking the exn was coming from a
different scanf invokation than it was, not sure how I screwed that up
given that I thought I checked them both, but anyway) and the fact that the
behavior of %s@c changed to eat the c.

So, this one was not a bug, sorry about the false alarm.

Chris


>From: Pierre Weis <weis@pauillac.inria.fr>
>Subject: Re: 3.07 beta 2 test build/run results (PR#1799)
>To: xleroy@pauillac.inria.fr
>Date: Thu, 28 Aug 2003 22:13:53 +0200 (MET DST)
>Cc: caml@pauillac.inria.fr, caml-bugs@pauillac.inria.fr
>Hi,
>
>First, thank you for your bug reports. I will just say a word about
>your Scanf problem that is new and interesting to me.
>
>[...]
> > >- Running the newly built game (native) has a problem where a try with
>_
> > >block around a scanf doesn't catch the exception, using either _ or
> > >Scanf.Scan_failure...I can try to make a small repro case if you don't
> > >already know about this
> >
> > No, we don't, and you're welcome to send a program that shows the
> > behavior.
>
>My guess is that you may have either a partial application of scanf
>(hence no exception is raised) or a bad use of kscanf ?
>
>In any case, I would be very glad to get a (small) example that
>reproduces this behaviour.
>
>Best regards,
>
>Pierre Weis

(0000166)
administrator (administrator)
2003-08-28 17:24

> This is a forward of my beta1 mailing to caml@inria.fr. Did that original
> mail not get through (I got no response)?

I got it. To summarize:

>- opt.opt binaries not installed with make -f Makefile.nt install

>- no camlp4 opt.opt built with opt.opt (useful if you just want fast
>streams and don't care about loading other syntax extensions)

As usual, the windows makefiles lags a bit behind, but I'll try to
update them before the release.

>
>
>- camlp4 opt.opt build broken if called from root
> - compile.sh: no /dev/null on windows, use NUL (or have an empty
> file in the dist)
> - then it breaks on something with pa_o_fast.ml interf0
> - make clean in camlp4/compile and then make && make opt seems to
> fix it
>
>- is there any way to include the patch below for toplevel/topdirs.ml? It
>makes an #init;; command that allows you to clear the environment, so you
>don't have to restart the toplevel if you've #load'ed a module you need to
>edit, it's very useful

I believe this command can break type safety by, in effect, allowing
different interfaces for the same module to be confused. Consider
a module Foo defining type t = int. At top-level, do

        let x = (1 : Foo.t);;
        val x : Foo.t

Then, change Foo so that type t = string and recompile.
        #init;;
        x ^ " hello";;

At this point, the system will believe that x is of type string,
and crash.

> >- tk83.lib link error when building if not in lib path...README.win32 has
> >a mention of this in the "installing" section but not in the
> >"recompilation" section, so it should probably be duplicated in the
> >checklist/algorithm there so lazy people like me don't miss it. (isn't it
> >possible to add an /L $(TK_PATH)/lib on the link command line in the
> >labltk makefiles and get the same results without requiring setting LIB,
> >or set LIB in the makefile?)

There is a comment to this effect in config/Makefile.msvc. You can do
that in the config file, but then the Tcl/Tk location is hard-wired in
labltk.cma and camltk.cma, which is not adequate for a binary
distribution of OCaml (but might be adequate if you install from sources).

>- was there a -cclib and -ccopt change or fix? I had to change a makefile
>to use -ccopt instead of -cclib, but I'm vaguely remembering reporting a
>bug about this in 3.06, so maybe it got fixed and that explains the
>behavior change

The change (IIRC) is that the options given with -ccopt are passed to
msvc at the end of the command-line, so that /link options (which must
be last on msvc's command line) can be given either as -ccopt or as
-cclib (but not both). That change was suggested by another user, and
it looked innocuous enough. Sorry if it broke something.

>- Running the newly built game (native) has a problem where a try with _
>block around a scanf doesn't catch the exception, using either _ or
>Scanf.Scan_failure...I can try to make a small repro case if you don't
>already know about this

No, we don't, and you're welcome to send a program that shows the
behavior.

>- I can't build my game for bytecode because linking one of the library
>thunk DLLs bombs on an unresolved _local_roots, even though ocamlrun.lib
>is being linked (and it works fine on 3.06)...again, let me know if you
>need a repro case

Does the thunk DLL in question belong to a library distributed with
OCaml, or is this a third-party library? In the first case, it's our
fault and I'm interested in more details. In the second case, you may
have to add -DCAML_DLL when creating the C object files that will go
in the DLL.

(I agree that producing a Caml/C library that works both with dynamic
linking and with static linking under Windows is currently a nightmare.
I have some ideas on how to simplify this, but not for 3.07.)

Thanks for your feedback,

- Xavier Leroy

(0000167)
administrator (administrator)
2003-08-28 22:13

Hi,

First, thank you for your bug reports. I will just say a word about
your Scanf problem that is new and interesting to me.

[...]
> >- Running the newly built game (native) has a problem where a try with _
> >block around a scanf doesn't catch the exception, using either _ or
> >Scanf.Scan_failure...I can try to make a small repro case if you don't
> >already know about this
>
> No, we don't, and you're welcome to send a program that shows the
> behavior.

My guess is that you may have either a partial application of scanf
(hence no exception is raised) or a bad use of kscanf ?

In any case, I would be very glad to get a (small) example that
reproduces this behaviour.

Best regards,

Pierre Weis

(0000168)
administrator (administrator)
2003-09-26 16:06

Issues resolved or explained. Suggestion for #init remains.

- Issue History
Date Modified Username Field Change
2005-11-18 10:13 administrator New Issue
2013-08-30 22:36 doligez Tag Attached: patch


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker