I'm using the haskellmode-vim plugin. Unfortunately it doesn't seem to work very well with cabal-dev (apparently it invokes GHC directly). Now I'm wondering if there's some way to get haskellmode to work in a project managed by cabal-dev (ideally, without a lot of project specific setup?). Searching for this I only found something pointing at ghcmod, and I'm not really sure how that'd help in this case.
I just figured this out for myself with some considerable help from #haskell on freenode.
In your .vimrc you should have the following lines (probably already if you have hdevtools and cabal-dev setup)
Taken from http://lpaste.net/94999 original author unknown. Slightly edited here to remove a deprecation warning.
function! FindCabalSandboxRoot()
return finddir('.cabal-sandbox', './;')
endfunction
function! FindCabalSandboxRootPackageConf()
return glob(FindCabalSandboxRoot().'/*-packages.conf.d')
endfunction
let g:hdevtools_options = '-g-ilib -g-isrc -g-i. -g-idist/build/autogen -g-Wall -g-package-db='.FindCabalSandboxRootPackageConf()
The documentation of haskellmode-vim recommends the following lines in your .vimrc:
au Bufenter *.hs compiler ghc
Reading the haskellmode-vim plugin source, the options to ghc are stored in a buffer variable called ghc_staticoptions, so now we know everything we need to know to make cabal-dev work.
au Bufenter *.hs let b:ghc_staticoptions = '-ilib -isrc -i. -idist/build/autogen -Wall -package-db='.FindCabalSandboxRootPackageConf()
However, as mentioned in this SO question haskellmode-vim is not quite dead but resting. So you may want to look into a different plugin.
Related
When I run the Syntastic syntax check on my C file I do not get warnings about unused-function.
When I run
:let g:syntastic_c_compiler_options
I get
-DUSE_STM32L476G_EVAL_REVB -DUSE_HAL_DRIVER -DSTM32L476xx -DDEBUG_CODE -I./Core/Inc -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/CMSIS/Device/ST/STM32L4xx/Include -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/STM32L4xx_HAL_Driver/Inc -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/BSP/Components -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/CMSIS/Include -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/BSP/Components/stmpe1600 -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/BSP/Components/stmpe811 -IC:/ST/STM32Cube_FW_L4_V1.13.0/Drivers/BSP/STM32L476G_EVAL -IC:/ST/STM32Cube_FW_L4_V1.13.0/Middlewares/ST/STM32_USB_Device_Library/Core/Inc -IC:/ST/STM32Cube_FW_L4_V1.13.0/Middlewares/ST/STM32_USB_Device_Library/Class/MSC/Inc -IC:/ST/STM32Cube_FW_L4_V1.13.0/Middlewares/ST/STM32_USB_Device_Library/Class/CDC/Inc -I./Drivers/STM32L4xx_HAL_Driver/Inc -I./Drivers/STM32L4xx_HAL_Driver/Inc/Legacy -I./Drivers/CMSIS/Device/ST/STM32L4xx/Include -I./Drivers/CMSIS/Include -I./FATFS/Target -I./FATFS/App -I./Application/Src -I./Application/Inc -I./Middlewares/Third_Party/FatFs/src -Wall
(notice it ends with -Wall).
When I run
:SyntasticInfo
I get
Syntastic version: 3.8.0-14 (Vim 800, Windows, GUI)
Info for filetype: c
Global mode:active
Filetype c is active
The current file will be checked automatically
Avaiable checkrs: gcc make
Currently enabled check: gcc
I know that syntastic is working because I do get other warnings, however, I do not get warning for unused-function (i.e. static int foo() {} that no one calls).
When I run on the command line.
$ gcc -....(all the options mentioned above) -c myfile.c
I do see those warnings.
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 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.
I am not sure exactly what my question is as I get seriously turned around by autoconf/automake/libtoolize etc. Several of us are trying to autoconferize mbsystem. I've thrown a repo up of the work to date here:
https://bitbucket.org/schwehr/mbsystem
I'm trying to improve the netcdf setup to use nc-config, but am uncertain how to do this correctly. I am working on configure.in. It seems unable to find a header with AC_CHECK_HEADER("netcdfcpp.h") after INCLUDES="$INCLUDES ``$nc_config --cflags``" (pardon the incorrect back ticks) as taken from the gdl netcdf check. What is the correct way to update the path from nc-config --cflags?
http://gnudatalanguage.cvs.sourceforge.net/viewvc/gnudatalanguage/gdl/configure.in?revision=1.121
I then tried to use AX_PATH_GENERIC and get stuck on this error with m4_include([m4/ax_path_generic.m4])
Running autoconf ...
configure.in:29: error: possibly undefined macro: AC_SUBST
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:12992: error: possibly undefined macro: AC_MSG_RESULT
Any help in getting better at creating a netcdf check that actually will work with funky non-standard install locations via nc-config and figuring out how to properly put a macro in the m4 directory would be a huge help.
A pointer to a package doing this really cleanly would be a super help. I've been looking at the netcdf, gdal, geos and gdl sources for examples. And things like the octopus netcdf check do not use nc-config... http://www.tddft.org/trac/octopus/browser/trunk/m4/netcdf.m4
The current setup with fink for netcdf 4.x:
nc-config --cflags --libs
-I/sw/opt/netcdf7/include -I/sw/include
-L/sw/opt/netcdf7/lib -lnetcdf
Thanks!
See Makefile.am: How to use curl-config and xml2-config in configure.ac? and substitute xml2/curl by netcdf.
Just use
PKG_CHECK_MODULES([libnetcdf], [netcdf])
in configure.ac, and then, in Makefile.am:
AM_CPPFLAGS = ${libnetcdf_CFLAGS}
bin_PROGRAMS = foo
foo_SOURCES = ...
foo_LDADD = ${libnetcdf_LIBS}
The "correct" way to use a third party m4 macro is to use aclocal (usually via automake) to generate aclocal.m4. If you are using automake, just add
ACLOCAL_AMFLAGS = -I m4
to Makefile.am and put
AC_CONFIG_MACRO_DIR([m4])
in configure.ac (after renaming configure.in).
If you are not using automake, add '-I m4' when you invoke aclocal. If you are not using aclocal, then you'll have to append the definition of the macro to the end of aclocal.m4 (and be careful to never run aclocal, as that will overwrite the file.)
There is no good example of a clean way to use conf scripts to do a build because using such scripts is an inherently flawed approach. A slightly cleaner approach is to stop using custom scripts and use pkg-config via PKG_CHECK_MODULES, but the cleanest way to do this is to educate your users. If the user wants to install the library in funky non-standard locations then they need to be educated enough to set LDFLAGS and CPPFLAGS appropriately.
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