I am extremely new to haskell and I have been searching all over the web but I haven't been able to solve my problem. I downloaded the Quipper package but I have not been able to get haskell to recognize where all of the modules and files are and how to properly link everything.
I have downloaded all of the files and programs and installed them properly, I just dont know how to get haskell to recognize the quipper libraries and templates. Evey time I try:
:load And_gate.hs or some other file.
I get:
Could not find module "Quipper" or its respective modules it requires.
I don't think it is an error or anything, I think it is just my lack of knowledge on how haskell works.
I'm using windows 7.
So I emailed Peter Selinger, one of the professors who created Quipper.
The only thing I need to do extra was inside MSYS:
ghci -iC:/quipper -iC:/quipper/quipper
This complies everything correctly and the files run properly.
Here is his email to me:
Dear -----,
thanks for writing. Let me see if I can help.
Are you following the instructions in the README file? Under "Building
the various algorithms and programs", the instruction is to run
"make". This would build all of the tests in the "tests" directory
automatically.
Next, to compile a Quipper program, you should use the "quipper"
script that is located in quipper/scripts. It works just like "ghc",
except that it automatically includes the correct directories for
Quipper's files in the search path. On Windows, you would be using
"quipper.bat".
Quipper is not really meant to be run interactively, i.e., from ghci.
However, if you do need to run Quipper interactively, I recommend
using the "quipperi" script, also in quipper/scripts. This too would
set the load paths correctly. In Windows, use "quipperi.bat".
Finally, if you need to include Quipper stuff from ghci, but for some
reason can't or don't want to use the quipperi script, you need to
specify those directories with the "-i" option, for example
ghci -iC:/quipper -iC:/quipper/quipper
It could be that in Windows, you need to use "\" instead of "/", but I
am not sure if this is necessary.
I hope this helps, -- Peter
When compiling and exe with ghc just make sure you include the commands:
-iC:/quipper -iC:/quipper/quipper.
If you use the quipper script as suggested by Professor Selinger, inside of MSYS do the following:
Navigate to the folder in which all of the Quipper files are held, this was my case:
cd C:/quipper/quipper/scripts
Then type quipper and your file's location in MSYS to compile an exe like so:
quipper C:/quipper/tests/And_gate.hs
The file will compile and should print updates like so:
[1 of 22] Compiling Libraries.Typeable (......
[2 of 22] Compiling Libraries.Tuple (......
and so on.
The exe (in this case And_gate.exe) will be inside the folder it was compiled from (C:/quipper/tests). You'll need to move it to a folder that contains the acroread.bat which comes in quipper/scripts for it to work properly.
For some reason, this code isn't packaged as a standard Haskell package. It if were, installing it would be fairly simple. As it is, the instructions in the README file look awful (especially under Windows, where it looks like you need MSYS to run the makefile).
Your problem might be as simple as telling GHCi which folder to look in to find the files; you can do that using the :cd command. Since you're on Windows, I'd suggest trying WinGHCi, which should allow you to browse to the right folder using the GUI.
If it isn't that simple... really, as a Haskell beginner, you're probably going to struggle to get this working. The documentation looks pretty minimal.
If you red both README and INSTALLING.windows and did everything as well, then you should add a path to Quipper's script folder to environment variable. Here is the path:
quipper-*/quipper/scripts/
where quipper-* is a <distribution name>-<version>.
There are two important scripts in that folder. The first one is quipper.bat which runs a ghc compiler to run Quipper's modules. The second one is quipperi.bat which is a ghci analogue for Quipper.
Now, when you added a path to variable, you can run And_gate.hs in Quipper's interpreter as follows:
quipperi And_gate.hs
Related
i want to install cpanm WWW::Curl::Form on my Synology NAS. But that fails. Here is the output cpanm WWW::Curl::Form WWW::Curl::Easy File::Find::Rule String::CRC32 URI::Escape
--> Working on WWW::Curl::Form
Fetching http://www.cpan.org/authors/id/S/SZ/SZBALINT/WWW-Curl-4.17.tar.gz ... OK
Configuring WWW-Curl-4.17 ... OK
Building and testing WWW-Curl-4.17 ... FAIL
! Installing WWW::Curl::Form failed. See /var/services/homes/fox/.cpanm/work/1541095458.25803/build.log
the log file gives me:
make: i686-linux-gnu-ld: Command not found
But i dont know how to fix it on my Synology NAS (DSM 6.2 and appollolake architecture DS918+)
After reviewing your additional comments, I believe I have potential solution. It looks like you are trying to install some Perl modules via the default Perl shell, cpan. As part of the installation process, the make utility is being executed. This utility is heavily used for compiling and building source from C and C++ source code, along with other languages.
The make utility is trying to call some executable i686-linux-gnu-ld which is a linker, see ld. A linker is a utility used in C programming for linking (combining) multiple compiled object files into a single executable binary. make is calling this utility as some sort of build process. Instead of calling i686-linux-gnu-ld it should probably just be calling ld. The only thing I am not sure about is why it is using the full name of the utility instead of ld.
I can think of two solutions. The first would be to update the make file to use the correct name for the linker. I'm not sure how you would do this when it is being installed via cpan since it is downloading a package and executing the make file before you have a chance to modify it. The other option is to create a symbolic link from the incorrect name and path of ld that the make file is using to the correct path /opt/bin/ld. This will result in ld being called when i686-linux-gnu-ld is called. Also, I forgot to mention it earlier but the which command will tell you where an executable / command is located on your shell's path.
The Stack Overflow post, How to symlink a file in Liunx?, gives a good explanation of how to create a symlink. You need to create a symlink to point to the correct name and path of the linker. To do so run the following command:
ln -s /opt/bin/ld /usr/bin/i686-linux-gnu-ld
Depending on the permissions of these directories you may need to run this command under a account with elevated permissions or via sudo. I apologize for this post being rather long and verbose. I just wanted to explain my solution in detail. I hope this helps. Please let me know if this doesn't resolve the problem.
edit: fixed typo in the command.
I am reading "Learn you a Haskell for great good", and have reached the chapter on I/O actions. I am using Windows, and have downloaded GHCi and WinGHCi.
I'm trying to compile a simple program and have saved a file on emacs as helloworld.hs with main = putStrLn "hello, world" in it.
The book says
Open your terminal, navigate to the directory where helloworld.hs is located, and enter the following:
$ ghc --make helloworld
However, if I enter $ ghc --make helloworld onto GHCi and WinGHCi I receive errors such as the one below, perhaps because I need to enter $ ghc --make helloworld elsewhere:
<interactive>:7:1: error:
parse error on input ‘$’
Perhaps you intended to use TemplateHaskell
In fact, in the online edition of the book (here: http://learnyouahaskell.com/input-and-output), the author remarks that:
For the purposes of this chapter, I'm going to assume you're using a unix-y environment for learning Haskell. If you're in Windows, I'd suggest you download Cygwin, which is a Linux-like environment for Windows, A.K.A. just what you need.
Question 1: Is it necessary for me to download Cygwin, or some other such thing, in order to be able to compile the program by entering $ ghc --make helloworld?
I ask this, since if there were some other way of compiling the program it would be very useful to know, since I am on a university computer and cannot download things like Cygwin without permission. (and even with permission it might not be possible, depending on what Cygwin requires)
Question 2: Given that only the technicians of my university are away for Easter, and only they can download things on this computer, how can I proceed with the chapter in I/O actions? Is it possible just to continue, but ignore the sections involving compiling programs?
In many Unix and Linux shells (at least in Bash with which I'm most familiar) the default prompt is $. That's what the shell displays.
On Windows, when you open a Command Prompt, you'll typically see something like this instead:
C:\Users\mark>
(That's my prompt.)
While instructions often include the $ prompt in order to indicate that the code is something that you're expected to enter at a command prompt, you're not expected to type the $. Just type ghc --make helloworld and hit Enter.
Also, you're not expected to do this from within GHCi, but from the command line. ghc is a command-line executable (an .exe), just like e.g. git. It has to be in your path, though, or otherwise, you'll have to type the full path the executable every time you want to run it.
You have downloaded ghci, which is interpreter. It is, by my opinion, totally enough to learn with it (it can :load sources as well), but you need to run a bit other commands. I don't know if your installation include compiler, I would not assume anything about it.
btw, you are typing command inside the interpreter already, the error message is specific for that
ps: to do same as "ghc --make" from the interpreter, run:
:load <file>
Yes, it will recurse to depenzecies automatically. You could use :help to learn other commands
I was trying to to install Haskell Platform 2014 2.0 but I can't really understand what am I supposed to do to make it work and there seems to be no useful documentation on the site.
I downloaded the binary dist from the site, unpacked it, launched the 'activate-hs' script and got this:
Haskell set to:
GHC /home/riccardo/usr/local/haskell/ghc-7.8.3-x86_64
Haddocks file:///home/riccardo/usr/local/haskell/ghc-7.8.3-x86_64/doc/frames.html
Other doc file:///home/riccardo/usr/local/haskell/ghc-7.8.3-x86_64/share/doc/ghc/html/index.html
Symlinks for command line tools (ghc, cabal, etc..) added to:
/usr/local/bin
Even running in --verbose tells me nothing more about what's going on, it just returns a list of all the files.
What should I do?
EDIT:
riccardo#eos:~$ whereis ghc
ghc: /usr/local/bin/ghc
If I go to /usr/local/bin the symlinks are there and they point to the respective files in /home/riccardo/usr/local/haskell/ghc-7.8.3-x86_64/bin, but in the property window it says they are broken, what does this mean?
Also, if I get into home/riccardo/usr/local/haskell/ghc-7.8.3-x86_64/bin and try to launch the scripts directly from there, it still won't work:
riccardo#eos:~/usr/local/haskell/ghc-7.8.3-x86_64/bin$ ./ghci-7.8.3
./ghci-7.8.3: line 2: /usr/local/haskell/ghc-7.8.3-x86_64/bin/ghc-7.8.3: File o directory non esistente
File o directory non esistente = file or directory does not exist
For posterity, if you're installing the generic-linux binary package as this appears to be describing, you cannot just run activate-hs. Rather you run install-haskell-platform.sh which puts everything in the proper place. Following that, you can use the installed activate-hs in the future if you want to swap between different versions...
[Note: This is ALMOST a duplicate of Linking to a library that hasn't been built yet with CMake, but in this case the unbuilt library is coming from an ADD_CUSTOM_TARGET rather than an ADD_LIBRARY, so CMake can't work its usual magic so effectively.]
One of my CMake 2.8 projects currently has the following code:
# the COMMAND was heavily simplified but you get the idea
ADD_CUSTOM_TARGET(custom_breakpad_target ALL
COMMAND cd ${CMAKE_SOURCE_DIR}/google-breakpad && make
)
# now here we are in the root "CMakeLists.txt"
LINK_DIRECTORIES(${CMAKE_SOURCE_DIR}/google-breakpad/src/client/linux)
ADD_EXECUTABLE(hello)
# ...many lines of code...
ADD_DEPENDENCIES(hello custom_breakpad_target)
TARGET_LINK_LIBRARIES(hello breakpad)
I know that LINK_DIRECTORIES has been deprecated (or at least disdained) because of its weird placement (it has to go before ADD_EXECUTABLE even though we'd really like to put it down next to the TARGET_LINK_LIBRARIES). Also, there's this nifty new command FIND_LIBRARY. So I'd like to write the root "CMakeLists.txt" more like this:
ADD_EXECUTABLE(hello)
# ...many lines of code...
ADD_DEPENDENCIES(hello custom_breakpad_target)
FIND_LIBRARY(breakpad breakpad ${CMAKE_SOURCE_DIR}/google-breakpad/src/client/linux)
TARGET_LINK_LIBRARIES(hello breakpad)
This code works fine... until I "make clean". The next rebuild fails to find breakpad, because it has been rm'ed and not created again yet by the time the FIND_LIBRARY runs.
How can I make this work? or make something work that's more elegant than what I've got?
So far, the best I've got is
ADD_EXECUTABLE(hello)
# ...many lines of code...
ADD_DEPENDENCIES(hello custom_breakpad_target)
TARGET_LINK_LIBRARIES(hello ${CMAKE_SOURCE_DIR}/google-breakpad/src/client/linux/libbreakpad_client.a)
This has the aesthetic disadvantage of having to explicitly write out the "libxxx.a" filename, whereas, as I understand it, FIND_LIBRARY would uncomplainingly continue to work even if we switched to "libxxx.1.so".
Building external targets through custom commands is very difficult to get right. CMake offers the ExternalProject module to assist with that.
With this module external libraries get build at CMake configure time - that is when running cmake for the first time and not when running make to build your actual project. This has the advantage that all of the files are already in place when configuring your project, so it is easy to locate them using a find script or a CMake configure file.
This approach of course only makes sense if the external library does not change frequently, because rebuilding the library requires running CMake again. If you need to recompile the external library upon changes by just running make, the best way to make it work is still to write a full-fledged CMakeLists.txt for it and pull that in with add_subdirectory.
I have a Haskell script that runs via a shebang line making use of the runhaskell utility. E.g...
#! /usr/bin/env runhaskell
module Main where
main = do { ... }
Now, I'd like to be able to determine the directory in which that script resides from within the script, itself. So, if the script lives in /home/me/my-haskell-app/script.hs, I should be able to run it from anywhere, using a relative or absolute path, and it should know it's located in the /home/me/my-haskell-app/ directory.
I thought the functionality available in the System.Environment module might be able to help, but it fell a little short. getProgName did not seem to provide useful file-path information. I found that the environment variable _ (that's an underscore) would sometimes contain the path to the script, as it was invoked; however, as soon as the script is invoked via some other program or parent script, that environment variable seems to lose its value (and I am needing to invoke my Haskell script from another, parent application).
Also useful-to-know would be whether I can determine the directory in which a pre-compiled Haskell executable lives, using the same technique or otherwise.
As I understand it, this is historically tricky in *nix. There are libraries for some languages to provide this behavior, including FindBin for Haskell:
http://hackage.haskell.org/package/FindBin
I'm not sure what this will report with a script though. Probably the location of the binary that runhaskell compiled just prior to executing it.
Also, for compiled Haskell projects, the Cabal build system provides data-dir and data-files and the corresponding generated Paths_<yourproject>.hs for locating installed files for your project at runtime.
http://www.haskell.org/cabal/release/cabal-latest/doc/users-guide/authors.html#paths-module
There is a FindBin package which seems to suit your needs and it also works for compiled programs.
For compiled executables, In GHC 7.6 or later you can use System.Environment.getExecutablePath.
getExecutablePath :: IO FilePathSource
Returns the absolute pathname of the current executable.
Note that for scripts and interactive sessions, this is the path to the
interpreter (e.g. ghci.)
There is executable-path which worked with my runghc script. FindBin didn't work for me as it returned my current directory instead of the script dir.
I could not find a way to determine script path from Haskell (which is a real pity IMHO). However, as a workaround, you can wrap your Haskell script inside a shell script:
#!/bin/sh
SCRIPT_DIR=`dirname $0`
runhaskell <<EOF
main = putStrLn "My script is in \"$SCRIPT_DIR\""
EOF