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.
Related
I'm trying to figure out which language is used in Linux scripts to make the system more personal? I mean things like you put in the dotfiles — like .vimrc, or .zshrc — or to make a function for the terminal (like one that compiles a .tex file with bibtex and then pdflatex and then opens that .pdf with some reader).
What you call dotfiles are just configuration files of one or another program. So the "language" of each of those configuration files depends on the program that is going to use it.
In fact, that doesn't have to be a language, in general, hence the quotes in the previous paragraph. Those config files just have to match the format that the program that uses them expects. This occasionally means that configuarion files are required to use a specific language; an example is .vimrc, which has to use the vimscript language (aka VimL).
I think the term "Linux Scripts" will cause misunderstandment in here.
These dotfiles have a particular syntax for each one, but it's not a programming language.
It's allways a good idea to read the official documentation.
https://www.vim.org/docs.php
https://www.zsh.org/
For vimscript learning, I had a good experience with this one:
https://learnvimscriptthehardway.stevelosh.com/
I have recently switched from vim to Emacs. In which, apparently, the standard workflow is always staying in one running instance with multiple opened files. (I'm not yet convinced this is really superior to the alternative I'm used to, "quit-grep-vi-edit-quit-compile etc." or multiple terminal windows / tabs, but at least I'm giving it a try. Anyway...)
So for compiling a file/project, the usual thing to do seems M-x compile (or shotcuts to it). That lets you specify a compilation command, by default offering make -k. Which may be a reasonable guess for the project most Emacs hackers tend to do; but in Haskell I obviously tend towards cabal, no makefiles at all. And even when I specify cabal build, it doesn't work because the command is executed from the file's directory, which is not where the .cabal file is.
At the moment, I find myself counting the module-hierarchy depth and typing
M-x "compile" Enter Bckspc Bckspc ... "cd ../../../; cabal build" Enter
this doesn't feel right!
Is there some nicer alternative, or should I just go back to my old workflow even though it's not idiomatic Emacs usage?
Set the default compile command to something more your style:
(setq compile-command "cabal build")
Before the first time you compile, if you’re not in the right directory, you can use the cd function to change the current working directory. Thereafter, you can just hit g in the *compilation* buffer to recompile, or bind the recompile function to a key you like.
I typically work with code on one side of the screen and the compile buffer on the other; C-x ` will take you to the next error, and M-n and M-p navigate by errors within the compile buffer.
I've added logic in Emacs to automatically call browse-url on a DMD generated html documentation file upon completion of a special build finish hook I've written.
In order for this to be usable I now want this call to only open a new browser tab the first time it is called and the rest of the times only reload the tab already showing the the doc file.
Is this possible, preferrably in Google Chrome?
I've scanned command line arguments for both GC and FF but have found nothing.
I suspect some Javascript/HTML-5 may do the trick but I know nothing about that.
For Firefox look into browse-url-firefox-new-window-is-tab and / or browse-url-maybe-new-window. You could follow the execution path from the definition of browse-url-default-browser, all in the browse-url.el.
But the basic idea is that you could just look at how, for example, browse-url-firefox is implemented, write the one that does exactly what you want (launches Firefox in the way that you need), and set it to be the browse-url-browser-function. The value of this variable must be a function which is called from browse-url.
What is interesting (perhaps something similar is available in Google Chrome), there's MozRepl, obviously, it will run in Mozilla browsers, and there's a binding for Emacs to talk to this REPL (interactive JavaScript interpreter). Using that you can have very fine-grained control over the behaviour of the browser, including, but not limited to creating new GUI components (using XUL), manipulating browser windows and so on. Would probably depend on how much time you are willing to spend on it.
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.
It is a simple question to which I am not able to find the answer:
Given a LaTeX command, how do I find out what package(s) it belongs to or comes from?
For example, given the \qquad horizontal spacing command, what package does it come from? Especially troublesome since it works without including any package!
Given a LaTeX command, how do I find out what package(s) it belongs to or comes from?
Consult your references:
If it's in the index to the TeXbook, it's inherited from TeX, the engine that drives LaTeX.
Otherwise, if it's in the index to the LaTeX manual, it's probably defined in latex.ltx or in one of the standard class files, not in a package.
Otherwise, if it's in the index to The LaTeX Companion, the page number probably tells you what package it's from.
Otherwise, you could do some fancy grepping on the results of find /usr/share/texmf -name '*.sty', but be prepared for a painful exercise.
Or, you could ask on http://stackoverflow.com. But then some idiot will respond by asking why you want to know...
You can search http://www.ctan.org/tex-archive/info/symbols/comprehensive/ for that information and more.
Remember that LaTeX is a macro language on top of TeX, and all the macros are made up of TeX which doesn't need to be imported. \qquad is in that category.
As far as I know, there is no really good general answer to this. But there are a number of techniques you might try for any given command. In the case of \qquad, it's part of basic TeX. Remember that you can always use TeX in interactive mode:
$ tex '\show\qquad'
This is TeX, Version 3.141592 (Web2C 7.5.6)
> \qquad=macro:
->\hskip 2em\relax .
\show\qquad
? x
No pages of output.
Some macros are added by LaTeX on top of TeX, such as \begin:
$ tex '\show\begin'
This is TeX, Version 3.141592 (Web2C 7.5.6)
> \begin=undefined.
\show\begin
? x
No pages of output.
whereas
$ latex '\show\begin'
This is pdfTeXk, Version 3.141592-1.40.3 (Web2C 7.5.6)
%&-line parsing enabled.
entering extended mode
LaTeX2e
Babel and hyphenation patterns for english, usenglishmax, dumylang, noh
yphenation, greek, monogreek, ancientgreek, ibycus, pinyin, loaded.
> \begin=macro:
#1->\#ifundefined {#1}{\def \reserved#a {\#latex#error {Environment #1 undefine
d}\#eha }}{\def \reserved#a {\def \#currenvir {#1}\edef \#currenvline {\on#line
}\csname #1\endcsname }}\#ignorefalse \begingroup \#endpefalse \reserved#a .
\show\begin
? x
No pages of output.
Everything else comes from packages. If you really wanna know which package a macro comes from (other than by google or grepping your texmf tree), you can check after each package you load whether it's defined. Try defining this before any \usepackage commands:
\let\oldusepackage\usepackage
\renewcommand\usepackage[1]{
\oldusepackage{#1}
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #1^^J}
\let\usepackage\oldusepackage
\fi}
Then when you run latex on your .tex file, look for a line in the output that says includegraphics is defined in graphicx. It's not likely, but some devious packages might do bad things with \usepackage so there's a chance this might not work. Another alternative would be to simply define the command you're interested in before loading any packages:
\newcommand\includegraphics{}
Then you might get an error message when the package that defines the command is loading. This is actually less reliable than the former approach, since many packages use \def and \let to define their macros rather than \newcommand, bypassing the "already-defined" check. You could also just insert a check by hand in between each load: \ifcsname includegraphics\endcsname\message{^^Jdefined after graphicx^^J}\fi
Due to lack of reputation I cannot comment on Steve's answer, which was very helpful to me, but I would like to extend it a bit.
First, in his second approach (fiddling with usepackage) the case where usepackage has optional arguments is not dealt with. Secondly, packages are often loaded by other packages via RequirePackage which makes it hard to find the actual place of definition of a command. So my refinement of Steve's answer is:
\usepackage{xargs}
\let\oldusepackage\usepackage
\let\oldRequirePackage\RequirePackage
\renewcommandx{\usepackage}[3][1,3]{
\oldusepackage[#1]{#2}[#3]
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #2^^J}
\let\usepackage\oldusepackage
\let\RequirePackage\oldRequirePackage
\fi}
\renewcommandx{\RequirePackage}[3][1,3]{
\oldRequirePackage[#1]{#2}[#3]
\ifcsname includegraphics\endcsname
\message{^^Jincludegraphics is defined in #2^^J}
\let\usepackage\oldusepackage
\let\RequirePackage\oldRequirePackage
\fi}
The xargs package is used here to get the unusual options of usepackage right (first and third parameter are optional).
Putting this directly after documentclass should tell where includegraphics is defined.