You can hack REPL directly. Suppose you have an incanter on your way to a class. Run REPL. The first thing we need to do is include the incanter classes in it.
user> (require 'incanter.core) nil
Now can we see the incanter.core / matrix function?
user> (incanter.core/matrix? 2) false
We can see the source code:
user> (require 'clojure.repl) nil user> (clojure.repl/source incanter.core/matrix?) (defn matrix? " Test if obj is 'derived' incanter.Matrix." ([obj] (is-matrix obj))) nil
Release and screw it:
First change in incanter.core namespace:
user> (in-ns 'incanter.core) #<Namespace incanter.core>
Then we can override it using the old source code as the crib:
incanter.core> (defn matrix? [obj] "hello")
Unit test:
incanter.core> (matrix? 2) "hello"
Return to the username space:
incanter.core> (in-ns 'user) #<Namespace user>
Try:
user> (matrix? 2) ; Evaluation aborted.
No user / matrix definition. We redefined it in the incanter.core namespace.
user> (incanter.core/matrix? 2) "hello"
For experiments in repl, just changing the source files and recompiling one file (CC Ck in emacs) is enough, or if you are in the right namespace, just reevaluate the definition.
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Now, if we want to make our valuable change permanent and accessible to other projects, it depends on how everything is set up.
I use maven to manage dependencies, so I would need to modify the source file and then restart the build process for the library in order to compile the new version and install it in the local maven repository.
With a maven project, this should be as simple as
$ mvn install
Note on version numbers:
If you are making constant changes and using dependency management to coordinate differences, you should change the version number of your library from 1.2 to 1.2.0-johnshack-SNAPSHOT, or something that is unlikely to come across the real thing when You want to use the unverified version in another project. You do not want the modified version to be in projects where this is not welcome.
Then you modify your own project files to make sure that you use the hacked version where you want, and the next time you run your replica, it should extract the last package you hacked.
You will need to reinstall again each time you want your changes to make their way to the repository, but actually this is probably a good thing.
Unfortunately (and it was at that moment that I began to wish for me to choose another example). Incanter turns out to be a leiningen project, which breaks down into sub-modules in the form of ad-hoc scripty, so we need to figure out how it will be installed. Finding out turned out to be rather complicated, although the answer is simple. Leyninen sets fire to my hair.
Here you can get the cracking source:
$ git clone http://github.com/liebke/incanter.git
and the corresponding source file:
~ / Slave / modules / Slave-core / SRC / Slave / core.clj
Change it to break the matrix? and then it turns out that you need to do the following:
Change the version numbers both at the top level of project.clj and in the project.clj submodule.
Then you start the lein installation in the incanter-core directory, and then back to the top-level directory, and you need to do this in that order. I don’t quite understand why.
At the moment, all this seems unnecessarily complicated. I'm (honestly) sure that he will calm down when the tools mature.