I am new to Clojure, and I am usually using it from (Spac)emacs, where the repl formats fine. However, when I try to use the repl within a gnome-terminal, then the formatting is broken, i.e. after 'sending' some code, the line of code gets 'reformatted' as shown in the screencast below:
Anybody has some idea what is going on here? The terminal is just a basic 'gnome-terminal' on Fedora.
B.t.w. the same screencast is used for reporting an issue with criterium about the bench example hanging.
Disclaimer: this is not a solution to the problem, but it shows,
where the problem lies and what are workarounds.
TL;DR: call clojure (which does not use rlwrap¹; use
Rebel-Readline
instead, for more features
clj calls clojure, but checks, if rlwrap is installed and uses
that to call clojure with some settings, that are suitable for a Lisp.
rlwrap is a great tool, to get readline capabilities with
interactive CLI tools, that don't have it (e.g. emacs/vi-mode, history,
"hippy" completion). But in this case it is the culprit to smash up the
REPL. What's underlying problem is not clear, but in cases like this
the options usually are: buggy software (the terminal, rlwrap, or the
way Clojure interacts with the terminal), wrong/buggy TERM settings or
term-capabilities.
That said, rlwrap might be the "just good enough" option here
anyway. First of all Clojure developers tend to use the REPL via the
editor anyway. Second there is a far superior option to get what
rlwrap brings to the table:
Rebel-Readline
Beside emacs/vi-modes and history it brings (and probably more):
syntax highlighting for both input and output (with pretty-printing)
multi-line edit in the REPL
proper auto-completion
showing the doc-string of the function under the cursor
¹) From: https://github.com/hanslub42/rlwrap
rlwrap is a 'readline wrapper', a small utility that uses the GNU Readline library to allow the editing of keyboard input for any command.
This is a rlwrap bug that has been fixed upstream (but, as of now, is still open in several distributions) . In a nutshell, either:
use a recent rlwrap (0.46-1 or newer),
or avoid the very newest readline (8.2 or newer),
or put set enable-bracketed-paste off in your inputrc
See this bug report on Github (or this summary of the history of this issue)
Hans Lub (rlwrap maintainer)
Related
I'm trying to debug a large C++ project on Linux remotely, which is a little difficult to re-build via Visual Studio locally. Therefore I attempt to debug it via console. While, the gdb or gdb --tui or gdb-dashboard tools is not convenient for interaction. I think pudb is a tool for python in the term of interaction. Therefore, are there any better text UI debuggers via console for C++?
Thanks for telling me the tools or any suggestion, I will really appreciate it!
pudb is awesome and you can drop into an IPython terminal at any time with the current local variables. You probably won't get that level of interaction in C++ anytime soon. But gdb is very powerful and using the TUI plus some pretty-printers is definitely very usable, even in larger projects.
It helps if you read the documentation and learn some tricks, such as using gdb's convenience variables. You can store an object in a convenience variable when it is in scope and access it later to check its state using the convenience variable (as long as it still exists).
Using breakpoint commands and a .gdbinit file with repetitive commands also helps a lot.
If you want to implement pretty printers for some of you classes, I think looking at other people's code is a great way to start. Here you can see some pretty printers for some classes in the armadillo library (used for linear algebra).
I'm having trouble getting started with ASDF and Common Lisp.
How can I get a minimal example working?
To answer my own question:
So, how to do your "Hello World!" with ASDF build system? Here's what worked for me. I'll help you side-step the time-consuming traps that I fell into.
Watch this video. He explains installation of sbcl, emacs, quicklisp (a Lisp library manager), slime, and quickproject, which sets up a project with ASDF.
Now to side-step a few traps:
slime didn't seem to work with clisp. I had to use scbl. Note, I'm on ubuntu 16.04.
You must have your .asd file in the path of your ASDF system. You can accomplish this by working in ~/common-lisp/; if you don't have it you can make it. See here to setup ASDF to look in other directories.
Once you have they system built, load the system with (asdf:load-system :<system>). Also, to access functions in a different package, use the following syntax: (<package>::<function> ...).
Happy coding.
For vim users: Emacs and Lisp, specifically with quicklisp and emacs's package manager, is a beautiful combination. Probably because Emacs is written in Lisp. I see the value of this. But I'm a vim user. I was pleased to find Evil, a great vim layer for emacs. Check out this 4 minute video, which impressed me. Also, here is a post of another vim user setting it up to be like his vim environment, better in some cases. I now think the combination of emacs and vim is better than either alternative.
I have been learning Clojure a bit recently. Is there such a thing in Clojure world as Scala-like worksheets, into which I can put any code and get it evaluated as soon as I save it? Or maybe there's a similar solution for Clojure?
I am now working with lein repl and, sadly, can't say it's the most usable tool ever.
In Lisp development in general (and Clojure in particular) the preferred programming style is what's usually dubbed interactive programming - the developer keeps an image of the app loaded at all times and interacts with it via a REPL. You can easily modify the loaded code on the fly and test changes immediately in the REPL (that's not easy at all with Scala - one has to resort to something like JRebel to do it). I find the Scala worksheets a pretty primitive solution in comparison...
The workflow that I follow in Clojure is:
I open nREPL.el in Emacs - this loads my lein2 project with all of its dependencies and gives me a REPL which I can use the try out stuff
I write some code in source code and load the changed functions (maybe by evaluating a top level form with C-M-x
Afterwards I'd press C-x C-z to jump back to the REPL and I try out the new code in it
I go back to step 2
Basically the Clojure REPL is much more powerful than the Scala REPL and I personally consider it hugely superior to the Scala IDE worksheets. Once you get used to the interactive incremental style of programming Lisp offers everything else starts to look strangely complex by comparison. I'm not familiar with Eclipse's CounterClockWise Clojure plugin, but I'm pretty sure it offers similar functionality to Emacs's nREPL.el.
You might want to take a look at the autoexpect plugin for Leiningen. Every time you save any file in the working directory, the plugin compiles and runs your code; as a bonus, it will evaluate any "expect" function calls which can serve as tests. This is very helpful for test driven development and is a nice compliment to working with the REPL as described in the other answer (I often use one or the other or both together depending on how many test cases I have in place).
I should note that running autoexpect is far faster than running "lein test" or "lein run" repeatedly, due to the startup cost of the JVM and Leiningen.
It sounds like what you are looking for is the Clojure Koan plugin. This a worksheet-style problem-solving exercise tool that watches your edits and provides instant feedback on the correctness of your work.
For actual development workflow I second the advice others here have provided on tooling and interactive environment setup, but since you specifically said you are learning Clojure, this can be a fun approach. There is also a web application called 4Clojure that you might have fun playing with.
However you will eventually (or right away) want to get a smooth and convenient development environment set up, and I haven't seen any mention so far of a few important tools. One person mentioned Nrepl. If you like Emacs, there's a slime/swank-like interaction mode that jacks into nrepl called nrepl.el that provides very nice integration between editing files and messing around in the repl. Similarly there is VimClojure, and you can find plugins for IntelliJ (LaClojure) and Eclipse (Counterclockwise) that are also popular and well-maintained.
Someone mentioned autoexpect. If you are looking for a good TDD setup, I would recommend midje. If you are using a 2.0 preview release of leiningen there are a few issues with the lazytest integration being in flux, and lazytest itself is or should be deprecated. But I prefer midje over expectations, personally, and these problems will surely be worked out in the 2.0 release of lein-midje. The stable version of lein-midje that works with the non-preview (1.x) leiningen has autotest-like functionality using lazytest.
As nobody has mentioned it, cursive is really nice these days, although I was sad to move back to a full blown IDE. You can easily do the same thing as Emacs with the built in repl, just move into the namespace that you are working with and synchronise every time you make changes. It's a really nice way of working.
can someone be kind enough to direct me to emacs tutorials for large C++ project using gdb as debugger, the project does contain make file.
I did search for emacs tutorials but some are too advanced for beginners and some only target one single file tutorial. I did read the previous posts too but did not find an answer suitable for large projects. Also I am not used to using 'git', one of the answers in previous posts.
Actually, learning Emacs is a thing that just can't be easy. You'll have to learn the basics before you will be able to read "advanced" tutorials.
The first thing you should do is to work through the builtin tutorial (C-h t). It's really good.
Then you should try to familiarize yourself with Emacs configuration basics. The easy way suggested by many users is to get a ready-for-use configuration (such as Emacs Starter Kit) and try to understand it and then tailor to your own needs and preferences. The advantages of using a ready-made configuration kit are:
It's a working code useful for learning the basics of Elisp. This learning path is way faster than reading Elisp manuals and gathering configuration code one small piece at a time.
It demonstrates a lot of useful Emacs features which otherwise might require you long time (sometimes years) to discover.
It offers a framework which you can base on writing your own configuration.
Still you should undoubtedly get rid of whatever parts of configuration you don't need.
Then (or along with the previous step) read some tutorial about using Emacs as a development platform. You can easily find a lot of tutorials via "emacs for [c] development" queries to Google. Here is one of many.
Then install Cedet (Alex Ott has written a great tutorial about it) and start feeling the power.
After that you'll know what to do next.
By the way, there is a great collection of Emacs resources maintained by Bozhidar Batsov.
Start simple. Launch Emacs without any customisations and start editing your source files. The only "tutorial" you'll need to do basic editing is the inbuilt one you'll get by hitting Control H followed by t (Referred to as C-h t in Emacs speak).
Compiling can be done by typing M-x (Alt x) compile and hitting enter. It will prompt you for the compile command which is by default make. Change it to whatever suits you.
Running gdb is done using M-x gdb and hitting enter. The interface is similar to the M-x make.
Don't use things like the Emacs starter kit which makes assumptions on your behalf. While useful as a starting point for newbies, it suppresses curiosity and that's the key to learning Emacs. The above things should be enough for you to start. Once you hit problems and are not satisfied with the ways of doing things, you can search for resources and things. Emacs is not an "IDE" and so you won't have the tight integration which many custom editors have. Don't expect it.
I'm doing my first steps with Clojure, but for some reason the up/down keys don't allow me to step through the command history in the REPL like in REPLs of other languages. Does the Clojure REPL use different keys to access the command history, or is this feature just not (yet) implemented?
If you are, by any chance, using a Unix-like environment you can use rlwrap to to achieve nice things like command line history and Ctrl-R for searching through it.
Just prepend your command which you use to start repl, e.g:
rlwrap java -cp clojure.jar clojure.main
Or use Leiningen or Cake. Either of these are useful in general, and you'll be happy to learn to use them, but specifically they use readline or jline automatically where available.
You can enhance the REPL to do this by using JLine, see here.
Depends which REPL you use. Most good REPLs have this functionality and more.
If you're coming from Java as an Eclipse user, for example, you may want to use the embedded nREPL provided by the Counterclockwise plugin. I found this easier to use than configuring a separate dedicated Clojure environment.
C-, M-x slime-repl-forward-input
C-, M-x slime-repl-backward-input
Go to the next/previous history item.
http://common-lisp.net/project/slime/doc/html/Input-Navigation.html