Here's how to simulate it.
$ cat t1.rkt
#lang racket/base
(require gregor)
(display "hello")
I'm running Racket 6.12. But the same happens to Racket 7.2.
$ racket t1.rkt
explode-path: contract violation
expected: (or/c path-for-some-system? path-string?)
given: #f
context...:
/usr/share/racket/collects/racket/path.rkt:116:0: do-explode-path
/usr/share/racket/collects/racket/path.rkt:126:0: find-relative-path7
/home/me/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:118:2: for-loop
/home/me/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:108:0: read-tzids
/home/me/.racket/6.12/pkgs/tzinfo/tzinfo/private/zoneinfo.rkt:71:0: make-zoneinfo-source
/usr/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18
/home/me/.racket/6.12/pkgs/tzinfo/tzinfo/main.rkt:63:0: system-tzid
/usr/share/racket/collects/racket/contract/private/arrow-val-first.rkt:388:18
/home/me/.racket/6.12/pkgs/gregor-lib/gregor/private/moment.rkt: [running body]
/home/me/.racket/6.12/pkgs/gregor-lib/gregor/private/generics.rkt: [traversing imports]
/home/me/.racket/6.12/pkgs/gregor-lib/gregor/private/clock.rkt: [traversing imports]
/home/me/.racket/6.12/pkgs/gregor-lib/gregor/main.rkt: [traversing imports]
/home/me/issue-gregor/t1.rkt: [traversing imports]
$ racket --version
Welcome to Racket v6.12.
How could I go back to an older version of gregor? I installed it this one with raco pkg install gregor and installed all its dependencies.
I'm the author of Gregor. (I don't normally post on Stack Overflow, or even use it much, but John Clements brought this to my attention.)
There's a bit of an unfortunate naming issue here, since tzdata appears to be the name of an Ubuntu package that provides the normal zoneinfo files, as well as being the name of a Racket package that also provides those files.
gregor depends on a package called tzinfo. tzinfo, in turn, conditionally depends on tzdata (the Racket one, not the Ubuntu one). Specifically, it only depends on tzdata on Windows systems. This is because I assumed that all Unix systems would have the zoneinfo files. (It never occurred to be that anyone would run a Unix without them these days.) But it is certainly the case that tzinfo (and thus gregor) will not work unless it can find zoneinfo files.
Maybe I should update the documentation with a conspicuous warning. I'd rather not make tzinfo unconditionally depend on tzdata (again, the Racket one), because most Unix systems will already have the necessary files, and it could be unduly confusing for gregor to use a version of them different from the one the system is using.
Related
I am working with the book Certified Programming with Dependent Types but each time I'm finding a different error. It seems to me that the error comes from a mismatch between the compilation process from Proof General and through the makefile of the sources of the book.
If I compile the sources with make and try to run for instance Subset.v in Proof-General I get:
Error: File /home/usuario/Desktop/Coq/cpdt/src/CpdtTactics.vo has
bad magic number 81100 (expected 8600). It is corrupted or was
compiled with another version of Coq.
If I clean the makefile compiled files with make clean and try to proceed with the option Coq -> Auto Compilation -> Compile before require then it is the line:
Require Extraction.
that fails. Originally it failed with the error:
Error: Unable to locate library Extraction.
but with the above option enables it gives something like:
echo "Require Extraction." > /tmp/ProofGeneral-coqQPJTf0.v coqdep -Q /home/usuario/Desktop/Coq/cpdt/src/ -R /home/usuario/Desktop/Coq/cpdt/src Cpdt /tmp/ProofGeneral-coqQPJTf0.v
* Warning: in file /tmp/ProofGeneral-coqQPJTf0.v, library Extraction is required and has not been found in the loadpath!
* Warning: in file /tmp/ProofGeneral-coqQPJTf0.v, library Extraction is required and has not been found in the loadpath!
/tmp/ProofGeneral-coqQPJTf0.vo /tmp/ProofGeneral-coqQPJTf0.glob /tmp/ProofGeneral-coqQPJTf0.v.beautified: /tmp/ProofGeneral-coqQPJTf0.v
/tmp/ProofGeneral-coqQPJTf0.vio: /tmp/ProofGeneral-coqQPJTf0.v
How can I solve this?
Side-questions: which OS are you using? do you rely on opam?
Regarding the first error you get, it certainly comes from the following fact:
outside proofgeneral, the coqc binary corresponds to Coq 8.11, while in ProofGeneral, the coqtop binary correspond to Coq 8.6. Maybe because the PATH variable is not the same in the two contexts.
To figure out which binary is found, you can do in the terminal which coqtop, and within Emacs, M-! which coqtop RET and you should thus get different paths.
Sometimes, opening emacs directly from the terminal (emacs &) can help for this kind of issue.
But if you want to change the coqtop binary that is used in ProofGeneral, you can set the coq-prog-name option, by using one of the following steps:
Interactively, type C-u C-c C-x (to kill Coq), M-: (setq coq-prog-name "…/coqtop"), and C-c C-n
Or create a .dir-locals.el file (Emacs' standard conf-file) in the project root containing:
((coq-mode . ((coq-prog-name . "…/coqtop"))))
and close/reopen the ….v file at stake (or just do M-x normal-mode RET or C-x C-v RET in the already-opened ….v buffer)
Regarding the second error you get, I'm a bit puzzled that Require Extraction triggers this error, as this library does exist in Coq 8.6 and 8.11.
At first sight, I'd suggest to re-test the auto-compilation with Coq 8.11, asserting From Coq Require Extraction. (instead of just Require Extraction.)
But maybe there is a bug in PG's Auto Compilation -> Compile before require feature; anyway feel free to open a related issue in the PG tracker if need be, bug reports and feature requests are very welcome: https://github.com/ProofGeneral/PG/issues
I'm a beginner in lisp and I'm unable to find out how to correctly use defpackage to load qtools (on arch linux).
For simplicity if I run this example project in sbcl with loaded quicklisp
https://github.com/Shinmera/qtools/tree/master/examples/helloworld
this error appears
While evaluating the form starting at line 8, column 0
of #P"/home/william/code/upol/lisp/helloworld/helloworld.lisp":
debugger invoked on a PACKAGE-DOES-NOT-EXIST in thread
#<THREAD "main thread" RUNNING {1000508083}>:
The name "CL+QT" does not designate any package.
Why "cl+qt" is not provided by any of installed packages with quickload?
Here is a list of installed packages
$ ls ~/.quicklisp/dists/quicklisp/software
Thanks for help
My resources:
https://github.com/Shinmera/qtools
https://lispcookbook.github.io/cl-cookbook/getting-started.html
Let's look at the example. The order of actions is:
compile the .asd file (for example, with C-c C-k). This creates the qtools-helloworld system.
load "qtools-helloworld" and its dependencies with Quicklisp: (ql:quickload :qtools-helloworld).
compile helloworld.lisp (again, with C-c C-k), and call its functions.
Also, look at Qtools readme: https://github.com/Shinmera/qtools#qtools-1 It says to install these 3 libraries:
(ql:quickload '(qtools qtcore qtgui))
The cl+qt package is provided by one of these systems.
update: the steps required to run the helloworld from the command line are:
load the asd definition: rlwrap sbcl --load qtools-helloworld.asd. (rlwrap is just a readline utility)
you are dropped into the Lisp REPL. Now we install the dependencies with Quicklisp, that you must have installed first. You type this into the Lisp REPL: (ql:quickload :qtools-helloworld). That is the name defined in the asd.
now you can compile the .lisp file: (load "helloworld.lisp):
* (ql:quickload :qtools-helloworld)
To load "qtools-helloworld":
Load 1 ASDF system:
qtools-helloworld
; Loading "qtools-helloworld"
[package qtools-helloworld]....
(:QTOOLS-HELLOWORLD)
it didn't show a GUI. We'll call the main function:
(qtools-helloworld::main)
and you should see the example. If you make changes to the lisp file you can load it again. This use of the REPL in the terminal works but is not as interactive as Lisp can be (far from it). You want your editor to be connected to the REPL and send changes automatically, with a keystroke.
Check out the Cookbook, editors section, Atom support is very good with SLIMA.
ps: I find Qtools a little bit difficult, passed running the provided examples. It is not as easily discoverable as other GUIs (like Ltk or IUP). Hope you'll prove me wrong though.
pps: also https://lispcookbook.github.io/cl-cookbook/gui.html#qt4
You need to install the qtools system.
A system is a way to organize software libraries
A package is a namespace
The two are theoretically unrelated. But often, when you load a system X, it defines a package named X.
In some cases (like qtools) there are many packages for one system, for example because the system wants to define different levels of API.
Another way to define multiple packages when loading one system comes from the fact that ASDF version 3.1 supports an extension copied from other build systems named package-inferred-systems, where each source file is implicitly mapped to one system and one package.
Here is a snippet of what Quicklisp shows when installing qtools:
* (ql:quickload :qtools)
To load "qtools":
Load 14 ASDF systems:
array-utils asdf bordeaux-threads cffi cl-ppcre
closer-mop dissect documentation-utils form-fiddle
named-readtables qt+libs trivial-features
trivial-garbage trivial-indent
... ... ...
To load "qtools":
Load 1 ASDF system:
qtools
; Loading "qtools"
[package uiop/package]............................
..................................................
[package cffi-sys]................................
[package cffi]....................................
..................................................
[package cffi-features]...........................
[package qt-libs].................................
[package qt]......................................
..................................................
[package deploy]..................................
[package dissect].................................
[package simple-tasks]............................
[package trivial-main-thread].....................
[package qtools]..................................
[package cl+qt]...................................
.............................
(:QTOOLS)
Quicklisp is able to intercept and print new packages when they are defined. Here above we can see that there are multiple packages defined while loading quicklisp, either (1) packages defined by the dependencies of qtools, or (2) packages defined by qtools itself. Here both qtools and cl+qt are packages defined by the qtools system.
Packages are not declared in systems, so you need to rely on documentation to know what packages a system defines.
I have installed frama-c (18.0) and coqide (8.9) through opam (plus other needed dependencies of course, but that may not be the matter here). Well the point is I simply installed it through opam, not done anything else strange (and I didn't see any particular instruction that I should do otherwise).
Frama-c works as expected when I use Alt-ergo with WP, but if I try to use coq or coqide instead of Alt-ergo, then I get the following error for each goal that Qed does not manage to prove immediately:
[wp] 13 goals scheduled
[wp] [Coq] 'Qed.v' compilation failed.
------------------------------------------------------------
--- Coqc (stderr) :
------------------------------------------------------------
File "/tmp/wp7fe5dc.dir/coqwp/Qed.v", line 27, characters 8-17:
Error:
Cannot find a physical path bound to logical path matching suffix bool.
------------------------------------------------------------
[wp] [Coq] Goal typed_nondet_loop_inv_preserved : Failed
Compilation of 'Qed.v' failed.
As a note, before displaying the error, it manages to compile some other .v files. I have tried to open manually the files in coqide, and I get the same result. For the record, here are the lines coq complains about:
Require bool.Bool.
Require int.Int.
Require int.Abs.
Require int.ComputerDivision.
Require real.Real.
Require real.RealInfix.
Require real.FromInt.
I have also tried to downgrade coq a bit, but not lower than 8.7 (as otherwise opam complains of incompatible base installation package and I don't really want to screw up my installation), and got the same result.
If someone would have an idea of what is causing that and how I can get to set it up that correctly, that'd be nice. Even if for what I'm doing with it for now, Alt-ergo is sufficient, I would have liked to play a bit with coq to see how it can be used.
Regards,
--
Vincent Penelle.
First, indeed you need coq < 8.8 (e.g. 8.7.2) if you want to use it with Frama-C/WP, as newer versions are not supported for the moment.
Second, the order in which you have installed your packages is relevant. In particular, if the appropriate version of coq has been installed after frama-c, WP did not compile and install its coq libraries, which are the ones that are missing here. Thus, you may want to do opam reinstall frama-c to compile the package against a compatible coq version.
I tried to install Lisplab with asdf and quicklisp but they all turned out to fail.
I use sbcl and slime.
Anyone can help me with installation. And I just want to manipulate matrix within lisp:)
Thanks, lisper!
The first thing to do about installing a lisp library using quicklisp, is see if it is available via quicklisp:
(Note for this answer I'm using the configuration roswell slime sbcl on antergos)
CL-USER> (ql:system-apropos "lisplab")
; No value
In this case the project it is not included, you can update your quicklisp, but in this case it is not necessary. this project is not in quicklisp and maybe will not be in the future. then you can choose to continue installing it or search for an atertnative for this thake a look a quickdocs this is a search about math
Let's try to install this quicklisp says this:
Can I load a local project that isn't part of Quicklisp? Yes. The
easiest way is to put the project's directory in Quicklisp's
local-projects directory. For example:
$ cd ~/quicklisp/local-projects/
$ git clone git://github.com/xach/format-time.git
The project will then be loadable via (ql:quickload "format-time")
Also, any system file that can be found via ASDF's source registry
system can be loaded with ql:quickload.
For example, if you have a system file my-project.asd in
/projects/my-project/, you can do something like this:
(push #p"/projects/my-project/" asdf:*central-registry*)
(ql:quickload "my-project")
If my-project depends on systems that are available via Quicklisp that
are not already installed, they will be automatically installed.
so for this project I will download the tarball and extract or download the repository in the local-projects folder, like it is suggested in a comment. In my case is ./roswell/local-projects but in your case should be cd ~/quicklisp/local-projects/
After that you "can" load with quicklisp, but I believe that since this library is not maintained, it will have errors,
If you want to manipulate matrix with lisp I recommend you to use lisp-matrix be sure to have installed lapack in your computer and read the documentaaion carefully especcilay the code at the end of the readme and also the tests.
CL-USER> (ql:quickload :lisp-matrix)
To load "lisp-matrix":
Load 1 ASDF system:
lisp-matrix
; Loading "lisp-matrix"
(:LISP-MATRIX)
CL-USER> (in-package :lisp-matrix-user)
#<PACKAGE "LISP-MATRIX-USER">
LISP-MATRIX-USER> (M* (ones 2 2 :implementation :lisp-array)
(ones 2 2 :implementation :lisp-array))
#<LA-SIMPLE-MATRIX-DOUBLE 2 x 2
2.0d0 2.0d0
2.0d0 2.0d0>
(be aware that foreign-array doesn't work for integers)
I have tried this example ECL repository asdf example , it works fine but it doesn't have any asdf dependencies. If i add
:depends-on (#:inferior-shell)
to example.asd then running the compiled standalone executable gives this error:
Condition of type: SIMPLE-PACKAGE-ERROR
There exists no package with name "ASDF/DRIVER"
No restarts available.
What causes this error, and what is the idiomatic way of dealing with asdf dependencies on ECL ?
EDIT: this problem is fixed for ECL newer than 16.1.3 (fixed in develop branch), so no `require' trick should be needed in the upcoming release.
In general path you have taken is correct.
Make sure, that you have required the ASDF:
(require 'asdf)
(find-package "ASDF/DRIVER")
Then "ASDF/DRIVER" package is defined. On the other hand inferior-shell requires a few other libraries (alexandria for instance), so you have to put the path to them in the ASDF central registry or use the Quicklisp bundles.
More detailed info about building with ECL is available in its Documentation.
// EDIT
After investigation it appears that ASDF has to be manually required at the program start. It is probably a bug. As a workaround add
:prologue-code '(require 'asdf)
to the (asdf:make-build …) for standalone executable. Everything works fine then.