Xavier Leroy | 1 Jul 1999 19:32
Picon
Picon
Favicon

Re: Sys.argv with interpreter and compiler

> E.g. I want to emit an error message that includes the name of the
> executable or, if the interpreter is used, the name of the script.
> 
> Wouldn't it be logically more consistent to pass the truncated array
> of arguments to the script under the interpreter so that the program
> always gets its name on index 0 - no matter whether it is compiled
> or interpreted?

Yes, it would be more consistent, but that's exactly what it does
currently.  At least, that's what a quick test under Linux shows.

> - With the current version it gets the name of the
> interpreter on this position.

That's surprising.  On which operating system do you see this
behavior?  The treatment of argv[0] in C w.r.t. #! scripts differs
between various versions of Unix, but we tried to compensate for this
in the OCaml bytecode interpreter.

- Xavier Leroy

Markus Mottl | 2 Jul 1999 01:35
Picon

Re: Sys.argv with interpreter and compiler

> > Wouldn't it be logically more consistent to pass the truncated array
> > of arguments to the script under the interpreter so that the program
> > always gets its name on index 0 - no matter whether it is compiled
> > or interpreted?
> 
> Yes, it would be more consistent, but that's exactly what it does
> currently.  At least, that's what a quick test under Linux shows.
>
> > - With the current version it gets the name of the
> > interpreter on this position.
> 
> That's surprising.  On which operating system do you see this
> behavior?  The treatment of argv[0] in C w.r.t. #! scripts differs
> between various versions of Unix, but we tried to compensate for this
> in the OCaml bytecode interpreter.

My explanation may probably be misconceived - maybe "interpreted" means
"interpreted by the byte code interpreter" to you whereas I use "compiled"
for byte code and native code and "interpreted" if I call the interactive
toplevel with a file argument.

Anyhow, I have made a test on two systems (Intel/Linux and Alpha/Digital
Unix) with ocaml-2.02-2. Both systems behaved exactly the same way, but
I got three different outputs for the three ways to execute the program.

The output of this program (bla.ml):

  print_endline Sys.argv.(0)

yielded:
(Continue reading)

Pierre Weis | 2 Jul 1999 02:39
Picon
Picon
Favicon

Re: Sys.argv with interpreter and compiler

> As far as I remember, making OCaml (at least under Unix) a "true"
> scripting-language (=with human-readable "#!"-scripts) is not so easy to
> achieve: only binaries may be used as interpreters of "#!"-scripts, which
> is not currently possible with the way the toplevel "ocaml" is designed -
> it needs to be a byte code file. Are there already any convenient ways
> around this problem?
> Using byte code for scripting is not so comfortable and I think that
> OCaml would give a wonderful language for "true" scripting...

I use a very simple way to achieve this: just tell the unix system to
execute the right ocaml interpreter, then I execute the file as
usual.

For instance:

pauillac:~$ cat > essai
#!/usr/local/bin/ocaml

print_string "Hello world!"; print_newline();;
exit 0;;
^D
pauillac:~$ chmod a+x ./essai
pauillac:~$ ./essai
Hello world!

Normally I use a special version of ocaml, with the regexp and unix
libraries linked, but it's the idea: just write plain caml code and
interpret it ! In many cases it is fast enough for what I need!

What do you think of this completely interpreted approach ?
(Continue reading)

Sven LUTHER | 5 Jul 1999 10:09
Picon
Picon

Re: Sys.argv with interpreter and compiler

On Fri, Jul 02, 1999 at 02:39:16AM +0200, Pierre Weis wrote:
> > As far as I remember, making OCaml (at least under Unix) a "true"
> > scripting-language (=with human-readable "#!"-scripts) is not so easy to
> > achieve: only binaries may be used as interpreters of "#!"-scripts, which
> > is not currently possible with the way the toplevel "ocaml" is designed -
> > it needs to be a byte code file. Are there already any convenient ways
> > around this problem?
> > Using byte code for scripting is not so comfortable and I think that
> > OCaml would give a wonderful language for "true" scripting...
> 
> I use a very simple way to achieve this: just tell the unix system to
> execute the right ocaml interpreter, then I execute the file as
> usual.
> 
> For instance:
> 
> pauillac:~$ cat > essai
> #!/usr/local/bin/ocaml
> 
> print_string "Hello world!"; print_newline();;
> exit 0;;
> ^D
> pauillac:~$ chmod a+x ./essai
> pauillac:~$ ./essai
> Hello world!

I don't get the same, why :

sh-2.02$ cat essay
#!/usr/local/bin/ocaml
(Continue reading)

Jacques GARRIGUE | 2 Jul 1999 03:30
Picon
Picon

Re: Sys.argv with interpreter and compiler

From: Markus Mottl <mottl <at> miss.wu-wien.ac.at>
> My explanation may probably be misconceived - maybe "interpreted" means
> "interpreted by the byte code interpreter" to you whereas I use "compiled"
> for byte code and native code and "interpreted" if I call the interactive
> toplevel with a file argument.

I had the same problem as you, and indeed find it disturbing.
Particularly, since there is no way to change the contents of
Sys.argv, this means that you cannot easily use the Arg module in a
caml script. Silly.

> As far as I remember, making OCaml (at least under Unix) a "true"
> scripting-language (=with human-readable "#!"-scripts) is not so easy to
> achieve: only binaries may be used as interpreters of "#!"-scripts, which
> is not currently possible with the way the toplevel "ocaml" is designed -
> it needs to be a byte code file. Are there already any convenient ways
> around this problem?

