I'm trying to install s-xml (I'm heading towards s-xml-rpc) on clisp 2.49 on os x. I think I've got asdf install correctly. I can run:
(asdf:asdf-version)
"2.014"
so I guess that bits installed ok. But when I run:
(asdf-install:install :s-xml)
this happens
Install where?
1) System-wide install:
System in /usr/local/asdf-install/site-systems/
Files in /usr/local/asdf-install/site/
2) Personal installation:
System in /Users/mattyw/.asdf-install-dir/systems/
Files in /Users/mattyw/.asdf-install-dir/site/
0) Abort installation.
--> 1
;;; ASDF-INSTALL: Downloading 25612 bytes from http://common-lisp.net/project/s-xml/s-xml.tgz to /Users/mattyw/asdf-install-0.asdf-install-tmp ...
;;; ASDF-INSTALL: Downloading 186 bytes from http://common-lisp.net/project/s-xml/s-xml.tgz.asc to /Users/mattyw/asdf-install-1.asdf-install-tmp ...
;;; ASDF-INSTALL: Installing /Users/mattyw/asdf-install-0.asdf-install-tmp in /usr/local/asdf-install/site/, /usr/local/asdf-install/site-systems/
x s-xml/
x s-xml/ChangeLog
x s-xml/doc/
x s-xml/doc/index.html
x s-xml/doc/S-XML.html
x s-xml/doc/style.css
x s-xml/Makefile
x s-xml/s-xml.asd
x s-xml/src/
x s-xml/src/dom.lisp
x s-xml/src/lxml-dom.lisp
x s-xml/src/package.lisp
x s-xml/src/sxml-dom.lisp
x s-xml/src/xml-struct-dom.lisp
x s-xml/src/xml.lisp
x s-xml/test/
x s-xml/test/all-tests.lisp
x s-xml/test/ant-build-file.xml
x s-xml/test/counter.lisp
x s-xml/test/echo.lisp
x s-xml/test/plist.xml
x s-xml/test/remove-markup.lisp
x s-xml/test/simple.xml
x s-xml/test/test-lxml-dom.lisp
x s-xml/test/test-sxml-dom.lisp
x s-xml/test/test-xml-struct-dom.lisp
x s-xml/test/test-xml.lisp
x s-xml/test/tracer.lisp
x s-xml/test/xhtml-page.xml
*** - Component "s-xml" not found
The following restarts are available:
RETRY :R1 Retry installation
ABORT :R2 Abort main loop
What does it mean by component s-xml not found. It seems to suggest it hasn't actually installed anything. I've tried doing asdf-install:install via a http link and a downloaded tar zip and I always seem to end up in this state. Any thoughts on what I'm doing wrong?
I've also tried doing the Personal Installation (option 2) and I can see that the files get downloaded. But the outcome is the same.
Yours is not a problem with ASDF. It's a problem with ASDF-install.
ASDF-install is not maintained anymore. Alternatives include quicklisp and clbuild. I'd recommend quicklisp to get started fast.
It is possible that your ASDF:*CENTRAL-REGISTRY* variable is not set properly, so that ASDF is not checking the directories into which you have installed the s-xml library. It actually looks like ASDF-INSTALL is functioning correctly, but not in such a way that ASDF can then find the installed systems. What's in that variable? Or are you using Faré's new ASDF configuration facility? If so, are the directories /usr/local/asdf-install/site-systems/ and /Users/mattyw/.asdf-install-dir/systems/ in your asdf search path? Finally, have you looked in those directories and verified that the files have actually shown up there?
Related
I'm trying to build my project and I'm running into a really strange problem. I got my friend to install Haskell with Chocolatey and when he goes to compile my project with cabal build and cabal run project he runs into the following error that I just don't have:
Expr.hs:103:1: error:
Type applications in patterns are not yet supported
|
103 | evalVal env val #(HInteger _) = return $ val
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I assumed that the cabal file would take care of dependencies but obviously not. A cursory search as well proves fruitless because I can't even find another instance of someone having the same error.
I'm not sure if the problem is due to him being on ghc 9.0.1 and cabal 3.4 and I'm on ghc 8.8.3 and cabal 3.2 or if it's due to different operating systems, his being Windows and I OSX.
My worry is that if I upgrade my ghc and cabal versions then I will run into this error and I'll have to reinstall everything which was messy and difficult the first time
It turns out that was a change in GHC 9.0: Whitespace-sensitive !, ~, #, and $
it's the second point there:
f # x = y
Before: value binding that binds both f and x to y using an as-pattern
After: infix function named (#)
To restore the old behavior, remove the leading and trailing whitespace around #, like so:
f#x = x
So if you change it to
evalVal env val#(HInteger _) = return $ val
it should work for both compilers
Context:
I am currently coding the generate-ninja-build.scm script in git commit cb7530e3ff10 of my GPLv3+ project bismon (funded by H2020 research projects). This is contractually some Linux free software project supposed to run on Debian.
That script should become an improvement over the existing shell script bismon/generate-ninja-builder.sh which generates some build.ninja file for the ninja tool (some build automation one).
Question:
The current generate-ninja-build.scm has just (outside of copyright notice comment) :
(use-modules
;; see https://www.gnu.org/software/guile/manual/html_node/Modules.html
(ice-9 posix) ;;;; problematic line, but why ?
(ice-9 readline)
(ice-9 format)
(ice-9 pretty-print)
)
;;;;;;;;;;;;;;;; constants
(define bm-packages '("glib-2.0" "jansson" "gtk+-3.0"))
(define bm-gcc "gcc")
but when I run it as ./generate-ninja-build.scm on my Debian/Sid, whose guile --version gives
guile (GNU Guile) 2.2.4
Packaged by Debian (2.2.4-deb+1-3)
I am getting:
rimski.x86_64 ~/bismon 8:17 .0 % ./generate-ninja-build.scm
;;; note: auto-compilation is enabled, set GUILE_AUTO_COMPILE=0
;;; or pass the --no-auto-compile argument to disable.
;;; compiling /home/basile/bismon/./generate-ninja-build.scm
;;; WARNING: compilation of /home/basile/bismon/generate-ninja-build.scm failed:
;;; no code for module (ice-9 posix)
Backtrace:
9 (primitive-load "/home/basile/bismon/./generate-ninja-b…")
In ice-9/eval.scm:
721:20 8 (primitive-eval (use-modules (ice-9 posix) (ice-9 #) # …))
In ice-9/psyntax.scm:
1235:36 7 (expand-top-sequence ((use-modules (ice-9 posix) (…) …)) …)
1182:24 6 (parse _ (("placeholder" placeholder)) ((top) #(# # …)) …)
285:10 5 (parse _ (("placeholder" placeholder)) (()) _ c&e (eval) …)
In ice-9/boot-9.scm:
3377:20 4 (process-use-modules _)
222:17 3 (map1 (((ice-9 posix)) ((ice-9 readline)) ((ice-9 #)) #))
3378:31 2 (_ ((ice-9 posix)))
2803:6 1 (resolve-interface _ #:select _ #:hide _ #:prefix _ # _ …)
In unknown file:
0 (scm-error misc-error #f "~A ~S" ("no code for modu…" …) …)
ERROR: In procedure scm-error:
no code for module (ice-9 posix)
however the output of locate ice-9/posix includes:
/usr/lib/x86_64-linux-gnu/guile/2.0/ccache/ice-9/posix.go
/usr/lib/x86_64-linux-gnu/guile/2.2/ccache/ice-9/posix.go
/usr/share/guile/2.0/ice-9/posix.scm
/usr/share/guile/2.2/ice-9/posix.scm
So I was expecting the (ice-9 posix) line to work. If I comment that line, everything works as I want.
My ~/.guile just has:
;; file ~/.guile
(use-modules
(ice-9 readline)
(ice-9 format)
(ice-9 pretty-print))
(activate-readline)
and my interactive guile works like a charm with the expected fancy GNU readline and autocompletion interface.
What am I doing wrong?
sudo apt install guile-2.2-dev guile-2.0-dev guile-1.8-dev
Consider use Guix instead Debian. All develop dependencies is install by default in replace of Python. http://guix.gnu.org/
I couldn't find any mention of a (ice-9 posix) module in the guile 2.2 documentation, and while the appropriate file exists in the source tree, the modules/ice-9 directory README says
The non-module files are:
boot-9.scm -- loaded on guile startup
...
posix.scm -- loaded by boot-9.scm
You can't load it because it's not a module file intended to be loaded by user code. Same thing applies at least as far back as guile 1.8, so if you found some documentation or tutorial somewhere including an attempt to load a module by that name, it's simply wrong.
I'm working on a team project using Haskell and whenever I compile our project using 'cabal install' I start seeing the following:
$ cabal clean && cabal install
cleaning...
Resolving dependencies...
Configuring hackathon-0.1...
Building hackathon-0.1...
Preprocessing executable 'hackathon' for hackathon-0.1...
[ 1 of 65] Compiling Data.MaybeUtil ( src/Data/MaybeUtil.hs, dist/dist-sandbox-52369b17/build/hackathon/hackathon-tmp/Data/MaybeUtil.o )
[ 2 of 65] Compiling Data.JQL ( src/Data/JQL.hs, dist/dist-sandbox-52369b17/build/hackathon/hackathon-tmp/Data/JQL.o )
[ 3 of 65] Compiling Data.Tuples ( src/Data/Tuples.hs, dist/dist-sandbox-52369b17/build/hackathon/hackathon-tmp/Data/Tuples.o )
...
$
However, my team members see:
$ cabal clean && cabal install
cleaning...
Resolving dependencies...
Configuring hackathon-0.1...
Building hackathon-0.1...
Installed hackathon-0.1
What is different in their configuration that they don't see all of the "Progress" messages that start with [X of N] My.Module?
I would really like them to be able to see the progress of the compilation as it is happening as our project is quite large and currently has 65 modules and growing. Cheers!
When you run cabal install multithreaded (-j2 and up), single file compilation does not appear on stdout, but should still be written to the log file.
Okay, I decided to just look at the source code and answer my own question. After diving through the cabal-install source code and ending up inside the GHC source I eventually found what I was looking for at the bottom of compiler/main/HscMain.hs:
showModuleIndex :: (Int, Int) -> String
showModuleIndex (i,n) = "[" ++ padded ++ " of " ++ n_str ++ "] "
where
n_str = show n
i_str = show i
padded = replicate (length n_str - length i_str) ' ' ++ i_str
This is the method that prints the Module Index. It is used inside a function called batchMsg which wraps it with a method called compilationProgressMessage:
compilationProgressMsg :: DynFlags -> String -> IO ()
compilationProgressMsg dflags msg
= ifVerbose dflags 1 $
logOutput dflags defaultUserStyle (text msg)
As you can see this method only prints things to the log output filestream if the verbosity is one or higher.
So I have just tried to do this in my terminal:
cabal install -j4 -v1
And then if I tail -f the .cabal-sandbox/logs/package-name.log file then I can see the module indexed compilation messages happening. I think that this solves this problem. Then, when the compilation finishes (or errors out) all of the module messages get printed to stdout. It seems that something is blocking print calls to stdout in parallel compilation in GHC. There is also something that sets the verbosity to 0 when you turn on parallel compilation. I think that both of these are bugs and should be fixed so I may go and try and raise feature requests now.
At any rate I hope that this investigation helps somebody else too. Cheers and thanks for the pointers everybody!
Here's my command and output (some command line arguments are left out). What is going wrong? Thank you.
$ brew reinstall pyqt --with-python3
==> Reinstalling pyqt --with-python3
==> Downloading http://downloads.sf.net/project/pyqt/PyQt4/PyQt-4.10.3/PyQt-mac-
Already downloaded: /Library/Caches/Homebrew/pyqt-4.10.3.tar.gz
==> Patching
patching file configure.py
==> python configure.py --confirm-license --bindir=/usr/local/Cellar/pyqt/4.10.3
==> python ./configure-ng.py --confirm-license --bindir=/usr/local/Cellar/pyqt/4
==> make
==> make install
==> Caveats
Set PYTHONPATH if you want Python to find your site-packages:
export PYTHONPATH=/usr/local/lib/python2.7/site-packages:$PYTHONPATH
==> Summary
🍺 /usr/local/Cellar/pyqt/4.10.3: 560 files, 18M, built in 6.6 minutes
UPDATE:
I think the formula of pyqt somehow hard-codes the python's version. For example it explicitly includes paths like python2.7/site-packages/. Here's part of the file:
def install
# On Mavericks we want to target libc++, this requires a non default qt makespec
if ENV.compiler == :clang and MacOS.version >= :mavericks
ENV.append "QMAKESPEC", "unsupported/macx-clang-libc++"
end
args = [ "--confirm-license",
"--bindir=#{bin}",
"--destdir=#{lib}/python2.7/site-packages",
"--sipdir=#{share}/sip" ]
# We need to run "configure.py" so that pyqtconfig.py is generated, which
# is needed by PyQWT (and many other PyQt interoperable implementations such
# as the ROS GUI libs). This file is currently needed for generating build
# files appropriate for the qmake spec that was used to build Qt. This method
# is deprecated and will be removed with SIP v5, so we do the actual compile
# using the newer configure-ng.py as recommended.
system "python", "configure.py", *args
(lib/'python2.7/site-packages').install 'pyqtconfig.py'
# On Mavericks we want to target libc++, this requires a non default qt makespec
if ENV.compiler == :clang and MacOS.version >= :mavericks
args << "--spec" << "unsupported/macx-clang-libc++"
end
system "python", "./configure-ng.py", *args
system "make"
system "make", "install"
end
You should check out this issue on Homebrew's git:
https://github.com/Homebrew/homebrew/issues/25735
We can no longer use the --with-python3 argument with pyside/pyqt/sip. Unfortunately, it seems like we can't use Homebrew for these modules in a while. They probably have to find another solution of handling the formulas for having Python 2.7 and Python3 installs first.
I scratched my head for days figuring this out. Ended up with installing PyQt from source.
Good luck.
I finally made it to install Haskell SDL bindings on Windows. Using this:
> $env:Path += ";C:\SDL;C:\SDL\bin;C:\SDL\include;C:\SDL\lib"
> cabal install SDL --extra-include-dirs="C:\SDL\include" --extra-lib-dirs="C:\SDL\lib"
This works, as long as Cygwin is installed for the configure script. However, I wrote a tiny test script:
import Graphics.UI.SDL as SDL
import Control.Monad (void)
import Control.Exception (bracket_)
main = bracket_ (SDL.init [InitEverything]) quit $ do
screen <- setVideoMode 800 600 0 []
SDL.flip screen
void $ waitEvent
Trying this now gives me this error message:
*Main> :main
Loading package SDL-0.6.4 ... <interactive>: mingw32: Cannot find specified module.
can't load .so/.DLL for: mingw32.dll (addDLL: could not load DLL)
Now I was looking for that mingw32.dll but I couldn't find it on my computer, though I have MinGW32 installed. Does anyone have had any experience here?
Using SDL-0.6.4, GHC 7.4.2 from Haskell Platform 2012.4.0.0. Windows 7 64-Bit.
ADDITION: I have now also tried it in the way A Haskell Adventure In Windows recommends, and that has the very same result.
It may be a 64 vs. 32 bit issue. Try copying that .dll to:
64-bit version of Windows: copy to c:\windows\syswow64
32-bit version of Windows: copy to c:\windows\system32
That helped me with FTGL - see here
I used MSYS/MinGW to build, and I was having the exact same problem. After fiddling around I found that the flag -lmingw32 (in the file sdl-config) is being used, and this seems to imply mingw32.dll. I simple remove this flagged, and everything worked.