When I try to compile files with coqc -Q . LF, I get the error:
coqc: -Q: no such file or directory
coqc information:
The Coq Proof Assistant, version 8.4pl6 (December 2020)
compiled on Dec 02 2020 23:06:36 with OCaml 4.02.0
What's strange is that it worked previously for me. I formatted my disk to the same exact OS, installed the same exact opam, yet I'm getting an error where I didn't before.
Also using 8.4.6 for legacy reasons.
Version 8.4.6 of Coq does not support a -Q option, this can be confirmed by looking in the manual, where no such option is documented. I also checked in the source files: they can be downloaded from https://github.com/coq/coq/releases/tag/V8.4pl6. a systematic search of string -R shows that it does appear in file scripts/coqc.ml but no string -Q appears anywhere in the sources.
You did not tell us the whole story. You are not reproducing exactly the same attempt... You must have been using a more recent version until now.
Related
I installed ghcup and:
Stack 2.9.1
HLS 1.8.0
cabal 3.6.2
GHC 9.2.5
All of them are the recommended versions(I verified it using ghcup tui). Then I installed the Haskell extension in VSCode. Unfortunately, it doesn't work. I get syntax highlighting (from the Haskell Syntax Highlighting extension, which seems to be automatically installed alongside the Haskell extension) but there is no Intellisense, no code completion, no error detection and no interactive mode (-->>> evaluation). I experimented with different folders and haskell files. The filetype is correct, because every time I open a .hs file, the Haskell extension checks for updates. I even installed Codium, because I suspected a fault in VSCode, but it was the same there as well.
The hsl language server doesn't seem to be working in Neovim, either. I uninstalled ghcup (ghcup nuke) and reinstalled again. The result is exactly the same. I prepended the PATH and chose vanilla and non-vanilla Stack integration in either installations.
Am I doing something wrong?
OS: Linux Mint on Ubuntu 20.04.1, kernel 5.15.0-56.
After around 10 tries, I managed to fix the problem. It turned out I had three problems:
I had only 12 GB free on my Linux partition, but it seems more are needed. I realised it, when it turned out some haskell-language-server files were missing. I enlarged my Linux partition (something I should have done months ago). The new installation installed all files
The Haskell Language Server HLS was not added to the PATH. I solved it by putting this snippet in ~/.ghcup/config.yaml:
"haskell.serverEnvironment": {
"PATH": "${HOME}/.ghcup/bin:$PATH"
}
The server was now discovered by the Haskell VS Code extension but crashed 5 times and gave up on trying. Restarting it manually didn't help. I opened the logs: View->Output->Haskell and saw the error:
haskell-language-server-wrapper: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by haskell-language-server-wrapper)
It turns out, my Linux Mint distribution uses GLIBC_2.31, not 2.32. This is a very important library, which most applications on the system use. If you are a newbie, it is strongly advised that you DO NOT update it manually.
Instead, what I did, was install a version of the HLS, which used GLIBC_2.31. This problem occured in September and was "fixed" but apparently not very well. There are two options:
download the HLS deb10 version manually (didn't work for me):
ghcup install hls -u https://downloads.haskell.org/~hls/haskell-language-server-1.8.0.0/h
download using ghcup tui HLS version 1.7.0.0 (or whatever newest, which uses your glibc version) and a GHC, which supports that particular version of the HLS (in my case 9.0.2).
I think it's a good idea to preemptively reinstall the extension, in case it used the PATH to configure the HLS, so that its settings are restored to default. It takes up to 20 seconds to initialize the server, so be patient. You can see what's happening in the Output window and verify there are no more errors.
I hope this helps.
We have installed PDFTK server edition on Mac OS X 10.10 and Ubuntu 12 and Ubuntu 14.
When trying to do a dump_data_fields for any PDF it seems to throw a weird error before even getting to that operation..
$ pdftk SchoolPermissionSlip.pdf dump_data_fields
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: ___emutls_get_address
Referenced from: /opt/pdflabs/pdftk/bin/../lib/libgcj.11.dylib
Expected in: /usr/lib/libSystem.B.dylib
in /opt/pdflabs/pdftk/bin/../lib/libgcj.11.dylib
Trace/BPT trap: 5
It's the latest version. Any ideas?
pdftk --version
pdftk 2.02 a Handy Tool for Manipulating PDF Documents
Copyright (c) 2003-13 Steward and Lee, LLC - Please Visit: www.pdftk.com
This is free software; see the source code for copying conditions. There is
NO warranty, not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
We have seen reports of this error intermittently on Mac OS X only.
That ___emutls_get_address symbol is provided by pdftk's own libgcc_s.1.dylib. The default location for pdftk's libraries on OS X is /opt/pdflabs/pdftk/lib. The default location for the pdftk binary is /opt/pdflabs/pdftk/bin/pdftk. If you ever move this pdftk binary, it is important to move its libraries along with it so that the pdftk bin directory remains siblings with this lib directory. This helps ensure that the binary can find its libraries. Perhaps your pdftk binary has been moved without also moving these libraries?
In any case, we have a solution that has worked for others.
Reading the dyld man page, the DYLD_LIBRARY_PATH environment variable can be used to give precedence to pdftk's libraries. From the Terminal, run:
export DYLD_LIBRARY_PATH=/opt/pdflabs/pdftk/lib:$DYLD_LIBRARY_PATH
Then test pdftk:
pdftk input.pdf dump_data_fields output data.txt
This is a duplicate of PDFtk Server on OS X 10.11 but posting our response here too:
We raised this to Sid back in August and he still has not fixed it so I think its fair to say that its a good idea to look for alternatives. Because of this, we have taken the initiative to submit a few first tools that people can enjoy for free in the following repository:
https://github.com/flexpaper/OSX-PDF-Toolkit
It contains easy to use scripts for CAT and BURST. We intend to add more tools going forward. Feel free to contribute
These new tools are using the native OSX libraries and no third party dependencies are needed whatsoever. Yay!
I have an application that deals with timezones, so naturally I want to be able to view the list of timezones in Postgresql.
I tried to view all available timezones with the following command:
SELECT * FROM pg_timezone_names;
Which prints the following error:
ERROR: timezone directory stack overflow
I even tried limiting the results and received the same error:
SELECT * FROM pg_timezone_names LIMIT 10;
At first I thought it might just be my IDE of choice having issues, but I tried to run the same sql query on the command line and received the same error. I can't, for the life of me, find an answer to this issue. Any information would be helpful. Thanks!
EDIT: I'm using Postgresql 9.3 on Gentoo. Self compiled version of postgresql-server.
Note: I can query the pg_timezone_abbrevs table just fine, just not pg_timezone_names.
According to this Postgres FAQ:
...
On platforms that receive regular software updates including new tzdata files, it may be more convenient to rely on the system's copy of the tzdata files. This is possible as a compile-time option. Most Linux distributions choose this approach for their pre-built versions of PostgreSQL.
...
The compile-time option referred to is the --with-system-tzdata, which is described about half-way down this page.
My guess is that this flag is set by the Portage distribution you're using, and that the tzdata is either missing or corrupted on your system. On Gentoo, the tzdata is distributed in the timezone-data package, which you can find here.
Try:
# emerge timezone-data
Then see if that fixes the problem.
This is an answer to my own question.
The following is at least true on the Gentoo distro of linux, but I assume can be present on others.
What causes the error mentioned in my post is a symlink loop by /usr/share/zoneinfo/posix
To solve this error you just have to delete that symlink, as follows:
rm /usr/share/zoneinfo/posix
Pretty easy fix. Be aware that any update to zoneinfo will cause this symlink to be recreated and thus requiring you to remove it again. I haven't had any issues with this link being removed, but I can't say the same for others. If anyone has a reason for NOT deleting this symlink, just post a comment stating so.
Had the exact same issue on Ubuntu 14.04 LTS with PostgreSQL 9.3.3 however my recursive symlink was with /usr/share/zoneinfo/localtime. Fixed by running:
$ sudo unlink /usr/share/zoneinfo/localtime
I have installed dmd and ddt as instructed:
DMD64 D Compiler v2.066.0
Copyright (c) 1999-2014 by Digital Mars written by Walter Bright
Documentation: http://dlang.org/
but when I create a dub project in eclipse, I dot an error that says standard libray not found:
(source: p.im9.eu)
any ideas?
OS: Mac OSX 10.9
Eclipse: 4.4
DDT: 0.10.2
I've also posted a temporary workaround in the discussion group (link):
# cd /usr/share/dmd
# mkdir dummy
# mkdir dummy/bin
# touch dummy/bin/dmd
# launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
# killall Dock
Note that the DUB_COMPILERS_PATH variable shouldn't point to the binary itself, it acts like an additional PATH variable, i.e should contain bin dirs.
To make this survive a reboot, add the launchctl line to /etc/launchd.conf:
launchctl setenv DUB_COMPILERS_PATH /usr/share/dmd/dummy/bin
You might need to create it if it doesn't already exist.
This seems to be a reported bug of DDT:
https://github.com/bruno-medeiros/DDT/issues/75
Basically, it boils down to the directory structure of the installed dmd. As they are many distributions and many installers, each one with its own convention, DDT missed some.
They should be added and recognized shortly, in the pending release.
Please follow the reported issue on github/DDT page.
Yes, I know this thread is really old, and yes DDT seems to be no longer in development.
However, for those of us who are new to D, Eclipse and DDT, and relatively new to using Linux (I'm using Mint 19.3), I have the following solution which worked for me. No doubt this is common knowledge somewhere, but I had to scratch around quite a lot to discover this. (Of course, your dmd version number may be different.)
Note that dub is automatically installed along with dmd in:
$HOME/dlang/dmd-2.090.1/linux/bin64/dub
The command
source ~/dlang/dmd-2.090.1/activate
will modify the $PATH variable to allow access to the compiler.
NOTE that this only changes the path for the shell where the command is issued... and only for the current session!
If you want the path change to be permanent (who doesn't?), add the following to ~/.profile using a text editor, e.g. nano ~/.profile or xed ~/.profile , etc.:
# Add dlang dmd compiler path
if [ -d "$HOME/dlang/dmd-2.090.1/linux/bin64" ] ; then
PATH="$HOME/dlang/dmd-2.090.1/linux/bin64:$PATH"
fi
This corrects the Eclipse error:
"D Standard Library [Error: none found]"
in the Project tree, and also allows dub to be run from any directory, e.g. from a terminal.
HTH.
I'm having the strangest issue while trying to build and install muParser on my windows machine. As suggested by the installation guide, I just cd into the build folder, and run
make -f makefile.mingw
This should be all well and good standard procedure. However, I can't make sense of the output from the command:
if not exist obj\gcc_static_rel mkdir obj\gcc_static_rel
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
Now... at this point, I'm really confused. Because according to the title of the command prompt window, I'm still INSIDE the make command. So, I type "exit" at the "prompt"
g++ -c -o obj\gcc_static_rel\muParser_lib_muParser.o -DNDEBUG -O2 -D_WIN32 - I..\include -MTobj\gcc_static_rel\muParser_lib_muParser.o - MFobj\gcc_static_rel\muParser_lib_muParser.o.d -MD -MP ../src/muParser.cpp
Microsoft Windows [Version 6.1.7600]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Chase\Desktop\muparser_v2_0_0\muparser_v2_0_0\build>
The command appears to "step" through it's next function. I continue to type exit at the "prompt" and the command appears to continue stepping until it's done. However, after exiting completely, I can't see any results and it appears nothing's actually been done.
Also, this doesn't have anything to do with the command prompt. I even wrote a python script to cd into the directory and call make, and the output still displayed a windows-style command prompt - complete with the copyright Microsoft line etc., and waited for an input. I typed exit the same way until the process exited back to python.
Now, I might be going insane, but I'm really confused. Asking on the forums yielded no help, the only response is that "the windows build should be working."
Does anyone know what's going on???
I downloaded the muParser package and tried to build it. I got the same strange behaviour from make as you did. Then I realised I only had MSYS-make installed, not MinGW-make (the first one is intended for use in the MSYS shell, the second one for use in the Windows cmd shell).
Unfortunately, installing and using mingw32-make gave a different error, but googling that lead me to this page, where it was suggested to rename sh.exe in the MSYS directory. After doing that, running mingw32-make -f makefile.mingw succesfully built (the static version of) the library.
The other method you and shellter are using of running ./configure; make in the MSYS shell, also fails to build the example for me. It does build the dll version of the library in this case, instead of the static version; perhaps this is why the example fails to build.
(You might want to add a tag for 'make' or 'gmake', that should boost the number of eyes looking at your problem).
Looking at the makefile.mingw, I'm surprised to see statements like '-if not exist ..', that is .bat file syntax.
I ran ./configure ; make and it got past the error messages you mention, but I'm seeing a bunch of error messages like undefined reference to mu::ParserError: , so I'm probably missing libraries to make it work completely. I'll have to leave it at that, and hope that it helps you. Note that I didn't use make -f makefile.mingw. After using configure, make just picked up the newly created Makefile, and it worked (excepting the library problems ;-)
(When you say forums, did you mean the mingw forums? If not, try looking around here. The search functionality is pretty good.)
I hope this helps.