irt 1.1.1
Sign up to get free protection for your applications and to get access to all the features.
- data/.gitignore +26 -0
- data/LICENSE +20 -0
- data/README.markdown +589 -0
- data/Rakefile +60 -0
- data/VERSION +1 -0
- data/bin/irt +101 -0
- data/bin/irt_irb +4 -0
- data/bin/irt_rails2 +6 -0
- data/goodies/nano/README +6 -0
- data/goodies/nano/irt.nanorc +86 -0
- data/goodies/vi/README +5 -0
- data/irt.gemspec +29 -0
- data/irtrc +48 -0
- data/lib/irt.rb +143 -0
- data/lib/irt/commands/core.rb +52 -0
- data/lib/irt/commands/help.rb +111 -0
- data/lib/irt/commands/log.rb +52 -0
- data/lib/irt/commands/ri.rb +59 -0
- data/lib/irt/commands/system.rb +102 -0
- data/lib/irt/commands/test.rb +60 -0
- data/lib/irt/differ.rb +87 -0
- data/lib/irt/directives.rb +28 -0
- data/lib/irt/directives/test.rb +84 -0
- data/lib/irt/extensions/irb.rb +45 -0
- data/lib/irt/extensions/irb/commands.rb +42 -0
- data/lib/irt/extensions/irb/context.rb +147 -0
- data/lib/irt/extensions/kernel.rb +18 -0
- data/lib/irt/extensions/method.rb +36 -0
- data/lib/irt/extensions/object.rb +7 -0
- data/lib/irt/hunks.rb +111 -0
- data/lib/irt/init.rb +1 -0
- data/lib/irt/log.rb +94 -0
- data/lib/irt/session.rb +59 -0
- metadata +167 -0
data/.gitignore
ADDED
@@ -0,0 +1,26 @@
|
|
1
|
+
## MAC OS
|
2
|
+
.DS_Store
|
3
|
+
|
4
|
+
## TEXTMATE
|
5
|
+
*.tmproj
|
6
|
+
tmtags
|
7
|
+
|
8
|
+
## EMACS
|
9
|
+
*~
|
10
|
+
\#*
|
11
|
+
.\#*
|
12
|
+
|
13
|
+
## VIM
|
14
|
+
*.swp
|
15
|
+
|
16
|
+
## PROJECT::GENERAL
|
17
|
+
coverage
|
18
|
+
rdoc
|
19
|
+
pkg
|
20
|
+
|
21
|
+
## Eclipse
|
22
|
+
.loadpath
|
23
|
+
.project
|
24
|
+
|
25
|
+
tutorial/
|
26
|
+
test/
|
data/LICENSE
ADDED
@@ -0,0 +1,20 @@
|
|
1
|
+
Copyright (c) 2010-2011 Domizio Demichelis
|
2
|
+
|
3
|
+
Permission is hereby granted, free of charge, to any person obtaining
|
4
|
+
a copy of this software and associated documentation files (the
|
5
|
+
"Software"), to deal in the Software without restriction, including
|
6
|
+
without limitation the rights to use, copy, modify, merge, publish,
|
7
|
+
distribute, sublicense, and/or sell copies of the Software, and to
|
8
|
+
permit persons to whom the Software is furnished to do so, subject to
|
9
|
+
the following conditions:
|
10
|
+
|
11
|
+
The above copyright notice and this permission notice shall be
|
12
|
+
included in all copies or substantial portions of the Software.
|
13
|
+
|
14
|
+
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
|
15
|
+
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
|
16
|
+
MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
|
17
|
+
NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE
|
18
|
+
LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
|
19
|
+
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION
|
20
|
+
WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
|
data/README.markdown
ADDED
@@ -0,0 +1,589 @@
|
|
1
|
+
# irt
|
2
|
+
|
3
|
+
Interactive Ruby Tools - Improved irb and rails console with a lot of easy and powerful tools.
|
4
|
+
|
5
|
+
## What is IRT?
|
6
|
+
|
7
|
+
IRT is an improved irb / rails console (for rails 2 and 3) that adds a lot of features to the standard irb.
|
8
|
+
If you use IRT in place of irb, you will have all the regular irb/rails console features, plus a lot of tools
|
9
|
+
that will make your life a lot easier.
|
10
|
+
|
11
|
+
### Powerful and easy
|
12
|
+
|
13
|
+
- clean colored output for easy reading
|
14
|
+
- 3 types of sessions: interactive, inspecting and binding
|
15
|
+
- irb opening from your code as binding session
|
16
|
+
- contextual ri doc with completion
|
17
|
+
- recording of session steps with filtering
|
18
|
+
- easy testing based on recorded steps
|
19
|
+
- easy in place opening of backtraced files
|
20
|
+
- in place editing with syntax highlight
|
21
|
+
- visual comparing tool and navigation aids
|
22
|
+
- system and session shortcuts... and much more
|
23
|
+
|
24
|
+
### Testing made easy
|
25
|
+
|
26
|
+
IRT records all the steps of your interactive session with irb (or rails console), and can re-run
|
27
|
+
them as tests. In practice, if you use IRT properly, when you are done with your code, you are done with
|
28
|
+
your tests.
|
29
|
+
|
30
|
+
### Fixing made easy
|
31
|
+
|
32
|
+
Don't you feel frustrated when a traditional test fails, printing a bunch of stuff difficult
|
33
|
+
to distinguish, and showing NOTHING about the test code that produced the failure?
|
34
|
+
|
35
|
+
When something fails IRT assumes that you don't want just to know that something went wrong,
|
36
|
+
but that you actually want to fix it! IRT assumes that...
|
37
|
+
|
38
|
+
- you want to know exactly what the resulting diffs are
|
39
|
+
- you want to look at the code that failed without having to search for it
|
40
|
+
- you want to play with it IMMEDIATELY in an interactive session, right in the context of the failure
|
41
|
+
- you want to eventually edit and possibly fix it, right in the console
|
42
|
+
- you want to rerun the fix right away, without waiting for the end of the whole suite
|
43
|
+
|
44
|
+
### Feedback!!!
|
45
|
+
|
46
|
+
This is feedback-driven software. Just send me a line about you and/or what you think about IRT:
|
47
|
+
that will be a wonderful contribution that will help me to keep improving (and documenting) this software.
|
48
|
+
|
49
|
+
My email address is ddnexus at gmail.com ... waiting for your. Ciao.
|
50
|
+
|
51
|
+
## Try the Tutorial first!
|
52
|
+
|
53
|
+
You can have a quick enlightening look (with a lot of screenshots) by reading the [IRT Tutorial](https://github.com/ddnexus/irt/raw/master/irt-tutorial.pdf "IRT Tutorial")
|
54
|
+
first, then if you want more details you can read this documentation.
|
55
|
+
|
56
|
+
## Installation
|
57
|
+
|
58
|
+
$ [sudo] gem install irt
|
59
|
+
|
60
|
+
### Executable Usage
|
61
|
+
|
62
|
+
$ irt --help
|
63
|
+
|
64
|
+
### Command/Directives Usage
|
65
|
+
|
66
|
+
>> irt_help
|
67
|
+
|
68
|
+
## Colored and Styled Output
|
69
|
+
|
70
|
+
This is a nice feature, enabled by default in the terminals that support it, that is really
|
71
|
+
helpful to visually catch what you need in the mess of the terminal input/output.
|
72
|
+
|
73
|
+
IRT uses colors consistently, so you will have an instant feedback about what a text or a label is referring to.
|
74
|
+
|
75
|
+
- __cyan__ for files, saved values (and object 'a' in a diff)
|
76
|
+
- __magenta__ for interactive sessions
|
77
|
+
- __black/white__ for generic stdin/stdout and inspecting sessions (e.g. 'irt my_obj')
|
78
|
+
- __blue__ for the Virtual Log and generic labels
|
79
|
+
- __yellow__ for result echo (not setting last value), for binding sessions and for tests with diffs
|
80
|
+
- __green__ for result echo (setting last value) (and object 'b' in a diff)
|
81
|
+
- __red__ for erros, exceptions and rerun
|
82
|
+
|
83
|
+
Besides IRT is using reversed and bold styles to compose a more readable/graphical output.
|
84
|
+
|
85
|
+
### ANSI colors for Windoze
|
86
|
+
|
87
|
+
The Windoze shell does not support ANSI escape codes natively, so if dumping Windoze is a luxury that you
|
88
|
+
cannot afford, you could use another shell (e.g. the bash that comes with git for windows works), or you can
|
89
|
+
enable it unless you are running Windows 7 (which has still no known ANSI support at the moment of this writing).
|
90
|
+
|
91
|
+
If you want to enable it there is an [official Microsoft page](http://support.microsoft.com/kb/101875 "How to Enable ANSI.SYS in a Command Window")
|
92
|
+
about that matter, or you can eventually find useful this
|
93
|
+
[simple tutorial](http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/UserTips/Miscellaneous/CommandInterpreterAnsiSupport.html "Command Interpreter Ansi Support").
|
94
|
+
|
95
|
+
## Sessions / Modes
|
96
|
+
|
97
|
+
There are 4 irt modes / session types: file, interactive, inspect, binding.
|
98
|
+
|
99
|
+
### File Mode (cyan)
|
100
|
+
|
101
|
+
IRT always start in file mode, which simply means that it will execute the code in a file.
|
102
|
+
Indeed you launch irt passing a path argument of one or more existing files or dirs. If any path does not refer
|
103
|
+
to any existing file, irt will ask you to confirm that you want to create that file. Eventually
|
104
|
+
if you don't pass any path argument, irt will create a temporary empty file.
|
105
|
+
|
106
|
+
A new or temporary created file contains just one statement: 'irt' which will open an interactive session.
|
107
|
+
|
108
|
+
Notice: When you pass a dir as the path, irt will recursively execute all the '.irt' files in it, so suffixing
|
109
|
+
with '.irt' the files is not just a convention. It allows to skyp any non .irt file, like libraries or files
|
110
|
+
used with the 'insert_file' directive.
|
111
|
+
|
112
|
+
#### Note about new files
|
113
|
+
|
114
|
+
The new created files are implicitly run with the -i (--interative-eol) flag by default.
|
115
|
+
That flag instruct irt to open an interactive session at the end of the file, so you will have the possibilty
|
116
|
+
to add your statements. As long as you rerun the file (with the 'rr' command) IRT will remember the flag,
|
117
|
+
anyway, if the session ends and you have to re-launch it from the command line, you must pass the -e flag
|
118
|
+
explicitly or no interactive session will be opened automatically.
|
119
|
+
|
120
|
+
You can save any running file as another file with the 'save_as' command.
|
121
|
+
|
122
|
+
### Interactive Sessions (magenta)
|
123
|
+
|
124
|
+
IRT opens an interactive session when you manually add the 'irt' directive in an irt file,
|
125
|
+
or automatically, when an exception is raised or when a test has some diffs (fails).
|
126
|
+
|
127
|
+
The interactive session retains all the variables and the last returned value at the last evalued line,
|
128
|
+
so you have the possibility to play with your variables and methods, inspect, try and fix what you want,
|
129
|
+
and specially use the irt commands to manage your environment.
|
130
|
+
|
131
|
+
When you close an interactive session with 'exit' (or 'x' or 'q'), IRT will continue to run the file from the point
|
132
|
+
it left, retaining also the variables you eventually changed or added, passing back also the last value.
|
133
|
+
(In practice it's like everything happened in the session has happened in the file).
|
134
|
+
|
135
|
+
### Inspecting Sessions (black/white)
|
136
|
+
|
137
|
+
You can open an inspecting session with the command 'irt <obj>'.
|
138
|
+
The 'self' of the new session will be the <obj> itself, so you can inspect it as you would be in its definition class.
|
139
|
+
|
140
|
+
When you close the session with 'exit' (or 'x' or 'q'), IRT will not pass back anything from the inspecting session.
|
141
|
+
|
142
|
+
### Binding Sessions (yellow)
|
143
|
+
|
144
|
+
You can open a binding session from any file being evaluated with the directive 'irt binding'.
|
145
|
+
The 'self' of the new session will be the 'self' at the line you called it, so you can play with local variables
|
146
|
+
and methods as you would do it at that line.
|
147
|
+
|
148
|
+
If you use 'nano' or 'vi' in a binding session you will open the file that contains the 'irt binding'
|
149
|
+
call at that line: very handy to edit your code in place.
|
150
|
+
|
151
|
+
When you close the session with 'exit' (or 'x' or 'q'), IRT will not pass back anything from the binding session.
|
152
|
+
|
153
|
+
## Virtual Log
|
154
|
+
|
155
|
+
The Virtual Log is a special filtered-and-extended history of what has been executed at any given time.
|
156
|
+
It records ALL the lines executed from a file till that moment, and all the RELEVANT steps
|
157
|
+
you did in an interactive session (inspecting and binding sessions are ignored).
|
158
|
+
|
159
|
+
RELEVANT is anything that is changing something in the code you are executing (plus comments and blank lines
|
160
|
+
used for description and formatting).
|
161
|
+
|
162
|
+
### Filtered steps
|
163
|
+
|
164
|
+
If you are in an interactive session, make a typo and get an error,
|
165
|
+
that's not relevant for your code so the typo and the error doesn't get recorded in the log.
|
166
|
+
|
167
|
+
When you just inspect a variable, using p, pp, ap, puts, y, ... or use any irt command...
|
168
|
+
that are not relevant steps that you want to rerun the next time, so they don't get recorded in the log.
|
169
|
+
|
170
|
+
Also , if you are in an inspecting or binding session,
|
171
|
+
that stesps are not relevant for your tests, so they don't get recorded in the log.
|
172
|
+
|
173
|
+
### Log Management
|
174
|
+
|
175
|
+
You can type 'log' (or simply 'l') to have the tail of your log, or type 'full_log' (or simply 'll')
|
176
|
+
to see all the logged lines from the start.
|
177
|
+
|
178
|
+
The lines in the log are graphically grouped in differently colored hunks: cyan for file lines,
|
179
|
+
magenta for interactive session lines.
|
180
|
+
|
181
|
+
The log contains the reference line numbers of the steps: notice that for interactive sessions
|
182
|
+
they might not be continuous if some step has been filtered out. The numbers could also be repeated
|
183
|
+
if some step has generated more lines, like it might happen with 'add_test' (or 'tt').
|
184
|
+
|
185
|
+
You can copy and save your last steps in a file to rerun later. You can use 'print_lines'
|
186
|
+
(or 'pl') to print the last session lines without any added reference number, for easy copying,
|
187
|
+
or if your system supports it you can use 'copy_lines' (or 'cl') and have them right in the clipboard, ready to paste.
|
188
|
+
You can also do the same with all the session lines using 'print_all_lines' (or 'pll')
|
189
|
+
or copy them all 'copy_all_lines' (or 'cll').
|
190
|
+
|
191
|
+
That 'pl'-copy or 'cl' plus the 'vi' or 'nano' irt command (or the 'cnn' and 'cvi' commands)
|
192
|
+
are a very time saver combination. See the [IRT Tutorial](https://github.com/ddnexus/irt/raw/master/irt-tutorial.pdf "IRT Tutorial") for details.
|
193
|
+
|
194
|
+
## Testing
|
195
|
+
|
196
|
+
Unlike the traditional testing cycle, where you write your test before or after coding,
|
197
|
+
IRT writes the tests for you DURING the coding: you will have just to copy and paste them
|
198
|
+
into an irt file.
|
199
|
+
|
200
|
+
Adding a test is as easy as typing 'tt' (or 'add_test') in the console at any given time.
|
201
|
+
When you type 'tt' irt serializes the current (last) value returned by the last line of code,
|
202
|
+
and adds one test statement to your log. If you paste the log in the irt file,
|
203
|
+
you will have it executed the next time you will run the file.
|
204
|
+
|
205
|
+
Your tipical testing cycle with IRT is:
|
206
|
+
|
207
|
+
- write/change some code in your IDE
|
208
|
+
- run it with irt and check some value from your code
|
209
|
+
- add a test ('tt') whenever you want it
|
210
|
+
- copy the last log lines into the file and save
|
211
|
+
- rerun the modified test file ('rr')
|
212
|
+
|
213
|
+
When a test fails IRT shows you a very readable yaml dump with the differences between
|
214
|
+
the expected and actual values, so you can immediately find any little problem even inside
|
215
|
+
a very complex object.
|
216
|
+
|
217
|
+
Besides, when a test fails IRT can show you the tail of the running file, (use 'l' or configure
|
218
|
+
IRT.tail_on_irt = true for automatic tail) so you have an instant feedback about where the
|
219
|
+
failure comes from. It also opens an interactive session at that point with all
|
220
|
+
the variables loaded, so you can imediately and interactively try and fix what went wrong.
|
221
|
+
|
222
|
+
If you want to edit the running file, just type 'nano' or 'vi' without any argument and you will open
|
223
|
+
the file at the current line. Edit, save and exit from the editor, and you will continue your session
|
224
|
+
from the point you left. You can also 'rerun' the same file (or 'rr') when you need to reload the whole code.
|
225
|
+
|
226
|
+
## Editing Tools
|
227
|
+
|
228
|
+
### In Place Editing
|
229
|
+
|
230
|
+
You can open the current executed file at the current line by just typing 'nano' or 'vi'
|
231
|
+
and the editor with that name will be opened (in insert mode). Paste and/or edit and save what
|
232
|
+
you want and 'rerun' (or 'rr') the file to try/test the changes.
|
233
|
+
|
234
|
+
You can also open the current executed file in your preferred (GUI) editor with 'edit'.
|
235
|
+
If you don't like the default editor, you have just to set the IRT.edit_command_format in the ~/.irtrc file
|
236
|
+
(see "Configuration" below).
|
237
|
+
|
238
|
+
You will also find the info about how to automatically have your files syntax highlighted when opened in vi
|
239
|
+
or nano. See "Goodies" below.
|
240
|
+
|
241
|
+
### Copy-Open
|
242
|
+
|
243
|
+
You can combine the copy to clipboard feature, with the in place edit feature by using one of the
|
244
|
+
commands 'cnano', 'cvi' or 'cedit', so saving a lot of boring steps. It use the copy_to_clipboard
|
245
|
+
command from your system. see below.
|
246
|
+
|
247
|
+
### Copy to Clipboard Command
|
248
|
+
|
249
|
+
IRT provides a few commands that will use an external command of your system to copy the
|
250
|
+
last lines to the clipboard: 'copy_lines' (or 'cl'), 'cnano', 'cvi', 'cedit' use that command
|
251
|
+
avoiding you the boring task to select the output from the terminal and copy it.
|
252
|
+
|
253
|
+
It uses 'pbcopy' on MacOS (which should be already installed on any mac),
|
254
|
+
'xclip' on linux/unix (which you might need to install) and 'clip' on Windoze
|
255
|
+
(which is not supported on all WinOS flavours).
|
256
|
+
|
257
|
+
You can however set the IRT.copy_to_clipboard_command to any command capable of piping
|
258
|
+
the stdin to the clipboard.
|
259
|
+
|
260
|
+
### Note about CLI text editors
|
261
|
+
|
262
|
+
I have never been a big fan of CLI editors like vi or nano, but I really appreciate them
|
263
|
+
when combined with IRT. Having the file I need to edit, opened at the right line at the touch of a 2 letter
|
264
|
+
command ('nn' or 'vi') is really fast and powerful.
|
265
|
+
|
266
|
+
You have just to know a few very basic commands
|
267
|
+
like paste, save, quit, and eventually a couple of other, and you will save a lot of time and steps.
|
268
|
+
|
269
|
+
For those (like me) that are not used to CLI editors here's a quick reference for for paste save and quit,
|
270
|
+
(and some edit) that you have to use after a copy-open command from IRT (like 'cnn' or 'cvi'):
|
271
|
+
|
272
|
+
|
273
|
+
NANO
|
274
|
+
paste from clipboard with your usual OS command
|
275
|
+
quit Ctrl-X
|
276
|
+
type 'y'<enter> confirming that you want also to save
|
277
|
+
type 'n' confirming that you don't want to save
|
278
|
+
Editing
|
279
|
+
copy (line) Alt/Esc-6
|
280
|
+
cut (line) Ctrl-K
|
281
|
+
uncut (paste) Ctrl-U
|
282
|
+
|
283
|
+
VI-VIM
|
284
|
+
paste from clipboard with your usual OS command
|
285
|
+
quit Esc (return to command mode)
|
286
|
+
type ':wq'<enter> if you want to save and quit
|
287
|
+
type ':q!'<enter> if you want quit without save
|
288
|
+
|
289
|
+
Vi has different modes. You have to know at least how to switch mode:
|
290
|
+
to insert type 'i' when in command mode
|
291
|
+
to command type Esc when in insert mode
|
292
|
+
|
293
|
+
Editing
|
294
|
+
cut (line) [Esc (return to command mode)]
|
295
|
+
type 'dd' (or 'cc' that will return to insert mode)
|
296
|
+
paste (line) [Esc (return to command mode)]
|
297
|
+
type 'p'
|
298
|
+
|
299
|
+
## Inspecting Tools
|
300
|
+
|
301
|
+
### Call irt from your code
|
302
|
+
|
303
|
+
You can add 'irt binding' anywhere in your code and have irt opened interactively
|
304
|
+
to play with your variables and methods during execution (see Binding Sessions)
|
305
|
+
|
306
|
+
### Object diff
|
307
|
+
|
308
|
+
IRT can compare complex objects and shows the diffs. You can run 'vdiff obj_a, obj_b'
|
309
|
+
and have a nice and easy to check graphical diff report of the yaml dump of the 2 objects
|
310
|
+
|
311
|
+
### Kernel#capture
|
312
|
+
|
313
|
+
You can hijack the output of a block to a variable to inspect and test:
|
314
|
+
|
315
|
+
output = capture { some_statement_that_writes_to_stdout }
|
316
|
+
|
317
|
+
### Object#own_methods
|
318
|
+
|
319
|
+
Get the list of the methods implemented by the object itself (not inherited).
|
320
|
+
|
321
|
+
### Method#location
|
322
|
+
|
323
|
+
When possible, it returns an array with file and line where the method is located (defined).
|
324
|
+
It is suitable to be passed to any in place editing command to open the file at the line.
|
325
|
+
|
326
|
+
>> context.method(:prompt_i).location
|
327
|
+
=> ["./lib/irt/extensions/irb.rb", 111]
|
328
|
+
>> nn _ # will open the file at line 111 with nano
|
329
|
+
|
330
|
+
### Method#info
|
331
|
+
|
332
|
+
Returns an hash with the info of the method. It is suitable to be passed to any
|
333
|
+
in place editing command to open the file at the line.
|
334
|
+
|
335
|
+
>> context.method(:prompt_i).info
|
336
|
+
=> {:file=>"./lib/irt/extensions/irb.rb", :name=>"prompt_i", :line=>111, :arity=>-1, :class_name=>"IRB::Context"}
|
337
|
+
>> nn _ # will open the file at line 111 with nano
|
338
|
+
|
339
|
+
### Inspecting libs
|
340
|
+
|
341
|
+
'pp', 'yaml' (and 'ap' if installed) are loaded, so you can use 'pp', 'ap' and 'y' commands to have
|
342
|
+
a better looking inspection of your objects. Besides they are also enhanced a bit: when invoked
|
343
|
+
with no arguments, they use the last value (\_) as the default (e.g. just type 'y' instead 'y \_')
|
344
|
+
|
345
|
+
### In place inspecting/editing of backtraced files
|
346
|
+
|
347
|
+
When an error occurs, IRT shows you an indexed exception backtrace: each file:line in the backtrace
|
348
|
+
has an index number (in brackets) that you can use to open that file at that line with your preferred in-place editor.
|
349
|
+
|
350
|
+
You have just to type '<editor> <index>' (<editor> is one of 'vi', 'nano' (or 'nn') 'edit' (or 'ed'),
|
351
|
+
and <index> is the index number shown in the backtrace), and you will open it in insert mode. Example:
|
352
|
+
|
353
|
+
# backtraced line: from /Users/dd/dev/hobo3/hobo/lib/hobo/controller/model.rb:57:in `each' [3]
|
354
|
+
>> nn 3
|
355
|
+
|
356
|
+
Besides, if you copy a traceline from another source (which obviously does not have backtrace indexes)
|
357
|
+
like a user group or a rails application trace, just paste it as the argument of any editor command
|
358
|
+
(even if it is splitted over many lines like in the first example below) and IRT will open the file at
|
359
|
+
the wanted line. Example:
|
360
|
+
|
361
|
+
>> nn "from /opt/local/lib/ruby/site_r
|
362
|
+
"> uby/1.8/rubygems/custom_require.rb:31:in `gem_original_require'"
|
363
|
+
# or a rails trace line
|
364
|
+
>> nn "activesupport (3.0.3) lib/active_support/dependencies.rb:491:in `load_missing_constant'"
|
365
|
+
|
366
|
+
## General Tools
|
367
|
+
|
368
|
+
### Contextual ri doc with autocompletion
|
369
|
+
|
370
|
+
IRT offers the 'ri' command, implemented with fastri so you should have it installed.
|
371
|
+
It uses 'qri' by default but you can change the IRT.ri_command_format if you prefer to use 'fri'.
|
372
|
+
|
373
|
+
In its basic form the 'ri' command can accept a string as the system ri command does (you can even omit the quotes).
|
374
|
+
|
375
|
+
>> ri reverse
|
376
|
+
------------------------------------------------------ Multiple choices:
|
377
|
+
|
378
|
+
1 ActiveSupport::Multibyte::Chars#reverse
|
379
|
+
2 Array#reverse
|
380
|
+
3 IPAddr#reverse
|
381
|
+
4 String#reverse
|
382
|
+
|
383
|
+
>> ri 4
|
384
|
+
--------------------------------------------------------- String#reverse
|
385
|
+
str.reverse => new_str
|
386
|
+
------------------------------------------------------------------------
|
387
|
+
Returns a new string with the characters from str in reverse order.
|
388
|
+
|
389
|
+
"stressed".reverse #=> "desserts"
|
390
|
+
|
391
|
+
But unlike the system command, when the search results in multiple choices, you can just type the
|
392
|
+
index of the choice and get the doc you want with less typing. The shortcuts in the list will work
|
393
|
+
until you use another command but 'ri'
|
394
|
+
|
395
|
+
Besides it offers a very useful contextual search, that will find the ri doc of the specific method used by the receiver.
|
396
|
+
Example:
|
397
|
+
|
398
|
+
# autocompletion
|
399
|
+
>> ri "any string".eq[TAB]
|
400
|
+
.eql? .equal?
|
401
|
+
|
402
|
+
>> ri "a string".eql?
|
403
|
+
------------------------------------------------------------ String#eql?
|
404
|
+
str.eql?(other) => true or false
|
405
|
+
------------------------------------------------------------------------
|
406
|
+
Two strings are equal if the have the same length and content.
|
407
|
+
|
408
|
+
>> ri [].eql?
|
409
|
+
------------------------------------------------------------- Array#eql?
|
410
|
+
array.eql?(other) -> true or false
|
411
|
+
------------------------------------------------------------------------
|
412
|
+
Returns true if array and other are the same object, or are both
|
413
|
+
arrays with the same content.
|
414
|
+
|
415
|
+
### IRT Help
|
416
|
+
|
417
|
+
The IRT Commands are the methods that you can call from any IRT console session, while the Directives are
|
418
|
+
the methods that you can call from any file. Type 'irt_help' in any IRT session to have the complete list.
|
419
|
+
|
420
|
+
### Status line
|
421
|
+
|
422
|
+
The status line shows the nesting status of your sessions: each time you open a new
|
423
|
+
session or exit from the current session it is automatically printed.
|
424
|
+
You can also print it with 'status' (or 'ss') at any time.
|
425
|
+
|
426
|
+
### System Shortcuts
|
427
|
+
|
428
|
+
Save some typing for common system calls like ls, cat, vi, nano
|
429
|
+
|
430
|
+
### FileUtils
|
431
|
+
|
432
|
+
All the FileUtils methods are included as commands: just call them in the session
|
433
|
+
and they will ignored by the log; if they are part of your testing, use them as usual
|
434
|
+
|
435
|
+
>> rm_rf 'dir/to/remove' # ignored because it's an irt command
|
436
|
+
>> FileUtils.rm_rf 'dir/to/remove' # logged because it's a regular statement
|
437
|
+
|
438
|
+
Notice: The FileUtils commands (unlike the other IRT commands) do echo their result,
|
439
|
+
although they don't set the last value \_ (like any other IRT command). In order to distinguish
|
440
|
+
that behaviour from a regular setting statement, their result is printed in yellow instead than in green.
|
441
|
+
and the prompt is '#>' instead '=>'. Example:
|
442
|
+
|
443
|
+
>> a = 5
|
444
|
+
=> 5
|
445
|
+
>> pwd
|
446
|
+
#> "/Users/dd/dev/irt" # yellow ignored and non setting _
|
447
|
+
>> _
|
448
|
+
=> 5
|
449
|
+
>> FileUtils.pwd
|
450
|
+
=> "/Users/dd/dev/irt" # green logged and setting _
|
451
|
+
>> _
|
452
|
+
=> "/Users/dd/dev/irt"
|
453
|
+
|
454
|
+
### File insert/eval
|
455
|
+
|
456
|
+
You can split your tests and reuse them in other files as you whould do with 'partials' template files.
|
457
|
+
Use "insert_file 'file/path'" to insert a file into another. It will be evaluated by IRT as
|
458
|
+
it were written right in the including file itself. Take that into account with variables and last_values.
|
459
|
+
Besides, you should NOT suffix them with '.irt', so they will get ignored by the irt executable scanning the dirs.
|
460
|
+
|
461
|
+
### Code completion and irb-history
|
462
|
+
|
463
|
+
Code completion and irb-history are enabled by default (just use the tab and up and down arrows even between sessions)
|
464
|
+
|
465
|
+
### Syntax Highlight
|
466
|
+
|
467
|
+
In the [goodies dir](https://github.com/ddnexus/irt/tree/master/goodies?raw=true) you can find
|
468
|
+
a few info about how to use syntax highlight for .irt files in nano and vi, along with a complete 'irt.nanorc' file.
|
469
|
+
|
470
|
+
## Configuration
|
471
|
+
|
472
|
+
IRT tries to load a ~/.irtrc file at startup, so you can customize a few options.
|
473
|
+
|
474
|
+
If you want to add your custom '~/.irbrc' file, try to load it at the top: if it doesn't
|
475
|
+
play well with IRT, then copy and paste just part of it.
|
476
|
+
|
477
|
+
You can also change a few configuration options in the ~/.irtrc file. The following are the defaults
|
478
|
+
which should work quite well without any change:
|
479
|
+
|
480
|
+
# set this to true if your prompt get messed up when you use the history
|
481
|
+
# IRT.fix_readline_prompt = false
|
482
|
+
|
483
|
+
# will open an interactie session if a test has diffs
|
484
|
+
# IRT.irt_on_diffs = true
|
485
|
+
|
486
|
+
# will print the log tail when an interactive session is opened
|
487
|
+
# IRT.tail_on_irt = false
|
488
|
+
|
489
|
+
# the lines you want to be printed as the tail
|
490
|
+
# IRT.log.tail_size = 10
|
491
|
+
|
492
|
+
# loads irt_helper.rb files automatically
|
493
|
+
# IRT.autoload_helper_files = true
|
494
|
+
|
495
|
+
# force true/false regardless the terminal ANSI support
|
496
|
+
# IRT.force_color = true
|
497
|
+
|
498
|
+
# the command to pipe to the copied lines that should set the clipboard
|
499
|
+
# default to 'pbcopy' on mac, 'xclip -selection c' on linux/unix and 'clip' on windoze
|
500
|
+
# IRT.copy_to_clipboard_command = 'your command'
|
501
|
+
|
502
|
+
# the format to build the command to launch nano
|
503
|
+
# IRT.nano_command_format = 'nano +%2$d %1$s'
|
504
|
+
|
505
|
+
# the format to build the command to launch vi
|
506
|
+
# IRT.vi_command_format ="vi -c 'startinsert' %1$s +%2$d"
|
507
|
+
|
508
|
+
# the format to build the command to launch the ri tool
|
509
|
+
# IRT.ri_command_format = "qri -f #{Colorer.color? ? 'ansi' : 'plain'} %s"
|
510
|
+
|
511
|
+
# add your command format if you want to use another editor than nano or vi
|
512
|
+
# default 'open -t %1$s' on MacOX; 'kde-open %1$s' or 'gnome-open %1$s' un unix/linux; '%1$s' on windoze
|
513
|
+
# IRT.edit_command_format ="your_preferred_GUI_editor %1$s +%2$d"
|
514
|
+
|
515
|
+
# any log-ignored-echo command you want to add
|
516
|
+
# IRT.log.ignored_echo_commands << %w[commandA commandB ...]
|
517
|
+
|
518
|
+
# any log-ignored command you want to add (includes all the log-ignored-echo commands)
|
519
|
+
# IRT.log.ignored_commands << %w[commandC commandD ...]
|
520
|
+
|
521
|
+
# any command that will not set the last value (includes all the log-ignored commands)
|
522
|
+
# IRT.log.non_setting_commands << %w[commandE commandF ...]
|
523
|
+
|
524
|
+
### Colors
|
525
|
+
|
526
|
+
The default color styles of IRT should be OK in most situation, anyway, if you really don't like the colors,
|
527
|
+
you can switch off the color completely (IRT.force_color = false) or you can also
|
528
|
+
redefine the colors by redefining them in your .irtrc file.
|
529
|
+
|
530
|
+
The following are the default Colorer styles, change them at will:
|
531
|
+
|
532
|
+
Colorer.def_custom_styles({ :bold => :bold,
|
533
|
+
:reversed => :reversed,
|
534
|
+
:null => :clear,
|
535
|
+
|
536
|
+
:log_color => :blue,
|
537
|
+
:file_color => :cyan,
|
538
|
+
:interactive_color => :magenta,
|
539
|
+
:inspect_color => :clear,
|
540
|
+
:binding_color => :yellow,
|
541
|
+
:actual_color => :green,
|
542
|
+
:ignored_color => :yellow,
|
543
|
+
|
544
|
+
:error_color => :red,
|
545
|
+
:ok_color => :green,
|
546
|
+
:diff_color => :yellow,
|
547
|
+
:diff_a_color => :cyan,
|
548
|
+
:diff_b_color => :green } , true)
|
549
|
+
|
550
|
+
### Note about IRT.autoload_helper_files
|
551
|
+
|
552
|
+
When autoload_helper_files is true (default) IRT will require all the 'irt_helper.rb' named files in
|
553
|
+
the descending path fom the current working dir (which is considered the test-root dir) to the dir containing
|
554
|
+
the irt file being executed. That is useful to add special methods or overriding to your test files without
|
555
|
+
worring about requiring them from your test files.
|
556
|
+
|
557
|
+
For example:
|
558
|
+
|
559
|
+
working_dir
|
560
|
+
irt_helper.rb #1
|
561
|
+
first_level
|
562
|
+
irt_helper.rb #2
|
563
|
+
testA.irt
|
564
|
+
testB.irt
|
565
|
+
second_level
|
566
|
+
irt_helper.rb #3
|
567
|
+
test1.irt
|
568
|
+
test2.irt
|
569
|
+
|
570
|
+
If you are running test1.irt and test2.irt from the working_dir IRT will automatically require the
|
571
|
+
irt_helper.rb #1, #2 and #3. If you are running the testA.irt and testB.irt, IRT will automatically
|
572
|
+
require the irt_helper.rb #1, #2. But if you run the same from the first_level dir, the irt_helper.rb #1
|
573
|
+
will not be loaded, so be careful to be in the right dir to make it work properly.
|
574
|
+
|
575
|
+
### Rails 3
|
576
|
+
|
577
|
+
You must add the gem to your Gemfile, to make the bundler happy:
|
578
|
+
|
579
|
+
gem 'irt', :group => :console
|
580
|
+
|
581
|
+
## Known Issue
|
582
|
+
|
583
|
+
IRT use yaml serialization, and inherits its limits (e.g.: Yaml cannot dump anonymous classes, MatchData, oject that contains binding, etc.)
|
584
|
+
so if you stumble upon on one of them, you have just to test the subparts of the object that you cannot dump. For example, instead of testing one whole anonymous
|
585
|
+
class, (which is however a bad idea) you can add tests for the values returned by its methods or variables.
|
586
|
+
|
587
|
+
## Copyright
|
588
|
+
|
589
|
+
Copyright (c) 2010-2011 Domizio Demichelis. See LICENSE for details.
|