I'm running Ubuntu, installed Ocaml, and wrote the following script, as I found it in a set of instructions (course notes):
;; open Assert
;; print_int 1
saved this file as test.ml. Then in a terminal I navigated to the folder containing the file and executed
$ ocaml test.ml
The containing folder has the assert.ml file and assert.mli. I looked at some documentation in these course notes and on Ocaml's website, and can't find any official statement about how to open a module other than trying the above. When I run this, I get the error message
File "test.ml", line 1, characters 8-14:
Error: Unbound module Assert
Can anyone describe how this is supposed to work?
If you have just assert.ml and assert.mli, then you need to compile them first before they can be used in other code.
You can use the ocaml compiler directly like this:
$ ocamlc -c assert.mli
$ ocamlc -c assert.ml
This will create files named assert.cmi (the compiled version of assert.ml) and assert.cmo (the compiled version of assert.ml).
After that, your test.ml file should work OK if you run it like this:
$ ocaml assert.cmo test.ml
(Thanks #camlspotter.)
The open construct in OCaml doesn't cause a module to become available if it wasn't available before. What it does is make the names in the module available directly. Without open, you need to prefix the names with the name of the module: Module.name. In my opinion (shared by some others) it is best to limit the use of open, to avoid introducing too many names into the scope of your code.
As a side comment, it is stylistically very strange to begin your lines with ;;. This token is used to tell the OCaml toplevel (the interpreter) that it should evaluate what you've typed so far. So it usually comes after some interesting expression.
I personally don't use ;; at all in source files. I only use it when typing expressions into the toplevel.
Related
In my home folder in Linux I have several config files that have "rc" as a file name extension:
$ ls -a ~/|pcregrep 'rc$'
.bashrc
.octaverc
.perltidyrc
.screenrc
.vimrc
What does the "rc" in these names mean?
It looks like one of the following:
run commands
resource control
run control
runtime configuration
Also I've found a citation:
The ‘rc’ suffix goes back to Unix's grandparent, CTSS. It had a command-script feature called "runcom". Early Unixes used ‘rc’ for the name of the operating system's boot script, as a tribute to CTSS runcom.
Runtime Configuration normally if it's in the config directory. I think of them as resource files. If you see rc in file name this could be version i.e. Release Candidate.
Edit: No, I take it back officially... "run commands"
[Unix: from runcom files on the CTSS system 1962-63, via the startup script /etc/rc]
Script file containing startup instructions for an application program (or an entire operating system), usually a text file containing commands of the sort that might have been invoked manually once the system was running but are to be executed automatically each time the system starts up.
Thus, it would seem that the "rc" part stands for "runcom", which I believe can be expanded to "run commands". In fact, this is exactly what the file contains, commands that bash should run.
Quoted from What does “rc” in .bashrc stand for?
I learnt something new! :)
In the context of Unix-like systems, the term rc stands for the phrase "run commands". It is used for any file that contains startup information for a command. It is believed to have originated somewhere in 1965 from a runcom facility from the MIT Compatible Time-Sharing System (CTSS).
Reference: https://en.wikipedia.org/wiki/Run_commands
In Unix world, RC stands for "Run Control".
http://www.catb.org/~esr/writings/taoup/html/ch10s03.html
To understand rc files, it helps to know that Ubuntu boots into several different runlevels. They are 0-6, 0 being "halt", 1 being "single-user", 2 being "multi-user"(the default runlevel), etc. This system has now been outdated by the Upstart and initd programs in most Linux Distros. It is still maintained for backwards compatibility.
Within the /etc directory are several folders labeled "rc0.d, rc1.d" etc, through rc6.d. These are the directories the kernel refers to to know which init scripts it should run for that runlevel. They are symbolic links to the system service scripts residing in the /etc/init.d directory.
In the context you are using it, it would appear that you are listing any files with rc in the name. The code in these files will set the way the services/tasks startup and run when initialized.
I have a package that uses config.json for some settings it uses. I keep the package locally rather than installing it from CPAN. My problem is when I make changes to config.json, the package doesn't recognize the changes since the config file's cached elsewhere, forcing me to run zef install --force-install or delete precomp. How can I ensure that the package always recognizes updates to the config file?
When you install packages using zef, it keeps them in the filesystem, but their names are converted into sha1, something like
/home/jmerelo/.rakudobrew/moar-2018.03/install/share/perl6/site/sources/81436475BD18D66BFD96BBCEE07CCCDC0F368879
zef keeps track of them, however, and you can locate them using zef locate, for instance:
zef locate lib/Zef/CLI.pm6
You can run that from a program, for instance this way:
sub MAIN( Str $file ) {
my $location = qqx/zef locate $file/;
my $sha1 = ($location ~~ /\s+ \=\> \s+ (.+)/);
say "$file → $sha1[0]";
}
which will return pretty much the same, except it will give you the first location of the file you give it at the command line:
lib/Zef/CLI.pm6 → /home/jmerelo/.rakudobrew/moar-2018.03/install/share/perl6/site/sources/81436475BD18D66BFD96BBCEE07CCCDC0F368879
You probably need to install your config.json file in a resources directory (which is the preferred location) and then use something like that.
That said, probably actually installing a module you're testing is not the best strategy. If you're still testing things, it's probably better if you just keep it in the directory you're working with and use perl6 -I<that directory> or else use lib <that directory> is probably a better option. You can just delete that when you release, or keep it, since that only adds another directory to the search path and will not harm the released module.
Sorry for the noob question. I just downloaded CAM::PDF along with Strawberry for Windows, and trying to do find/replace from the command line. Ran buidinstalldeps to get all needed prereqs.
I'm trying to run changepagestring.pl from command line. But idk how to reference the file location and have it put the output file for me in a specified location:
changepagestring.pl master-exch-manual.pdf "as shown in Figure" figure output.pdf
My goal is to replace "see above figure" with "figure" in this file. But it's in a different directory than the one I'm in, C:\Users\Me\Doc\CAM-PDF-1.60\
So how do I run and do all this from the command line. I've seen the help file with example, but I get this:
CAM::PDF from command shell with PL file not recognized
There are a few possible solutions. The easiest one from the directory you mentioned is:
perl -Ilib bin/changepagestring.pl ...
Alternatively, if you run the usual Perl install commands from that folder, then changepagestring.pl should be included in your usual path
perl Makefile.PL
make install
Alternatively^2, you can use the "cpan" tool to automate the download, build, test and install steps in one go:
cpan install CAM::PDF
what i want to achieve
I want to pack a .clang-format file with my software, which only gets used if the user doesn't provide their own.
My idea so far is to use clang-format -style=file which will find the users .clang-format if it is "located in one of the parent directories of the source file". (Which might be the case because it is in their home directory, or because they are using my package as a git submodule, or because they manually placed it after downloading my software).
If no .clang-format file is found, then the one shipped with my software should be used - e.g. by symlinking to mypackage/auxiliary_files/.clang-format in the top level. I want to do this somewhat automatized from cmake directly or by calling a shell script from cmake (or other).
workflow in short
clang-format finds .clang-format: do nothing (as shell script exit 0; as cmake script set(I-FOUND-CLANG-FORMAT 1) or something similar)
clang-format doesn't find .clang-format: call ln -s auxiliary_files/.clang-format
what I don't want to do
I don't want to write a loop which replicates the search behaviour of clang-format (going one directory up to look for .clang-format until either it's found or the top most directory is reached) to have built-in 100% compatibility.
options i've seen but didn't figure out how to use for my goal
clang-format does not appear to return a non-zero status code if no style file has been provided although style=file is set, even if -fallback-style=none is set. I also don't see in the printout if the fallback option or the regular option is used.
I am pulling my hair out over an issue I am having with building rpms through LTIB. I am trying to write my own spec file and for some reason It seems as though simple macros I have defined will not expand within the %Files section.
For example, at the top of my spec file I have the following:
%define myfilepath %{pfx}/lib/python%{pyver}/site-packages/wx-2.8-gtk2-unicode/
and my %Files section looks like this:
%Files
%defattr(-,root,root)
%{myfilepath}
Yet when I run ./ltib -m scdeploy -p I get the following error
RPM build errors:
File must begin with "/": %{myfilepath}
Build time for wxPython: 0 seconds
Is there something I'm missing? Nowhere in the documentation do I see that macros are dissallowed in the %Files section. predefined macros seem to expand fine within the %files section but any macro I have defined with %define in the header of my spec file acts as though its undefined when I am running ltib with the scdeploy option. Macros all work as expected when executing ltib withprep, scbuild and scinstall modes.
Edit: Using ltib version 9.1.1, rpmbuild version 4.0.4
Managed to figure it out after looking at the ltib source. It turns out ltib fabricates a spec file when running in scdeploy mode. This fabricated spec file only preserves the contents of the %files section in the spec file you wrote so the header and all of the macros you defined there are lost.
Not sure why LTIB behaves this way for scdeploy and not sbuild, scinstall, etc. I have a question out to the LTIB mailing list.