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.
Related
I have broken out the MEMORY{} command of my linker script into a separate file memmap.ld in order to share it between projects (bootloader and target firmware).
The file is currently located in the same directory as the main linker script and I include it using the line
INCLUDE memmap.ld
from my main .ld script however this does not work and I get the error
ld.exe: cannot open linker script file memmap.ld: No such file or directory
when building. The section of the ld manual dealing with the INCLUDE filename command reads
Include the linker script filename at this point. The file will be searched for in
the current directory, and in any directory specified with the ‘-L’ option. You
can nest calls to INCLUDE up to 10 levels deep.
You can place INCLUDE directives at the top level, in MEMORY or SECTIONS commands, or in output section descriptions.
What is up with this? Is the current directory taken from the current script, executable, some other external parameter?
Am using the ST build of the GNU Linker distributed with the 64 bit Windows STM32CubeIDE if it makes any difference.
It appears the matching of .ld scripts within the current directory when using INCLUDE only compares with script names introduced via either '-L searchdir' or '-T scriptfile'.
[i.e. the LD program doesn't do a file system search but instead searches the list of scripts provided during invocation (or at least behaves as such) ].
My case in point when using STM32CubeIDE only provides the option to provide a single loader script via the -T option within project system (while Eclipse Embedded CDT which ST bases it's tools on allows multiple files to be passed by -T) required the addition of the folder containing both my scripts using the -L option (from the Libraries subsection of the Linker project properties).
Once the script I was referencing inside LD was being passed through the build system by including the directory location in the command line the 'current directory' did resolve to that of the script doing the inclusion.
I am using Conan package manager on Windows to create a package. The conan command to create the package copies files to a folder within %USERPROFILE%\.conan (or C:\Users\xxxxxxx\.conan). Then from this location it builds a Visual Studio project and ultimately calls doxygen.exe to create a .chm help file in a post-build command. The doxygen command fails with:
error : failed to run html help compiler on index.hhp
Further investigation reveals the hhc.exe command executed by doxygen is failing with:
C:\Users\xxxxxxx\.conan\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation>"C:/Program Files (x86)/HTML Help Workshop/hhc.exe" html\index.hhp
HHC5010: Error: Cannot open "C:\Users\xxxxxxx\data\Module\1.0.0\user\channel\build\524dc97e4a3dd1f774ea3897f9e4faf26c5457d2\Documentation\html\Module.chm". Compilation stopped.
Close inspection reveals that in the error message, the ".conan" folder is missing. Sure enough, I confirmed that hhc.exe fails when the index.hpp resides in a folder that has a parent folder that starts with a ".".
Attempts to resolve this:
changing the Doxyfile setting OUTPUT_DIRECTORY to "$(TMP)/DoxygenModule" resolves the error, but creates the .chm file in another location, which I do not prefer.
navigating to the 8DOT3 name of the ".conan" folder, which is "CONAN~1", to run the hhc.exe command, succeeds, but unfortunately I have no way of getting conan to use this 8DOT3 path for creating the package. E.g. C:\Users\xxxxxxx\CONAN~1\...
I can live with the using the %TMP% folder but would prefer generating the .chm in the current folder. Anyone have any ideas?
HTML Help Workshop v1.31 is installed on my machine at C:\Program Files (x86)\HTML Help Workshop, probably from a Visual Studio installation (not sure). I attempted using a version downloaded from Microsoft website (v1.30) as well, which made no difference.
Other info: Conan version 1.18.0, Doxygen version 1.8.14, Windows 10 Version 1809
Unfortunately not a solution, but this is a known limitation in the hhc.exe, see: https://social.msdn.microsoft.com/Forums/en-US/0681145c-223b-498c-b7bf-be83209cbf4e/issue-with-html-workshop-in-a-windows-container?forum=visualstudiogeneral
HTML Help 1.x command line compiler hhc.exe cannot compile CHM file to folder whose full path contains folder name starting with dot. If you have that problem, you probably specified output path with folder starting with dot, e.g. "d:\My files.NET\documentation". You can use dots in folder names but not at the beginning.
Edit 2019-11-15:
I've just pushed a proposed patch to github (pull request 7402, https://github.com/doxygen/doxygen/pull/7402).
This proposed patch changes inside doxygen from the current directory to the short named current directory, but just for the HTML Help compilation.
Edit 2019-11-16:
Code has been integrated in the master version on github.
This is not an answer either. Actually, you found the answer and workaround[s] yourself.
Use OUTPUT_DIRECTORY to specify a directory containing no folder names beginning with periods.
The error you described is a known issue of the MS HTML Help compiler. More general, the HTML Help compiler does not like some folder and file names. Try and stick with these characters _, a..z, A..Z, 0..9. Do not use these signs in particular ., -, # .
Please note that the proprietary CHM file format is about 20 years old (Windows 95, ...). HTML Help is in maintenance mode, which means no new features and bug fixes are expected for either the runtime or the compiler. All mainstream development on HH has stopped.
There is no way to avoid this error if a directory name above begins with a period. Not even if only the necessary files are written by Doxygen and compiling of the index.hhp is done by a third-party tool like FAR HTML using your path that contains .conan. This is because all applications are using the faulty HHA.dll.
The above applies of course to the entire workflow you have described. Maybe you can interrupt it.
Doxygen can be configured not to call the HTMLHelp compiler. Just uncheck the GENERATE_HTMLHELP option (DoxyWizard: Experts > Topics > HTML). You have all files generated by Doxygen in your preferred output directory - but of course without the CHM file. This can be imported later e.g. by HelpNDoc and compiled as a CHM file in another location.
If you can interrupt the workflow and can also make changes to Doxygen's settings, then a preference setting of OUTPUT_DIRECTORY to e.g. C:/CacheMenu/CONAN~1/DOXYGE~1 also works as expected (here used as test case).
No matter what you do, your workaround and copy and paste from another directory outside is a quick solution at this stage. Please note the EDIT in #albert's answer.
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. *)
Everytime i dot source a file in PowerShell it opens a copy of the file in notepad.
Exe:
.\MyScript.ps1
The script runs fine - its just really annoying having these pop up all the time. Is there a way to suppress this?
I'm on windows 7 x64 and using the latest version of PowerShell.
Ex2: This is still launching notepad.
cls
Set-Location "\\PSCWEBP00129\uploadedFiles\psDashboard\"
. .\assets\DCMPull\Powershell\SqlServerTransfer.psm1
. .\assets\DCMPull\Powershell\RunLogging.psm1
You cannot dot source PowerShell files with the .psm1 file extension. One option is to rename them to .ps1.
Alternatively (and, in my opinion the better approach), you can load the PowerShell modules using Import-Module <module.psm1>. Just note that the behavior of Import-Module is different from dot sourcing it. Dot sourcing runs the script in the current scope and also persists all variables, functions, etc.in the current scope. Import-Module does not do that.
Although not very common, you can also export variables from modules with Export-ModuleMember.
Adding to Raziel's answer, there's a lot of thought that went into only being able to dot source files with .ps1 extension, and otherwise why it tries to run it as a system executable. Here's a snippet from PeterWhittaker on GitHub:
. ./afile would only execute something if there's either an
extension-less but executable aFile in the current dir, or a
(not-required-to-be-executable) afile.ps1 file, with the former taking
precedence if both are present; if the file exists, but is neither
executable nor has extension .ps1, it is opened as if it were a
document.
. <filename> with <filename> being a mere name (no path component) by
(security-minded) design only ever looks for a file of that name in
the directories listed in $env:PATH (see below), not in the current
directory.
I encountered exactly the same situation : If the point source imports the .psm1 file, the file will be opened directly instead of importing the code in the file.
Because the function of point source import is only valid in the file with suffix of.ps1, if the suffix does not meet the requirements, it will not be regarded as path, but as a code , so it is like running the corresponding string directly, and the effect is naturally to open the file.
So,this phenomenon is not aimed at .PSM1,if you change the extension to TXT, it will have the same effect. It will have the same effect for any file whose suffix is not .PS1.
You can bypass this problem by creating symbolic links or hard links!
In PowerShell 7, it's easy to create links using New-Item.
I've been working on expanding my vim-foo lately and I've run across a couple of plugins (autotag.vim for example) that require them to be "sourced" in my .vimrc file. What exactly does this mean and how do I do it?
Sourcing a file is 'executing' it. Essentially, each line of the file is considered a command. Sourcing it is the same as typing each command in order. You source with the command :source (usually shortened to :so).
So if you source myStuff.vim
:so myStuff.vim
and if myStuff.vim contained these lines
set xx iI just intersted this<C-]>
set yy bbbb4dw
It's the same as if you typed those commands into Vim
:set xx iI just intersted this<C-]>
:set yy bbbb4dw
The only file sourced by default is the .vimrc(_vimrc on windows) so that's a place you can keep all the commands you use to set up Vim every time.
Where it gets interesting is the fact that since a sourced file is just a series of commands, and sourcing is a command, you can source files from your source files. So plugins you use every time could be sourced when you start up Vim by adding a line to your .vimrc like this
so myPlugin.vim
Files in your .vim/plugin directory are sourced (loaded) automatically.
There is always the :source file command. I usually write .vimrc that contains custom commands and what not for the console application and then a .gvimrc that contains additional goodies that are appropriate for a windowed version. My .gvimrc starts with source $HOME/.vimrc to pick up everything from the console version before adding in new stuff.
There are normally two vimrc files, one is _vimrc and the other _gvimrc (in the first one are the things for vim, and in the second for gvim - graphical things) - although most people I know just put everything in _vimrc.
A good practice is to keep all your extra files (plugins, colorschemes, snippets ...) in a separate (your own) vimfiles directory (which you can take with you).
If you do
:help vimfiles
vim will tell your vimfiles directory should be located. It depends somewhat on the platform (win, unix). On windows the usual is in your user folder (documents and settings, then user ...).
In vimfiles directory there are a couple of subdirectories. Amongst them is the "plugin" subdirectory. Plugins put in that dir will be loaded automatically (also plugins put in subdirectories of "plugin").
If you do not wish to load it automatically, just put it in your "vimfiles", or some other directory, and
:so plugin_name.vim (with the appropriate path)
(you can use the $vim, $vimfiles, and $home as shortcuts when defining path to plugin)