I'd assumed I'd need to add additional modules (files) to a cabal project file? But not too sure where I would find this?
The solution is burried somewhat in the FAQ: https://wiki.haskell.org/Xmonad/Config_archive#Modular_configs
Create a lib directory, and place your modules there, you can them import them into xmonad.hs like so:
import Path.To.Foo
which would corresponde to the module located here: ~/.xmonad/lib/Path/To/Foo.hs
When using GHCi you will need to add a .ghci file with the following:
:set -i:lib
Related
I am using ubuntu 20.04 and python3. I want to import so file "ext.so" like this:
impot Ext
from another code. But the so file is in different folder. What is the right way to do it?
What is the right way to do it?
your project should be structured like so:
-head
--sub1
---Ext.so
--sub2
---caller.py
you should have head the folder containing head in your pythonpath somehow (by installing the python module using distutils, or just having head as your working directory or added by modifying PYTHONPATH in .bashrc, or appending it to sys.path in your script), and you should use
from head.sub1 import Ext
granted that your .so file is a python extension and not some sort of dll, anyone installing your project should be able to run your code without any problems.
however, there is definitely nothing stopping you from adding sub1 to your pythonpath and just import Ext.
Edit: i am sorry, if head is in pythonpath, you only need to import from sub1, not head, so you should have the folder containing head in your pythonpath, my bad.
I am taking a close look at Scons and something smells. SCons uses SConstruct files as base configuration file. This configuration file is a Python file but:
It does not have the .py extension
It does not have any import directives
It is not possible to have auto-completion from IDEs
It it possible to use a variant of the SConstruct file where I could find something like the following?
# build.py
import scons
env = scons.Environment()
env.Program('foo')
It would be not simple (but possible) to do what you're asking. SConscripts are plain python, however the globals available in the context of SConstruct or SConscripts are carefully constructed.
Any user can add methods and also pass python objects into the SConscripts via Export() or exports (in a SConscript call).
That said try:
from SCons.Script import *
That should get you some of what you're looking for.
The fact that Pycharm cannot find the symbols in question doesn't mean the it is not a plain python file.
Additionally I'm not sure how the subject of your question relates to the contents of your question. Typically setup.py is a file to build packages ala setuptools and install via pip (or similar).
Sure you can build whatever you are trying to build with setuptools, it will likely be harder to do, but that said if you get it to work, perhaps easier to upload and distribute via pypi
p.s. It's SCons not Scons.
I use vim, and I'd like to be able to navigate to function and type definitions spread across multiple Elm projects. My understanding is that the easiest way to go about this is to use ctags.
There is an existing open issue from January 2016 with various suggestions, including a link to ctags-elm which provides:
--langdef=Elm
--langmap=Elm:.elm
--regex-Elm=/^ *([[:lower:]][[:alnum:]_]+)[[:blank:]]*:[^:].*->.*/\1/f,function,functions/
--regex-Elm=/^ *([[:lower:]][[:alnum:]_]+)[[:blank:]]*:[^:][^-]+$/\1/c,constant,constants/
--regex-Elm=/^port +([[:lower:]][[:alnum:]_]+)[[:blank:]]*:[^:]/\1/p,port,ports/
--regex-Elm=/^type +([[:upper:]][[:alnum:]_]+)/\1/t,type,types/
--regex-Elm=/^type[[:blank:]]+alias[[:blank:]]+([[:upper:]][[:alnum:]_]+)/\1/a,type-alias,type-aliases/
If you install this in ~/.ctags, you can scan all your sources:
$ ctags -R --languages=-all,+Elm
However this approach still has problems:
It ignores qualified names, so an attempt to navigate to the definition of List.map will offer all the definitions of Dict.map, Set.map, Random.map etc.
It scans all the *.elm files in all my directories, including tests and old dependencies.
Basically I'd like a solution that:
Can follow qualified names☨ to their definition: navigating to List.map should prefer definitions of map in files named List.elm.
Scans all the *.elm files in each project's source-directories
Ignores everything in each project's tests directory
Ignores all the built *.js files
Optionally scans the latest versions☨ of library sources in each project's elm-stuff/packages directory
Is this possible with ctags, or with a ctags wrapper that parses each project's elm-packages.json file?
[☨] Regarding qualified names: I'm aware that some people abbreviate qualifiers, like:
import Math.Vector3 as V3
and I wouldn't expect a ctags regex to look for V3.add in Math/Vector3.
The longer-term solution would be a tool that understands Elm modules and imports, like hasktags does for Haskell. For now I could live with ctags not understanding abbreviated qualifiers.
[☨] Regarding latest versions: Sources of dependencies are downloaded into elm-stuff/packages/GITHUB-USERNAME/GITHUB-PROJECTNAME/VERSION-TAG, and over time it is possible to accumulate multiple versions, eg:
elm-stuff/packages/kfish/elm-gamepad/3.0.0
elm-stuff/packages/kfish/elm-gamepad/3.1.0
elm-stuff/packages/kfish/elm-gamepad/3.2.0
elm-stuff/packages/kfish/elm-gamepad/3.4.0
I can't answer on the Elm-specific points but…
Ignores everything in each project's tests directory
Add this to ~/.ctags:
--exclude=tests
Ignores all the built *.js files
Add this to ~/.ctags if they are not compiled in a specific directory:
--exclude=\*.js
or exclude the directory/directories in which they are compiled.
Optionally scans the latest versions of library sources in each project's elm-stuff/packages directory
How do you define "latest"?
The only way I could think of to reach that goal would be to pre-compile the list of places to look in and feed it to ctags via the -L flag:
$ ctags -R -L list-of-files.txt .
Actually, writing a shell script to generate a proper list-of-files.txt could probably fix all your pain points. Maybe someone already thought about that…
See $ man ctags.
In python, it is
import argparser
print argparser.__file__
My questions are:
How can i do the same in haskell i.e. to get the file location of a module from using loaded module object in haskell?
In haskell, the library file is in non-readable .hi format. Is there a way with cabal install, that i can download source files into ~/.cabal and compile it locally?
This doesn't exactly answer your question, but this is how I would find the location of the module in Haskell. Say I have a module named Data.Text and I want to find it's location. Then I initially find out it's package name:
$ ghc-pkg find-module Data.Text
/nix/store/cq4qqjii3s9ghr6p59kkrdf44wnyhpp4-ghc-7.8.4/lib/ghc-7.8.4/package.conf.d
/home/sibi/.ghc/x86_64-linux-7.8.4/package.conf.d
text-1.2.0.4
Now I know that the package name is text-1.2.0.4. So, now all I do is use this command to find the module location:
$ ghc-pkg describe text-1.2.0.4 # (Just text should also work)
And this will give you a big output. The interested fields for you are import-dirs and library-dirs.
To find out the source of the installed package, you can use cabal get <package_name> as mentioned by #Martin.
I'm pretty sure you cannot do the first thing in Haskell. However, if you just want to find out this path for yourself, you can use the command
ghc-pkg describe <package>
where <package> is the name of the package the module belongs to.
For downloading the source code of a package, just use
cabal get <package>
It will download the sources without any dependencies into a directory <package>-<version> within your current directory.
Syntastic works great in my system with hdevtools and hlint. But if I'm editing a file under a test directory, importing packages that are exclusively under the test-suite configuration of the cabal package, it marks my imports as bogus and tells me to include them in my cabal file. The same problem happens with the hs-source-dir, it only finds the ones under the library or executable directory.
There is no silver bullet. You can either set g:syntastic_haskell_hdevtools_args and friends to the proper flags for your project, or write a wrapper script similar to this and point g:syntastic_haskell_hdevtools_exec to it. Syntastic has no built-in support for looking at cabal files.