On 6.12.2, this just worked for me, I think. But now I'm on a new box with 6.12.3 (generic unix binary), and there's obviously some setting I'm missing.
I have a console history in ghci within a single session (i.e. execution of ghci), but this history isn't saved and reloaded between sessions, as it used to be. I can't keep track if ghci is using readline, editline, or haskeline even, so I'm not quite sure where to start in terms of fixing this.
This might not be of much help but have you checked whether the ghci_history file is being written to in ~/.ghc/ghci_history?
The Sean Seefried's answer does not work in Windows systems because ghc has its home in %APPDATA%\ghci (in my case, C:\Users\me\AppData\Roaming\ghci).
The file can be found in there: ghci_history
Related
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.
I saw that there is a lua plugin for eclipse and there is a docpage on the awesome main page api_doc and all the .lua files in /usr/share/awesome/lib.
So I thought it must be possible to create a Library or Execution Environment so that one has tabcompletion and docview.
So I tried making my own Execution Environment:
wrote the standard .rockspec file
downloaded the documentation made an ofline version of it and put it in docs/ folder
ziped the files and folders in /usr/share/awesome/lib
ziped all up
tried it out ... and it failed.
When I try to view a documentaion for a .lua file I get "Note: This element has no attached documentation."
Questions: Am I totaly wrong in my doing (because I have the feeling I am)? Is there any way to edit the rc.lua with tabcompletion and docview?
Koneki will probably take a while to setup, but it's definitly worth it. Going for the".doclua"(by using version 1.2) would certainly make it, but I doubt that using a script to generate the information you need, would work out on the long run.
Most likely, you'll probably pass a bit of time to define what kind of object you're dealing with every time you come across one. The right to do, would be to actually take the time to see if the object/module/inner type inherit from an another object, so can actually have more completion feature as you keep using autocomplete to go from one object to another by pressing "dot"+ctrl_space.
In an ideal world, one person could probably make it right and share to other, so they can enjoy a full featured autocomplete editor.
Found solution for eclipse.
First off the idea of setting up an Execution environment was the wrong one.
So the whole thing about downloading the doc although.
For more information on that visit eclipse Wiki for LUA Development Tool.
The right thing to do is to add a source folder which contains the /usr/share/awesome/lib directory.
The bad news is that my comment from above was totally right, which means one has to configure each .lib file in /usr/share/awesome/lib to meet the requirements of the Documentation Language described here.
Than editing the rc.lua (which one can add to the project in eclipse) works with tabcompletion and doc view.
Since the Documentation Language used in the lib files is similar to the one used by "LUA Development Tool" one has not to change many things. Maybe there are even scripts for that.
I've been using hsenv (with great success!)
to deal with the usual cabal dependency issues.
Its terrific, but there is one glitch I can't get around: how to persuade the
(also excellent!) vim-haskellmode to use the environment variables set by hsenv -- namely the paths to GHC, cabal database and so on
when compiling, generating tags etc.
Does anyone know how to solve this problem?
Sorry, hit the wrong button -- I should be asking questions about how to use SO instead :)
Anyways, an even better trick is to put this into the .vimrc
let g:ghc=system("which ghc")
This way (assuming that g:ghc gets bound when you run vim) it will pick up whichever ghc
is being currently used (by hsenv).
Ranjit Jhala.
One, simple solution is to hack one's .vimrc so that
let g:ghc="/path/to/hsenv/ghc"
I often find myself taking a lot of time to navigate through my filesystem when using the linux shell. This generally occurs because the autocompletion of bash only works if you provide the start of the file/dirname. What I often end up in is a lot of 'ls' with 'grep' commands, finally doing a 'cd'.
When you use a GUI based filebrowser (like Nautilus) you can type any part of a file/dirname and it will have matches that it jumps to directly. This makes it a lot easier and faster to navigate.
I wonder if anybody knows any great tools that helps with this problem. I know of the existence of Midnight Commander, though I never really used it for real and I couldn't figure out a direct solution for my problem the first couple of times I tried it. Also it seems not suitable because I want to have my shell's current working directory to be changed so I can do stuff there, instead of being stuck in an external program like Midnight Commander.
Try autojmp
https://github.com/joelthelion/autojump
And following article provides another solution
http://jeroenjanssens.com/2013/08/16/quickly-navigate-your-filesystem-from-the-command-line.html
You can first use the autocd or autopushd in zsh. You would just have to type the directory you want to go to, without the hassle of typing cd or pushd everytime.
You also have the globing possibility. For example, if I got those file in a directory:
1-a.tar
1-b.tar
c.tar
I can just type
*a.tar
without caring about the beginning of the file.
As a last solution you can always use an alias to the find command with a personalized option.
When working in the ocaml or ghci toplevels I often build up a significant "context" for want of a better word, values bound, functions, modules loaded, and so on. Is there a way to save all of that and reload it later so I can continue exactly where I left off? Or better yet, dump out the entire lot as a text file that could be reloaded or be trivially modified into code that I could compile into an executable (e.g. by adding a Main)?
Users of HOL light have had similar needs, and they use a checkpointing program to save a snapshot of the toplevel. See this message on the caml mailing-list, or page 8 of this HOL tutorial.
In general it is better to keep the definitions as source code, rather than a binary toplevel snapshot. Numerous tools allow to quickly load a .ml file into the toplevel for easy experimentation (emacs modes, etc.). See the warning in the HOL tutorial:
When developing large proofs in HOL, you should always keep the proof script as
an OCaml file ready to reload, rather than relying on ckpt. This will allow the proofs
to be later modified, used by others etc. However, it can be very convenient to make
intermediate snapshots so you do not have to load large files to work further on a proof.
This is analogous to the usual situation in programming: you should always keep your
complete source code, but don’t want to recompile all the sources each time you use
the code.
At least in OCaml there's no built-in support for that. On solution is to use rlwrap or any other readline wrapper to record your input's history to a file. For example :
> rlwrap -H mysession.ml ocaml
The drawback is that this will also record the input that had syntax errors so you'll have to clean that out. Note that by default rlwrap will automatically save your input in ~/.ocaml_history if you invoke it without the -H option.
In Haskell, just use :e file. This opens the standard editor and lets you edit some file. Afterwards, use :r to reload it. It will be automatically recompiled.
Please notice, that all your "ad-hoc" defined functions will be lost after this. Refer to the doc for more information.
ghci uses haskeline for commandline input history, so you can scroll up to repeat/edit inputs. Your input history is usually recorded in a file, which you can find as ghci_history in the directory given by
System.Directory.getAppUserDataDirectory "ghc"
There are various commands to explore the 'context' (:show bindings, :show modules, :def, ..) but their output won't suffice to reproduce your session (though it is worth knowing about them anyway).
In general, the advice to combine your ghci session with an open editor window is sound: if it is more than a throwaway definition, even if just for debugging purposes, better include it in a module to be loaded into ghci, so that you can reuse it.
Oh, and if by 'context', you mean some default settings or modules you want loaded, on a per-project basis, there is also ghci's configuration file. Also handy for defining your own ghci commands.
In ocaml, you can build your own top-level. It solves problem with loaded modules at least.
http://caml.inria.fr/pub/docs/manual-ocaml/toplevel.html#sec278
The ocamlmktop command builds OCaml toplevels that contain user code
preloaded at start-up.
The ocamlmktop command takes as argument a set of .cmo and .cma files,
and links them with the object files that implement the OCaml
toplevel. The typical use is:
ocamlmktop -o mytoplevel foo.cmo bar.cmo gee.cmo
This creates the bytecode file mytoplevel, containing the OCaml
toplevel system, plus the code from the three .cmo files. This
toplevel is directly executable and is started by:
./mytoplevel
This enters a regular toplevel loop, except that the code from
foo.cmo, bar.cmo and gee.cmo is already loaded in memory, just as if
you had typed:
#load "foo.cmo";;
#load "bar.cmo";;
#load "gee.cmo";;
on entrance to the toplevel. The modules Foo, Bar and Gee are not
opened, though; you still have to do
open Foo;;
yourself, if this is what you wish.
This has always bothered me too, so I wrote a quick python/expect script to replay ghci_history at the beginning of each ghci session.
It's not very polished. For example it always replays the whole history and that could be slow.