Вы можете взломать прямо на REPL. Предположим, у вас есть incanter на вашем пути к классу. Запустите REPL. Первое, что нам нужно сделать, это ввести в него классы incanter.
user> (require 'incanter.core)
nil
Теперь мы можем увидеть функцию incanter.core/matrix?
user> (incanter.core/matrix? 2)
false
Мы можем посмотреть на оригинальный исходный код:
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
Пойдемте облажаться:
Первое изменение в incanter.core имен:
user> (in-ns 'incanter.core)
#<Namespace incanter.core>
Затем мы можем переопределить его, используя старый исходный код в качестве кроватки:
incanter.core> (defn matrix? [obj] "hello")
#'incanter.core/matrix?
испытания Единица измерения:
incanter.core> (matrix? 2)
"hello"
переключатель обратно в пространство имен пользователя:
incanter.core> (in-ns 'user)
#<Namespace user>
Попробуйте:
user> (matrix? 2)
; Evaluation aborted.
Там нет определения пользователя/матрицы. Мы переопределили его в пространстве имен incanter.core.
user> (incanter.core/matrix? 2)
"hello"
для экспериментов в REPL, это нормально просто изменить исходные файлы и повторно скомпилировать один файл (CC Ck в Emacs), или если вы находитесь в правильном пространстве имен, просто пересмотреть определение ,
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
Теперь, если мы хотим сделать наше ценное изменение постоянным и доступным для других проектов, это зависит от того, как все настроено.
Я использую maven для управления зависимостями, поэтому было бы вопросом изменения исходного файла, а затем повторного запуска процесса сборки для библиотеки для компиляции новой версии и установки ее в локальный репозиторий maven.
С проектом Maven, который должен быть столь же просто, как
$ mvn install
примечание о номерах версий:
Если вы делаете постоянные изменения и использовать управление зависимостями для координации различий, то вы должны измените номер версии вашей библиотеки, от, возможно, 1.2.0 до 1.2.0-johnshack-SNAPSHOT, или что-то, что вряд ли столкнется с реальной вещью, если вы хотите использовать неревертированную версию в другом проекте. Вы не хотите, чтобы измененная версия находилась в проектах, где это не приветствуется.
Затем вы изменяете свои собственные файлы проекта, чтобы убедиться, что вы используете взломанную версию там, где хотите, и в следующий раз, когда вы начнете замену, она должна вытащить последний взломанный вами пакет.
Вам нужно будет переустановить его каждый раз, когда вы хотите, чтобы ваши изменения вошли в хранилище, но на самом деле это, вероятно, хорошо.
К сожалению, (и именно в этот момент я начал желать, чтобы я выбрал другой пример). Incanter оказывается проектом leiningen, который разбивается на подмодули в виде ad-hoc scripty , поэтому нам нужно выяснить, как он будет установлен. Выяснение оказалось довольно сложным, хотя ответ прост. Лейнинен поджигает мои волосы.
Вы можете получить источник Ведуна здесь:
$ мерзавца клона http://github.com/liebke/incanter.git
и соответствующий исходный файл:
~/Ведун/модули/Ведун-ядро/SRC/Ведун/ядро. clj
Изменить его, чтобы разбить матрицу? а затем выясняется, что вам нужно сделать следующее:
Измените номера версий как на верхнем уровне project.clj, так и в подмодуле project.clj.
Затем вы запускаете установку lein в каталоге incanter-core, а затем снова в каталоге верхнего уровня, и вы должны сделать это в этом порядке. Я не совсем понимаю, почему.
На данный момент все это кажется излишне сложным. Я (честно) уверен, что он успокоится, когда инструменты станут зрелыми.
Или используйте локальный репозиторий Maven – Greg
С Leiningen это можно сделать, используя «lein install». – Mars