Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#init in toplevel (was: 3.07 beta 2 test build/run results) #8250

Closed
vicuna opened this issue Aug 26, 2003 · 8 comments
Closed

#init in toplevel (was: 3.07 beta 2 test build/run results) #8250

vicuna opened this issue Aug 26, 2003 · 8 comments

Comments

@vicuna
Copy link

vicuna commented Aug 26, 2003

Original bug ID: 1799
Reporter: administrator
Assigned to: @diml
Status: resolved (set by @diml on 2017-01-05T12:08:58Z)
Resolution: suspended
Priority: normal
Severity: feature
Category: ~DO NOT USE (was: OCaml general)
Tags: patch

Bug 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, ~40 .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

@vicuna
Copy link
Author

vicuna commented Aug 27, 2003

Comment author: administrator

(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

@vicuna
Copy link
Author

vicuna commented Aug 27, 2003

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Aug 28, 2003

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Aug 28, 2003

Comment author: administrator

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 (#8250)
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

@vicuna
Copy link
Author

vicuna commented Aug 28, 2003

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Aug 28, 2003

Comment author: administrator

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

@vicuna
Copy link
Author

vicuna commented Sep 26, 2003

Comment author: administrator

Issues resolved or explained. Suggestion for #init remains.

@vicuna
Copy link
Author

vicuna commented Jan 5, 2017

Comment author: @diml

I'm closing this old issue. If #init is still desired, please open a new ticket or submit a PR.

@vicuna vicuna closed this as completed Jan 5, 2017
@vicuna vicuna assigned ghost Mar 14, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant