I use both intel and gnu fortran compilers. Syntastic gives the following errors when I compile my module, with these settings:
syntastic_fortran_compiler set to 'ifort' & using ifort -c my_mod.f90, then it displays an error on the USE my_mod line.
syntastic_fortran_compiler set to 'gfortran' & using gfortran -c my_mod.f90, then it displays an error on the CALL subroutine line.
To change the value of syntastic_fortran_compiler, I edit the file: syntastic-checkers.txt by accessing it through :help syntastic-checkers-fortran in vim.
There is no problem with the code running though; everything is fine. The module does what it is supposed to. I like the loc_list when it displays errors, but it is irritating when it comes up with a non-removable, non-error. For now, I have set let g:syntastic_auto_loc_list = 0.
This is produced on a machine with gcc version 4.8.4. An interesting thing is that when I do this on a machine with gcc version 5.*, the gfortran error disappears. Also, I use ifort version 16.0.3 .
EDIT1: I see the errors when I open the main program file with vim after I compile as above.
EDIT2: As lcd047 mentions in the comments, I am supposed to add let g:syntastic_fortran_compiler ="ifort" to my .vimrc. Doing so resolves error(1), and now both cases produce error(2).
EDIT3:
The funniest thing happened. After I performed EDIT2, I indented the code inside the SUBROUTINE contained in my MODULE, because the cursor kept jumping one indent every time I pressed enter, and it was getting irritating (up until now all code in the module was without indentation).
Then, when I opened my main file this time, syntastic actually tells me what is wrong as an error message (till now it only said error). Message: The type of the actual argument differs from the type of the dummy argument. It underlined all the REALs amongst the args (I have REAL and INTEGER args).
So then I open my_mod.f90 to check; everything seems okay. And this time when I open main.f90, there isn't an error anymore. What I wrote above is all I did. I have no idea how the error disappeared.
EDIT4: The above effect is reproducible. When g:syntastic_fortran_compiler = "ifort", if I compile once with gfortran, and open the file, syntastic says that it does not recognize the module. That is okay. Now, if I compile again with ifort, syntastic gives that error message of differing types again. Closing and opening the file again removes the error.
Related
I'm running:
GNU Emacs 24.4.1
Stack Version 1.3.3
org-mode
haskell-mode
I've looked through:
Emacs Org-Mode & Literate Haskell
https://gist.github.com/reetinder/4022989
https://wiki.haskell.org/Emacs/Literate_programming
https://wiki.haskell.org/Literate_programming
https://github.com/haskell/haskell-mode/issues/1429
While the gist above looks promising, I haven't found anything that looked to be an authoritative way to get org-haskell running (eg, nothing on melpa), and certainly nothing aimed specifically at whatever intricacy running a stack environment rather than using my global ghc would entail.
When I try to:
#+BEGIN_SRC haskell
let x = "test"
putStrLn x
#+END_SRC
I get
executing Haskell code-block
...which hangs forever. When I C-g, I see:
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Some flags have not been recognized: prompt2, ghci |
ghci λ> let x = "TESTING!"
putStrLn x
"org-babel-haskell-eoe"
Prelude|
<interactive>:4:1: parse error on input `putStrLn'
ghci λ> "org-babel-haskell-eoe"
When I tab to the haskell buffer, I see it has genuinely evaluated what I sent, it just has this org-babel-haskell-eoe error and never returns control to my org session.
Any chance this is because I have a custom prompt? Using the lambda instead of Prelude> ?
This is not a complete answer: in particular, it does not even mention Stack. But I (a complete ignoramus on Haskell) wanted to find out what it would take to get the OP's test program to run in babel. Here's what I found:
You need a haskell interpreter ;-) I'm on Fedora 24, so I installed the ghc-compiler package and I got ghci.
You need haskell-mode. I installed that from MELPA, using the emacs package manager. That also installed inf-haskell.el
By default, inf-haskell wants to run hugs, so I customized haskell-program-name and set it to "ghci".
M-x load-library RET ob-haskell RET
C-c C-c on the code block: the first time it fails and the Messages buffer shows "Buffer haskell.org does not exist or has no process".
But if you do it C-c C-c on the code block again, it succeeds!
Obviously, ob-haskell.el needs some work - and that's before we even get to Stack, of which I know even less than I know of Haskell, so I'll leave that as an exercise for the interested reader :-)
EDIT: Re. version info (requested in a comment): I keep close to the bleeding edge. At this point in time (2017-05-01), I run Org mode version 9.0.5 (release_9.0.5-444-g998576 # /home/nick/elisp/org-mode/lisp/) and GNU Emacs 26.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.20.10) of 2017-04-14
It is probably because of the custom prompt: I had the same issue, and when I removed ":set +t" and ":set prompt "GHCI >" from ~/.ghci, it worked. I fiddled with it some, and it seems it will work so long as your custom prompt doesn't have any spaces in it except the end (I changes mine to "GHCI> " and it works). It seems to be that the regular expression it parses the information from assumes the prompt will have no spaces in it.
In my case it was .ghci, like Testare's. As soon as I commented out :set prompt "λ ", emacs stopped freezing but gave the message ‘org-babel-script-escape’ expects a string. It was necessary to comment out :set +t for it to work.
what i did after installed stack and ghci (with stack itself)), was to install intero in emacs and then add those to init.el:
(setq haskell-process-type 'stack-ghci)
((org-babel-do-load-languages
'org-babel-load-languages
'((haskell . t)))
after that i can C-c C-c in haskell code block and i get a result under the code block.
I am attempting to set up a new Stack project on NixOS with GHCJS as the compiler following the instructions at http://docs.haskellstack.org/en/stable/ghcjs.html
I have included in my stack.yaml file the following lines of code (all on one line because tab spaces seem to give issues):
# Compiler specifying the GHCJS compiler for this project (using improved base).
compiler: ghcjs-0.2.0.20151230.3_ghc-7.10.2
compiler-check: match-exact
setup-info:
ghcjs: source:
ghcjs-0.2.0.20151230.3_ghc7.10.2:
url: "https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz"
and I have retrieved the following error message when I ran stack setup
Could not parse '/home/lorkaan/pandocJS/stack.yaml':
InvalidYaml (Just (YamlParseException {yamlProblem = "mapping values are not allowed in this context", yamlContext = "", yamlProblemMark = YamlMark {yamlIndex = 487, yamlLine = 12, yamlColumn = 17}}))
See https://github.com/commercialhaskell/stack/blob/release/doc/yaml_configuration.md.
Additionally, I tried removing the setup-info field because Stack was complaining about it, leaving my stack.yaml file like:
# Compiler specifying the GHCJS compiler for this project (using improved base).
compiler: ghcjs-0.2.0.20151230.3_ghc-7.10.2
compiler-check: match-exact
which produces this output with the stack setup command:
Warning: /home/lorkaan/pandocJS/stack.yaml: Unrecognized field in ProjectAndConfigMonoid: compiler
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.
The following executables are missing and must be installed: make
Does anybody have any idea why this would be happening?
the first error is because of a basic syntax error in your YAML configuration. The correct version would be:
setup-info:
ghcjs:
source:
ghcjs-0.2.0.20151230.3_ghc7.10.2:
url: "https://github.com/nrolland/ghcjs/releases/download/v.0.2.0.20151230.3/ghcjs-0.2.0.20151230.3.tar.gz"
The second error is because of exactly what it says: you are lacking the make utility. You need to use your Linux distribution's package management system to install make. Since I don't know which distribution you are on, I can only recommend simply executing the $ make command and seeing if the environment is smart enough to point out which package it can be found in. Ubuntu typically does that. Then it's only a matter of apt-get install-ing the package, or possibly yum install-ing on e.g. CentOS and Fedora, etc.
P.S. questions like yours normally get a downvote for not having shown sufficient effort in diagnosing the problem (or for putting 2 totally separate problems under a single question) but I'm giving you the benefit of the doubt and just hoping you'll be tidier next time.
I can't figure out how to get WinGHCi to load and compile my .hs file.
I have a file, C:\Users\Haskell\Source\hello.hs, that only contains the following line:
main = putStrLn "Hello, world!"
If, at the Prelude> prompt, I run
:cd C:\Users\Haskell\Source\
nothing happens, which I'm assuming means the command was successful. However, when I try to run
:load hello.hs
I get a "[1 of 1] Compiling Main. Ok, modules loaded: Main" message. My prompt then changes from "Prelude" to "*Main" and I type:
ghc -o hello hello.hs
After that, I will get a series of errors talking about how ghc, o, hello, hello, and hs are "Not in scope."
I am in the correct directory. Why won't my program run?
One of my problems is that I'm unable to navigate the directories. I know that :!dir lists the files, and I am in the right directory, but :load hello.hs still doesn't work and I keep getting the scope error.
Any help would be appreciated.
EDIT: A user pointed out that if I have gotten to the *Main prompt, then my program has been loaded and compiled and I do not need to run the ghc command. If that is the case, how would I run it? Haskell.org states that, "You can then run the executable (./hello on Unix systems, hello.exe on Windows)," but an exe has not been created.
I find it easier to first navigate to the directory then invoke ghci. Once in Prelude you can use :l and the file name.
Or, you could load ghci then use :l and use the fully qualified path for the file.
Edit:
After reading your edits, it is clear you are getting your code compiled fine. Once it says it has compiled, there is no reason to try and do so again with ghc (I don't think you can do that from within ghci anyhow).
Now that it is compiled, you can use any of the code and data types defined there in. So to use your main function, just type in main at the *Main> prompt.
So, I'm trying to use the Plugins package to dynamically load a haskell function from a source file. The source file depends on a package foo with module Foo.Bar. I'm running my project in a Cabal sandbox, where I have foo installed. Both my main program, and the module I'm loading with plugins, depend on foo. I always get one of the following two errors:
When I have foo installed in ~/.cabal, I get the error:
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
aizmvszmaizmlibzm0zi1_FooziBar_zdfTypeableBazzuds2_closure
whilst processing object file
/home/joey/.cabal/lib/foo-0.1/ghc-7.6.3/HSfoo-0.1.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
When I don't have it installed in ~/.cabal, I get a standard "module not found" error. And when I don't have it installed in my sandbox, I get the same module not found error trying to compile my main program code.
The plugins documentation is scarce at best. Any thoughts on how to solve this?
I got this working by using System.Plugins.Make to actually do the compliation, instead of relying on pre-existing object files. Not a complete solution, doesn't explain the problem, but it works for me for now.
I copied clang_complete.vim to plugin, but when I typed . after some variable, it says:
pattern not found
I searched this issue, and somebody said I should configure g:clang_complete_auto: and g:clang_complete_copen:. How can I do this?
I had the same problem and resolved it by adding the following to my .vimrc
let g:clang_user_options='|| exit 0'
Try opening a sample file
vim /tmp/sample.cpp
and enter some cpp code
#include <iostream>
int main() {
std:: // <-- this should complete
}
Note that you actually need to include the headers, since completion is done with the compiler. If this works, but your project still keeps saying "Pattern not found" then clang++ is probably not able to compile your project. Do you use any -I switches when you compile your code? Add them to a file named .clang_complete in your project directory.
For me this works fine with my .vim/plugin folder containing only the clang_complete.vim file that is available for download:
$ find .vim
.vim
.vim/plugin
.vim/plugin/clang_complete.vim
... but in this issue report https://github.com/Rip-Rip/clang_complete/issues/39 it is suggested that you might need more than that file (additional files are in the git repo).
The following got things working for me on Cygwin using clang version 3.0 (tags/RELEASE_30/final), as well as on Windows using the Clang build instructions and a version checked out from trunk (usually stable, as I've read) yesterday (clang version 3.1 (trunk 154056)) and built with Visual Studio 2010:
" clang_complete
let g:clang_complete_auto = 0
let g:clang_complete_copen = 1
" :h clang_complete-auto_user_options
if has('win32unix') " Cygwin
" Using libclang requires a Vim built with +python
let g:clang_use_library = 1
" Mit der Option "gcc" kriege ich Fehler.
" Remove "gcc" option as it causes errors.
let g:clang_auto_user_options='path, .clang_complete'
elseif has('win32') " Windows
let g:clang_auto_user_options='path, .clang_complete'
let g:clang_use_library = 1
let g:clang_library_path='D:\Sourcen\LLVM\build\bin\Debug'
endif
Note that the Windows version may have sporadic assertion failures but works fine, although not exactly like the Cygwin version. Guess it's to do with using MSVC versus GCC header files.
The Cygwin version has an initial error: release unlocked lock, but it works regardless.
Did you try to compile the code outside Vim, by explicitly invoking Clang on the command-line?
I had the same problem with my code, but it turns out Clang was not able to compile my code due to usage of the MPI libraries (mpich2). Maybe a similar problem is causing Clang to fail in your case? In my case, if I remove the MPI-dependencies, everything works fine, for example in something like:
#include <iostream>
#include <string>
int main() {
std::string myString("test string");
std::cout << myString.size() << std::endl; // After typing the dot, I get a list of std::string methods
}
By-the-way, I still miss clang_complete in my MPI code. Did anyone find a solution for this?
To configure Vim, you must find or create your .vimrc file:
$ vim ~/.vimrc
Then enter:
let g:clang_complete_copen = 1