For my summer programming course I need to compile and test several functions from an ocaml file (a .ml file) our teacher gave us. I've never programmed in ocaml before, but I downloaded it on my ubuntu vm and not I can't figure out how to compile it and test the functions from the terminal.
I'm also curious if I need to add print statements to the code in order to test them, since ocaml doesn't require main methods. If so, how do I print the return value of a function?
Thank you for your help, I apologize if this is a newbie question.
Make sure that you have installed OCaml properly, by running the OCaml interactive toplevel (don't type $ this is a prompt from your shell):
$ ocaml
It should show something like this:
OCaml version 4.07.0
#
The # symbol is a prompt, you can type OCaml definitions there and send them to the interpreter using the ;; terminating sequence (again don't type # it is also a prompt symbol), e.g.,
# print_endline "Hello, world";;
Hello, world
- : unit = ()
#
Hint: to enable history install rlwrap with sudo apt install rlwrap and run the ocaml toplevel as
$ rlwrap ocaml
Now, we are ready to compile our first program. In OCaml, like in Python, all top-level definitions in your program are evaluated in order of their appearance, therefore you don't need to have a special main function. Despite this fact, I'm usually defining one, using the following idiom
let main () =
print_endline "Hello, world"
(* the entry point - just call the main function *)
let () = main ()
Now, create a new folder (make sure it is empty)
$ mkdir my-first-ocaml-program
$ cd my-first-ocaml-program
and put the OCaml code above into a file named test.ml (the filename doesn't have any special meaning for the compiler toolchain, but I will reference this name in the shell commands below).
let's test that everything is correct, by printing the contents of the test.ml file
$ cat test.ml
and the output should be
let main () =
print_endline "Hello, world"
(* the entry point - just call the main function *)
let () = main ()
Now, let's compile and run at the same time,
$ ocamlbuild test.native --
And we should see the "Hello, world",
Finished, 4 targets (4 cached) in 00:00:00.
Hello, world
The first line is the output from the compiler (ignore it, unless it is different). Starting from the second line it is our output. Here are some explanations on the build one-liner, ocamlbuild test.native. It uses ocamlbuild, an easy to use but powerful OCaml build tool. The test.native tells ocamlbuild that you want to build a native (machine code) binary and that test.ml is the main source file. You can also ask to build a bytecode binary, e.g., test.byte. This is called a target in ocamlbuild parlance. The -- is optional, and it tells ocamlbuild to run the built target as soon as it is ready. Any argument past -- is passed to your program as command line arguments.
What about larger programs or programs with dependencies? The good news is that you can put your code in several files in the same folder, and ocamlbuild will be clever enough to build them in the proper order (it will do the dependency analysis, compiling, and linking for you - all seamlessly). If you need to use some external package, then you can specify it via the -pkg option. For example, let's assume that we're using the fileutils package to implement our version of the ls program1. Let's update our test.ml so that it now is having the following contents:
$ cat test.ml
let main () =
FileUtil.ls "." |> List.iter print_endline
(* the entry point - just call the main function *)
let () = main ()
and, as usual, build and print in one
$ ocamlbuild -pkg fileutils test.native --
Finished, 4 targets (4 cached) in 00:00:00.
./test.native
./_build
./test.ml
1) How to install a package is system dependent. E.g., if you're using apt to install OCaml then you can do sudo apt install libfileutils-ocaml-dev. If you're using opam (the recommended way), then it is just opam install fileutils. In any case, package installation is out of the scope of this question, I'm assuming that in your course you would be using some packages pre-installed. We use fileutils here just as an example, which you can easily adapt to your own purposes.
Related
I'm trying to reconfigure some .config variables to generate a modified kernel with wifi support enabled. The native layer/recipe for the kernel is located in this directory:
meta-layer/recipes-kernel/linux/linux-yocto_3.19.bb
First I reconfigure the native kernel to add wifi support (for example, adding CONFIG_WLAN=y):
$ bitbake linux-yocto -c menuconfig
After that, I generate a "fragment.cfg" file:
$ bitbake linux-yocto -c diffconfig
I have created this directory into my custom-layer:
custom-layer/recipes-kernel/linux/linux-yocto/
I have copied the "fragment.cfg file into this directory:
$ cp fragment.cfg custom-layer/recipes-kernel/linux/linux-yocto/
I have created an append file to customize the native kernel recipe:
custom-layer/recipes-kernel/linux/linux-yocto_3.19.bbappend
This is the content of this append file:
FILESEXTRAPATHS_prepend:="${THISDIR}/${PN}:"
SRC_URI += "file://fragment.cfg"
After that I execute the kernel compilation:
$ bitbake linux-yocto -c compile -f
After this command, "fragment.cfg" file can be found into this working directory:
tmp/work/platform/linux-yocto/3.19-r0
However none of the expected variables is active on the .config file (for example, CONFIG_WLAN is not set).
How can I debug this issue? What is supposed I'm doing wrong?
When adding this configuration you want to use append in your statement such as:
SRC_URI_append = "file://fragment.cfg"
After analyzing different links and solutions proposed on different resources, I finally found the link https://community.freescale.com/thread/376369 pointing to a nasty but working patch, consisting in adding this function at the end of append file:
do_configure_append() {
cat ${WORKDIR}/*.cfg >> ${B}/.config
}
It works, but I expected Yocto managing all this stuff. It would be nice to know what is wrong with the proposed solution. Thank you in advance!
If your recipe is based on kernel.bbclass then fragments will not work. You need to inherit kernel-yocto.bbclass
You can also use merge_config.sh scripts which is present in kernel sources. I did something like this:
do_configure_append () {
${S}/scripts/kconfig/merge_config.sh -m -O ${WORKDIR}/build ${WORKDIR}/build/.config ${WORKDIR}/*.cfg
}
Well, unfortunately, not a real answer... As I haven't been digging deep enough.
This was working alright for me on a Daisy-based build, however, when updating the build system to Jethro or Krogoth, I get the same issue as you.
Issue:
When adding a fragment like
custom-layer/recipes-kernel/linux/linux-yocto/cdc-ether.cfg
The configure step of the linux-yocto build won't find it. However, if you move it to:
custom-layer/recipes-kernel/linux/linux-yocto/${MACHINE}/cdc-ether.cfg
it'll work as expected. And it's a sligthly less hackish way of getting it to work.
If anyone comes by, this is working on jethro and sumo:
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:"
SRC_URI_append = " \
file://fragment.cfg \
"
FILESEXTRAPATHS documentation says:
Extends the search path the OpenEmbedded build system uses when looking for files and patches as it processes recipes and append files. The directories BitBake uses when it processes recipes are defined by the FILESPATH variable, and can be extended using FILESEXTRAPATHS.
I have a C extension to Tcl where command mytest is defined. The extension is compiled correctly (I am on Linux, extension is *.so). For example, I can start tclsh and use it like this:
$ tclsh
% load /path/extension.so
% mytest abc
...
But, if I create a file myscript.tcl with the following content:
load /path/extension.so
mytest abc
then I get error:
$ tclsh myscript.tcl
invalid command name "mytest"
while executing
"mytest abc"
(file "myscript.tcl" line 2)
I am using bash on Ubuntu 14.04. Tcl 8.6.
EDIT 1: My question/problem is that I want to use tclsh with a script as an argument - this script should properly load extensions in such a way that mytest and other implemented functions are working without error.
EDIT 2: Uhh, If I use command "source myscript.tcl" inside tcl shell the result is the same. If I use absolute path for myscript.tcl the error is still the same --- "load" executes without warning but I am not sure about it because I get invalid command name "mytest". Maybe the problem is with scope, but it is working correctly when tclsh is used interactively.
If you are using the full path of the extension library in both cases, that part should work identically. It probably is doing though; if it couldn't load it, it would generate an error (which might or might not be helpful, as some of the ways that things fail give very little information; Tcl reports what it has got, but that's sometimes not enough, as it is dependent on the OS to tell it some things). Instead, the problem is probably elsewhere.
The main difference between interactive use and scripted use is that in interactive use, the unknown command will expand unknown command names to Tcl commands that the thing you typed is an unambiguous prefix of. This is convenient, but when converting to a script, you should always use the full command name. OK, not the full full command name — you mostly don't want or need the :: namespace on the front — but without abbreviation, so don't use lappe for lappend. (In interactive use, Tcl will also exec things as external programs without requiring you to type the exec explicitly; again, that's turned off in scripts as it is rather fragile.)
Could it be that this is what is going on? You can check by setting the global variable tcl_interactive to 0 before typing in your code (I recommend using cut-n-paste for that typing, so that you know exactly what is going in). If that fails, it's the interactive-mode helpfulness that is tripping you up. Check what commands you might have as an expansion for a prefix with info commands (after the load, of course):
info commands mytest*
If that just reports mytest, my theory is wrong. (Well, if it does that and the length of that string is 6; there could theoretically be extra invisible characters have been put on the command name, which would be legal Tcl but very nasty and DON'T DO THAT!)
I'm not entirely sure how to define an Erlang function within an Erlang module. I'm getting the following error:
11> invoke_record:invoke().
** exception error: undefined function erlang:rr/1
From this simple code trying to invoke the rr(?MODULE). from within the beam executable in order to "initialize" records so that it doesn't need to be called from the shell every time.
-module(invoke_record).
-export([invoke/0]).
-record(process, {pid,
reference="",
lifetime=0
}).
invoke() ->
erlang:rr(?MODULE).
The command rr("file.hrl"). is meant to be be used only in shell for debugging purposes.
As other users highlighted in their answers, the correct way to import a record (or a function) contained in a .hrl file within your erlang code consists in using the command -include("file.hrl').
Once you have included the .hrl file in your code (and usually in a module based on OTP behaviours this is done after the -export(...) part) you can refer to the Erlang record (or function) without any problem.
rr is a shell command. You cannot use it it compiled code.
http://www.erlang.org/doc/man/shell.html
If your intent is to read many record definitions in the shell, in order to facilitate the debug, you can write a file containing all needed include statements and simply invoke rr once in the shell.
in rec.hrl:
-include("include/bank.hrl").
-include("include/reply.hrl").
and in the in the shell
1> rr("rec.hrl").
[account,reply]
2>
I didn't find any way to execute this automatically, when starting the VM.
When working on a project, you can gather all necessary includes and other command line arguments that you want to use for that particular project in a plain text file. After having made the plain text file, you can start your shell:
erl -args_file FileName
where FileName is the name of the plain text file. Note that all command line arguments accepted by erl are allowed. See also erl Flags in the ERTS Reference Manual
I need to add the csv module in one module compute.ml of an OCAML package.(see discussion ocaml hash from mysql)
Do you know of a simple way to amend the makefile (it is a complex document in my case and I don't think that I can fully rewrite it or switch to ocamlfind install) to enable a compilation without "Unbound value Csv.load" error messages?
ie can I include a new library inside an existing stable Ocaml package?
modified module : compute.ml,
modification;
let data = Csv.load ("foo.csv")
....
error message during compilation :
camlp5r ../wserver/pa_macro5.cmo -DUNIX -o compute.ppo compute.ml
ocamlopt.opt -warn-error A -I ../wserver -I ../sally -I +camlp5 -c -impl compute.ppo
File "compute.ml", line 110, characters 13-21:
Error: Unbound value Csv.load
Thanks for help
You have to tell ocamlopt where to look for csv.cm{i,x} files with the appropriate -I option, like the ones you already have at the end of your command line.
If the library lies in a subdirectory of OCaml's standard library (as given by ocamlc -where), you can use
-I +csv_dir, as is done for camlp5 in your example. Otherwise, you'll have to provide the full path.
Note that this is not the only modification that you'll have to do: you'll also have to add csv.cmx (or .cmxa) on the command line that perform the final link of your application/library.
So I am very new and inexperienced to the ways of TCL programming. I wrote a script that calls a proc written by someone else, first removing the output file. It then does some additional logic I wrote.
I moved the logic into a second proc and instantly a bunch of it broke (namely the rm commands).
From what I can tell, the first program on a line inside the central execution (the text following proc definitions) executes normally without an "exec" command. However, if you move it inside a proc, it now needs an "exec" command.
Can anyone explain to me why TCL behaves this way?
e.g.
proc helloworld {} {
puts "hi"
}
#works
rm my_file
helloworld
..
proc helloworld {} {
#doesn't work
rm my_file
puts "hi"
}
helloworld
..
proc helloworld {} {
#works
eval rm my_file
puts "hi"
}
helloworld
..
proc helloworld {} {
#works
file delete my_file
puts "hi"
}
helloworld
*Note this weird behavior may be specific to the program I'm feeding the script to vmd, which has its own built in TCL behavior. Perhaps in your responses you can indicate if this is standard for other interpreters as well?
An interactive tclsh session will try to exec an unknown command (such as rm). You cannot count on this behaviour in non-interactive script execution or, as you've discovered, in procs.
I can't see that this is documented in the tclsh man page, but the unknown man page does. See also the tclsh page on the Tcl wiki. In an interactive tclsh session, you can see what unknown does by typing:
info body unknown
[update]
Quoting from "Practical Programming in Tcl and Tk":
The unknown command provides a few other conveniences. These are used only when you typing commands directly. They are disabled once execution enters a procedure or if the Tcl shell is not being used interactively. The convenience features are automatic execution of programs, command history, and command abbreviation. These options are tried, in order, if a command implementation cannot be loaded from a script library.
Note this is programatically testable too, via the variable tcl_interactive, which is "1" if the Tcl is being run via an interactive shell, and "0" if not. The variable is also settable, so one could start an interactive shell, then [set tcl_interactive 0], and continue on. At this point, one loses such features as the % command prompt proc name / command name completion (i.e.: can't type [pu "xyz"] and get the effect of typing [puts "xyz"], like an interactive shell)automatic "shell-out" to have external commands complete a request (like the "rm" in this original question)and perhaps others...