I am very new to Coq.
In our project, we switched to using the coq_makefile utility and came across the following problem.
Stepping through a proof script would result in this error:
Require Import comparable.
Error:
The file /Users/ayman/open-source/regex-reexamined-coq/comparable.vo contains library
Top.comparable and not library comparable
Our _CoqProject file is very simple (maybe that is the problem), it just lists all the files in the project https://github.com/awalterschulze/regex-reexamined-coq/blob/2c865aecc00276e0a926c1729cc35553c1cc6767/_CoqProject.
Coq libraries have a logical path. For example, files from the standard library all have a logical path starting with Coq. In your case, you did not specify anything about the logical path, so Coq arbitrarily puts the compiled files into a path starting with Top. Later, when trying to load the file, Coq compares the logical path Top to the physical path . and complains about the discrepancy.
The simplest fix is to add the following line to your _CoqProject file: -R . Top. Option -R maps a physical path (here .) to a logical path (here Top), which will fix the discrepancy.
But Top is a poor name for a library, so you should replace it with something else. Moreover, that name will serve as the installation path for your library, so choose a meaningful name (e.g., RegexDerivatives), as that is the name users will be using.
Related
my issue seems to be a common one, but none of the found answers could solve it.
I am following the software foundations course on Coq, and so I come to the command:
> From LF Require Export Basics.
Whatever I try, I get always the following answer:
"Cannot find a physical path bound to logical path matching suffix <>
and prefix LF."
I compiled Basics.v from coqIde, and the Basics.vo file is created correctly.
I also compiled it from the coqc command line, as suggested somewhere
My _CoqProject file exists, in the same folder as Basics.v, and states: -Q . LF
the _CoqProject parameter is set to "appended to arguments".
when I load Basics.v I see on the bottom of CoqIde "Reading Options from ..._CoqProject"
I put the lf folder into a folder which is in the LoadPath of coq.
What else could I check?
My system is Windows 10. I run CoqIde 8.9.1
Thank you!
I usually work under a Linux machine, but here something I did using a virtual machine.
I downloaded the windows installer from https://github.com/coq/coq/releases/tag/V8.9.1
I downladed the lf.tgz file from https://softwarefoundations.cis.upenn.edu/lf-current/index.html
I ran the windows installer for Coq. It placed the coq system in C:\coq
I used cygwin tools to expand the file lf.tgz so that I had a directory C:\Users\user\foundations\lf containing Basics.v, _CoqProject etc.
Then I used the search command to find coqide as an installed app. I then proceeded with the following steps:
start coqide
open the file Basics.v
use the option Compile->Compile buffer
I could then observe that the directory C:\Users\user\foundations\lf contained a file named Basics.vo
Then I opened a new buffer, and wrote From LF Require Export Basics. and did not try to execute this line
I saved this buffer in a file in directory C:\Users\user\foundations\lf. Let's assume this file is named toto.v
I closed the toto.v buffer.
I re-opened the toto.v using the option File->Open
I executed the file contents.
This process is the result of trial-and-error. What I know is that Require Export ... only works if there are ...vo files on you disk, but coqide needs to know where to look for these files. For this it maintains a "load path". When opening a file from a given directory, coqide looks in this directory (and ancestors) to find a _CoqProject file, and the latter may contain directives to modify the load path. It is the case here "-Q . LF" indicates that all .vo files in the current directory should be considered, and that their symbolic name should start with the prefix "LF."
The problem is that when you start from an empty buffer, no _CoqProject file gets read and coqide does not where to look for your data. This is why I did the steps 5-6-7: when reading the file toto.v, I provoked the reading of the _CoqProject file.
Takeaway lesson: Make sure the Basics.vo file exists, and then make sure the buffer you are working on was obtained through a reading operation from the same directory. If needed, save, close, and re-open to make sure this is the case.
For an application I am running, there is a run time error as it cannot find libwayland-client.so.0 shared object. How do I know which package provides it and where do I add it. I tried as shown below but it gave me a Nothing PROVIDES error.
CORE_IMAGE_EXTRA_INSTALL += "libwayland-client"
You don't typically work with single files when building Yocto images
In reverse order
You install packages to the image
You build packages by using a recipe
You find (or as a last resort write) recipes as part of layers.
Generally when something is missing you take the following steps:
Check the layerindex https://layers.openembedded.org/layerindex/branch/master/recipes/?q=wayland It tells you that there is a recipe called wayland in layer openembedded-core
Add the layer in question. openembedded-core is already contained in Yocto's poky (directly under the name meta, just to confuse the newcomer...), so nothing to add in this example
Create the environment listing of the recipe in question, bitbake -e wayland >wayland.env
Check what packages the recipe in question creates grep ^PACKAGES= wayland.env. In this case it is easy because there is really only one package wayland (-debug, -dev etc. are special purpose that would not contain the library)
Add a package to the image by its package name. How to do that exactly depends on the image type you create. The variable name given in the question works for some images, but not all. Search for IMAGE_INSTALL in the manual https://www.yoctoproject.org/docs/2.6.1/mega-manual/mega-manual.html for other options.
Once you have built the recipe in question you can also check what files are contained in a package (In this case recipe name and package name are identical, but that is not always the case. Some recipes build more than one package suitable for installation, so obviously they need to use different names)
$ oe-pkgdata-util list-pkg-files wayland
wayland:
/usr/lib/libwayland-client.so.0
/usr/lib/libwayland-client.so.0.3.0
/usr/lib/libwayland-cursor.so.0
/usr/lib/libwayland-cursor.so.0.0.0
/usr/lib/libwayland-server.so.0
/usr/lib/libwayland-server.so.0.1.0
I am running CoqIDE to use read the textbook series "Software Foundations", I am currently reading the volume "Logical Foundations". I just started Chapter 2 (Induction), but when I try to run the line
From LF Require Import Basics.
I get an error statement
The file ...\LF\Basics.vo contains library
Basics and not library LF.Basics
I tried renaming the directory the file was located in, and recompiled the buffers, but neither of these actions helped. What Shoudl i do in order to solve this problem?
We've been improving the explanation in the soon-to-be-released new version of LF. Here is the relevant bit:
For the [Require Export] to work, Coq needs to be able to
find a compiled version of [Basics.v], called [Basics.vo], in a directory
associated with the prefix [LF]. This file is analogous to the [.class]
files compiled from [.java] source files and the [.o] files compiled from
[.c] files.
First create a file named [_CoqProject] containing the following line
(if you obtained the whole volume "Logical Foundations" as a single
archive, a [_CoqProject] should already exist and you can skip this step):
[-Q . LF]
This maps the current directory ("[.]", which contains [Basics.v],
[Induction.v], etc.) to the prefix (or "logical directory") "[LF]".
PG and CoqIDE read [_CoqProject] automatically, so they know to where to
look for the file [Basics.vo] corresponding to the library [LF.Basics].
Once [_CoqProject] is thus created, there are various ways to build
[Basics.vo]:
- In Proof General: The compilation can be made to happen automatically
when you submit the [Require] line above to PG, by setting the emacs
variable [coq-compile-before-require] to [t].
- In CoqIDE: Open [Basics.v]; then, in the "Compile" menu, click
on "Compile Buffer".
- From the command line: Generate a [Makefile] using the [coq_makefile]
utility, that comes installed with Coq (if you obtained the whole
volume as a single archive, a [Makefile] should already exist
and you can skip this step):
[coq_makefile -f _CoqProject *.v -o Makefile]
Note: You should rerun that command whenever you add or remove Coq files
to the directory.
Then you can compile [Basics.v] by running [make] with the corresponding
[.vo] file as a target:
[make Basics.vo]
All files in the directory can be compiled by giving no arguments:
[make]
Under the hood, [make] uses the Coq compiler, [coqc]. You can also
run [coqc] directly:
[coqc -Q . LF Basics.v]
But [make] also calculates dependencies between source files to compile
them in the right order, so [make] should generally be prefered over
explicit [coqc].
If you have trouble (e.g., if you get complaints about missing
identifiers later in the file), it may be because the "load path"
for Coq is not set up correctly. The [Print LoadPath.] command
may be helpful in sorting out such issues.
In particular, if you see a message like
[Compiled library Foo makes inconsistent assumptions over
library Bar]
check whether you have multiple installations of Coq on your machine.
It may be that commands (like [coqc]) that you execute in a terminal
window are getting a different version of Coq than commands executed by
Proof General or CoqIDE.
- Another common reason is that the library [Bar] was modified and
recompiled without also recompiling [Foo] which depends on it. Recompile
[Foo], or everything if too many files are affected. (Using the third
solution above: [make clean; make].)
One more tip for CoqIDE users: If you see messages like [Error:
Unable to locate library Basics], a likely reason is
inconsistencies between compiling things _within CoqIDE_ vs _using
[coqc] from the command line_. This typically happens when there
are two incompatible versions of [coqc] installed on your
system (one associated with CoqIDE, and one associated with [coqc]
from the terminal). The workaround for this situation is
compiling using CoqIDE only (i.e. choosing "make" from the menu),
and avoiding using [coqc] directly at all. *)
I have a matlab guide program I want to compile (package).
This program is not using the curve fitting toolbox.
Nevertheless the compiler complains about a missing licence.
mcc -C -o ...
Compiler version: 5.0 (R2013b)
Dependency analysis by DEPFUN.
Processing C:\Program Files\MATLAB\R2013b\toolbox\matlab\win64\mcc.enc
Processing C:\Program Files\MATLAB\R2013b\toolbox\curvefit\win64\mcc.enc
Depfun error: 'License checkout failed.
License Manager Error -4
Maximum number of users for Curve_Fitting_Toolbox reached.
How can I remove this dependancy for compilation?
According to the mcc document,
-N Clear Path
Passing -N effectively clears the path of all folders except the following core folders
(this list is subject to change over time):
matlabroot\toolbox\matlab
matlabroot\toolbox\local
matlabroot\toolbox\compiler\deploy
It also retains all subfolders of the above list that appear on the MATLAB path at compile time.
Including -N on the command line lets you replace folders from the original path,
while retaining the relative ordering of the included folders.
All subfolders of the included folders that appear on the original path are also included.
In addition, the -N option retains all folders that you included on the path that are not under matlabroot\toolbox.
In other words, you can clear all folders from the path and only keep the core MATLAB ones.
If you want to include some toolbox folders, you can use the -a option:
mcc ... -a C:\Program Files\MATLAB\R2013b\toolbox\...\...
Personally, I simply temporarily rename toolbox folders I don't need.
Just manually navigate to "matlabroot()\toolbox\" and rename, say, "signal" -> "signal_".
Surprisingly, the same could be done from the script, calling mcc() - almost no files in those folders are locked by matlab.exe.
This method doesn't sound like a "solution", of course it's just a "quick-and-dirty workaround". But, for me, it seem to work (R2015a).
Note, that you can easily check, what's actually included in your "deployed" dll (or exe), with 7z. Including files, added from toolboxes - see "my.dll.text\toolbox\"
PS1:
From my experience ,"-N" removes some unrelated stuff. Not all.
Moreover, when using "-N", you should carefully add stuff you need with "-I".
PS2:
In ".prj" file, created by deploytool(), there's something, that sounds related:
<matlab>
<root>D:\Program Files\MATLAB\MATLAB Production Server\R2015a</root>
<toolboxes>
<toolbox name="matlabcoder" />
...
</toolboxes>
...
</matlab>
but I've not checked, whether this actually controls witch toolboxes are used by mcc.
I am using Eclipse Juno CDT for a class I am taking, but it is telling me it can't resolve types found in include files, and these aren't headers I wrote.
The program I wrote compiles and runs exactly as it should if I run it through g++ via the command line. The problem is that I can't debug in Eclipse because it doesn't recognize even basic types like string. Also, no code completion. It finds the include files just fine, I can open those and look at the contents, but it still won't resolve types.
I've seen lots of suggestions for people with similar problems, but those all turned out to be not finding the include files, which isn't my problem. Any suggestions?
Maybe the types are in a namespace and you're not qualifying them (and not using a using declaration).
You likely have included the proper directory for the headers themselves. On my system it is: /usr/include/c++/4.4.6/
However, you probably don't have the directory containing the definition of the macro _GLIBCXX_BEGIN_NAMESPACE. Without this macro definition eclipse does not know that the stl types are in the std namespace. On my system this macro definition is squirreled away beneath the main c++ dir. Try adding the following paths to your include list:
/usr/include/c++/4.4.6/x86_64-redhat-linux
/usr/include/c++/4.4.6/x86_64-redhat-linux/bits
If you're not on redhat look for something similar. You can go to /usr/include and run the following grep to look for the headers with the necessary macro definition:
grep -R -P "define\\s*_GLIBCXX_BEGIN_NAMESPACE\(" .