I want to use the sqlite3 interface of clsql. I already install clsql using quicklisp. But when I try to run:
(clsql:with-database (db '("database.db")
:database-type :sqlite3)
nil)
I get
OPERATION-ERROR while invoking #<COMPILE-OP > on
#<CLSQL-UFFI-SOURCE-FILE "clsql-uffi" "uffi" "clsql_uffi">
[Condition of type ASDF/BACKWARD-INTERFACE:OPERATION-ERROR]
It is the same if I just try to quicklisp clsql-uffi.
cl-sql,cl-sql-uffi,cl-sql-sqlite3 and libsqlite3-dev are installed. I am using Ubuntu,Linux.
Edit: Separated the problem topics more clearly.
Installing CLSQL is not always straightforward.
CLSQL builds foreign libraries for its database interfaces, so make sure you have build-essentials installed as well. To check that the foreign libraries compile successfully (and if not, to check the error message), I recommend running make on a terminal in the respective directories.
There's a bug in clsql makefiles that affect certain systems, most notably AWS instances - check if that applies on your system. Fix the makefiles in the quicklisp's clsql directories as necessary.
On earlier Ubuntu versions, I successfully used the distribution's of cl-sql package. On 14.04+, however, they do not usually work too well - so installing clsql from quicklisp is probably a better idea.
Related
my first posting on setting up Yocto development environment
on my Ubuntu system (Ubuntu 18.04.3 LTS/bionic), based on the information enclosed in the document from
this web link (https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html).
All is well until... ~/poky/build$ bitbake core-image-sato
which results in this error:
File "/usr/local/lib/python3.5/sqlite3/dbapi2.py", line 27, in <module>
from _sqlite3 import *
ImportError: No module named '_sqlite3'
Below is my effort to proceed past this error, which didn't resolve the
error above. Please be generous and provide some guidance. I searched for
relevant posting locations; any advice on a better place is appreciated.
Thank you.
------------------------------------------------
A web search on this error () results in:
How to Use SQLite in Ubuntu | Chron.com
with
~/poky/build$ sudo apt-get install sqlite3 libsqlite3-dev
which tells me this:
Reading package lists... Done
Building dependency tree
Reading state information... Done
libsqlite3-dev is already the newest version (3.22.0-1ubuntu0.1).
sqlite3 is already the newest version (3.22.0-1ubuntu0.1).
The following packages were automatically installed and are no longer
required:
linux-headers-5.0.0-23 linux-headers-5.0.0-23-generic linux-image-5.0.0-23-generic linux-modules-5.0.0-23-generic
linux-modules-extra-5.0.0-23-generic
Use 'sudo apt autoremove' to remove them.
0 upgraded, 0 newly installed, 0 to remove and 12 not upgraded.
So, evidently sqlite3 exists on my system. Here are the SO references that I checked:
[ImportError: No module named '_sqlite3' in python3.3][1]
[importerror no module named '_sqlite3' python3.4][2]
[ImportError: No module named _sqlite3 (even after doing eveything)][3]
[ImportError: No module named _sqlite3][4]
[1]: https://stackoverflow.com/questions/20126475/importerror-no-module-named-sqlite3-in-python3-3
[2]: https://stackoverflow.com/questions/24052137/importerror-no-module-named-sqlite3-python3-4
[3]: https://stackoverflow.com/questions/35889383/importerror-no-module-named-sqlite3-even-after-doing-eveything
[4]: https://stackoverflow.com/questions/2665337/importerror-no-module-named-sqlite3
I have just kicked off a build verifying the Brief-Quickstart steps verbatim on an otherwise fresh Ubuntu 18.04 install. There is not even SQLite installed at all, yet the build proceeds nicely. So the chances are pretty high the python installation in your development host is busted in some way or the other. Yet, there might be reasons for it:
you maybe selected python 3.5 explicitly because some other thing you did requires it
you maybe selected python 3.5 implicitly because you forwarded from on old installation, installed something that depended on it, or similar.
In any case, I'd guess that now tinkering with the link might break things somewhere else on your machine, which should be avoided IMHO.
So what are your options now? My advice would be to start building in a container, in the simplest for that requires no more than installing docker and kicking off docker run -it ubuntu:bionic /bin/bash - at least to verify things are generally working.
In the longer term you might want to make a specialized container for this with one or two additions:
1) have all the needed packages set up already
2) using a standard user instead of root.
This is the way I do things personally. An alternative would be to use the prepared things by CROPS as it is a known good solution, and it significantly reduces problems originating from host system pecularities.
In the R FAQ section 4.6 (Package TclTk does not work) I found the following sentence:
... although they [missing Tcl/tk packages] may be downloaded via the Teacup facility
What is "teacup"? How can I install and use it?
I am using RStudio running on Ubuntu Linux and Windows 7.
Teacup is a program that ships as part of ActiveTcl, a commercial zero-cost distribution of Tcl (and Tk and many other packages) for various platforms. It does package management, looking after the key part that is download, installation and upgrading of packages from a remote repository. It is not open source, though Tcl itself is (as are the majority of packages that aren't single-company-specific).
If you've got it installed, you use these commands from a shell:
teacup update-self
teacup update
Depending on where your Tcl installation is, you might need to elevate privileges to make these command calls work. How you do this is platform-dependent; on Unix it's usually simplest to use sudo for each of the commands, whereas on Windows it is probably easier to create an elevated command shell and run inside that.
Depending on your site, you might need to configure a web proxy with teacup proxy. Try without first.
If you're using a non-ActiveTcl installation but you have an ActiveTcl installation present, you can still use teacup. You just need to use teacup link to connect that Tcl installation to the teacup local repository. This is slightly more complex because you can have multiple repositories on the one system (though I've never needed that).
First, you find where the repository is:
teacup default
Then you need to link the shell to the repository:
teacup link make $PATH_FROM_TEACUP_DEFAULT $LOCATION_OF_TCLSH_TO_LINK
Making this work with R Studio will be a matter of determining which Tcl installation it is using. If it's already an ActiveTcl, you just need the first part of this answer. Otherwise, you need the second part as well. Also note that pretty much requires that you be using either Tcl 8.5 or 8.6; there are no guarantees for older, unsupported versions.
I am building a debian package using dpkg.
The package has a dependency on libvirt which is not desired.
The rules file does not specify this dependency, but it is added by dpkg, I suppose due to some calls to libvirt-dev at build time.
However my package works fine without libvirt. As such, libvirt is a "Recommended" package but not "Required". How do I override this dependency and make sure it is not present in my final deb file ?
Hard to know without seeing your actual package, but I'd guess that you have a binary or shared library which is linked against libvirt. That would cause dh_shlibdeps to include libvirt in the ${shlibs:Depends} substvar.
If that's your problem, then the right fix depends on what's getting linked to libvirt. It should be straightforward to determine; just run ldd on each binary or shared library object in your package, and grep for "libvirt".
If the thing linked against libvirt is only incidental to the package, and isn't part of the main functionality, then using Recommends: would indeed be the right thing. To make dh_shlibdeps exclude that object from its dependency scanning, give it a -X option. Example target for debian/rules, assuming debhelper7-style packaging:
override_dh_shlibdeps:
dh_shlibdeps -Xname_of_your_object_to_exclude
If the thing(s) linked to libvirt actually are an important part of the package functionality, then the generated libvirt dependency is appropriate. If you still don't want it, you'll need to work out how to avoid linking against libvirt during your build.
I am trying to compile Network.HTTP (http://hackage.haskell.org/package/network) on win32/cygwin. However, it does fail with following message:
Setup.hs: Missing dependency on a foreign library:
* Missing (or bad) header file: HsNet.h
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
If the header file does exist, it may contain errors that are caught by the C
compiler at the preprocessing stage. In this case you can re-run configure
with the verbosity flag -v3 to see the error messages.
Unfortuntely it does not give more clues. The HsNet.h includes sys/uio.h which, actually should not be included, and should be configurered correctly.
Don't use cygwin, instead follow Johan Tibells way
Installing MSYS
Install the latest Haskell Platform. Use the default settings.
Download version 1.0.11 of MSYS. You'll need the following files:
MSYS-1.0.11.exe
msysDTK-1.0.1.exe
msysCORE-1.0.11-bin.tar.gz
The files are all hosted on haskell.org as they're quite hard to find in the official MinGW/MSYS repo.
Run MSYS-1.0.11.exe followed by msysDTK-1.0.1.exe. The former asks you if you want to run a normalization step. You can skip that.
Unpack msysCORE-1.0.11-bin.tar.gz into C:\msys\1.0. Note that you can't do that using an MSYS shell, because you can't overwrite the files in use, so make a copy of C:\msys\1.0, unpack it there, and then rename the copy back to C:\msys\1.0.
Add C:\Program Files\Haskell Platform\VERSION\mingw\bin to your PATH. This is neccesary if you ever want to build packages that use a configure script, like network, as configure scripts need access to a C compiler.
These steps are what Tibell uses to compile the Network package for win and I have used this myself successfully several times on most of the haskell platform releases.
It is possible to build network on win32/cygwin. And the above steps, though useful (by Jonke) may not be necessary.
While doing the configuration step, specify
runghc Setup.hs configure --configure-option="--build=mingw32"
So that the library is configured for mingw32, else you will get link or "undefined references" if you try to link or use network library.
This combined with #Yogesh Sajanikar's answer made it work for me (on win64/cygwin):
Make sure the gcc on your path is NOT the Mingw/Cygwin one, but the
C:\ghc\ghc-6.12.1\mingw\bin\gcc.exe
(Run
export PATH="/cygdrive/.../ghc-7.8.2/mingw/bin:$PATH"
before running cabal install network in the Cygwin shell)
I'm trying to install cffi package into sbcl.
First, I tried clbuild that is recommended on the cffi installation page.
When I tried to run :
clbuild quickload cffi
I was given an error saying :
The function ASDF::SOURCE-REGISTRY is undefined.
I then tried asdf-install, it end up complaining about
Component "cffi-examples" not found
Any help on this would be appreciated.
UPDATE
For asdf-install, I'm running sbcl with slime. It seems that whenever it complains about a component that is missing, that component is actually installed. I just have to abort the debugger and restart Emacs, start slime, and do that install again, and it will finish successfully. If I don't run it with slime, just running it inside sbcl prompt in terminal, it will keep complaining about the component missing nonstop.
So to get cffi installed with asdf-install, I had to restart Emacs for about 4-5 times.
I'm not sure if there is configuration issue with sbcl?
I suppose I should ask this question in different thread.
It's pretty easy with Quicklisp. To install Quicklisp:
Download http://beta.quicklisp.org/quicklisp.lisp
sbcl --load quicklisp.lisp
(quicklisp-quickstart:install)
(ql:add-to-init-file)
Then you can install and load CFFI like so:
(ql:quickload "cffi")
I wrote a bit about how I manage small projects and their required libraries at Making a small Lisp project with quickproject and Quicklisp.
Here are the exact steps for manual installation under Windows 7:
First, download and install SBCL from:
http://www.sbcl.org/platform-table.html
Then download and untar (tar xzf ...) babel, alexandria, trivial-features, and cffi.
Then, start SBCL, load ASDF, and add the paths to these systems to asdf:*central-registry*:
C:\Program Files\Steel Bank Common Lisp\1.0.49>sbcl.exe --core sbcl.core
This is SBCL 1.0.49, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.
SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses. See the CREDITS and COPYING files in the
distribution for more information.
This is experimental prerelease support for the Windows platform: use
at your own risk. "Your Kitten of Death awaits!"
* (load "asdf/asdf")
T
* (push "C:/Users/dhl/build/asdf/babel_0.3.0/" asdf:*central-registry*)
("C:/Users/dhl/build/asdf/babel_0.3.0/")
* (push "C:/Users/dhl/build/asdf/alexandria/" asdf:*central-registry*)
("C:/Users/dhl/build/asdf/alexandria/" "C:/Users/dhl/build/asdf/babel_0.3.0/")
* (push "C:/Users/dhl/build/asdf/trivial-features_0.6/" asdf:*central-registry*)
("C:/Users/dhl/build/asdf/trivial-features_0.6/"
"C:/Users/dhl/build/asdf/alexandria/" "C:/Users/dhl/build/asdf/babel_0.3.0/")
* (push "C:/Users/dhl/build/asdf/cffi_0.10.6/" asdf:*central-registry*)
("C:/Users/dhl/build/asdf/cffi_0.10.6/"
"C:/Users/dhl/build/asdf/trivial-features_0.6/"
"C:/Users/dhl/build/asdf/alexandria/" "C:/Users/dhl/build/asdf/babel_0.3.0/")
*
(Of course, you'd have to give your paths to the libraries instead of `"C:/Users/dhl/...")
Then, you can load CFFI:
* (asdf:load-system 'cffi)
[much compilation output]
T
*
Now, that's pretty much the bare bones way to install systems for Common Lisp. Nowadays, there is Quicklisp, which is easy to use and covered by Xach's answer. Also, note that there are better ways to register your systems with asdf, like symlinking the asd-files to a single directory on platforms that support symlinking, and ASDF 2 provides a source-registry facility, so you won't have to deal with asdf:*central-registry* at all (I still like it for REPL use).
All in all, I guess Xach's answer provides the easiest way to get a working installation of CFFI, so I recommend his answer and will vote it up, but I already started writing my article before he posted it, and maybe its of some use to you to know how to do things manually.