That part is not really a problem.
ocaml does not need to be a code file. You can perfectly link it with
the -custom option.  This is actually what you do when you add the
Unix library, which is a minimum to write scripts...
I suppose this is Pierre did, and he never realized that there was a
potential problem here.

Actually I use this scripting approach when developping libraries:
this avoids having to compile small test examples.

For scripting, there is however another potential problem: if your
script becomes a bit long, you should really think about compiling it,
(Continue reading)

Fabrice Le Fessant | 2 Jul 1999 02:53
Picon

Re: Sys.argv with interpreter and compiler


> achieve: only binaries may be used as interpreters of "#!"-scripts, which
> is not currently possible with the way the toplevel "ocaml" is designed -
> it needs to be a byte code file. Are there already any convenient ways

Maybe you can use "ocamlmktop -custom -o ocaml" to generate a
binary version of ocaml ...

- Fabrice

Markus Mottl | 2 Jul 1999 10:56
Picon

Re: Sys.argv with interpreter and compiler

> > As far as I remember, making OCaml (at least under Unix) a "true"
> > scripting-language (=with human-readable "#!"-scripts) is not so easy to
> > achieve: only binaries may be used as interpreters of "#!"-scripts, which
> > is not currently possible with the way the toplevel "ocaml" is designed -
> > it needs to be a byte code file. Are there already any convenient ways
> > around this problem?

Sorry for that (it was well past midnight when I wrote this). It is of
course possible to make a binary version of the toplevel with "-custom"
- I mixed this up with the debugger, which exists as byte code version
only. It didn't even come to me to try the "#!"-version (!?). Maybe I
should stop going to bed this late...

The problem with the argument vector still remains, of course: instead
of the script name, the path to the toplevel is given on index 0.

> For scripting, there is however another potential problem: if your
> script becomes a bit long, you should really think about compiling it,
> typechecking becoming slow.  The multiple VM is useful then.

Another solution would be to make parts of the file which hardly change
a separate module, compile them to binary code and link them with
the toplevel.  So only the parts that are considered more "volatile"
stay in the script.

The possibility to generate one's own "interpreter" is really a very
interesting feature of OCaml. Thus, one can nearly arbitrarily speed up
scripts by linking more and more parts with the toplevel...

Best regards,
(Continue reading)

Favicon

small code problem


Hello all--

I'm having a problem with a core dump due to an uncaught exception.
The following snippet of code best illustrates the problem:

let usage = lazy (Printf.printf "Usage: %s file\n" Sys.argv.(0); exit ~-1);;
let filename =
        try
           Sys.argv.(1)
        with Invalid_argument("Array.get") ->
           Lazy.force usage;;

When I compile using the byte-code compiler, it seems to work fine.

         [knotwell <at> knotwell stock]$ ocamlc junk.ml
	 [knotwell <at> knotwell stock]$ ./a.out
	 Usage: ./a.out file
	 [knotwell <at> knotwell stock]$ 

On the other hand, when I compile with the optimizing compiler, I
receive the following:

	[knotwell <at> knotwell stock]$ ocamlopt junk.ml
	[knotwell <at> knotwell stock]$ ./a.out
	Segmentation fault (core dumped)
        [knotwell <at> knotwell stock]$	
When I change the code slightly:

let usage = lazy (Printf.printf "Usage: %s file\n" Sys.argv.(0); exit ~-1);;
(Continue reading)

Markus Mottl | 5 Jul 1999 12:37
Picon

Re: Sys.argv with interpreter and compiler

> I don't get the same, why :
> 
> sh-2.02$ cat essay
> #!/usr/local/bin/ocaml
> print_string "Hello world!"; print_newline();;
> exit 0;;
> ^D
> sh-2.02$ ./essai
> ./essai: line 2: syntax error near unexpected token `;'
> ./essai: line 2: `print_string "Hello world!"; print_newline();;'

Your toplevel "/usr/local/bin/ocaml" is obviously compiled to byte code.
Take a look at it with "less" and you will see that the first line of
this executable is actually "#!/home/mottl/mysys/bin/ocamlrun".

As far as I know it is not allowed on any unix system to run scripts
whose interpreter is a script itself. This would make it much easier to
replace this interpreter with something evil - e.g. some kind of wrapper
that executes unfriendly commands under you UID and continues with the
"true" interpreter.

Try the difference like this:

  ocamlmktop -o newtop

Now place replace "#!/usr/local/bin/ocaml" with the path to the newly
created "newtop" and run "essay" again - you will again receive an error
message, because the system will run the script with your current shell
instead with "newtop" which is not a "true" binary.

(Continue reading)

STARYNKEVITCH Basile | 5 Jul 1999 12:57
Picon
Favicon

Q: parametric types in simple functors?


The subject title is poor. I have a concrete simple question.

(All CAML code is indented to the right here)
Consider

   type 'a symbol = { sy_name: string; sy_hash: int; mutable sy_prop: 'a option };;

This is essentially a symbol, memoizing its hash code for fast
access. Some structures are naturally hashed map, whose key are
symbols (eg bindings). We make symbols with

  let get_symbol n =
    try Hashtbl.find symdict n 
    with Not_found ->
     let s = { sy_name=n; sy_hash=Hashtbl.hash n; sy_prop=None } in
      Hashtbl.add symdict n s;
      s
  ;;

The property field of symbols could be used the way you like it.

I want to define a binding as an hashtable mapping symbols to (say)
integers - or even any type 'b. But I can't code:

  module SymbolHash = Hashtbl.Make(
     struct 
       type t = symbol
       let equal s1 s2 = s1 == s2
       let hash {sy_hash=h} = h
(Continue reading)


Gmane