When I install things with cabal-install, it automatically creates a ~/.ghc/x86_64-freebsd-8.8.3/environments/default with a bunch of stuff in it; this allows me to import my installed packages, but takes away my ability to import the standard library, even the Prelude:
gtk.hs:1:1: error:
Could not load module ‘Prelude’
It is a member of the hidden package ‘base-4.13.0.0’.
You can run ‘:set -package base’ to expose it.
(Note: this unloads all the modules in the current scope.)
Use -v (or `:set -v` in ghci) to see a list of the files searched for.
|
1 |
| ^
(It used to give me this error pointing to the first character of line 1 when line 1 was an unrelated import, so I put a blank line at the start of the file to see if it would still point the error there if there was nothing there. It does.)
If I delete the ~/.ghc/x86_64-freebsd-8.8.3/environments/default, I can import base again but not the installed packages. I need to give it the Cabal database with -package-db on the command line.
While that apparently works, I think there must be a way to configure that environment file to do this automatically. But as long as ~/.ghc/x86_64-freebsd-8.8.3/environments/default even exists, the entire standard library, including Prelude, is rendered hidden, and I can't compile anything at all (even an empty file fails with the above error). Including global-package-db in the environment file also didn't affect it.
Other info: I am not using Cabal to build because a .cabal file and a Setup.hs are added complexity I shouldn't need to compile a one-file throwaway program. I also tried installing the packages with --global passed to cabal install, but it still didn't install them globally.
OS: FreeBSD 12.1
GHC: 8.8.3
cabal-intsall: 3.0.2.0
Related
sbt.version 0.13.15
Question:
How can I force sbt to reload and recompile all build definition regardless whether they are changed or not?
The story:
I have a multiproject build consiting of multiple sbt and scala files. When I first loaded the project (I am not an author) by sbt -v in console I got a list of deprecated warnings (mainly operators like <<= <+= <++=). I want to fix all these but now when I start sbt -v again I do not get these warnings any more. Not even after reload.
I tried to modify build file (removing import) and reloading then. It showed me errors caused by removed import but no warnings. After fixing import back it showed no warnings still.
Only way I was able to see the list again was to change build file in a way which directly affects build definition and reload it then...
Bottom line
So yes I can edit every single sbt file and reload it then. But I wonder there must be a better way. There must be a way how to either force-reload whole build definition or recall that list of warnings somehow.
Thanks for ideas on this!
I found out that compiled build definition is stored in project/target. So to achieve what I want it is enough to remove this dir and then reload. It's not a command from sbt but it works.
I'm trying to get PyQt5 working with WinPython. PyQt5 comes with a readme file for installation, and I have unsuccessfully tried a few combinations of what I thought the first part of the readme tells me to do.
I have:
Windows 7 Home Premium 64-bit
WinPython-64bit-2.7.9.1
Qt 5.4
PyQt-gpl-5.4
PyQt-gpl-5.4 is in the folder (only partially sure that this is where I should have put it)
C:\WinPython-64bit-2.7.9.1\python-2.7.9.amd64\Lib\site-packages\PyQt-gpl-5.4
My current attempt at getting everything working is: I'm trying to run the configure.py file in PyQt-gpl-5.4, but when I do so I consistently get the following error:
Error: PyQt5 requires Qt v5.0 or later. You seem to be using v4.8.6.
Make sure the correct version of qmake is on your PATH.
What I think is the required version of qmake being referred to is in the folder
C:\Qt\5.4\mingw491_32\bin
However, I have no idea how to fix the error by adding the qmake in this folder to PATH. My most recent attempt was to add the folder using Spyder's Tools->PYTHONPATH manager, but this made no difference. I also tried adding it using sys.path.append('C:\Qt\5.4\mingw491_32\bin'), but this didn't work either. I have since removed the folder name from both of these locations.
How do I get PyQt5 working with WinPython-64bit-2.7.9.1, or I think equivalently, how to I get the configure.py file in the PyQt-gpl-5.4 folder to run?
Thanks.
You definitely don't want the source code (i.e. PyQt-gpl-5.4) in the site-packages folder, because that's where the compiled modules will end up. Instead, it should just go in a temporary folder whilst you compile it.
When you run configure.py, you must take care to use the executable for the specific python that you are targeting. I do not know anything about WinPython, but for a normal python installation this means doing something like this:
C:\Python34\python configure.py
As a first step, before attempting to actually compile anything, it would be advisable to take at look at all the configuration options that are available, like this:
C:\Python34\python configure.py --help
(There's also the Installing PyQt5 section in the PyQt Docs).
This will tell you, for instance, that the simplest way to specify the Qt installation you are targeting would be something like this:
C:\Python34\python configure.py --qmake C:\Qt\5.4\mingw491_32\bin\qmake
EDIT:
Sorry, that last part is wrong: the --qmake option isn't available on Windows, so you have to add the directory containing the qmake executable to your PATH. This can be done with the following command:
set PATH=%PATH%;C:\Qt\5.4\mingw491_32\bin
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)
Here is the situation:
fresh Plone 4.2 buildout
a fresh package created using Zopeskel 2.21.1 with template 'archetype'
and configured in my buildout using mr.developer
Trying to add some content types inside my package fails with:
[ajung#dev1 nva.aktionsmittel]$ bin/paster addcontent
Command 'addcontent' not known (you may need to run setup.py egg_info)
Running setup.py egg_info did not help.
setup.py contains:
setup.py: paster_plugins=["ZopeSkel"]
setup.cfg contains:
[zopeskel]
template = archetype
What is the magic behind the local commands in order to make "paster addcontent" working?
It worked in other contexts as it should?!
ZopeSkel 2 issues
You are following a bad tutorial. Please make sure that
You follow instructions specific here http://collective-docs.readthedocs.org/en/latest/getstarted/paste.html#adding-zopeskel-to-your-buildout - paster command must come from buildout
If you are not following the link above then please give the link to the page whose instructions you are follow and I can burn that page as it contains misleading instructions.
Make sure that paster you are using comes from buildout (from your command line it doesn't seem to be so).
Make sure your egg is registered in buildout correctly in eggs =
section
Make sure your setup.py contains necessary boilerplate http://collective-docs.readthedocs.org/en/latest/getstarted/paste.html#how-paster-local-commands-work (note: example is ZopeSkel 3+)
This is the way to make paster aware of your egg and its dependencies correctly and thus local commands can work.
ZopeSkel 3 issue (seemingly unrelated)
There was a recent change in ZopeSkel, meaning that you if you use ZopeSkel 3+ you need to be in srcfolder when running the command.
See note here:
https://github.com/collective/templer.plone.localcommands/#executing-local-commands
In order for the paster localcommand to run, it must be called from the same directory that contains the .egg-info directory (or a child directory inside it). If pasterns unable to find the .egg-info directory, it cannot run a local command. Paster uses the location of the .egg-info directory to locate setup.cfg, which is then used to determine if any local command entry points are available.
Check to see that you have an .egg-info directory generated inside your package, and that you are invoking paster from the same location or a child folder.
I'm trying to build my own package using Windows. I installed everything I need, and running R CMD build mypackage and R CMD INSTALL mypackage seem to run fine. when I run the build command, though, I get a warning from cygwin:
cygwin warning:
MS-DOS style path detected: C:/Documents and Settings/e_sander/My Documents/mypackage_1.0.tar.gz
Preferred POSIX equivalent is: /cygdrive/c/Documents and Settings/e_sander/My Documents/mypackage_1.0.tar.gz
CYGWIN environment variable option "nodosfilewarning"turns off this warning. Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
I did go to the recommended website, but I don't know much about cygwin or linux so I'm not sure there's anything I need to do. I realize that using the MS-DOS style path is deprecated and not recommended in cygwin, but I'm not sure how to change that, since I'm running Windows and that's the path I need. I also haven't noticed any problems with my package, at least when I install it to my computer (and although I haven't used the tarball, I've opened it and everything looks fine). So here's what I'm trying to figure out:
Does leaving the path as is affect my package in any way?
If so, how could it adversely affect my package?
How do I change the path to make cygwin happy?
This is just a warning and it tells you how to disable it. It doesn't affect anything. If you want it to go away, run this from your shell:
export CYGWIN="nodosfilewarning"
Or you could mount C: to /c/ (see man mount).
Does leaving the path as is affect my package in any way?
- No, it is just a warning.
If so, how could it adversely affect my package?
- N/A
How do I change the path to make cygwin happy?
- Set the environment variable as the output states. There are multiple ways to do this; I chose to go with a solution that handles the issue across any invoked environment that parses or inherits from the windows environment by using the "Rapid Environment Editor" program to add a User Variable named CYGWIN with a value nodosfilewarning. But if you wanted you could add it through the control panel using Add environment variables for your account.