Currently in my code when I want to create a pathname object and create a path at the same time I must use tap
```
path = Pathname.new("/tmp/new").tap(&:mkpath)
```
I think it would be cleaner to be able to chain on the results of these methods instead:
```
path = Pathname.new("/tmp/new").mkpath
```
When I want to create a tmpdir I often want to manipulate it as a pathname. By introducing Pathname.mktmpdir I can get this behavior.
Currently I must:
```ruby
Dir.mktmpdir do |dir|
dir = Pathname(dir)
# ... code
end
```
I would like to be able to instead:
```ruby
Pathname.mktmpdir do |dir|
# ... code
end
```
Rather than checking the class we can check the type.
This is very subtly different for String subclasses, but I think it's
OK.
We also save on checking the type again in the fast path.
772a0201ab
On my `JSON.dump` benchmark it shows up as 6% of runtime, compared
to 40% for `convert_UTF8_to_JSON`.
Since the vast majority of the time this function is called we
still have some buffer capacity, we might as well check that
first and skip the expensive loop etc.
With this change my profiler now report this function as 0.7%,
so almost 10x better.
a7206bf2db
Given that we called `rb_enc_str_asciionly_p`, if the string encoding
isn't valid UTF-8, we can't know it very cheaply by checking the
encoding and coderange that was just computed by Ruby, rather than
to do it ourselves.
Also Ruby might have already computed that earlier.
4b04c469d5
The values of `@@map` are `Symbol`s and `@value` should be an
`Integer` since unpacked as unsigned long, so this comparison should
be false always. Probably comparison with `Symbol` was intended.
The allocated parser string is never freed, which causes a memory leak.
The following code leaks memory:
Ripper.sexp_raw(DATA.read)
__END__
<<~EOF
a
#{1}
a
EOF
There are some codepages like cp708 for which no ruby encoding exists:
$ ruby -e "Encoding.find('cp708')"
Traceback (most recent call last):
1: from -e:1:in `<main>'
-e:1:in `find': unknown encoding name - cp708 (ArgumentError)
win32/registry uses ENCODING to transcode error messages and expand environment
variables from UTF-16LE, so using UTF-8 seems like the best choice and is better
than a hard failure.
This should resolve [Bug #13831]
This change is reduce Ruby C API dependency for Universal Parser.
Reuse dedent_string functions in rb_ruby_ripper_dedent_string functions and remove dependencies on rb_str_modify and rb_str_set_len from the parser.
(https://github.com/ruby/strscan/pull/106)
It supports non-head match cases such as StringScanner#scan_until.
If we use a String as a pattern, we can improve match performance.
Here is a result of the including benchmark.
## CRuby
It shows String as a pattern is 1.18x faster than Regexp as a pattern.
```
$ benchmark-driver benchmark/check_until.yaml
Warming up --------------------------------------
regexp 9.403M i/s - 9.548M times in 1.015459s (106.35ns/i)
regexp_var 9.162M i/s - 9.248M times in 1.009479s (109.15ns/i)
string 8.966M i/s - 9.274M times in 1.034343s (111.54ns/i)
string_var 11.051M i/s - 11.190M times in 1.012538s (90.49ns/i)
Calculating -------------------------------------
regexp 10.319M i/s - 28.209M times in 2.733707s (96.91ns/i)
regexp_var 10.032M i/s - 27.485M times in 2.739807s (99.68ns/i)
string 9.681M i/s - 26.897M times in 2.778397s (103.30ns/i)
string_var 12.162M i/s - 33.154M times in 2.726046s (82.22ns/i)
Comparison:
string_var: 12161920.6 i/s
regexp: 10318949.7 i/s - 1.18x slower
regexp_var: 10031617.6 i/s - 1.21x slower
string: 9680843.7 i/s - 1.26x slower
```
## JRuby
It shows String as a pattern is 2.11x faster than Regexp as a pattern.
```
$ benchmark-driver benchmark/check_until.yaml
Warming up --------------------------------------
regexp 7.591M i/s - 7.544M times in 0.993780s (131.74ns/i)
regexp_var 6.143M i/s - 6.125M times in 0.997038s (162.77ns/i)
string 14.135M i/s - 14.079M times in 0.996067s (70.75ns/i)
string_var 14.079M i/s - 14.057M times in 0.998420s (71.03ns/i)
Calculating -------------------------------------
regexp 9.409M i/s - 22.773M times in 2.420268s (106.28ns/i)
regexp_var 10.116M i/s - 18.430M times in 1.821820s (98.85ns/i)
string 21.389M i/s - 42.404M times in 1.982519s (46.75ns/i)
string_var 20.897M i/s - 42.237M times in 2.021187s (47.85ns/i)
Comparison:
string: 21389191.1 i/s
string_var: 20897327.5 i/s - 1.02x slower
regexp_var: 10116464.7 i/s - 2.11x slower
regexp: 9409222.3 i/s - 2.27x slower
```
See:
be7815ec02/core/src/main/java/org/jruby/util/StringSupport.java (L1706-L1736)
---------
f9d96c446a
Co-authored-by: Sutou Kouhei <kou@clear-code.com>
A string similar to "0x____" should be treated as a string.
Currently it is processed as an Integer.
This alters the regex specified by http://yaml.org/type/int.html
to ensure at least one numerical symbol is present in the string
before converting to Integer.
81479b203e
delete_prefix with a string is easier to read than a regular expression
also it should be faster. It is available since ruby 2.5 and the gem requires
ruby 2.7.
0070f43f19
[Feature #20590]
For better of for worse, fork(2) remain the primary provider of
parallelism in Ruby programs. Even though it's frowned uppon in
many circles, and a lot of literature will simply state that only
async-signal safe APIs are safe to use after `fork()`, in practice
most APIs work well as long as you are careful about not forking
while another thread is holding a pthread mutex.
One of the APIs that is known cause fork safety issues is `getaddrinfo`.
If you fork while another thread is inside `getaddrinfo`, a mutex
may be left locked in the child, with no way to unlock it.
I think we could reduce the impact of these problem by preventing
in for the most notorious and common cases, by locking around
`fork(2)` and known unsafe APIs with a read-write lock.
getlogin is only called if USER environment variable is not set,
but if getlogin returns NULL in that case, then do not call
getpwnam, and assume /bin/sh as shell.
Mentioned in comment to bug 20586.
This test is checking what happens if you try and define a class in a C
extension where that constant is already not a class. It was doing this
by overriding ::Date and then trying to require 'date. The issue with
this is that if we ever add 'date' as a dependency for the test runner,
this test will break because the test runner files get implicitly
required in an `assert_separately` block.
Better use an explicit class for this purpose which can't be accidentally
required elsewhere.
RUBY_TYPED_DEFAULT_FREE will only free the rand_loop_t, but it will cause
the buf to be leaked. This commit fixes the memory leak by implementing
a free function for the rand_loop_t type.
When an exception is raised, it can leak memory in `head`. There are two
places that can leak memory:
1. `Check_Type(tuple, T_ARRAY)` can leak memory if `tuple` is not an
array.
2. `StringValue(name)` and `StringValue(value)` if they are not strings
and the call to `to_str` does not return a string.
This commit fixes these memory leaks by wrapping the code around a
rb_ensure so that the memory is freed in all cases.
The following code demonstrates the memory leak:
emitter = Psych::Emitter.new(StringIO.new)
nil_to_string_tags = [[nil, "tag:TALOS"]] + ([1] * 1000)
expected_array_tags = [1] * 1000
10.times do
1_000.times do
# Raises `no implicit conversion of nil into String`
emitter.start_document([], nil_to_string_tags, 0)
rescue TypeError
end
1_000.times do
# Raises `wrong argument type Integer (expected Array)`
emitter.start_document([], expected_array_tags, 0)
rescue TypeError
end
puts `ps -o rss= -p #{$$}`
end
Before:
47248
79728
111968
144224
176480
208896
241104
273280
305472
337664
After:
14832
15088
15344
15344
15360
15632
15632
15632
15648
15648
053af73818
These files were to build libffi from the bundled source, but are no
longer used since we stopped bundling the libffi sources in commit
e4f5296f06.
The gemspec file is unchanged because fiddle gem itself still supports
ruby 2.5.
