I'm trying to get Coq working as a plugin for Sublime Text 3 on MacOS. I have everything working save for code that requires import statements.
The exact same code works perfectly when run in CoqIDE (which runs Coqc version 8.9), but when I try to run from Coqc verion 8.8 (homebrew install), when I reach my statement:
From LF Require Export Basics.
it throws the error:
Cannot find a physical path bound to logical path matching suffix <> and prefix LF.
When I remove From LF I get:
Basics.vo contains library LF.Basics and not library Basics
which indicates (at least to me) that the libraries are, indeed, compiling and making correctly, and something else is wrong.
Here are the commands that I run:
coq_makefile -f _CoqProject -o CoqMakefile
make -f CoqMakefile -B
My _CoqProject looks like this:
-R . LF
Basics.v
Induction.v
Anyone have any ideas or any experience with this?
Related
I'm trying to use Graphviz but am getting the error message:
graphviz.backend.ExecutableNotFound: failed to execute ['dot', '-Tpdf', '-O', 'test-output/aoc.gv.pdf'], make sure the Graphviz executables are on your systems' PATH
The code I am running is cut and pasted from the documentation:
from graphviz import Digraph, Graph
dot = Digraph(comment='The Round Table')
dot.node('A', 'King Arthur')
dot.node('B', 'Sir Bedevere the Wise')
dot.node('L', 'Sir Lancelot the Brave')
dot.edges(['AB', 'AL'])
dot.edge('B', 'L', constraint='false')
dot.render('test-output/aoc.gv.pdf')
The file will output to the correct folder and the file is there and it has 170 bytes but it will not open. I have tried other extensions such as just 'gv' and they do not work either. I'm using the latest version of Graphviz which is 0.10.1 and I have tried opening this file on a PC and it does not work on PC either (I have a Mac). This problem is similar to
Graphviz's executables are not found (Python 3.4)
and
Why is pydot unable to find GraphViz's executables in Windows 8?
However, there are major stumbling blocks to my understanding these posts. Number one, I have very little understanding of how Python is executed on a computer, so I really don't even know what an environment variable is. Second, when they refer to computer's PATH I can only assume that they're talking about the directory of the file which is executing the Graphviz module, but I'm not sure about that. So I've added this line of code:
import sys
str1 = "/library/frameworks/python.framework/versions/3.6/lib/python3.6/site-packages/graphviz/"
sys.path.append(str1)
But that is not working. Third, if I were to implement this step:
Add this string to the end of your Variable value list (including semicolon): ;C:\Program Files (x86)\Graphviz2.34\bin
Then I would have to translate that into its Mac counterpart and I'm not able to. Any help would be appreciated.
The diagnostic is saying that dot is not in your $PATH, it does not appear in any of the directories mentioned by that env var. You want to get to a point where trying the following command reports some version number:
$ dot -V
dot - graphviz version 2.40.1 (20161225.0304)
$
$ which dot
/usr/local/bin/dot
$
$ echo $PATH | tr : ' ' | fmt -w1 | grep local
/usr/local/bin
If you are not yet using Brew, you should. It's the easiest way to get this and many other programs onto your Mac. Visit https://brew.sh/ and follow the instructions. Then type:
$ brew install graphviz
...
$ /usr/local/bin/dot -V
That should work just fine. If dot -V says "not found" then simply append the proper directory to your PATH:
$ export PATH="${PATH}:/usr/local/bin"
If your bash shell can run it, then your python program should be able to, as well.
I tried these commands to help me locate the DOT file path on my mac. It was not: "/usr/local/bin/dot" on my system.
dot -V
dot - graphviz version 2.49.2
which dot
/opt/homebrew/bin/dot
I had installed Graphviz, but I was still running into trouble finding the right path. I am using Protege, and I had to modify the path for OwlViz since it was displaying the entire hierarchy at (0,0). I copied the path that I got by running the which dot command to the OWLViz tab on the preference dialog, and restarted protege and it worked perfectly! Good luck!
Problem solved. It took me a while to figure out that I had to download some non-pythonic software before I could get the pythonic software to work.
brew install graphviz
Was step 1 and I had done that before but I was getting an error message. It told me to change ownership of some files so I did that. Then tried
brew install graphviz
again and that did the trick.
I have a project writed for DEC Unix v4. I want to compile it for linux.
My project have Imakefile, I run xmkmf to generate Makefile and after that run make to compile but I get Makefile:1059: *** missing separator. Stop.
When I see this post I installed SparkyLinux and install CDE and libmotif-dev on it for Motif and CDE and again I am going to generate Makefile and run make, but my problem still
line 1059: MComplexProgramTarget(_gdsv_.o,$(LOCAL_LIBRARIES),)
That line is valid in an Imakefile, but not in a Makefile. It looks like a macro for the C preprocessor. When the preprocessor does not find a definition for a macro, it leaves it as-is.
The next question is therefore: Why is the macro MComplexProgramTarget undefined, and which file defines it usually?
To answer this, you need to know where imake reads its definition files ("strace -f xmkmf" can help you with this), and in which file does this word appear?
The most probable thing is that you have lead to some incompatibility issue with gmake, which should be the make version you are using. Install BSD make and use it to build the system. Probably this will solve your problem (or not, but I have had this kind of problems) Depending on the platform, the package is called bmake or pmake.
I am using the automatic Coq 8.5 makefile generator. This makefile prefixes all modules by "Top." .
Now let's say you run a lot of files by make and then want to change/debug some file in the IDE.
Then the annoying fact is that Coq complains it cannot find the compiled other files, because in the IDE it assumes the names without the "Top" prefix.
I tried to tweak the makefile to get rid of this prefix. But I always ended in some error message of the make.
Can someone show me either how to remove "Top" prefix in make or tell the IDE to use the "Top" prefix.
You can start CoqIDE with the following arguments coqide -R . Top.
This will get rid of the following error Error: The file ..../Logic.vo contains library Top.Logic and not library Logic.
This is annoying indeed. In order to avoid that kind of annoyance, always start your _CoqProject with a line listing options:
-Q . MyProject
To note: the options you can put on the first line of your _CoqProject are the ones listed when calling coqtop -help.
In older versions of Groovy, I could run Groovy as a shell script under Cygwin, following their own instructions for doing so:
$ cat ~/bin/hiworld
#!/usr/bin/env groovy
println("Hello world")
This worked. However, under (at least) Groovy 2.3.2 and 2.3.3, I'm seeing this instead:
$ hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
My best stab in the dark: "env" launches scripts via an absolute path (e.g. "groovy /home/myacct/bin/hiworld"), and newer versions of Groovy have been, un, 'improved' so that Groovy no longer understands how to handle this.
Indeed, I can produce the same error by doing that:
$ groovy ~/bin/hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
So I'm not sure how Groovy is (a) resolving that to a windows-style path, and then (b) failing to understand it's a windows-style path.
I can "fix" this, then, by running it thusly:
$ groovy $(cygpath -w ~/bin/hiworld)
Hello world
... but, c'mon, that's a completely insane way of having users launch a utility script. (Or I could write a "front" script, with just that line, to launch another script, of course. But then, for what I'm trying to ultimately accomplish, I might as well just give up on Groovy and distribute a runnable JAR with an associated launching script.)
So has Groovy simply dropped support for Cygwin? Or is it really possible that they've gone at least two releases without testing their own recommended way of running a script under one of the most popular environments?
If not, what am I missing or doing wrong?
Update: I thought it would be helpful to back up some of the things I'm suggesting here.
First, I want note Cygwin clearly is (or was) at least somewhat supported: groovyStart, for example, has considerable code in it supporting the Cygwin platform (seemingly as much as, say Mac OSX). As noted, it apparently worked fine under previous versions.
Currently, the last example resolves, under groovyStart, to this:
'/cygdrive/c/Program Files/Java/jdk1.7.0_51/bin/java' -classpath C:/cygwin64/home/myacct/opt/groovy-2.3.3/lib/groovy-2.3.3.jar -Dscript.name=/home/myacct/opt/groovy-2.3.3/bin/groovy -Dprogram.name=groovy -Dgroovy.starter.conf=C:/cygwin64/home/myacct/opt/groovy-2.3.3/conf/groovy-starter.conf -Dgroovy.home=C:/cygwin64/home/myacct/opt/groovy-2.3.3 '-Dtools.jar=C:/Program Files/Java/jdk1.7.0_51/lib/tools.jar' org.codehaus.groovy.tools.GroovyStarter --main groovy.ui.GroovyMain --conf C:/cygwin64/home/myacct/opt/groovy-2.3.3/conf/groovy-starter.conf --classpath . C:/cygwin64/home/myacct/bin/hiworld
Just to clarify, there's no problem invoking the JDK itself -- runs that part of the command runs just fine. The part which is broken is the very last argument: if I change
C:/cygwin64/home/myacct/bin/hiworld
to
file:///C:/cygwin64/home/myacct/bin/hiworld
... it works again. This agrees with my assertion above that "groovy" (the script) is indeed correctly converting from Cygwin/UNIX-style paths to a native Windows path, but the underlying process -- running in Windows Java -- is actually confused by having been a windows path! Apparently it was expecting a URL.
Update 2: Below, Warren makes the excellent suggestion of trying to use GVM. Sadly, this still produces the same error:
$ which groovy
/home/myacct/.gvm/groovy/current/bin/groovy
$ hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
$ sh $(which groovy) ~/bin/hiworld
Caught: java.net.MalformedURLException: unknown protocol: c
java.net.MalformedURLException: unknown protocol: c
Adding the "-x" flag to the previous command shows that Groovy is still using my Windows JVM (which isn't wrong, just noting) and is now referencing the GVM-installed libraries (shown here reformatted slightly for readability):
'/cygdrive/c/Program Files/Java/jdk1.7.0_51/bin/java' \
-classpath C:/cygwin64/home/myacct/.gvm/groovy/2.3.3/lib/groovy-2.3.3.jar \
-Dscript.name=/home/C400334/.gvm/groovy/current/bin/groovy \
-Dprogram.name=groovy \
-Dgroovy.starter.conf=C:/cygwin64/home/myacct/.gvm/groovy/2.3.3/conf/groovy-starter.conf \
-Dgroovy.home=C:/cygwin64/home/myacct/.gvm/groovy/2.3.3 \
'-Dtools.jar=C:/Program Files/Java/jdk1.7.0_51/lib/tools.jar' \
org.codehaus.groovy.tools.GroovyStarter \
--main groovy.ui.GroovyMain \
--conf C:/cygwin64/home/myacct/.gvm/groovy/2.3.3/conf/groovy-starter.conf \
--classpath . \
C:/cygwin64/home/myacct/bin/hiworld
As before, adding a "file:///" before the final argument seems to resolve the problem.
So I'm wondering perhaps if we're using a different version of the JVM or something?
Update 3: Upgrading to jdk1.7.0_60 (tried both 64- and 32-bit versions) but that didn't seem to make a difference. Java 6 exhibits the same problem, but also adds a complaint about missing NioGroovyMethods.
I'm not sure how Groovy is (a) resolving that to a windows-style path
The startGroovy script has specific code in it to detect Cygwin and use cygpath as necessary.
I discovered this by installing Groovy via GVM, the approved way of getting Groovy for Unixy platforms. (You do not want to use the native Windows distribution of Groovy in this case!)
The only tricky thing was figuring out how to set JAVA_HOME. Here, it needed to be:
$ export JAVA_HOME='/cygdrive/c/Program Files (x86)/Java/jre7'
If you're on a 64-bit version of Windows and have a 32-bit JRE installed as I do, this should also work for you. Otherwise, you may have to adjust the path.
Once I got gvm install groovy to succeed, your hiworld example worked fine here if I ran it as ./hiworld. This was with the 32-bit version of Cygwin with Java 1.7.0_55.
However, when I put it in the PATH and ran it as hiworld, as you are doing, this passed a fully-qualified path to the groovy wrapper script (e.g. /home/wyoung/bin/hiworld) instead of a relative path, which caused the startGroovy script to run the path through cygpath -m, which turns that into something like C:/cygwin64/home/wyoung/bin/hiworld. Oracle's JRE can't cope with forward slashes in local paths. It blindly assumes that forward slashes on Windows means it's a URL of some kind, so C: gets treated as the URL scheme, or "protocol" as they put it.
I don't know if this is a regression in Java or in the startGroovy script. Although you could pass a file:// URL here as you discovered, you can also pass a "proper" Windows path with backslashes instead of forward slashes. You get that from cygpath with the -w switch instead of -m. You have to be a lot more careful about avoiding accidental backslash escaping in this case, which may explain the regression.
Just hit the same problem and changed the exec call in the startGroovy script to the following (note the last two lines):
exec "$JAVACMD" $JAVA_OPTS \
-classpath "$STARTER_CLASSPATH" \
-Dscript.name="$SCRIPT_PATH" \
-Dprogram.name="$PROGNAME" \
-Dgroovy.starter.conf="$GROOVY_CONF" \
-Dgroovy.home="$GROOVY_HOME" \
-Dtools.jar="$TOOLS_JAR" \
$STARTER_MAIN_CLASS \
--main $CLASS \
--conf "$GROOVY_CONF" \
--classpath "$CP" \
"$(cygpath -w $1)" \
"${#:2}"
... that way the script being called is altered to a windows path with backslashes as suggested above, and then not interpreted as a URL it seems. Nasty hack, but at least I was able to execute my script again :)
Not sure if anyone still interests in this. But shortly I commented the above answer, I found a solution for this.
Update the "startGroovy" script with the following two changes:
for dir in $ROOTDIRSRAW ; do
ROOTDIRS="$ROOTDIRS$SEP$dir"
SEP="|"
done
ROOTDIRS="/c$SEP$ROOTDIRS" ## <<<< ADD THIS LINE;assuming cygwin on c: drv
and also replace the --mixed with --windows:
CHECK=`echo "$arg"|egrep -c "$OURCYGPATTERN" -`
if [ $CHECK -ne 0 ] ; then
### change the --mixed to --windows here
patched=`cygpath --path --ignore --windows "$arg"`
else
patched="$arg"
fi
and it should work.
I got this error while (re)building, using cygwin make.exe version :3.81.
Error : *** target pattern contains no `%'.
This error is due to a presence of a ":". Therefore it no longer supports windows paths.
You need to download version 3.80 and replace the make.exe in the \bin directory.
Apparently it needs cygintl12.dll too.
rollback to make 3.80 (Geant4)
cd /usr/bin
mv make.exe make_381.exe
wget http://geant4.cern.ch/support/extras/cygwin/make.exe
chmod +x make.exe
install libintl2 from cygwin setup for the required cygintl-2.dll
I got the same error when trying to build a project on Linux or OSX, that was previously built on a Windows machine and had some .o.d files hanging around in the output folder.
Once I manually deleted the .o.d files the problem was resolved. Apparently the "Clean" command of my IDE (CodeLite in this case) wasn't deleting the .o.d files.
Most likely due to the presence of a colon following a drive letter. For example consider
build : $(NativeHeaders)/*
If
NativeHeaders=../../../cpp/generated
then all is well, but
NativeHeaders=C:/dev/folder/cpp/generated
results in the error that you get.
I was getting this error because I didn't have a Tab (\t) character at the beginning of my commands. I had expandtab in my vim set so it was replacing a tab character with 4 spaces. When I turned that off and changed spaces to a tab it was fixed
I had the target pattern contains no '%' error while building with the Android NDK using cygwin.
I found the following link helpful:
Errors Generated by Make
‘missing target pattern. Stop.’
‘multiple target patterns. Stop.’
‘target pattern contains no `%'. Stop.’
‘mixed implicit and static pattern rules. Stop.’
These are generated for malformed static pattern rules. The first means there’s no pattern in the target section of the rule; the second means there are multiple patterns in the target section; the third means the target doesn’t contain a pattern character (%); and the fourth means that all three parts of the static pattern rule contain pattern characters (%)–only the first two parts should. If you see these errors and you aren’t trying to create a static pattern rule, check the value of any variables in your target and prerequisite lists to be sure they do not contain colons. See Syntax of Static Pattern Rules.
And so, my solution included changing my system variables from Windows format to Unix format like so:
Instead of C:\Android\android-ndk-r10c, I used /cygdrive/c/Android/android-ndk-r10c for the NDK path.
Similarly, I changed the NDK project path to /cygdrive/c/Android/project/src/main/jni.
In my case I was using CMake under Cygwin when I got this error. It turned out the Windows version of CMake was executed. Subsequently, Windows paths were used in the make file. I installed Cygwin's version of CMake through the setup program and got it working.
I had this problem on Linux when the build directory contained a ":" caused by doing a mercurial checkout which created a directory named "server:port".
I had to change the following in my make file to be compatible with Make_381:
before:
ARDUINO_BASE_DIR = C:\programs/arduino
now:
ARDUINO_BASE_DIR = \\programs/arduino
Try this if you're running Eclipse C/C++ and referencing files from Cygwin under Windows, make sure c:/cygwin/bin or c:/cygwin64/bin comes after your preferred compiler tools in your Windows Path environment.
Example:
Path = ;C:\yagarto\bin;C:\yagarto-tools\bin;C:\cygwin64\bin;
After making the changes, exit Eclipse and restart for it to take effect (simply restarting Eclipse without exiting won't fix the problem.
In my project, obj folder was probably corrupted and I was getting this error. Manually deleted obj folder. Then ndk-build completed fine.