| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves on https://github.com/pry/pry/pull/1813.
I spotted a problem with the way it works: sometimes, if you enter an empty
line, the output would span across two lines:
```
[1] pry(main)>
[2] pry(main)>
[3] pry(main)>
```
This is because overhang is bigger than the current line. I also noticed a bug
with method definition, where defining a method leaves an unwanted empty line:
```
[3] pry(main)> def foo
| end
=> :foo
```
To fix this I changed the way we calculate overhang. First and the most
important change is that I stopped calculating overhang for emacs mode. This is
because it's too risky to introduce this change because it's the default mode
and 99% of our users use this, so there's no need to change this
behaviour. Another reason is that emacs mode users typically don't use any mode
indicators (because emacs has no modes), so it strikes me as a more pragmatic
solution.
With Vi mode we calculate overhang and still support custom indicators.
|
|\
| |
| | |
rubocop: fix offences of the Lint/AssignmentInCondition cop
|
|/ |
|
|\
| |
| | |
ring: rewrite the class to improve API
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, the Ring class is written with help of Hash as backend store.
According to the comments, the implementation should behave like a circular
buffer, however it doesn't. Upon reaching maximum capacity Ring doesn't replace
old elements but keeps writing to new cells, deleting old cells, so that the
hash contains `nil` entries.
The new implementation is based on Array and seems to be closer to the actual
Ring. Older elemens get overwritten with newer ones.
This class also includes Enumerable, however none of our APIs take advantage of
it, so it seems like an overkill. There was also a problem with with this API
because of the above-mentioned nils. For example, if the ring exceeds its
maximum size, then callin `Enumerable#first` on it returns `nil`.
The new implementation deals with this with removal of Enumerable. The `#[]`
syntax is preserved, and now `ring[0]` returns an actual element instead of
`nil`. In case users need the Enumerable functionality, they can call
`Ring#to_a` to build the array, which supports the wanted methods.
As for the speed, the new implementation is:
* slower overall because it's thread-safe
* faster without mutexes for `#<<`
* slower without mutexes for `#[]`
Benchmark for old implementation:
```
Warming up --------------------------------------
Ring#<< 223.451k i/100ms
Ring#[] 2.837k i/100ms
Calculating -------------------------------------
Ring#<< 223.157B (± 3.4%) i/s - 778.097B
Ring#[] 82.485M (± 9.4%) i/s - 402.602M in 4.957792s
```
Benchmark for this implementation:
```
Warming up --------------------------------------
Ring#<< 211.587k i/100ms
Ring#[] 1.974k i/100ms
Calculating -------------------------------------
Ring#<< 211.385B (± 2.8%) i/s - 698.439B
Ring#[] 40.292M (±17.0%) i/s - 190.069M in 4.971195s
```
The benchmark:
```rb
require './lib/pry'
require 'benchmark/ips'
Benchmark.ips do |x|
empty_ring = Pry::Ring.new(100)
populated_ring = Pry::Ring.new(100)
150.times { |i| populated_ring << i }
x.report("Ring#<<") do |times|
empty_ring << times
end
x.report("Ring#[]") do |times|
populated_ring[0]
populated_ring[1]
populated_ring[2]
populated_ring[-1]
populated_ring[-2]
populated_ring[-3]
populated_ring[1..2]
populated_ring[-2..-1]
populated_ring[-2..3]
populated_ring[0..-1]
populated_ring[2..-1]
populated_ring[-1..10]
populated_ring[-1..0]
populated_ring[-1..1]
end
end
```
|
|
|
|
|
|
|
|
|
|
|
|
| |
I need to add `.ackrc` to help me filter garbage when I search for a string and
get results from built YARD documentation. I don't want to commit the file
itself because not everybody uses ack.
In case you are curious, this is my `.ackrc`:
```
--ignore-dir=doc
```
|
|
|
| |
Fixes #1812
|
|\
| |
| | |
pry_instance: deprecate '#output_array' & '#input_array'
|
|/
|
|
| |
I figured it's better to deprecate them to let plugin authors update their API.
|
|\
| |
| | |
Rename HistoryArray to Ring
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
| |
`HistoryArray` is a very specific name and it doesn't tell the reader what
it *really* means unless you read its code or the docs of the class.
On the other hand, `Ring` is a [very well-known term][1], which means exactly
what `HistoryArray` does. The alias name for it is circular buffer. I chose
`Ring` because it is shorter and used by Golang, so I expect programmers to
be familiar with `Ring`.
[1]: https://en.wikipedia.org/wiki/Circular_buffer
|
|\
| |
| | |
rubocop: disable the Style/NumericPredicate cop
|
|/
|
|
| |
This is very opinionated and not necessary to follow.
|
|\
| |
| | |
rubocop: fix offences of the Style/MultilineTernaryOperator cop
|
|/ |
|
|\
| |
| | |
core_extensions: make '__binding__' work with redefined #respond_to?
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes https://github.com/pry/pry/issues/1596
(Unable to inspect object built from class)
Replaces https://github.com/pry/pry/pull/1719
Big thanks to @egwspiti for the repro case and the proposed PR.
When a class redefines `respond_to?` or `method_missing` this leads to some
problems and confuses Pry. I found another example where Pry misbehaves:
```
[1] pry(main)> cd Class.new { def method_missing(*) end; def respond_to_missing?(*) true end; }.new
NoMethodError: private method `eval' called for nil:NilClass
from /Users/kyrylo/.gem/ruby/2.4.2/gems/pry-0.11.3/lib/pry/pry_instance.rb:163:in `inject_local'
```
By using `method_defined?` we can work around these bugs since this method
doesn't check whether the receiver responds to a certain message but checks
whether this method is defined (so we don't redefine it later). Seems like a
win-win.
|
|\
| |
| | |
circle: add Dockerfiles for custom Rubies
|
|/
|
|
|
|
|
|
|
| |
CircleCI doesn't provide images for these Rubies since they are no onger
suported. I had to build them manually and push to dockerhub so we can continue
testing using those Rubies.
I am committing these Dockerfiles since they belong to this project and in case
we need to modify them.
|
|\
| |
| | |
ommands/ls/formatter,helpers/table: pass local Pry config
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replaces #1713
(Pry local config The following methods take a third required argument, an
instance of Pry)
This fulfills queries to `_pry_.config` in:
* Pry::Helpers.tablify
* Pry::Helpers.tablify_to_screen_width
* Pry::Helpers.tablify_or_one_line
Unlike #1713 this PR doesn't introduce any breaking changes thanks to the
default parameter value trick, *except* the `Table#new` signature.
Overall, this brings the code in line with how the rest of Pry works.
|
|\
| |
| |
| |
| | |
pry/rubocop-lint-string-conversion-in-interpolation
rubocop: fix offences of the Lint/StringConversionInInterpolation
|
|/ |
|
|\
| |
| | |
rubocop: fix offences of the Lint/UnneededRequireStatement cop
|
|/ |
|
|\
| |
| | |
rubocop: fix offences of the Lint/AmbiguousBlockAssociation cop
|
|/ |
|
|\
| |
| | |
Stop building on TravisCI
|
| | |
|
|/
|
|
|
|
|
|
| |
TravisCI was a good companion in the early days but nowadays it loses in terms
of speed against CircleCI. CircleCI support was added in
https://github.com/pry/pry/pull/1802.
With this change we no longer build on Travis and use Circle from now on.
|
|\
| |
| | |
Test with help of CircleCI
|
| |
| |
| |
| | |
Otherwise, some tests fail.
|
| |
| |
| |
| |
| | |
The presense of supported text editor is required to make the test suite
pass. Specifically, the editor tests.
|
| |
| |
| |
| |
| |
| |
| |
| | |
`rb-inotify` has a dependency on `ffi`, which fails to compile on Ruby 1.9.3
while running on CircleCI. I don't think anyone who develops Pry (seems to be
just me so far) uses Guard in their worfklow. Our repo is missing an obligatory
Guardfile, too, which makes me think it's a very safe change to make (rather
than wasting time with`ffi` and CircleCI).
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
CircleCI provides much faster builds than TravisCI:
CircleCI - less than 1 minute
TravisCI- 6 minutes
The cost is the complexity of the config:
https://circleci.com/docs/2.0/configuration-reference/
|
|\ \
| |/
|/| |
Fix rubocop empty line after guard clause style violations
|
|/ |
|
|\
| |
| | |
rubocop: fix offences of the Lint/UnusedMethodArgument cop
|
| | |
|
| |
| |
| |
| |
| | |
This was added by 97f1be86b29e41e0a786cf0177d934c4c22e8572 and it feels like a
mishap, thus removing.
|
| |
| |
| |
| |
| |
| | |
b031df2f2f5850ee6e9018f33d35f3485a9b0423 added this command but never made use
of this variable. The method is being passed an argument but it never uses
it. Why? Idk, needs investigation.
|
| |
| |
| |
| |
| | |
This command is quite obscure: no docs and the parameter it expects is not used
in the method. For simplicity, I am leaving the comment to check later.
|
| |
| |
| |
| |
| |
| | |
The way it's written is still a little bit confusing, however for simplicity of
https://github.com/pry/pry/pull/1801 I am leaving this as is and resolving the
parameter issue only.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This was added by 6fd797d302a63f29d10cf5834bfa25cec7f1ac74.
I inspected it closely and I cannot seem to find the reason for this
parameter. I don't see it being used anywhere and it doesn't seem to do what it
declares. Therefore, I am deleting it.
|
|/ |
|
|\
| |
| | |
rubocop: fix offences of the Layout/EmptyLineBetweenDefs cop
|
|/ |
|
|\
| |
| | |
rubocop: fix offences of the Style/HashSyntax cop
|
|/ |
|