Currently, cabal repl is unusable for me. Typing at the prompt is erratic: a few letters appear, then it seems to hang for 5-10 seconds, only to proceed again afterwards. I suspect it's related to the fact that it loads Alex/Happy generated files (81K and 134K respectively) into the REPL. I don't really need those files for REPL support most of the time. I'm not sure if that's actually the problem, but I don't know what else to try.
I'd like to be able to exclude them from the REPL while still including them in the build process. Even better: can I only use one function from each of those files (lex/parse) somehow?
Edit: I'm seeing this behavior with GHC 7.8.3/Cabal 1.20.0.3 running on OS X 10.9 and a mid-2012 rMBP (Sandy Bridge) with 16GB of RAM. GHC/Cabal was installed via Homebrew.
Edit 2: Cabal file in question
Can you post your .cabal file?
If I understand your situation correctly, here's how I might proceed:
Verify that the alex and happy generated files are causing the slowdown.
If that is the case, consider moving them into a different package so that ghci will load the compiled versions of them.
For #1, I might try replacing the alex and happy generated files with just stubs - skeletal files which contain definitions (= undefined) for only the symbols which are imported by other modules.
I tried reorganizing the code per user5402's answer, but I wasn't able to get much of a speedup, even with code in different base packages.
Instead, I created a .ghci file in the project directory with the following contents:
:set -fobject-code
This loaded compiled versions of modules, with only the exported functions callable. For my uses, this is fine.
Related
I'd like to build a small set of vimscript libraries, however, it seems that the only way to use them would be to load them all globally into vim.
Furthermore, it means that if i wanted to share a single script that depends on those, i'd have to share to them all, which sounds tiresome.
What i was hoping for is some common.js and webpack style approach to vimscript,
does such a thing exist. Something that:
Resolves dependencies
Allows for vimscript files to be "bundled" together into one file.
Everything that i found, winds up being a plugin manager, rather than a plugin build tool.
Do such things exist?
The situation so far, up to Vim 8.
There is no script isolation. When a script is loaded, it's globally. The script can hide variables and functions, but that's all.
Sharing/exporting a function is quite easy: we drop it in an autoload plugin, and we just have to use that function named dirrelatativeto_rtp#subdir#suddir...#scriptname#funcname(). If the script scriptname.vim is installed in dirrelatativeto_rtp/subdir/subdir somewhere in a directory registered in 'runtimepath', it'll get loaded automatically.
Regarding commands, abbreviations, mappings... they are meant to be defined in plugin files, or ftplugin files -- other approaches are possible when we want submodes. Also we cannot use them naively from an autoload plugin or when a script is being loaded -- we'll have to explicitly use :runtime to load the script where this command/mapping/... is defined (as we'd do an import in Python).
Yet, like with Python, scripts aren't installed automagically on our system. It's still up to us to trigger manually the installation of scripts.
We can decide to have library plugins and other plugins that depend on these libraries. But, we need either to tell the end-user everything that must be installed manually, or kindly tell him/her to stop using a plugin manager that don't understand dependencies.
This has been a personal rant of mine for years, the trendy plugin managers don't understand dependencies. There are so far only two plugin managers that do so:
Vim-Addon-Manager (aka VAM): it relies on a central repository (vim-pi) to install a plugin (and its dependencies) with just its name (e.g. :InstallAddon fugitive, :InstallAddon lh-cpp). Unfortunately the central repository is no longer maintained and we can't register new names. Fortunately, we can always install anything with :InstallAddon github:{N}/{repo}. Other functions are available for installing from the .vimrc.
and vim-flavor which is written in ruby, and which install plugins as Vim 8 packages.
Both have their own syntax to declare dependencies. Unlike VAM, we can specify constraints on plugin versions with vim-flavor.
Last thing, if we don't want to distribute all files, we can organize them as several "plugins". But beware of cyclic dependencies. And be kind to end users that are using these trendy plugins managers that don't understand dependencies as they'll need to explicitly install many "plugins"
Starting from Vim 9
We can start to isolate imported plugins in the sense that two plugins can define a function or a command with a same name. Again, this feature seems to mimic Python way of doing things.
However, I expect global stuff like autocommands to continue to operate globally. For instance: I don't see how we could have two template expander plugins running concurrently.
Vim 9 new scripting language won't change anything to the installation of plugins we depend on.
Disclaimer: It has been almost 2 decades now that I've been maintaining my plugins as a bunch of interdependent plugins, organized around a few library plugins, as I don't like to duplicate a same thing several times. In my rant about dependencies & co, I explore quickly other alternative approaches available to us.
Back to the bundling/packaging question (EDIT)
We have ways to package files together.
We can always manually define plugins: put files together in a directory tree, play with git and so on.
We can define tarballs.
We can also define vimballs. Vimballs are a quite old solution for installable archives: files are put in their right directory and documentation tags are produced. There are ways to produce vimballs. I continue to maintain scripts that help producing them for all my plugins. But in all honesty, this is not what people expect to have nowadays to install plugins. I just keep them around in case I release new versions of my plugins on vim.org.
In any case, neither of these solutions end up defining one single file we put somewhere in our ~/.vim/ directory. And I think we will never have something like that because:
Isolation is not perfect. Even with Vim 9 new scripting language: I don't see how we could correctly handle duplication of autocommands. If a same file, that defines autocommands, is duplicated in different versions in several distributed "plugins" I don't see how Vim could handle that correctly.
Vim expects different files in different places: ftplugins, plugins (the original meaning in vim context, not the set of files that could be installed together), syntax files, fold plugins, indent plugins, colorschemes, langmaps, and so on. Vim architecture does not expect everything in a single file.
For these reasons, I cannot see how we could have build systems that build single files ready to be distributed. It could work in some cases (pure collections of functions and "classes"), but not in the general case.
http://community.activestate.com/node/7011
It's kinda like that poor chap shang (can I use chap gender-neutrally?) over there in the link, except it's another year and I have MSVS 2012.
Details
CMake has placed C:...\Tcl\lib\tcl85.lib on the dependencies list for my binary (I checked in the generated .vcproj file - it's there). Nevertheless, the linker errors are numerous and of the form:
nativeTCL_wrap.obj : error LNK2019: unresolved external symbol __imp__Tcl_[some-command-name] referenced in function _SWIG_Tcl_[some-other-command-name].
So I check the header file as listed in the dependencies list for my project in MSVS: version is #define as 8.5. This matches the library that I'm trying to link to. I tried exploring tcl85.lib with dependency walker. Apparently it can't explore that kind of file. I ran dumpbin.exe on it... And the .lib file has ALL OF THE MISSING FUNCTIONS, but of the following form:
__imp_Tcl_[some-command-name]
It has all of the symbols... But there's an underscore missing in each of them!
I then explored the libtcl85.dll.a file given by ActiveState's Tcl distro used in Cygwin, and the symbols look like this:
__imp__Tcl_[some-command-name]
So it has the extra underscore, and the binary links properly on Cygwin.
...
This is seriously one of those moments where I'm throwing my hands up in the air and thinking, "What do?" in all of its simplistic grammatically screwed up glory. The same swig interface file with the same CMake generates a module successfully in Cygwin. But developing Cygwin is a pain in the ass because of how slow it is (builds are almost 5-8 times as long as in more native-Windows-ish systems).
What Happens Next?
Do I try to convince Swig to generate with dependencies with one less underscore? If so how? Do I give up and file a bug report? If so, where? Is this a bug in ActiveState Tcl? Is this a bug in Swig? Is this not a bug at all and I'm just screwed?
For the lack of an underscore the kingdom was lost?
So, as I was writing my question, I started thinking about all of the different alternatives to how this could have gone wrong. Then I remembered that CMake by default chooses the 32-bit version of MSVS. I am now feeling quite sheepish, but as someone else apparently had a similar problem on the ActiveState fora, I'm leaving my answer here for anyone else needing this little, tiny, itsy bitsy reminder...
As it turned out, selecting the 64-bit version of MSVS with cmake -G "Visual Studio 2012 Win64" fixed everything. Linking worked fine. The binary got loaded successfully into Tclsh.
I would've expected a more comprehensive error message from my build tool about trying to link 32-bit and 64-bit binaries together, though...
I've been using Libpng15 in Windows 7, but I've been getting errors in relation to the
Unresolved External _png_set_longjmp_fn error when I compile my code. I followed the directions in the aforementioned link, and while it DID compile without any errors, I wound up with a message saying that I needed libpng12.dll to continue.
So, I did some Googling for libpng12.dll...nothing came up but generic "find x.dll" websites which appeared to be scams.
I've tried reading the INSTALL docs for the libpng source code on their website, and all that I see is instructions on how to do it via Unix based systems. I tried to do this in Cygwin with no luck, so I'm kind of stuck on how to compile this library.
All in all, I'm willing to do either the compilation or just using the .dll, though the problem is that I can't find a working .dll for version 12.
Another thing I tried was downloading binaries from here, which claimed to be "libpng12 for windows". I then copied the files into my VC compiler directory, which overrode libpng15, I think. Still, when I link against it statically and run my program in VC, it says that I require the .DLL file. The libpng12.dll file was in fact a .dll.a file instead. I honestly am not sure to link these (I tried linking it statically by typing "libpng12.dll.a" in the Linker Input setting through VS).
If I can go the .dll route for libpng12, how do I do this? Where is the file? How do I link it in VS?
Any help would be appreciated, as it seems there really isn't a whole lot of information on this. Either that, or I'm just not looking properly.
Look in the "projects" directory of the libpng distribution, and use one of the visual projects.
As mentioned above Look in the "projects" directory of the libpng distribution
Then make the adjustments outlined here
https://stackoverflow.com/a/38547948/293792
Which I note here for simplicities sake
(as stated there) adding two lib values to
Config -> Linker -> Input -> Additional Dependencies
these values are ucrt.lib;vcruntime.lib
Ensuring the build type is /MD
Allowed me to build these older versions, and fix that error on Windows 10 VS2015.
This link seems to have an installer for 1.2 for you:
http://gnuwin32.sourceforge.net/packages/libpng.htm
it's 32 bit. Not sure if that makes a difference for you.
I am looking for a ctags equivalent to Haskell. I tried hasktags, but it have some problems:
In the source folder of enumerator, run hasktags . gives:
hasktags: tags: openFile: resource busy (file is locked)
And when I run vim -t enumFile, an error occurs:
E431: Format error in tags file "tags"
Before byte 4085
E426: tag not found: enumFile
I also tried gasbag, but it doesn't compile on ghc-7.0.4.
You are using Mac OS X (or Windows, see below), aren't you?
In that case, hasktags -c (which only creates Vi-format tags) would fix your problem.
That's not the only explanation, but here's what happens on an OS X system:
by default, hasktags assumes you want both tags for vi and Emacs.
thus, it tries to create both tags (for Vi) and TAGS (for Emacs)
however, OS X, unlike Unix, is by default case insensitive. Hence you can't have both files there.
instead of overwriting one file with the other, for some reason hasktags runs into a conflict, probably because it opens one file before closing the "other". I'd expect that's by virtue of lazy I/O, as explained by Evan Laforge.
Update: as pointed out by a comment, Windows is also case insensitive, so similar problems might arise.
hasktags has some bugs, one of which is that it uses lazy IO, which tends to give those resource busy errors.
As it happens, I just wrote a tags program, at http://hackage.haskell.org/package/fast-tags
Other options are hothasktags, which makes qualified Module.function tags, and lushtags, which is designed to integrate with a fancy IDE-like vim tagbar thingy. In my experience hothasktags generates giant tags files and lushtags crashes as soon as it can't parse a file. Both use haskell-src-exts which means they are accurate, but will crash if they can't parse your file, and can't deal with .hsc files. fast-tags has its own parser, which means it doesn't have those problems, but is also more vulnerable to parsing bugs that miss tags or give bogus tags.
As you noticed, gasbag (and htags) use haskell-src which means they only work on Haskell 98.
Disclaimer: if by TAGS you mean emacs tags, fast-tags doesn't do those yet, though if someone cared it would be easy to add.
Forgive me if this is a FAQ but I'm a bit puzzled about how to get around this problem properly.
I recently downloaded the package TagSoup which installed fine with the latest version 0.12.2
Then I installed the package download-curl which installed fine with the latest version. What I failed to realise was, download-curl depends on TagSoup with a version =< 0.11, so as part of the installation process Cabal downloaded an older version of TagSoup too.
This is a problem because I want to use both libraries (the latest version of TagSoup AND download-curl) - and when you do for some reason GHCI gets in a bit of a mess.
My question is, is there a way of specifying versions in your import statements, i.e.
import Text.Html.TagSoup-0.12.2
or is this a no go? I'm thinking not.
The only way I got around this was to download the download-curl source, modify the .cabal file to use TagSoup-0.12.2 and reinstalled the package with my little "hack" in place which works as I would expect it to - but I don't think this is the solution
Any help would be appreciated
Normally one specifies the required version in the .cabal file. There is an extension syntax for specific package imports (-XPackageImports) but it's usually better to let Cabal deal.
That said, yes, if you need to use both then you enter the dark realm of diamond dependencies. Yours is pretty much the only solution available currently. -XPackageImports is not a good idea here, as trying to use two versions of the same library in the same program probably won't link and almost certainly will dump core at runtime if it does manage to link without duplicate symbols.