After defining variables, functions, etc., can you save what you have done on the REPL too an text .clj file?
most people work with the repl through an editor such ad Eclipse/Emacs/vim and that editor has the ability to save the repl, though without some diligence on the developers part this will likely be an incomplete record of what happened. Some of the state of the repl may have come from loading files etc which will be in a different state.
So the short answer is typically not.
In Linux (mine = Ubuntu 16.04.2 LTS) if you are using lein then check for .lein (hidden directory) and look for repl-history. You should find the commands that you have typed or pasted into the REPL. This can be a source for later edit - I use geany...
I am answering the parenthetical part of your question. For me, the Clojure REPL is very useful for testing functions and proving out concepts that take no more than a few lines. I will often put hooks in a module that is not the main, just so I can load a file and run it through a couple of functions. I can also do this from main using the same mindset; that is write a debug function.
I found the Eclipse plugin to be quite useful, but I do not use it much these days, mostly Vim and running the module with one or more special functions and running the main. I don't know of any way to save REPL state.
Related
I've been hacking away at the 4clojure.com problem set and having a lot of fun. I've done a few dozen of the Elementary and Easy level problems.
However, my "development" environment for this work leaves something to be desired. Basically, I'm writing one-liners, either in the Leiningen REPL or Sublime Text's "SublimeREPL" for Clojure.
I'd like to be able to unpack those one-liners as I work (few solutions need to be longer than a few lines that I've seen so far, but one line is pretty condensed at least for my newbie eyes).
My desired workflow is, as I implied in the title, is to have a single file for each solution, and to be able to iteratively hack on it, save it, run it and see the output.
I'm on OS X and Ubuntu; my primary editor is Sublime Text, but I do use Emacs as well. CIDER perhaps?
Emacs with, as Charles suggests, either the Emacs Live config or Emacs Prelude (or mine).
Open a file, hack away, and run
Ctrl-cAlt-j to start up a clojure repl through Cider (nrepl's replacement)
Ctrl-cC-k to load the file
Ctrl-cAlt-n to put the repl in that namespace,
and hack away.
And if you're installing Emacs Live you might as well play with Overtone and make some "music"
Currently I am calling an R script from C++ in the following way:
system("PATH C:\\Program Files\\R\\R-3.0.1\\bin\\x64");
system("RScript CommandTest.R");
Where CommandTest.R is my script.
This works, but is slow, since I need a particular package and this method makes the package load on every call.
Is there a way to load the package once and then keep that instance of Rscript open so that I can continue to make calls to it without having to reload the package every time?
PS: I know that the 'better' method is probably to go with Rcpp/Rinside, and I will go down that route if necessary, but I thought it'd be worth asking if there's an easy way to do what I need without it.
It seems like the Rserve package is what you seek. Basically it keeps open a "server" which can be asked to evaluate expressions.
It has options for Java, C++ and communication between one R session and another.
In the documentation, you might want to look at run.Rserve and self.ctrlEval
I'm not aware of a solution to keeping R permanently open, but you can speed up startup by calling R with the --vanilla option. (See Appendix B.1 of Intro to R for more options.)
You could also try accessing the functions using :: to save completely loading the package. (Try profiling to see if that really saves you much time. Is the package load actually the slow part of your analysis?)
So I have been working on a Clojure tutorial and it's pretty fun so far. Unfortunately, every time I close my REPL out, I lose all of the defn and def that I created in the previous session.
So, to save time in the future, is it possible to have the Clojure REPL save everything I've typed to a file so I can dig out what I need for future uses?
I think most people work by using their IDE to send fragments of code to the REPL, rather than doing a lot of direct hacking in the REPL. This way you have a better idea of the current state of the program.
If you use Emacs and SLIME, you can save the REPL buffer to a file just like saving any other buffer.
If you are using a Unix-like operating system you can start your REPL using rlwrap. This would give you Ctrl-R for accessing commands from history in an easy way, as well as storing the history itself.
You'd just have to install rlwrap and prepend it to the line where you start REPL, e.g. rlwrap lein repl
Couple of tips:
I do a lot of coding in the REPL, but as soon as I write something that works then I copy/paste it into a source file. Then I can just run or reload that source file whenever I want to get a REPL environment back to a fully configured state.
Some REPLs (e.g. the Eclipse Counterclockwise REPL that I use) keep history from previous sessions so you can up-arrow to the earlier REPL commands you want to repeat.
This is actually a harder problem than it seems because a dump like this must take into account symbol and vars dependencies and output to file in the correct order of symbols. That said since code is data one should be able to write a function that does that.
Clojure has introduced me to the concept of Lisp syntax, and I'm interested, but it's a pain to get the Clojure repl set up and use it on different machines. What other resources are there out there for actually on-the-fly testing and playing with Lisp syntax?
I'm imagining something like a website where you can input rudimentary code, or a browser add-on, or even just a standalone application that steps you through Lisp (something that runs on Linux/Ubuntu).
Haven't been able to find anything like that to start me off in a simple/accessible way.
The SISC Online REPL is exactly what you need. It accepts Scheme syntax, which is a variant of Lisp.
For a standalone app I like PLT Scheme because it seems to work the same on every platform I've tried. I was previously using MIT Scheme on Ubuntu, but decided to switch when I bought a new machine with 64-bit Vista installed.
At the risk of losing all of my rep points, try newlisp.
I've used LispBox in the past. Easy to set up and get going, but I have to admit that Emacs is second nature to me. If you're unfamiliar with that, you may can use another editor, but getting intimate with Emacs will help you live comfortably in Lispville.
It's not hard to get to a Clojure REPL nowadays.
Go to http://build.clojure.org/ and download clojure.jar.
Install a JVM.
java -jar clojure.jar
This should work on any machine that has a JVM installed.
For more fun, install rlwrap and use rlwrap java -jar clojure.
For learning Lisp the LispWorks personal edition is fine: LispWorks downloads. There are versions for Mac OS X, Windows, Linux and FreeBSD. All have the same user interface capabilities and this includes an editor and listener - plus lots of other tools. On Linux and FreeBSD in currently (LispWorks 5) uses X11/Motif for the GUI - this will change in a future version (LispWorks 6) to GTK. So to run it now under Linux, you need to have the Motif lib installed. Other than that using it is relatively painless. There are some restrictions to it (only 5 hours runtime, then you need to save and restart, ...) and the full version is commercial. But for learning some Lisp basics, it is quite good.
Franz has an online REPL for Allegro Common Lisp.
http://www.franz.com/products/allegrocl/prompt/
codepad.org is a nice simple online way to enter and run code (in many different languages, including Scheme). I use it all the time for testing out snippets of code to use in SO answers.
I won't edit Lisp code without an editor that does what Emacs will do with the following configuration:
(define-key lisp-mode-shared-map "[" 'insert-parentheses)
(define-key lisp-mode-shared-map "]" 'move-past-close-and-reindent)
The former inserts balanced parentheses. If you give it a numeric prefix argument, it inserts that many nested pairs. By default, it inserts one. If you have a text region marked, it encloses that region in the innermost inserted pair. That means that you'll never open a parenthesis that's not closed.
The latter is harder to explain, as it's used less frequently. It's more of a navigation command than an insertion command. It confirms that you're done editing the current form and moves the cursor up, out, and past it, preparing for the next likely insertion.
With these keys bound, one no longer needs to use the Shift key to access the parentheses. Also, this leaves the parentheses keys bound as normal, for when sexp repair or a literal parenthesis character is required. I stole the bracket keys because they're used so infrequently in Emacs Lisp and Common Lisp. The bracket characters are still accessible with meta key bindings:
(defmacro make-key-inserter (def)
"Substitute for `self-insert-command'."
`(lambda (arg)
(interactive "*P")
(insert-char ,def (prefix-numeric-value arg))))
(define-key lisp-mode-shared-map "\M-[" (make-key-inserter ?\[))
(define-key lisp-mode-shared-map "\M-]" (make-key-inserter ?\]))
It's not essential to use Emacs, but don't settle for less with another editor that can't at least match this capability. There's also a whole family of commands for navigating and manipulating the sexp tree as a tree. Understanding why that's valuable will require you to fumble around for a while until you stop seeing syntax and start seeing the tree.
Since you're using Ubuntu, I'd just install some of the packages and give them a try.
Common Lisp: apt-get install clisp
Scheme: apt-get install drscheme
These aren't the only packaged implementations, but maybe the easier to get started with. You'll be able to play at a REPL and also run your own scripts through the interpreter.
BioBike provides a full Common Lisp evaluator through the web (with extras like a knowledge representation system, biocomputing, and an alternative visual langauge as well).
If you just want to play with LISP, interactively, quickly, GNU Emacs has a LISP interpreter built in, and listening in the *scratch* buffer. Type an S-expression, position immediately after it, and then hit Ctrl-J to evaluate it. Or <ESC>: will put an Eval: prompt in the minibuffer, accept an S-expression, and evaluate it.
You can define functions, using defun, and test things that way. You have access to ALL of the GNU Emacs built-in functions, and anything you have loaded. If you want to keep things around, you can put them in your .emacs file.
https://github.com/fogus/himera
was very easy for me to setup on a https://www.nitrous.io virtual box. Makes a nice web interface.
Downloading and running clojure-1.6.0.jar on my windows (XP) box was as easy as using this script to run the REPL :
java -cp clojure-1.6.0.jar clojure.main
I was going to create the C++ IDE Vim extendable plugin. It is not a problem to make one which will satisfy my own needs.
This plugin was going to work with workspaces, projects and its dependencies.
This is for unix like system with gcc as c++ compiler.
So my question is what is the most important things you'd need from an IDE? Please take in account that this is Vim, where almost all, almost, is possible.
Several questions:
How often do you manage different workspaces with projects inside them and their relationships between them? What is the most annoying things in this process.
Is is necessary to recreate "project" from the Makefile?
Thanks.
Reason to create this plugin:
With a bunch of plugins and self written ones we can simulate most of things. It is ok when we work on a one big "infinitive" project.
Good when we already have a makefile or jam file. Bad when we have to create our owns, mostly by copy and paste existing.
All ctags and cscope related things have to know about list of a real project files. And we create such ones. This <project#get_list_of_files()> and many similar could be a good project api function to cooperate with an existing and the future plugins.
Cooperation with an existing makefiles can help to find out the list of the real project files and the executable name.
With plugin system inside the plugin there can be different project templates.
Above are some reasons why I will start the job. I'd like to hear your one.
There are multiple problems. Most of them are already solved by independent and generic plugins.
Regarding the definition of what is a project.
Given a set of files in a same directory, each file can be the unique file of a project -- I always have a tests/ directory where I host pet projects, or where I test the behaviour of the compiler. On the opposite, the files from a set of directories can be part of a same and very big project.
In the end, what really defines a project is a (leaf) "makefile" -- And why restrict ourselves to makefiles, what about scons, autotools, ant, (b)jam, aap? And BTW, Sun-Makefiles or GNU-Makefiles ?
Moreover, I don't see any point in having vim know the exact files in the current project. And even so, the well known project.vim plugin already does the job. Personally I use a local_vimrc plugin (I'm maintaining one, and I've seen two others on SF). With this plugin, I just have to drop a _vimrc_local.vim file in a directory, and what is defined in it (:mappings, :functions, variables, :commands, :settings, ...) will apply to each file under the directory -- I work on a big project having a dozen of subcomponents, each component live in its own directory, has its own makefile (not even named Makefile, nor with a name of the directory)
Regarding C++ code understanding
Every time we want to do something complex (refactorings like rename-function, rename-variable, generate-switch-from-current-variable-which-is-an-enum, ...), we need vim to have an understanding of C++. Most of the existing plugins rely on ctags. Unfortunately, ctags comprehension of C++ is quite limited -- I have already written a few advanced things, but I'm often stopped by the poor information provided by ctags. cscope is no better. Eventually, I think we will have to integrate an advanced tool like elsa/pork/ionk/deshydrata/....
NB: That's where, now, I concentrate most of my efforts.
Regarding Doxygen
I don't known how difficult it is to jump to the doxygen definition associated to a current token. The first difficulty is to understand what the cursor is on (I guess omnicppcomplete has already done a lot of work in this direction). The second difficulty will be to understand how doxygen generate the page name for each symbol from the code.
Opening vim at the right line of code from a doxygen page should be simple with a greasemonkey plugin.
Regarding the debugger
There is the pyclewn project for those that run vim under linux, and with gdb as debugger. Unfortunately, it does not support other debuggers like dbx.
Responses to other requirements:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
My BuildToolsWrapper plugin has a g:BTW_run_parameters option (easily overridden with project/local_vimrc solutions). Adding a mapping to ask the arguments to use is really simple. (see :h inputdialog())
work with source control system
There already exist several plugins addressing this issue. This has nothing to do with C++, and it must not be addressed by a C++ suite.
debugger
source code navigation tools (now I am using http://www.vim.org/scripts/script.php?script_id=1638 plugin and ctags)
compile lib/project/one source file from ide
navigation by files in project
work with source control system
easy acces to file changes history
rename file/variable/method functions
easy access to c++ help
easy change project settings (Makefiles, jam, etc)
fast autocomplette for paths/variables/methods/parameters
smart identation for new scopes (also it will be good thing if developer will have posibility to setup identation rules)
highlighting incorrect by code convenstion identation (tabs instead spaces, spaces after ";", spaces near "(" or ")", etc)
reformating selected block by convenstion
Things I'd like in an IDE that the ones I use don't provide:
When I run or debug my compiled program, I'd like the option of having a dialog pop up which asks me for the command line parameters. It should remember the last 20 or so parameters I used for the project. I do not want to have to edit the project properties for this.
A "Tools" menu that is configurable on a per-project basis
Ability to rejig the keyboard mappings for every possible command.
Ability to produce lists of project configurations in text form
Intelligent floating (not docked) windows for debugger etc. that pop up only when I need them, stay on top and then disappear when no longer needed.
Built-in code metrics analysis so I get a list of the most complex functions in the project and can click on them to jump to the code
Built-in support for Doxygen or similar so I can click in a Doxygen document and go directly to code. Sjould also reverse navigate from code to Doxygen.
No doubt someone will now say Eclipse can do this or that, but it's too slow and bloated for me.
Adding to Neil's answer:
integration with gdb as in emacs. I know of clewn, but I don't like that I have to restart vim to restart the debugger. With clewn, vim is integrated into the debugger, but not the other way around.
Not sure if you are developing on Windows, but if you are I suggest you check out Viemu. It is a pretty good VIM extension for Visual Studio. I really like Visual Studio as an IDE (although I still think VC6 is hard to beat), so a Vim extension for VS was perfect for me. Features that I would prefer worked better in a Vim IDE are:
The Macro Recording is a bit error prone, especially with indentation. I find I can easily and often record macros in Vim while I am editing code (eg. taking an enum defn from a header and cranking out a corresponding switch statement), but found that Viemu is a bit flakey in that deptartment.
The VIM code completion picks up words in the current buffer where Viemu hooks into the VS code completion stuff. This means if I have just created a method name and I want to ctrl ] to auto complete, Vim will pick it up, but Viemu won't.
For me, it's just down to the necessities
nice integration with ctags, so you can do jump to definition
intelligent completion, that also give you the function prototype
easy way to switch between code and headers
interactive debugging with breaakpoints, but maybe
maybe folding
extra bonus points for refactoring tools like rename or extract method
I'd say stay away from defining projects - just treat the entire file branch as part of the "project" and let users have a settings file to override that default
99% of the difference in speed I see between IDE and vim users is code lookup and navigation. You need to be able to grep your source tree for a phrase (or intelligently look for the right symbol using ctags), show all the hits, and switch to that file in like two or three keystrokes.
All the other crap like repository navigation or interactive debugging is nice, but there are other ways to solve those problems. I'd say drop the interactive debugging even. Just focus on what makes IDEs good editors - have a "big picture" view of your project, instead of single file.
In fact, are there any plugins for vim that already achieve this?